06:46 <whitequark> sb0: okay, this numpy change results in a serious deterioration of error message quality

06:46 <whitequark> like, either way I'm doing it, that happens

06:47 <sb0> how so?

06:49 <whitequark> specifically, what's taking so long is I implemented it the straightforward way, and they were bad, and now I did it the hard and more proper way, and they are also bad, in different ways

06:50 <whitequark> straightforward way: alias int(width=32) to np.int32

06:50 <whitequark> problem: implementation detail leaks into error messages, because initially all int literals are int(width='a)

06:50 <whitequark> hard way: make literals initially untyped (i.e. just 'a) and then unify them with int32 or int64 later

06:51 <whitequark> problem: when they have the type 'a, they can get unified with weirdest shit, like <instance TTLOut>, and then that will be propagated everywhere

06:52 <whitequark> the underlying issue is that HM type system has no way of expressing "either int32 or int64"

06:57 <sb0> can't the error messages be simply edited to print int(width=32) as np.int32?

06:58 <sb0> or rather, formatted

06:58 <whitequark> yes, that's the straightforward part

06:58 <sb0> what sort of error message would be inappropriate with that?

06:58 <whitequark> int(width='a) has no np. equivalent though.

06:58 <sb0> when does itn print int(width='a)?

06:59 <sb0> *it

06:59 <whitequark> every time you have an integer literal whose bit width is not yet known

06:59 <sb0> print it "np.int?"

06:59 <whitequark> which is the case for the majority of errors, as they happen before monomorphization

06:59 <whitequark> oh.

06:59 <whitequark> ... oh.

06:59 <whitequark> yeah, that works.

06:59 <sb0> "width='a" is certainly confusing to users anyway

07:00 <whitequark> well, there's list(elt='a)

07:00 <whitequark> I guess that is not much better after all...

07:01 <whitequark> ok. I will finish that branch and push it this evening

07:03 <sb0> "'a" certainly doesn't mean much to users. it's a minor detail, but I'd suggest "list(elt=?)" here

08:17 <cr1901_modern> rjo: Just to confirm I understand correctly; the register that's used to latch data to be sent out in the artiq SPI core is simultaneously used to clock in new data (presumably as a resource optimization)?

10:26 <rjo> cr1901_modern: yes. afaik this is typically done like that in most bit-serial protocols.

10:38 <cr1901_modern> rjo: Fair enough. I imagine it works for 99% of the cases (except for maybe a theoretical device which receives LSB first and sends MSB first or vice-versa)