<d_n|a>
The kind of close-to-hardware code that ARTIQ Python is mostly used for is especially prone to these errors, so the language semantics should be chosen appropriately
<d_n|a>
Huh, is test_pulse_rate flakey again?
<whitequark>
it should, but then it departs even further from being a subset of python
<whitequark>
in my view, python is a completely wrong base language to use for this in the first place
<whitequark>
it gives nothing but passing familiarity, and creates a lot of difficulties, e.g.: numbers, inheritance, ...
<bb-m-labs>
build #2814 of artiq is complete: Failure [failed anaconda_upload_1 python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2814 blamelist: David Nadlinger <code@klickverbot.at>
<bb-m-labs>
build #2815 of artiq is complete: Failure [failed make_doc python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2815 blamelist: Drew <drewrisinger@users.noreply.github.com>
monicaleung has quit [Quit: Leaving]
lkcl has quit [Excess Flood]
lkcl has joined #m-labs
futarisIRCcloud has joined #m-labs
_whitelogger has joined #m-labs
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<whitequark>
sb0: so, the reason `val` ends up as int32 is the cast used in assignment to `val_lower_int32`
<whitequark>
this is probably a bug in pass ordering.
<whitequark>
unfortunately, while this specific instance (with the literal) is a bug, i can construct some very similar example that would still be broken, by making clever use of operators
<whitequark>
replace it with 1<<32 and you'll have the same problem
<whitequark>
which won't be fixed by the fix i'm about to apply
<bb-m-labs>
build #2818 of artiq is complete: Failure [failed python_unittest_3] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2818 blamelist: whitequark <whitequark@whitequark.org>, David Nadlinger <code@klickverbot.at>