<cr1901> Wanda[cis]: Your commentary reminds me on how every time a 1-byte guy (8-bit Guy) video came out I had to will myself to not point out the stuff he oversimplifies or gets wrong lmao
<_whitenotifier-1> [prjcombine] wanda-phi created branch wip-belslot - https://github.com/prjunnamed/prjcombine
<_whitenotifier-1> [prjunnamed/prjcombine] wanda-phi pushed 1 commit to wip-belslot [+8/-0/±107] https://github.com/prjunnamed/prjcombine/commit/3d2224c49eff
<_whitenotifier-1> [prjunnamed/prjcombine] wanda-phi 3d2224c - wip
<Wanda[cis]> mei: need rust help
<Wanda[cis]> it is intended to generate a boatload of consts for all bel slots in a given FPGA family
<Wanda[cis]> and it works. the problem is that it takes 18s to compile this: https://github.com/prjunnamed/prjcombine/blob/wip-belslot/public/ultrascale/src/bels.rs
<Wanda[cis]> any idea how to make it not suck?
<Wanda[cis]> also a thing I'd really like is to be able to specify just a (base name, number) tuple (like [HPIOB; 26] in this example) and have it automatically fill out an array instead of... well the shit this is currently doing
<Wanda[cis]> but everything I can think of involves const traits which are not a thing.
<whitequark[cis]> what if you make it less recursive
<whitequark[cis]> and more iterative
<Wanda[cis]> how
<whitequark[cis]> oh, you need to increment the index.
<Wanda[cis]> yes
<Wanda[cis]> this is what makes it quadratic
<Wanda[cis]> I'm uh.
<Wanda[cis]> thinking of making a proc macro, despite my better judgement
<whitequark[cis]> can you use a const fn in the middle or something
<whitequark[cis]> make a const fn that returns an array of indices
<whitequark[cis]> idk
<Wanda[cis]> I know, right
<Wanda[cis]> core::array::from_fn could fix everything
<Wanda[cis]> however, as you know, const traits
<Wanda[cis]> (Fn is a trait)
<Wanda[cis]> actuallly
<Wanda[cis]> hm
<Wanda[cis]> what if I thread $previous.to_idx_const() as the accumulator
<whitequark[cis]> yeah
<Wanda[cis]> instead of manually incrementing by one (or rather, making a giant AST for it)
<Wanda[cis]> that still doesn't give me arrays, but eh
<Wanda[cis]> I can just suffer
<Wanda[cis]> okay that did the trick, rust-analyzer is usable again
<Wanda[cis]> oh gods
<Wanda[cis]> this results in different kind of bullshit
<Wanda[cis]> this triggers in client crate upon trying to use a const defined in the public crate
<Wanda[cis]> the public crate already has a bumped recursion_limit
<Wanda[cis]> but somehow the queries run when compiling a dependent crate? does it not serialize the computed consts into whatever metadata thing it's using? I'm so confused
mei[m] has joined #prjcombine
<mei[m]> <Wanda[cis]> "any idea how to make it not suck..." <- hm i think the motherfucker might be quadratic
<mei[m]> concept: have the macro define a private enum, and then a bunch of typed consts that... hold on why isn't this an enum in the first place
<Wanda[cis]> because it needs to be type-erased for generic code
<Wanda[cis]> ie. I want every target to use a common type for the bel slot index
<mei[m]> okay, that makes sense
<mei[m]> yeah, then a macro-internal enum and then a bunch of consts that each independently cast a variant of the enum to an int and then the BelId or whatever
<Wanda[cis]> mmmm
<Wanda[cis]> yeah that would avoid the recursion I suppose
<Wanda[cis]> I don't suppose you have any idea how to do the array thing?
<mei[m]> you don't even need the tt-muncher business
<mei[m]> wdym array thing?
<Wanda[cis]> <Wanda[cis]> "also a thing I'd really like..." <- this
<Wanda[cis]> note how repetitive the ultrasale bel list is
<Wanda[cis]> s/ultrasale/ultrascale/
<Wanda[cis]> and how I then manually gather the repetitions into their own arrays
<mei[m]> do you care about having both the individual names and the arrays?
<Wanda[cis]> I don't need the individual names if I have the arrays
<mei[m]> and then have the macro collect into: an enum that will be used to index the GROUP_START array, and the GROUP_SIZES array
<mei[m]> you can have an additional enum member at the end to be able to provide the size of the array involved
<Wanda[cis]> ohhh right
<Wanda[cis]> you can actually create arrays with the [dummy_val; N] syntax, ok
<Wanda[cis]> I was too hung up on array::from_fn
<mei[m]> yeah, it seems like the type of thing you'd need to use for const fn, doesn't it?
<Wanda[cis]> yes
<mei[m]> like, it has a very consty vibe
<Wanda[cis]> yup
<mei[m]> oh, because they added it as part of const generics becoming a thing that actually exists
<Wanda[cis]> ok, so, this handles the slot consts
<Wanda[cis]> but I also need the list of all stringified names
<Wanda[cis]> and I don't suppose I can stringify numbers in any const-fn way
<Wanda[cis]> hm, or
<Wanda[cis]> I could just make a list of (name, first index, optional length) and deal with that crap in non-const code
<Wanda[cis]> this actually seems workable?
<mei[m]> optional length?
<Wanda[cis]> well I have both arrayed and non-arrayed slots
<mei[m]> feels like length=1 with extra steps
<Wanda[cis]> different display
<Wanda[cis]> or hm
<mei[m]> i hope you're not planning to interleave the array ones with the non-array ones because I don't think you can write a performant macro to handle that
<Wanda[cis]> I would like to, actually
<mei[m]> okay actually it's doable, because both [MEOW; 2] and just MEOW are one tt
<Wanda[cis]> one expr even
<mei[m]> if you parse it with expr you can't unparse it later
<mei[m]> and you'll want to
<Wanda[cis]> oh?
<Wanda[cis]> does this go through one of these invisible grouping things
<Wanda[cis]> gods
<Wanda[cis]> fine.
<Wanda[cis]> macro_rules is a funny drug
<Wanda[cis]> just barely good enough that you'll spend hours or days trying to get this thing to do what you want
<Wanda[cis]> cpp is much easier to deal with. you just immediately conclude the situation is hopeless and go write a TableGen instead.
<whitequark[cis]> yeah