18:22 <vup> gatecat: do you have any guidance on how quick the prjtrellis fuzzers are roughtly? (specifically 051-pio_ioconfig)

18:23 <gatecat> that one can take a few hours iirc

18:24 <gatecat> you can set the TRELLIS_JOBS env var to something higher than the default of 4 if you have plenty of cores and RAM

18:24 <vup> I tried that, but it doesn't seem to really help

18:25 <gatecat> ah that fuzzer might not support the parallelism

18:47 <vup> Yeah seems like it

21:48 <cr1901> azonenberg: Looks like you'll get to donate to RPI after all if you wish: https://twitter.com/jackstripling/status/1408539064647786505

21:49 <azonenberg> Lol

21:49 <azonenberg> you're the third one to tell me

21:49 <azonenberg> Honestly, it feels like an occasion worth celebrating

21:53 <cr1901> From what I can gather: She is highly accomplished, but used her power to really screw students over

21:57 <vup> gatecat: would this be a problem with my additions to the fuzzer or something else: https://paste.niemo.de/raw/ikemovubul ?

21:57 <azonenberg> Correct

21:58 <azonenberg> cr1901: she's a brilliant physicist and generally smart person, but also has a bit of a god complex

21:58 <azonenberg> a shame the first black woman to get a PhD from MIT had to be such an asshole lol

21:58 <gatecat> vup: I suspect this was a regression from the move from boost::python to pybind11

22:00 <vup> hmm yeah, just `python3 -c 'import pytrellis; pytrellis.EnumSettingBits()'` also triggers it

22:01 <azonenberg> She had everything she needed to make RPI a great place to be a student

22:01 <azonenberg> then she went dictator instead

22:03 <cr1901> azonenberg: Yes indeed. And almost certainly ppl use that as a shield an excuse to shit on an accomplished black woman just because she's an accomplished black woman. As opposed to "she pissed a lot of ppl off"

22:25 <kc8apf> Finally starting to catalog my programmable logic museum collection: https://docs.google.com/spreadsheets/d/198OwVd5EvKgZrCU4X1MJh3aA3eBPXSmvTGsBtPXHBYQ/edit#gid=0

22:31 <vup> gatecat: Ok I think I know how to fix this, but I there there are a bunch more constructors missing. Is there a easier way to test this than just running all the fuzzers?

22:32 <gatecat> vup: unfortunately, probably not, but if it looks reasonable then it's probably OK in this case

22:32 <vup> well I was more looking for a way to check all the fuzzer actually work after that

22:33 <gatecat> at least seeing if they start is probably a good initial test, even if you don't let them run to completion

22:33 <gatecat> (which is likely to be a multi day process)

22:34 <vup> the problems unfortunately seem to mostly occur in the end

22:34 <vup> (atleast the exception I linked above only happend after ~2 hours)

22:36 <cr1901> There's a nontrivial chance that your errors were caused by changes I made to accomodate MachXO2, and I only fixed the fuzzers as needed

22:37 <cr1901> I didn't really worry about touching fuzzers I already ran because gatecat and I accepted at the time that the full flow from empty dbs to filled dbs was already broken/needed to be fixed.

22:43 <vup> Interesting, I don't think the MachXO2 changes were the cause of this issue

22:44 <cr1901> Well, that's why I didn't put a concrete bound on the odds its my fault :)

22:45 <vup> :)

23:16 <vup> gatecat: is it normal that running a unchanged fuzzer actually produces changes to the database? Running 001-plc2_routing produces this diff: https://paste.niemo.de/raw/ohohefipim.diff

23:17 <gatecat> yes, there's a fixup pass at the end that folds these back into the muxes

23:18 <vup> makes sense, thank you :)

23:18 <cr1901> The fuzzers treat "no change to bitstream" as a fixed connection. Sometimes those "no changed to bitstream" connections are default outputs for muxes

23:18 <cr1901> So dbfixup handles that

23:19 <cr1901> Tho without opening up EPIC right now, ".fixed_conn F0 F0_SLICE" seems like a genuine fixed connection?

23:20 <vup> are there any more interdependencies between the fuzzers (when starting from the current db), or can I just run some random fuzzers and then db_fixup in the end?

23:21 <cr1901> I don't remember running into problems doing that

23:21 <vup> great

23:23 <gatecat> the only other thing is that the "copy" fuzzers need to be run after fuzzers producing the data that they copy between tile types

23:27 <vup> I see