06:02 <cr1901_modern> sb0: Can you pull, uncomment line 26, and confirm you get an AssertionError during startup when you get the chance. If you comment line 26 and repeatedly resize the widget, you'll see the problem.

12:44 <sb0> of course, pyqtgraph.GraphicsWindow doesn't behave like a qt widget as far as winId & co are concerned. what else did I expect...

14:12 <cr1901_modern> sb0: redrawing is fixed, but I'm currently mulling over a difficult problem with resizing

14:13 <cr1901_modern> Everything is implemented, save for data points and ensuring sliders cannot have their order swapped (which is tougher than I thought to do elegantly)

14:18 <sb0> _florent_, what do you think about removing the sop signal from dataflow?

14:22 <GitHub20> [artiq] sbourdeauducq pushed 6 new commits to applets: https://github.com/m-labs/artiq/compare/38cdeb0a32c3...3d56ea5c7120

14:22 <GitHub20> artiq/applets 341bbde Sebastien Bourdeauducq: examples: add histograms demo

14:22 <GitHub20> artiq/applets e37e0bd Sebastien Bourdeauducq: applets/plot_xy_hist: use applets.simple and datasets

14:22 <GitHub20> artiq/applets 81a86b2 Sebastien Bourdeauducq: applets/plot_xy_hist: do not clear arrow/histogram when unrelated data is modified

14:24 <sb0> cr1901_modern, alternately clicking the zoom buttons alters the view, which seems fishy to me

14:25 <sb0> cr1901_modern, sometimes it displays a lot of decimals in the graduations which makes them unreadable (as the labels collide with one another)

14:26 <sb0> cr1901_modern, so you only support those cases where both sliders are visible?

14:27 <sb0> cr1901_modern, zooming in and out should not alter the cursor positions

14:37 <_florent_> sb0: I'm ok with that

14:40 <_florent_> sb0: I'll adapt liteeth_mini if you want

14:45 <cr1901_modern> sb0: "alternately clicking the zoom buttons alters the view" << Related to aforementioned AssertionError

14:46 <cr1901_modern> sb0: "graduations which makes them unreadable" << Yes, the alternative at pathological cases is to have major tick labels which display the same number (1e-15 1e-15 1e-15).

14:47 <cr1901_modern> sb0: "so you only support those cases where both sliders are visible?" << The scene tries hard to ensure that both sliders are visible at all times.

14:49 <cr1901_modern> sb0: "zooming in and out should not alter the cursor positions" << During a zoom in, what happens is that the linear transformation from pixels to units is changed, and the cursors are moved/keep their old unit values. Do you want it so that the cursors maintain their position and change values instead?

14:52 <cr1901_modern> In any case, I'm stumped on the AssertionFailure, so I'm prob gonna make a minimal test case and post to QtForums

14:53 <sb0> _florent_, ok. thanks!

14:53 <sb0> cr1901_modern, well, zooming is only something that is related to the view, and it should not change the data

14:53 <sb0> so moving the cursors is bad

14:54 <sb0> cr1901_modern, why do you want to keep both cursors visible at the same time? i don't think you should try to enforce that at all. there is the "zoom to fit" button that the user can click to bring both cursors into the view.

14:55 <cr1901_modern> Okay, let's tackle each point separately. I'm certainly open to changing what I've done b/c I've done some things that I don't really like

14:58 <cr1901_modern> The view deals with pixels only; it has no knowledge of what's displayed on the sliders. All that the view knows is to move the sliders when told to by a proxy class, and notify the proxy class of any changes via signals

14:58 <cr1901_modern> By "zooming changing the data", I presume you're talking about what happens when the sliders reach the edges?

14:58 <cr1901_modern> sb0: ^^

14:59 <sb0> cr1901_modern, well, when i zoom the cursors do not move but the graduations change. this is wrong.

15:00 <sb0> and yeah it changes the data in the spinboxes, too...

