<sb0>
just a quick hack I put together when llvmpy was really sucky
<whitequark>
i'm not sure how that helps
<whitequark>
i mean... llvmpy is obviously shit and should be rewritten. the problem is not that i cannot do so, the problem is that i haven't got time
<sb0>
whitequark, pointing out there seems to be no nasty surprises interfacing python with the LLVM C API. you never know...
<whitequark>
that's quite expected, given that LLVM C API was created for this sole purpose
<sb0>
yeah, famous last words
<whitequark>
no one actually wants to use C, it's specifically for FFI
<whitequark>
meh
<sb0>
next thing you know, some fancy-exception related feature is missing from the C API...
<whitequark>
you do realize llvmlite already uses the C API?
<whitequark>
anyway. yes, things are sometimes missing from the C API. the standard operating procedure is to use my commit rights to LLVM and add them.
mumptai has joined #m-labs
rohitksingh has joined #m-labs
mumptai_ has joined #m-labs
mumptai_ has quit [Remote host closed the connection]
<sb0>
"Anaconda gives superpowers to people who change the world."
<cr1901_modern>
Erm... that's laying it on thick
<whitequark>
typical startup bullshit
<whitequark>
the brokenness of their software is also quite typical
sb0 has quit [Quit: Leaving]
rohitksingh has quit [Quit: Leaving.]
sb0 has joined #m-labs
rohitksingh has joined #m-labs
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
<rjo>
sb0: yes. only downside is that then ttls are another piece of hardware. but maybe that's the lesser evil.
<rjo>
sb0: are you proposing ttls are a different AMC card or a different (e.g. FMC) daughterboard?
<sb0>
different AMC card
<rjo>
if it wasn't so tight on front panel real estate, i would have considered always bundling e.g. 16 ttl channels per 4 dac channels. and have only one board.
<sb0>
if the RF cards fit in FMC, don't we have space to bundle TTLs?
<sb0>
what is the typical DAC/TTL ratio in experiments? 4?
<sb0>
it's 2.25 for qc2
<rjo>
if ttls are simple and easy and space saving, 4 would cover ions and neutrals imho.
rohitksingh has quit [Ping timeout: 244 seconds]
<sb0>
ok. i'll do some research on available connectors... any suggestions?
<sb0>
there's the lemo stuff which HEP people love
<sb0>
what about ADCs?
<rjo>
connectors for the ttls?
<rjo>
in my experience, you need a breakout box anyway. either to reduce the wire density or to add decoupling (opto or lvds). then a single connector for the ttls is fine. i think the ohwr people have put some thought into that as well with the same consequence and a connector they use (some display thing?)
<rjo>
for the analog signals on the frontpanel i don't think there is much choice other than sma. the lemo stuff is expensive and hard to build and buy and actually not that phase stable.
<rjo>
same for smb, smc, qma, bnc
<cr1901_modern>
sb0: Most likely the crash is a signal loop problem. This was a deliberate design decision from me to reduce the number of unique signals that I needed. But it looks like it's no longer sufficient
<cr1901_modern>
The spinbox's setValue slot is attached to a signal; the scanwidget.setStart/setStop functions are meant to be slots for the spinbox valueChanged signal.
<cr1901_modern>
The signal doesn't care how the value is set; if the value changes, the signal will fire. There should probably be logic to determine why the spinbox's signal fired. Or maybe I could make a custom event that includes information on the source of why the spinbox value changed
<cr1901_modern>
rjo: Thoughts?
<cr1901_modern>
"There should probably be logic to determine why the spinbox's signal fired"... erm I mean "why the spinbox's value changed". Was it due to the user clicking or the slot being run?
<cr1901_modern>
Looks like spinboxes don't have events.
key2 has joined #m-labs
<cr1901_modern>
rjo: The root of the signal recursion problem is that self.realToRange and self.rangeToReal are not inverses of each other (and they REALLY should be)
acathla has quit [Ping timeout: 244 seconds]
<rjo>
cr1901_modern: i have tried to point you at that a couple times. you might be tracking the wrong state.
<rjo>
the two transforms can never be exactly inverteible. already because flotating point numbers can not exatly be inverted.
<rjo>
as i outlined. a) you need to break the reliance on the signal loop and b) you need to make sure that signal feedback does not escape your widget again.
<rjo>
if you update the slider position due to a method being called, the slider will round the value to its integer position. you can never let the resulting small rounding error of the start/stop floating point value a) affect the internal floating point value and b) let it escape.
<rjo>
and it looks like you can distinguish the origin of the change of the slider value (setting the value _or_ moving the slider): sliderMoved() vs valueChanged() (and the tracking flag).
<cr1901_modern>
rjo: I do not see how detecting the origin of the change will get rid of the feedback, which is your desired goal
<cr1901_modern>
The feedback will occur the millisecond that the spinbox's value is programmatically set
<cr1901_modern>
spinbox makes no distinction between value changed by user input and value changed programatically
<cr1901_modern>
naive solution is to set a flag when slider emits a signal to be propogated up to the spinboxes, which is checked when the signal comes back down the hierarchy and then NOPed
<cr1901_modern>
If the flag wasn't set, then we know that the user clicked the spinbox, and that the slider really should update its values
<rjo>
cr1901_modern: you don't have any spinboxes. they are not your problem.
<rjo>
your problem is that you get a change event, then you round a bit and therefore you create another change event that you can't even filter by checking whether the value actually has changed.
<rjo>
did you understand why the transforms will never be exactly invertible? and do you see that relying on exact mutual inverses is bound to fail?
<cr1901_modern>
rjo: Yes, I took for granted that floating point numbers are not infinite precision, and that if your floating point number and its inverse are not exactly representable in a finite precision, you won't be able to multiply them together and get 1.0 exactly
<cr1901_modern>
I knew all this. My problem is that I didn't think it would bite me anyway. I was wrong.
<cr1901_modern>
I thought a little precision errors were okay, "no big deal" :/
<cr1901_modern>
As long as the conversion from floating-point space to integer space worked (and it didn't)
acathla has joined #m-labs
key2 has quit [Ping timeout: 244 seconds]
acathla has quit [Changing host]
acathla has joined #m-labs
<rjo>
the rouding errors are fine as long as you don't expect the round trip to hold up to an equality test
larsc has quit [Ping timeout: 244 seconds]
larsc has joined #m-labs
mumptai has quit [Quit: Verlassend]
<sb0>
rjo, one breakout box for each card in a crate sounds a bit messy
<sb0>
or should the breakout box take TTL bundles from many cards?
<rjo>
sb0: usually. yes. but i would consider that to be downstream.
<rjo>
also the number of ttls for a single card to be future proof if we want people to avoid such a MIMO box, would be 128 ttl channels.
<rjo>
now we would need to find a cable and a connector that preferrably also fit on FMC and its tiny front panel, that do 128 pairs + lots of grouns.
<rjo>
therefore you usually need many ttl cards anyway.
<sb0>
not if the TTLs aren't on FMC
<rjo>
also, because the actual points where the ttl signals are needed, are rather dispersed throughout the lab. there would be splitting in most cases anyway.
<rjo>
well. yes. but that doesn't really save the day, right?
<sb0>
the breakout boxes can also be smart, i.e. contain a small FPGA, and receive a DRTIO fiber
<sb0>
that gives galvanic isolation too
<rjo>
sb0: could you test the m-labs/scanwidget repo if you can crash that? i rewrote most of the signal handling
<sb0>
and if everything is spread out, why do we need a crate at all?
<rjo>
sure. then the question is wether a ttl card is needed at all. but you loos JTAG, power supply ease, box making, etc. all the things why a rack is nice in the first place.
<rjo>
anyway. going to bed. see you tomorrow.
<sb0>
rjo, works totally fine now. before that it didn't crash like in artiq, but the dragging was broken