whitequark changed the topic of #amaranth-lang to: Amaranth hardware definition language · weekly meetings on Mondays at 1700 UTC · code https://github.com/amaranth-lang · logs https://libera.irclog.whitequark.org/amaranth-lang
lf has quit [Ping timeout: 248 seconds]
lf has joined #amaranth-lang
<d1b2> <VA3TEC-Mikek-14362> I do have some questions tho..
<d1b2> <VA3TEC-Mikek-14362> but so far, it's comments in the limesdr-mini-v2.py file.
bl0x_ has joined #amaranth-lang
bl0x has quit [Ping timeout: 248 seconds]
bl0x has joined #amaranth-lang
bl0x_ has quit [Ping timeout: 255 seconds]
Degi_ has joined #amaranth-lang
Degi has quit [Ping timeout: 268 seconds]
Degi_ is now known as Degi
<_whitenotifier-9> [rfcs] tilk commented on pull request #11: Minimal type annotation support - https://github.com/amaranth-lang/rfcs/pull/11#issuecomment-1456035802
other_ash has quit [Quit: Client closed]
Raito_Bezarius has quit [Remote host closed the connection]
<_whitenotifier-9> [rfcs] whitequark commented on pull request #11: Minimal type annotation support - https://github.com/amaranth-lang/rfcs/pull/11#issuecomment-1456049137
<_whitenotifier-9> [rfcs] whitequark synchronize pull request #7: Const-castable Amaranth value to Python value conversions - https://github.com/amaranth-lang/rfcs/pull/7
<_whitenotifier-9> [rfcs] whitequark synchronize pull request #7: Const-castable Amaranth value to Python value conversions - https://github.com/amaranth-lang/rfcs/pull/7
<cr1901> I feel silly asking this, but... no meeting today?
whitequark_ has joined #amaranth-lang
<whitequark_> cr1901: the libera bridge is down, it seems
<whitequark_> I was wondering why no one is attending
<whitequark_> okay, irc->matrix works, but matrix->irc does not
<whitequark_> let's take a roll call. cr1901? vup? adamgreig? crzwdjk? anuejn? nelgau?
<whitequark_> agg ^
<whitequark_> jfng is participating from the other side of the bridge, I can copy his messages or he can join through web.libera.chat
<agg> ah, I see, matrix->irc isn't going through
<cr1901> I'm here
jfng_ has joined #amaranth-lang
<agg> but irc->matrix is, weird
<cr1901> Probably time to poke a Libera mod again
<whitequark_> I have no idea what's going on. I'm unhappy with how unreliable it is, we might have to move to Zulip eventually or something
<agg> the heisenbridge irc<->matrix bridge I run for rust-embedded has been reliable lately, but is a bit annoying for irc users as it works like d1b2 does
<agg> anyway sorry, where did we get to on RFCs?
<whitequark_> good afternoon everyone, it is time for our regular Monday meeting
<whitequark_> we will probably not get through everything in time. I will start with the least controversial items
<whitequark_> please respond with your comments and proposed disposition: close or merge
<agg> merge on rfc10
<agg> i have used Repl once ever and would have been happier with .replicate in that instance anyway
<cr1901> I've used it, but merge anyway. I'm fine w/ my code breaking
<whitequark_> we can keep the deprecation for that one until 1.0 or something
<whitequark_> it's low cost
<whitequark_> or I guess maybe not, I'd like to kick it out of the prelude
<cr1901> Kick it out
<whitequark_> btw, Chips4Makers isn't participating, he is busy with something
<whitequark_> outcome on RFC 10: merge
<whitequark_> please respond with your comments and proposed disposition: close or merge
<agg> I like the result and haven't thought in depth about the implementation details but seems fine, merge
whitequark_ has quit [Quit: Client closed]
whitequark_ has joined #amaranth-lang
<whitequark_> combined with RFC 8 we get a situation where ShapeCastables are effectively required (for interop with data.View) to implement __call__ which wraps a value-castable and returns an instance of the shape-castable
<whitequark_> if we merge RFC 8 + RFC 9 as it is, then __call__ always takes a value-castable and returns whatever (but realistically an instance of the shape-castable), and .const takes whatever (but realistically a literal of some sort) and returns a Const
<whitequark_> this seemed preferable than one superpolymorphic __call__ that takes whatever and returns whatever, but specific things in specific cases
<whitequark_> but one could also see the superpolymorphic __call__ to be implementing casting as a concept
<cr1901> >The reset= argument becomes dependently typed. <-- what does this mean?
<whitequark_> right now the type of reset is just int, but with this change, if you tried to write the type for Signal, it would become something like `Signal : forall T: ShapeCastable. T -> reset=T::ConstCastableFrom -> Signal`
<whitequark_> you know GATs in Rust? it's that
<whitequark_> I would expect no Python type system to be able to handle that
<agg> at least you could just say the type is "integer or const-castable"?
<whitequark_> well {"foo": 1} is not const-castable in general, you can't `Const.cast({"foo": 1})`
<whitequark_> that's what I mean when I say it's dependently typed
<jfng_> will this break existing code that define ShapeCastables ?
<whitequark_> is there existing code? ShapeCastable hasn't been in a release yet
<cr1901> I don't see the GAT comparison, but I can ask about that after the meeting. It doesn't _sound_ like a huge cognitive burden
<cr1901> for Amaranth users*
<jfng_> i haven't used it yet, indeed
<whitequark_> oh wait it's not GAT, it's just associated types
<whitequark_> I completely misremembered what GATs were, sorry
<cr1901> AFAIR, GAT is "generic on LHS of associate type decl"
<whitequark_> yeah I was just wrong
<cr1901> Well, I don't think it's a huge cognitive burden to make reset dependently-typed
<agg> for users it seems like "it will just do the thing you expect", it seems
<whitequark_> since these are related, I will also put up RFC 8: Aggregate data structure extensibility https://github.com/amaranth-lang/rfcs/pull/8 https://github.com/whitequark/amaranth-rfcs/blob/aggregate-extensibility/text/0000-aggregate-extensibility.md
<agg> "reset is whatever type you need to initialise the signal"
<whitequark_> agg: yeah, that's the idea
<agg> I'm also +1 on rfc8
<cr1901> I'm still going thru RFC 8, merge RFC9
<cr1901> > or the result of the previous call to as_shape() <-- should this be "call as_shape().shape.as_shape()"?
<whitequark_> no, it's field.as_shape().as_shape().as_shape()... until it returns Shape
<cr1901> ahhh okay
<cr1901> (well field.shape.as_shape().as_shape()*)
<cr1901> Anyways, merge rfc8
<jfng_> merge 8+9
<whitequark_> okay, decision on RFC 8 and RFC 9: merge both
<whitequark_> I want to emphasize that `f: unsigned(8)` is not a valid Python type hint and AFAIK cannot be made a valid Python type (without a typechecker plugin, or possibly at all); it's considered syntactically invalid. `f: Value[unsigned(8)]` is also considered syntactically invalid for typechecking, *but* pyright/pylance accept it enough to autocomplete
<whitequark_> f.<cursor> to the various Value methods
<whitequark_> both of these show `f` in the autocomplete list for the struct
<whitequark_> so as it is, both options presented in the RFC are only useful for autocomplete, and Value[] is only marginally more useful. RFC 11 is not necessary to get autocompletion of field names, including for nested structs
<whitequark_> if we ever decide to ship something with full typechecking support it will have to be either a plugin, or yet another different syntax
<cr1901> I'm predisposed to don't merge... this seems to be a not-very-nice workaround to limitations in Python
<cr1901> And also, I don't care that much about type annotations
<whitequark_> I think I want to hear the most from the folks using IDEs since this is who this RFC is for
<jfng_> i don't like the syntax, struct layouts are much more readable without
<cr1901> Is vscode an IDE?
<whitequark_> yes, vscode uses pylance
<whitequark_> (pylance is a language server. pyright is a language server too that is usable in vim/st/etc. they are more or less the same for our purposes)
<cr1901> I don't like the syntax either. But yes, I'm not wanting for type annotations, so wait for others to chime in who want it
<whitequark_> agg?
<cr1901> Well, at least you can opt-out of this syntax
<cr1901> Sigh, well... I guess I'll get over myself if this is merged
<cr1901> FWIW, I like emilazy's idea for mypy too
<cr1901> along w/ a typing module
<whitequark_> I'm not sure if mypy will ever be usable
<whitequark_> re: this being merged, we have no consensus, and so far my policy has been "merge if there is full consensus"
<whitequark_> actually we seem to be going towards "consensus to close"
<cr1901> I want to close, but I also don't want to say "this is a bad design"
<whitequark_> why not?
<whitequark_> (and yeah you can just say that your proposed disposition is to close)
<cr1901> Because just because _I'm_ having a visceral reaction to the syntax and deprecating/removing the old syntax doesn't mean that I have a profound insight
<whitequark_> right. well, honestly I don't like it at all either, and I proposed it
<cr1901> into what ppl who want typechecking are thinking
<cr1901> Alright, predisposition to close
<jfng_> how about a "hold" decision, and we re-discuss it later ?
<whitequark_> we can postpone it, yes
<cr1901> whitequark_: Basically: If I say "I don't like it", I want to interrogate that rather than say "close instantly", if that makes sense
<whitequark_> it does
<cr1901> I'm for the new postpone/rework option
<cr1901> otherwise, close for me
<whitequark_> it's really an old option, Rust has it and I didn't pull it because I didn't feel it was relevant to our process. well, it is relevant now
<whitequark_> I'll update the process section later
<cr1901> ahhh, neat.
<whitequark_> ok, decision on RFC 11: postpone
<jfng_> merge, the benefits outweigh the drawbacks imo
<whitequark_> do you expect to use it in more than just enums? (for enums, I can do an implicit conversion to a const integer in amaranth.lib.enum)
<whitequark_> for context, I'm thinking about close, since it's pulling out a really big hammer and makes code more fragile in a way I've so far tried to avoid, but I'm open to comments as it is an RFC
<cr1901> I'm in preference to the "implicit lift" alternative, otherwise close
<jfng_> hmm, reset values come to mind too, but rfc9 handles that
crzwdjk has joined #amaranth-lang
<whitequark_> I don't think RFC 7 will help much with reset values?
<cr1901> "Implicit lift" seems to be analogous to something like Rust's coercion sites, which are a minimal set of sites where type conversions implicitly happen. There was pushback when they were introduced (AIUI), but in practice work just fine
<whitequark_> oh I see, you mean Cat(...)
<jfng_> yes
<whitequark_> yeah, RFC 9 will handle that
<whitequark_> cr1901: hold on, the only alternative i put in is "do not do this"
<whitequark_> I'm confused
<cr1901> whitequark_: Disregard everything above, I confused myself reading the RFC. Would take too long to explain
<whitequark_> crzwdjk: feel free to comment on RFCs we already discussde (8-10) as well as this one
<whitequark_> 8-11, sorry
<cr1901> I will trust your judgment to close, is there a way to make the error message better for now?
<whitequark_> for Enum or in general?
<cr1901> In the motivating example, I certainly would not understand the error "Attempted to convert Amaranth value to Python boolean"
<cr1901> for Enum
<cr1901> (without the text that follows, anyway)
<whitequark_> for Enum, if you use amaranth.lib.enum, I can do the cast already
<whitequark_> if you don't, unfortunately it's out of my hands
<whitequark_> or... well, ok, no it's not, I could inspect the frame above and see if it comes from the enum module. this is exceptionally cursed but it would work
<cr1901> if isinstance(var, enum.Enum): print("you tried using enum.Enum, please use amaranth.lib.enum")
<cr1901> ahhh
<cr1901> And how cursed is using inspect, really :P?
<whitequark_> you can't do isinstance(var, enum)
<whitequark_> because the EnumMeta code runs == directly on Amaranth values
<jfng_> if you did a cast instead, what would Instr.ADD.value return ? an int ?
<whitequark_> yes
<jfng_> what i like about this rfc, is that the Cat() information isn't lost
<whitequark_> that was the original idea. but it's really difficult to do anything about the == in EnumMeta
<whitequark_> it's a 100 line method in which we need to customize one line
<whitequark_> I don't want to vendor the entirety of it, I'm sure we will regret it if I do
<cr1901> >because the EnumMeta code runs == directly on Amaranth values <-- I'm going to have to look this up to understand this
<cr1901> Right now, vote to close, possibly w/ the cursed inspect workaround to make the error less cryptic
<cr1901> I'm also receptive to postpone
<whitequark_> agg? (though he didn't respond to RFC 11 either)
<whitequark_> I guess we also ran out of time half a hour ago
<crzwdjk> I would also say postpone or close this one
<crzwdjk> For the other ones, RFC 9: merge, RFC 10: merge. breaks back-compat but it's a pretty minor annoyance. RFC 8: merge.
<agg> (sorry yea, I had to run, though no particular opinion on typing for 11 and haven't looked into 7)
<crzwdjk> RFC 11: abstain, I don't know much about type annotations.
<whitequark_> okay, I think we should call it quits for today. RFC 8, 9, 10 will be merged. RFC 7, 11 will be discussed again on the next meeting
<whitequark_> thanks everyone for the input
<cr1901> Seems like decent progress?
<whitequark_> there is progress yeah
<crzwdjk> Seems like pretty great progress as far as I'm concerned
<cr1901> (And the RFCs _were_ in order from least to most controversial :P)
<FireFly> re the bridging issues, I didn't want to interrupt the meeting, but https://github.com/matrix-org/synapse/issues/15216 was linked elsewhere earlier and is the issue I guess, seems like some problem in the bridge
<whitequark_> thanks!
indy- has joined #amaranth-lang
cybernaut has joined #amaranth-lang
feldim2425_ has quit [Ping timeout: 248 seconds]
mikolajw has quit [Ping timeout: 248 seconds]
koschei[m] has quit [Ping timeout: 248 seconds]
indy has quit [Ping timeout: 248 seconds]
byteit101 has quit [Ping timeout: 248 seconds]
cesar has quit [Ping timeout: 248 seconds]
byteit101 has joined #amaranth-lang
feldim2425 has joined #amaranth-lang
urja has quit [Ping timeout: 248 seconds]
GenTooMan has quit [Ping timeout: 248 seconds]
urja has joined #amaranth-lang
cybernaut has quit [Client Quit]
GenTooMan has joined #amaranth-lang
cesar has joined #amaranth-lang
<_whitenotifier-9> [amaranth-lang/amaranth] whitequark pushed 1 commit to main [+0/-0/±1] https://github.com/amaranth-lang/amaranth/compare/ae1aeff0f2b1...32eabd9372b8
<_whitenotifier-9> [amaranth-lang/amaranth] whitequark 32eabd9 - hdl.ast: remove `Value.__hash__`.
<_whitenotifier-9> [amaranth-lang/amaranth-lang.github.io] whitequark pushed 1 commit to main [+0/-0/±27] https://github.com/amaranth-lang/amaranth-lang.github.io/compare/22f059bd2382...e967d1a786b9
<_whitenotifier-9> [amaranth-lang/amaranth-lang.github.io] whitequark e967d1a - Deploying to main from @ amaranth-lang/amaranth@32eabd9372b877f916e0f81cf3d2e0489e48e18e 🚀
koschei[m] has joined #amaranth-lang
jfng_ has quit [Quit: Client closed]
mikolajw has joined #amaranth-lang
byteit101_ has joined #amaranth-lang
feldim2425_ has joined #amaranth-lang
cybernaut has joined #amaranth-lang
feldim2425 has quit [Ping timeout: 248 seconds]
byteit101 has quit [Ping timeout: 248 seconds]
koschei[m] has quit [Ping timeout: 248 seconds]
cesar has quit [Ping timeout: 248 seconds]
GenTooMan has quit [Ping timeout: 248 seconds]
koschei[m] has joined #amaranth-lang
cesar has joined #amaranth-lang
cybernaut has quit [Quit: Leaving]
whitequark_ has quit [Quit: Client closed]
<_whitenotifier-9> [amaranth] richardeoin commented on pull request #759: add Lattice Nexus vendor platform (using nextpnr-nexus and prjoxide) - https://github.com/amaranth-lang/amaranth/pull/759#issuecomment-1456977688
<_whitenotifier-9> [amaranth-boards] bl0x commented on pull request #185: Add support for cmod_a7 board. - https://github.com/amaranth-lang/amaranth-boards/pull/185#issuecomment-1457010338
<_whitenotifier-9> [amaranth-boards] bl0x edited pull request #185: Add support for cmod_a7 and cmod_s7 board. - https://github.com/amaranth-lang/amaranth-boards/pull/185
GenTooMan has joined #amaranth-lang
nelgau has quit [Ping timeout: 255 seconds]