sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
sb0 has quit [Ping timeout: 244 seconds]
fengling has joined #m-labs
sb0 has joined #m-labs
<cr1901_modern>
sb0: Push to m-labs/scanwidget from now on? Should I keep my own repo?
<sb0>
m-labs
<cr1901_modern>
Ack.
<sb0>
whitequark, actually, kintex-7 (unlike spartan-6) has clamp diodes.
zoobab has quit [Ping timeout: 252 seconds]
zoobab has joined #m-labs
lars_ has joined #m-labs
lars_ has quit [Client Quit]
<sb0>
whitequark, test_rtio is still broken, please fix it.
<sb0>
you get artiq.coredevice.exceptions.RTIOSequenceError out of LoopbackCount, which suggests your 'with parallel' isn't doing what it should
<sb0>
other tests are also failing after I converted them to 'with parallel'. and we should test that, not 'with interleave', as this is what the users are going to use
<GitHub67>
[artiq] sbourdeauducq pushed 2 new commits to master: https://git.io/v23TD
<GitHub67>
artiq/master 82f4fd1 Sebastien Bourdeauducq: test/coredevice: convert to 'with parallel'
<GitHub67>
artiq/master 5d41113 Sebastien Bourdeauducq: doc: convert to 'with parallel'
<GitHub143>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/v23k4
<GitHub143>
artiq/master 53d5a45 Sebastien Bourdeauducq: test/hardware_testbench: properly close devices
sb0 has quit [Quit: Leaving]
Gurty has quit [Ping timeout: 240 seconds]
key2 has joined #m-labs
fengling has quit [Quit: WeeChat 1.4]
sb0 has joined #m-labs
Gurty has joined #m-labs
<whitequark>
sb0: yes, unittests do not run on my machine for some reason. I was going to tell you about that yesterday
<whitequark>
they spit out a bunch of noise about workers and then die
<rjo>
whitequark: you have two flterms sucking cpu.
<cr1901_modern>
rjo: Dealing with a merge conflict now (wtf did I do o.0;?)
<cr1901_modern>
rjo: Wow, this is a lot nicer than what I was trying to do
<cr1901_modern>
You went above and beyond again
<rjo>
cr1901_modern: as i said: you need to commit much more frequently. commit incrementally. then merge conflicts become the problem of somebody who commits less frequently than you...
<whitequark>
hm, I figured out the bug.
<whitequark>
looks like a honest bug in libunwind. can't believe it lasted that long, if it really is
<whitequark>
fortunately, easy to both fix and work around.
<cr1901_modern>
rjo: Ack. Right now, the resize bug is giving me trouble. The problem is that I think I abstracted wrong, and I'm in a situation where the two widget subcomponents need to update their size in a specific order (axis, then slider).
<cr1901_modern>
Probably the easiest way around this is to just move the sliders twice: once during axis resize, the other during slider resize. So that way, the order of events do not matter.
<cr1901_modern>
(Except that's gross, IMO. But whatever...)
<rjo>
cr1901_modern: sounds like wrong data dependencies. why don't you track the relevant data in one place and then explicitly emit (custom) resizes?
<GitHub149>
[artiq] jordens pushed 3 new commits to master: https://git.io/v2Z3L
<GitHub149>
artiq/master 8568218 Robert Jordens: examples/transport: cleanup
<GitHub149>
artiq/master 5599ec1 Robert Jordens: sim: align API closer to non-sim...
<GitHub149>
artiq/master a714be1 Robert Jordens: examples/pdq2_simple: fix offset scan
<cr1901_modern>
rjo: Because the slider-to-pixel transform is provided by Qt, not by me
<cr1901_modern>
I don't actually have access to the transformation that maps a slider position to a pixel position, just a function from Qt that is used to provide information on how slider components should be drawn
<rjo>
cr1901_modern: if Qt handles the sliders during resize then you only have to care about the axis.
<cr1901_modern>
rjo: Actually I think I know how to solve this now, but... the problem is during a resize the sliders will move such that they keep the same values in slider space. So If the sliders are at 33 and 66 respectively on a 100-position slider, their pixel positions will move proportionally. Because a resize does not update the zoom factor (real-to-pixel space), they will display the wrong value.
<cr1901_modern>
A resize doesn't update the zoom factor b/c either you or sb0 explicitly said you didn't want it
<cr1901_modern>
s/they will display the wrong value/"they will be positioned incorrectly relative to what the spinboxes display"/
<cr1901_modern>
rjo: If you have the scanwidget open, try resizing and see what happens!
<rjo>
cr1901_modern: no. resize can behave in such a way that what Qt does with the sliders already is "sufficient" (for the sliders, you need to handle the axis).
<rjo>
maybe s/,/;/ to clarify that.
<cr1901_modern>
rjo: So you're okay with the axis scale changing then on resize?
<cr1901_modern>
What I was planning to do was to just override the slider's resizeEvent and modify it's slider positions manually (using the new width as a bias factor)
<rjo>
cr1901_modern: yes. just acknowledge that the existing behavior of sliders themselves is fine and does not need overriding.
<rjo>
... since Qt presumably put a lot of thought into their HIG
<cr1901_modern>
Well yes. I just recall being told that rescale was undesirable during resize, so I avoided implementing it.
<rjo>
if that was me then i suspect i had "scale" defined as "the range of values shown on the axis". that stays constant.
<cr1901_modern>
rjo: Scale to me refers to the "real number quantity elapsed in the spinbox/axis per pixel increment". I woul probably refer to the range of values shown on the axis as... well, the "range" :P
<rjo>
cr1901_modern: you can rephrase my defnition as "change in value per change in slider positions" the later being that thing that is 0-99 independent of zoom.
<cr1901_modern>
"The later being that thing that is 0-99 independent of zoom." <-- slider space
<cr1901_modern>
"Pixel value reference relative to the center of a slider placed at position 0" <-- pixel space w/ bias correction
<cr1901_modern>
"Pixel value relative to the left side of the widget" <-- pixel space without bias correction
<cr1901_modern>
"Spinbox values" <-- real space
<cr1901_modern>
Perhaps I should make a README for this...
<cr1901_modern>
(The bias correction is needed so that the axis position at the center of the sliders is what actually is displayed in the spinbox)
<rjo>
cr1901_modern: referencing to the center is awkward. always use left and right. then all this "bias" talk becomes redundant, right?
<cr1901_modern>
That's the EE in me talking lol :P. Any DC offset is a bias. But point taken. In any case, commits are coming in in a few
<cr1901_modern>
damnit, a signal is being called when it shouldn't
<rjo>
whitequark: you have to take care of the runaway flterm.py yourself. i have killed it four times now.
<whitequark>
yes, and once you did it while I was trying to use it.
<whitequark>
actually, it looks like this is how flterm normally "works"
<whitequark>
well, whatever, I need it, and I'm not going to fix it right now
<rjo>
i won't kill it anymore. but flterm.py shouldn't spin busy.
<cr1901_modern>
rjo: Before I tackle the resize problem, I'm going to redo the transformations referencing relative to the left/right of the widget as you suggest. Simply put, the nonzero pixel width of the sliders and it's effect on what pixel maps to what slider position is killing me.
<cr1901_modern>
rjo: Taking the time to do this will fix bugs 2 and 3 on the todo list
<rjo>
cr1901_modern: ack. if you say you have the correct design for this, go ahead.
<cr1901_modern>
rjo: To explain it simply, slider space begins at pixel 0 and ends at widget_width - slider_width + 1 (I haven't figured out why the +1 is necessary). That slider_width remains constant no matter how big the widget is. If we have "x" slider positions and a widget_width "w" and slider_width "n", each position is (w-n)/x pixels apart.
<cr1901_modern>
Thanks to "n", multiplying the slider_width by a constant factor does not change the number of pixels per slider position by a constant factor.
<cr1901_modern>
(w-n)/(x - 1) pixels apart*
<cr1901_modern>
Do you understand the problem?
<rjo>
widget_width - slider_width would be the border around the slider.
<cr1901_modern>
rjo: slider_handle* anywhere I use slider*, bleh
<cr1901_modern>
i.e. slider_handle_width*
<cr1901_modern>
multiplying the widget_width by a constant factor*
<rjo>
cr1901_modern: then you should take the center of the sliders: slider_width/2 to widget_width-1-slider_width/2
<rjo>
the -1 is because widget_width is zero-indexed.
<rjo>
cr1901_modern: no. i don't see the problem. i would just write down where stuff is relative to each other with a few variables and then you can "solve for x"...