<whitequark>
we should record runtime version separately.
<sb0>
they're theoretically flashed together, but a similar warning at runtime (and probably BIOS) startup would be OK...
ylamarre has joined #m-labs
<rjo>
cr1901_modern: how is the scanning widget?
<rjo>
cr1901_modern: could you outline the work that needs to be done and push your current state? i have a bit of time on my hands and would like to advance this a bit.
<sb0>
fuck savannah
<sb0>
let's mirror lwip on something more reliable...
<GitHub28>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/v2m3m
<cr1901_modern>
rjo: That should actually be everything left to do, minor and major.
attie has quit [Remote host closed the connection]
attie has joined #m-labs
<rjo>
cr1901_modern: could you please run flake8 (or similar) over it and fix style?
<cr1901_modern>
rjo: Okay, will do. I didn't think it was THAT bad :P
<rjo>
cr1901_modern: you can also just run yapf on it as a git hook and be done with it.
<rjo>
cr1901_modern: from that list, is there something that i can help you with and do right now?
<cr1901_modern>
"Need to add a "max number of ticks to display" to ticker class to avoid label overlap" should be easy enough, since it's mostly your code
<cr1901_modern>
rjo: ^^
<rjo>
sure. anything "non-easy"?
<rjo>
cr1901_modern: the ticker class does that already. it won't display more than 2.5 times the desired ticks
<cr1901_modern>
It does? And I'm adding a "non-easy" bullet
<rjo>
cr1901_modern: that's intrinisic to the algorithm. the worst mismatch is when a step of 2 yields barely to few ticks then a step of 5 is just under 2.5 times the desired number of ticks.
<cr1901_modern>
In some cases, labels will overlap.
<rjo>
well yes. then the minimum number of labels is too large and the labels are too long.
<cr1901_modern>
So my axis class had a method to calculate how many labels could safely fit in the given width. My idea was to pass that to the ticker class as a fallback
<rjo>
cr1901_modern: from my last review there are a few things missing. "%e" is the wrong format.
<rjo>
it should be equivalent to "%g" with the choice between %f and %e synchronized across the ticks.
<cr1901_modern>
I'm not sure what g does actually.
<cr1901_modern>
okay, so I can decide which format to use by running a dummy loop where I compare the output of both formats
<rjo>
cr1901_modern: you might be better of with doing it yourself. you can get the relevant exponent from ticker. then decide like %g. then format all ticks yourself accordingly. and while you do that you would implement that offset/magnitude visualization at the same time.
<cr1901_modern>
rjo: Okay, that's probably a good idea. Let me fix the errors w/ magnitude repr first
<rjo>
cr1901_modern: and increase the number of possible slider positions to ~1024
<cr1901_modern>
rjo: Yes I did promise that. I forget why I didn't do that yet. I think I considered it a minor change and wanted to be one of the last things I added
<rjo>
cr1901_modern: and 5% zoom increments per 120 wheel units.
<cr1901_modern>
rjo: Ahh yes, we need to figure that out. While 5% makes it more reasonable zoom for you, that doesn't solve the underlying problem that you're recieving hundreds of wheelEvents w/ a magnitude of 120 in the time I receive lesss than 10
<rjo>
whitequark: the two different dns resolvers that i tested just refreshed lab.m-labs.hk with the same old ip again.
<rjo>
whitequark: for 16k second lifetime.
<rjo>
cr1901_modern: but even for a mouse wheel i would like 5%. the inertia thing on my touchpad is secondary. put it low on the list
<cr1901_modern>
rjo: Okay. I'll also make zoomToFit/fitToView go to 1/6 and 5/6 of the current view
<rjo>
cr1901_modern: ack
<rjo>
cr1901_modern: i would just make that "6", the label precision, the min number of ticks all configurable. gets much more algorithmic than magic constants that way
<rjo>
and the dynamic range variable in Ticker
<cr1901_modern>
rjo: That's fine, but where do I put them all? You already want me to reduce the physical size of the widget.
<rjo>
just class attributes.
<rjo>
for now.
<rjo>
whether to expose them at __init__ is for later.
<rjo>
no, not graphically configurable. programmatically.
<cr1901_modern>
rjo: Ack. I added that to the list. Let me fix bugs first.
<cr1901_modern>
Note that I don't think the top half of the image is inherently bad, but it did get me thinking
<rjo>
i don't think it is that easy. you can also get lost figuring out whether the skateboard is the correct first step or not.
<rjo>
nothing currently.
<rjo>
do you want me to prioritize your items for maximum impact?
<cr1901_modern>
rjo: Sure.
<cr1901_modern>
rjo: Yes, the reality is, I grossly underestimated the time this would take. I was arrogant.
<cr1901_modern>
rjo: And you may be right re: the skateboard. My widget evolved from leveraging pyqtgraph and then Qt to get full functionality as quickly as possible (the top panel), into manually handling most of the widget functionality myself in a custom job.
<cr1901_modern>
Yes, just saw it (I never forked a gist lol)
<rjo>
i was doing etherpad for a minute then got bored and forked
<cr1901_modern>
Ahh, well etherpad might've been better tbh if I had heard of it prior to 20 seconds ago XD
<cr1901_modern>
Remove asserts (or catch AssertionFailure) and just refuse to honor zooms at some point. <-- I will need to at least get to thiss point. sb0's not going to be happy if the ScanWidget brings down all of ARTIQ
<cr1901_modern>
rjo: If you think of anything else, add it to the list. At the end of today, I'll modify the list to remove the things that got done
<rjo>
cr1901_modern: the increase in number of slider positions?
<rjo>
cr1901_modern: let me do the full label generation in ticker. you give it left and right and it will give you text (offset and labels). that resolves at least three of the items.
<cr1901_modern>
left and right what? What spinbox value maps to the left of the axis, and right respectively?
<rjo>
no. the same way it does now.
<rjo>
you give it the [a, b[ interval to be decorated with ticks.
<cr1901_modern>
(2:48:08 PM) rjo: no. the same way it does now. <-- how I described it IS the way it does it now :P
<rjo>
yes. it gives you an offset string and a list of (value, label) ticks
<rjo>
the spin boxes are supposed to be the sliders, not the view.
<rjo>
but the ticker applies to the view. it has nothing to do with the sliders.
<cr1901_modern>
rjo: Yes, but I internally keep a transform from spinbox space to pixel space and vice-versa
<rjo>
the ticker doesn't care.
<cr1901_modern>
In my current implementation, the ticker does care
<rjo>
just try yourself: figure out appropriate for the interval [0, .5[ with min_ticks=2
<cr1901_modern>
But now that I'm looking at it, by the time we execute thiss line, the number of ticks is set
<rjo>
yes
<cr1901_modern>
Wait... what I could've done was had minStep = i/max and then:
<cr1901_modern>
if min_step <= good_step <= step:
<cr1901_modern>
return good_step
<cr1901_modern>
But this fails if minStep >= step :P
<cr1901_modern>
(which may very well be possible if the max number of ticks that can be drawn without overlap is less than the minimum ticks)
<cr1901_modern>
rjo: In any case, I defer to you b/c you know better about what type of scaling that you want.
<cr1901_modern>
I'll work on things that don't depend on what you're doing
<rjo>
yes
tmbinc__ has quit [*.net *.split]
cyrozap has quit [*.net *.split]
larsc has quit [*.net *.split]
kmehall has quit [*.net *.split]
kmehall has joined #m-labs
cyrozap has joined #m-labs
tmbinc__ has joined #m-labs
lars__ has joined #m-labs
lars__ is now known as larsc
<cr1901_modern>
rjo: For future reference. Do you know anything like etherpad for ipython notebooks? I didn't publish it, but most of my testing of your ticker widget was done against that
acathla has quit [Read error: Connection reset by peer]
<rjo>
cr1901_modern: you should really clean up your code and scrub it thoroughly
<cr1901_modern>
rjo: Can you elaborate? I mean, I of course would clean out debugging and dead code before a final commit. But I've tried to divide the scanwidget into multiple components with minimal communication between them (to reduce hard-to-find bugs)
<rjo>
cr1901_modern: also the zooming should be proportional to angleDelta().y(), not just sign(angleDelta().y())
<cr1901_modern>
Ahhh, that.
<rjo>
i just looked at the wheelEvent path. there are three methods that seem very redundant.
<rjo>
and mutually overlapping
<rjo>
just convert angleDelta().y() into a factor _once_ and pass that.
<rjo>
why would you even sign() it? and it can also be zero.
<cr1901_modern>
rjo: The reason the methods are redundant is because that was a scar back from when I was using QGraphicsView and called handleZoom from multiple places
<cr1901_modern>
If it's zero, there's nothing to do?
<rjo>
that's why i recommend cleaning up the code.
<cr1901_modern>
Okay, I understand what you mean now, and you're right
<rjo>
probably. it's in the docs.
<cr1901_modern>
Alright very good. I'll add it to the list when I update it again; I'll just copy your changes back into my list
<rjo>
cr1901_modern: i have commited a few things to m-labs/scanwidget.git. you can take that
<cr1901_modern>
rjo: I'm not sure how I just noticed this, but... the highest priority thing on your and my list:
<cr1901_modern>
s/zoom/resize
<cr1901_modern>
the slider positions are not updated properly on resize, not zoom. Zoom works, minus the tweaks I need to make
<cr1901_modern>
Wow, I'm sorry
<cr1901_modern>
and ack
<cr1901_modern>
rjo: Thankfully, when recentering the widget, the RELATIVE error between the old center and new center stays at about 10^-15, no matter what the current scaling iss.
<cr1901_modern>
(if the old Center cannot be represented in the current pixel-to-spinbox transform)