15:00 <cr1901_modern> That shouldn't be the case/wasn't my intent. Can you please post screenshots of before and after?

15:00 <sb0> it's easy to reproduce, put the cursors at -10/+10

15:00 <sb0> and then zoom in to the max

15:01 <sb0> with the mouse wheel

15:01 <sb0> when the graduations are at small values, e.g. -0.1/0.1, the data will begin to change

15:03 <cr1901_modern> "zoom in to the max" << Zooming is not dependent on cursor position, so I assume you mean "just keep zooming in"

15:03 <sb0> yes

15:04 <sb0> just bring the cursors out of the view when you are zooming on a different part of the axis ...

15:04 <sb0> or when the cursors are so spread apart that they cannot be both displayed at the current zoom level

15:05 <sb0> i guess you may have to review the architecture of this thing...

15:05 <cr1901_modern> Alright, I'll get rid of it.

15:06 <cr1901_modern> I'm going by your Github description and implementing what pyqtgraph did without pyqtgraph. There's two ways to change the center of the displayed axis in pyqtgraph that I'm aware of

15:06 <cr1901_modern> 1. Right mouse click and drag

15:07 <cr1901_modern> 2. When you move a slider to the edge of the screen, the axis will zoom out automatically and recenter the axis

15:08 <cr1901_modern> To implement #2, the sliders send a signal called sigBoundsUpdate when they detect they are at the edge of the screen. The transformation from pixels to spinboxes is recalculated.

15:09 <cr1901_modern> You do not want this behavior?

15:10 <cr1901_modern> sb0: ^^ (not sure if I should keep sending you notifications or not lol)

15:44 <sb0> cr1901_modern, #2 is fine, or scroll instead of zooming

15:45 <sb0> scrolling is probably better imo

15:58 <sb0> _florent_, when eop=1 you are also supposed to send valid data (the last message in the packet), correct?

15:59 <sb0> there is no way to send all the data of the packet first, and then, eop in a later cycle

16:00 <_florent_> i don't know, maybe, but here here we are sending valid data while eop=1

16:00 <_florent_> as it's done generally (Avalon ST, AXI)

16:04 <sb0> so in the rtio analyzer case, when finishing the transmission, the encoder would have to send a dummy packet with eop

16:04 <sb0> *dummy message

16:04 <sb0> ...which is redundant with eop

16:04 <sb0> corner cases, corner cases ...

16:07 <_florent_> i'm not opposed to change that, having control packets in the stream can be interesting.

16:08 <sb0> but if control messages are separate, that will limit throughput when the packet size is small

16:10 <_florent_> yes

16:11 <sb0> might be OK, though

16:11 <sb0> I'm certainly fine with that, and probably that works too for ethernet?

16:12 <_florent_> I think yes

16:12 <sb0> bbl

17:40 <sb0__> whitequark: how do I fix AssertionError: artiq-0.0-py_2399+git63f7899.tar.bz2 MatchSpec('aiohttp')

17:40 <sb0__> when doing conda install artiq-kc705-nist_qc1

17:41 <sb0__> whitequark: http://paste.debian.net/365583/

20:56 <whitequark> sb0__: absolutely no idea

20:56 <whitequark> is the corresponding artiq package uploaded?

21:01 <whitequark> ah yes, old conda, that's to be expected

21:01 <whitequark> there is no fix except upgrading conda.

21:42 <GitHub145> [artiq] sbourdeauducq pushed 5 new commits to master: https://github.com/m-labs/artiq/compare/63f7899f93e7...79986791bc67

21:42 <GitHub145> artiq/master 0b37000 Sebastien Bourdeauducq: manual: add core device analyzer TCP port

21:42 <GitHub145> artiq/master e4996fe Sebastien Bourdeauducq: manual/thorlabs_tcube: add note about USB/power sequencing

21:42 <GitHub145> artiq/master adf552e Sebastien Bourdeauducq: manual: artiq.coredevice.runtime_exceptions -> artiq.coredevice.exceptions