<rjo>
whitequark: could you allow ipv6/udp 60000-601000 through the firewall and also ipv6/tcp/http?
<rjo>
sb0: could you add lab.m-labs.hk AAAA 2002:3b98:d55a:0:a60:6eff:fe44:4295 to the zone?
<rjo>
cr1901_modern: up as well.
<whitequark>
rjo: done
<sb0>
whitequark, do you know how to fix RuntimeError: Setuptools downloading is disabled in conda build. Be sure to add all dependencies in the meta.yaml
<sb0>
I have pyserial as a run dependency in meta.yaml and as a requirement in setup.py
<sb0>
one way to fix it is to have pyserial as a build dependency as well in meta.yaml
<sb0>
but for some reason, artiq doesn't do that and seems to get away with it
<whitequark>
I think you're supposed to have it as a build dependency.
<sb0>
so why does it work for artiq?
<sb0>
rjo, done
<rjo>
whitequark: i never did much 6to4 but the routing seems to only wake up when there are outgoing packets. and then after a while it is forgotten again and you need another outgoing packet to establish it.
<cr1901_modern>
rjo: Let's... try this again.
<rjo>
sb0: ns1.serverraum.org still dishes out the old zone version. i think.
<sb0>
rjo, let's see what it does in 15min
<rjo>
sb0: ack. thx
<rjo>
whitequark: thanks.
<cr1901_modern>
rjo: Your changes are giving me an "if all else fails" idea.
<rjo>
cr1901_modern: where?
sb0__ has joined #m-labs
<cr1901_modern>
When you removed the groove, I have an overwhelming urge to move the sliders closer to the axis to remove dead space. This is giving me an idea to say "screw using QGridLayout" and have the sliders and the axis be a composite widget.
<whitequark>
rjo: that's weird.
sb0__ has quit [Client Quit]
<whitequark>
rjo: please tell me when it's next 'forgotten' and I'll run tcpdump
<whitequark>
to figure out where the packets get dropped
<rjo>
whitequark: will do.
sb0__ has joined #m-labs
<cr1901_modern>
rjo: But first I need to revert some changes. Try moving the slider with the mouse; it's no longer smooth
<rjo>
cr1901_modern: unless you make them very narrow (so that they don't interfere with the other npoint markers, which again would make the hard to use), i don't see much wasted space.
<rjo>
cr1901_modern: i thought i had seen that non-smoothness as well and was trying hard to debug, bisect and fix it. but i couldn't reproduce it. and i can't reproduce it now.
<rjo>
s/the hard/them hard/
<rjo>
the only bad thing about mosh is -- i think -- that it doesn't transition between ipv4 and ipv6.
<cr1901_modern>
rjo: Now *I* can't reproduce it lol.
<cr1901_modern>
but it's not a fluke, so... something's wrong
<rjo>
cr1901_modern: you mentioned a few changes you hadn't pushed yet yesterday. please push them.
<GitHub173>
[misoc] sbourdeauducq pushed 1 new commit to master: https://git.io/vasfb
<cr1901_modern>
rjo: Your changes rendered them redundant, so I discarded them/favored yours
<sb0>
_florent_, FYI, I'll be working on fixing windows asyncserial soon
<_florent_>
sb0: ok great, if you need some testing for that, ping me
<rjo>
sb0: aaaa record works.
sb0__ has quit [Quit: leaving]
<cr1901_modern>
rjo: Please let me know if you duplicate that bug by accident. Fortunately, I think it's Qt's fault, because the beginning and end points always follow the mouse even if the slider handle doesn't (which implies pixelPosToRangeValue/QStyle.sliderPositionFromValue is returning bad data sometimes)
<rjo>
cr1901_modern: sure.
<cr1901_modern>
rjo: At the moment, I can confirm; you weren't seeing things. I saw it too. I cannot currently duplicate. Again, the beginning and end points on the axis were always working properly even when the slider handles weren't.
<GitHub53>
buildbot-config/master 74e7cb0 whitequark: Fix coverage combine invocation on Windows.
<cr1901_modern>
rjo: Let's reiterate. The problem with widget initialization is that the code that constructs the widget is not temporally close to the code that should initialize the widget with default values (setStart/setStop/fitToView). Is this correct?
<cr1901_modern>
widget initialiation in artiq*
<whitequark>
bb-m-labs: force build artiq
<bb-m-labs>
build #396 forced
<bb-m-labs>
I'll give a shout when the build finishes
<rjo>
cr1901_modern: i replaced the QTransform stuff with a multiplication and addition. it initializes a bit off. will fix that later.
<rjo>
cr1901_modern: not really. imho your choice of state to track and where you track it is wrong leading to a case where you need data that you don't have yet.
<rjo>
cr1901_modern: just now?
<cr1901_modern>
Yes, just now. It took me a while to figure out how to fix it
<rjo>
cr1901_modern: the initialization that i am referring to? the one i broke 3 minutes ago?
<cr1901_modern>
no, the initialization of the widget that displays the slider handles in the wrong place
<rjo>
ah.
<rjo>
that's not the initialization that i am referring to. i gotta go now for an hour or so but will be back later. and i'll fix the bug that i just introduced 4 minutes ago unless you beat me to it.
<cr1901_modern>
rjo: I know. I'm saying I fixed the bug that's been making me pull my hair out the past 20 hours or so
FabM has joined #m-labs
<cr1901_modern>
rjo: I've found the scope of the "slider doesn't scroll smoothly" bug... a signal is being fired repeatedly when it shouldn't be. I had a problem similar to this before.
<cr1901_modern>
The idea was that the proxy only communicates one way- from spinbox down to the slider handles. If anything updates that wasn't due to the proxy doing something on behalf of the scanwidget, I use signals to propogate the changes back up to the spinboxes.
<cr1901_modern>
When the spinboxes value change, they call proxy functions to update the slider/axis state, which could potentially fire the signals again; this is deliberate, so for example, if the proxy changes something by its own accord, the spinboxes are eventually notified.
<cr1901_modern>
"this is deliberate" as in "the proxy functions being able to fire signals" is deliberate.
<cr1901_modern>
(The spinbox's ValueChanged signal will be fired regardless of whether I changed the value of the spinbox manually, or the spinbox changed in response to a propogated signal.)
<cr1901_modern>
I included guards in setSpan and friend to ensure that if the slider handles update/fire a signal due to the mouse moving, the signals wouldn't be fired again due to the spinboxes valueChanged signal from firing; these guards broke sometime in the past 24 hours.
<cr1901_modern>
So I at least have an idea of what's wrong now
<cr1901_modern>
(Let me know if you have questions or feedback. I thought signals were a clean way to propogate changes up the hierarchy, at the cost of adding code to prevent infinite signal recursion when signals propogate down the hierarchy)
kyak has joined #m-labs
<rjo>
cr1901_modern: ok. could you commit the fix for that state management/initialization bug?
<cr1901_modern>
As soon as I'm done rebasing against all your changes and fixing the new transform bug
<rjo>
cr1901_modern: ack
<cr1901_modern>
You calculate the scale and translate in the reverse order that I did
<rjo>
whitequark: ping6 to lab.m-lab.hk is down now.
<cr1901_modern>
to go from pixel to real, I translate, then scale
<rjo>
they get up to my upstream 6to4 relay, ams1.he.net
<rjo>
cr1901_modern: i do it that way. that per se is not the issue.
<cr1901_modern>
It
<cr1901_modern>
s fine if you want to do it in the reverse order, but you didn't change all the places that calculate transforms
<cr1901_modern>
I feel like removing calculateNewRealToPixel was a mistake for that reason; it kept all the transform calculations in one place
<rjo>
well. if you are certain that you know what's wrong, please feel free to fix it.
FabM has quit [Remote host closed the connection]
<rjo>
cr1901_modern: nonesense. if you look at the diff it is shorter _everywhere_. there is no calculation that has move to somewhere else.
<cr1901_modern>
I fixed it. You missed a negative sign :P
<rjo>
cr1901_modern: awaiting your fix then.
FabM has joined #m-labs
<cr1901_modern>
rjo: pull now
<whitequark>
rjo: please keep it running
<cr1901_modern>
rjo: Don't pull yet T_T
<rjo>
cr1901_modern: looks good
<cr1901_modern>
rjo: Try resizing the widget
<cr1901_modern>
I really wish linear transforms were commutative
<whitequark>
rjo: still running?
<whitequark>
I see nothing on the 6to4 interface
<rjo>
whitequark: the pings?
<whitequark>
yes
<rjo>
currently yes. a minute ago no
<whitequark>
rjo: indeed, everything is as you say
<rjo>
whitequark: i started a ping to another unrelated ipv6 host from lab and then my ping to lab went through
<whitequark>
er
<whitequark>
I did that too
<whitequark>
and 600ms after I got your ping
<rjo>
must have been at the same time. i did it within seconds of your post "indeed..."
<rjo>
but anyway. looks like some hidden tunneling/routing/6to4 state that gets forgotten
<rjo>
cr1901_modern: is that the signal problem?
<cr1901_modern>
rjo: No. I fixed one negative sign, but forgot to fix the other. Looking into signal problem now
<whitequark>
so... tcpdump sees packets before iptables
<cr1901_modern>
also, pull now... resize is fixed
<whitequark>
hang on
<whitequark>
rjo: can you keep pinging? I need to check somehting else
<rjo>
linear transforms are commutative. affines are not.
<rjo>
whitequark: pinging
<cr1901_modern>
... oh... did not know that o.0;. I figured none of them were b/c matrix multiplication in general doesn't commute
<rjo>
in 1D it does.
<cr1901_modern>
[1]*[2] = [2]*[1] :P
<cr1901_modern>
In any case, I guess using QTransform was a mistake. I thought it would make my life easier, but it didn't
<whitequark>
rjo: still pinging...
<rjo>
whitequark: yes.
<whitequark>
I mean, I still see them
<cr1901_modern>
rjo: Take the scanwidget, place the sliders close to each other, and keep zooming in with the "View Range" button. Do you get a RecursionError
<cr1901_modern>
There's still a bug with zooming in to about 10^-9 and the axis not updating properly, so I need to be able to zoom in at least that much temporarily
<cr1901_modern>
s/axis/transform/
<rjo>
whitequark: pretty sure this (the icmp replies) will keep the state alive.
<whitequark>
oh
<whitequark>
alright
<rjo>
whitequark: i think you have to look for 6to4 traffic on the openwrt wan interface. not for traffic on the 6to4 interface.
<rjo>
cr1901_modern: yes. my dynamicRange check is not correct. fixing that now.
<whitequark>
yes. that's what i wanted to check.
<rjo>
cr1901_modern: could you look at the context menu for the two buttons?
<rjo>
we can refactor the rest as we go along.
<rjo>
whitequark: i'll stop the traffic so that it can forget.
<cr1901_modern>
rjo: Sure, I can code that/push it. I'll take a look at the zoom bug as well
<cr1901_modern>
rjo: Do we still need a reset() context menu? If so, should we just reset to the initial start/stop values that were given when the scanwidget was constructed?
<rjo>
cr1901_modern: i don't think we need a reset. we have that in the gui already.
<rjo>
i wouldn't know what it would do different/better than the "recalculate arguments" thing we have there.
<cr1901_modern>
Well somebody suggested it earlier, so just wanted to check
<rjo>
i suspect they meant the "recalculate arguments" button that exists already.
<cr1901_modern>
rjo: Should the context menu pop up regardless of where I click on the widget, or just the axis?
<rjo>
if you can make it active on the entire gridlayout, that would be great.
<rjo>
ah. i remember. i think i may have actually suggested the reset but meaning something different: move the "recalculate arguments" into the context window to remove clutter and save space.
<rjo>
but let's not do that now.
<rjo>
i'll clarify the todo and we can leave that for a future revamp of the gui.
<cr1901_modern>
gridlayouts don't have context menus :P. Widgets do (I'll put the menu in the scanwidget)
<rjo>
but you are right. it actually wants the interface specifier... funny.
<cr1901_modern>
rjo: Context menu implemented
<whitequark>
rjo: start again?
<rjo>
whitequark: pinging. no response
<rjo>
cr1901_modern: nice.
<cr1901_modern>
Naturally I forgot to update todo.md b/c I got sick of git's merge conflicts/just used your copy
<whitequark>
hm, weird. i allowed proto 41 forward
<whitequark>
ah, needed to allow proto 41 input.
<whitequark>
done.
<cr1901_modern>
be back in 15 minutes
<rjo>
cr1901_modern: i personally would love ctrl-i and ctrl-p shortcuts for "view range" and "snap range" (more or less unused, somewhat symmetric.
<rjo>
whitequark: ack. let's test
<rjo>
cr1901_modern: check whether you can still hit your 1e-9 bug. this class of problem should be prevented by the dynamic range limit.
<cr1901_modern>
rjo: Ack on the shortcutss
<cr1901_modern>
rjo: Preventing the bug from triggering is not the same as fixing it. I would like to know why it occurs. But first I need to fix the signal recursion problem
<GitHub148>
[artiq] jordens pushed 1 new commit to scanwidget: https://git.io/vaGUS
<GitHub148>
artiq/scanwidget e4b854b Robert Jordens: scanwidget: apply changes as of 98f0a56
<rjo>
cr1901_modern: it is a floating point rounding error imho. preventing catastrophic cancellation due to floating point errors is a way of fixing the bug.
<rjo>
cr1901_modern: the transform is never accurately invertible numerically. and it becomes catastrophic at large dynamic range.
<rjo>
cr1901_modern: i updated the todo for you.
<cr1901_modern>
rjo: The thing is, I used to be able to go to large zooms beyond 10^-9. So somewhere along the line, I broke it
<rjo>
cr1901_modern: if i can get unmodified drag on the widget (axis, groove, not handles) to move the axis origin, i'll merge the artiq scanwidget branch.
<rjo>
cr1901_modern: ah. you are right. you can still happily zoom to 1e-20 range. then the points and handles become jerky.
<rjo>
cr1901_modern: minor. write it down and save it for later.
<cr1901_modern>
rjo: If I zoom in normally, the zoom stops at about bias + 1e-3
<cr1901_modern>
line 394: newLeft * newScale isn't the dynamic range?
<rjo>
whitequark: feels like ipv6 is good now.
<rjo>
cr1901_modern: 391?
<cr1901_modern>
yes, sorry. I have some print statements that I've been stripping out when I commit
<rjo>
cr1901_modern: if you keep the zero in your view you can zoom in until 1e-20
<rjo>
cr1901_modern: feel free to use a logger for the print statements. then neither of us has to do cleanups repeatedly.
<rjo>
left is the value (in axis units) at the left of the axis. scale is pixels per axis unit. newLeft*newScale is the pixel position of the axis zero. if that is too far away, the transformation will break.
<rjo>
away as in "away from the view"
<cr1901_modern>
ahhh so the dynamic range isn't a ratio, it's an actual pixel distance away from the origin
<rjo>
it's also the ratio of offset to visible range.
<rjo>
modulo maybe the actual width in pixels.
<rjo>
but that doesn't matter much.
<rjo>
"modulo" in the conceptual sense. not the mathematical sense.
<cr1901_modern>
rjo: Well I'm just used to dynamic range being the ratio between the smallest value and largest value of a set
<rjo>
yeah. or by some other definition the offset or the mean over some delta or stdev.
<cr1901_modern>
rjo: One of the problems I was having seems to have disappeared by switching from QTransforms. Continuously zooming in does not break at 10^-9, but rather at 10^-20 like you said (if 0 is in range). So I think you're right that it's a transform/floating point precision problem.
<rjo>
or the inverse. usually "large dynamic range" implies high resolving power: large offset, small delta
<cr1901_modern>
(Zooming using the "View Range" menu, btw)
<rjo>
but it falls apart in a very nice way.
<rjo>
yes.
<cr1901_modern>
It's also important to note that right now "View Range" can bypass the dynamic range check (there is none). Prob should add that in
<rjo>
now on to unmodified drag on axis and groove. would that take longer?
<cr1901_modern>
My q right now: Will there ever been a need to have a simultaneously large offset and large delta
<rjo>
cr1901_modern: ack. let me handle that check on "view range".
<rjo>
cr1901_modern: no. you can assume there won't. that doesn't make sense physically.
<cr1901_modern>
Still need to fix the signal bug before doing unmodified drag.
<rjo>
ack
<cr1901_modern>
(9:57:19 AM) rjo: "modulo" in the conceptual sense. not the mathematical sense. <-- I'm afraid I don't actually know what you mean here
<rjo>
cr1901_modern: and this also needs to check/react on resize.
<rjo>
might be physicist lingo. we use "i claim $statement" -- pause -- "maybe modulo $correction" to sneak in an addendum to a claim. but it is never modulo in the mathematical sense.
<rjo>
is a physicist says: "a = 9 .... ah .... maybe modulo b" he usually mean something like "a = 9*b"
<rjo>
not "a = 9 mod b"
<rjo>
*means
<rjo>
anyway. insider joke.
<cr1901_modern>
Fun fact: The highest level of physics I took was classical electromagnetics lol
<cr1901_modern>
rjo: A bit curious, I decided to do the math. Indeed you're right: b*a is the ratio of the absolute value of real offset to the visible range, multiplied by the widget's current width.
<cr1901_modern>
So, what happens on resize then? It's possible for the dynamic range to be violated on resize
FabM has quit [Quit: ChatZilla 0.9.92 [Firefox 45.0/20160303134406]]
<cr1901_modern>
actually no it won't, now that I think of it.
<cr1901_modern>
(Did the math; on resize, b*a won't change value barring floating point errors)
<cr1901_modern>
be back in a bit
<rjo>
cr1901_modern: yes. but i'll want to do some more refactoring there anyways.
Gurty has quit [Ping timeout: 260 seconds]
rohitksingh has joined #m-labs
<GitHub139>
[artiq] jordens pushed 1 new commit to scanwidget: https://git.io/vaGi9
<GitHub139>
artiq/scanwidget 7f3e1c9 Robert Jordens: scanwidget: apply changes as of 10439cb
<GitHub184>
[artiq] jordens pushed 1 new commit to scanwidget: https://git.io/vaGP3
<GitHub184>
artiq/scanwidget 22b0726 Robert Jordens: gui: fix scanwidget usage
<GitHub128>
artiq/master 78f2706 Robert Jordens: scanwidget: apply changes as of 579bf5e
<cr1901_modern>
rjo: Sorry "be back in a bit" became "good night". Ack.
<rjo>
cr1901_modern: i started disentangling a bunch of things. the dependencies on signal loops need to be removed. and i don't think there is anything wrong with making the ScanProxy and the ScanWidget the same. it's an impressive amount of code duplication and forwarding the way it is now.
<cr1901_modern>
rjo: That's fine, but I'm not sure if the signal loops can be avoided (and a signal loop in and of itself isn't a bad thing IME); they propogate information back to the spinboxes, and the spinboxes call proxy methods to finish updating.
<cr1901_modern>
The proxy methods need to be able to fire signals as well, since what the proxy does can affect widget components in ways that require immediate attention.
<rjo>
you can not rely on the loop. that's a bug. the spinboxes are not part of the scanwidget.
<cr1901_modern>
Okay then. Let me think about how to fix this.
<rjo>
cr1901_modern: just short-circuit the update paths in proxy and ignore set*() calls that don't change values.
<rjo>
cr1901_modern: i'm done for today.
<cr1901_modern>
rjo: Ack. I'll fix the signal propogation, and try to break the widget