00:24 <GitHub141> [artiq] sbourdeauducq tagged 0.1 at e8891eb: https://git.io/vz0zK

00:41 <GitHub37> [artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vz02x

00:41 <GitHub37> artiq/master 4dd0693 Sebastien Bourdeauducq: add release notes/process

02:18 <GitHub26> [artiq] sbourdeauducq pushed 2 new commits to master: https://git.io/vz0Mr

02:18 <GitHub26> artiq/master fa1afb7 Sebastien Bourdeauducq: add information about CLOCK hardware

02:18 <GitHub26> artiq/master b3ba97e Sebastien Bourdeauducq: gateware: clean up and integrate QC2 modifications from Daniel

02:27 <GitHub14> [artiq] sbourdeauducq pushed 2 new commits to master: https://git.io/vz0Db

02:27 <GitHub14> artiq/master db8ba8d Sebastien Bourdeauducq: gateware: add clock target from David

02:27 <GitHub14> artiq/master 18f0ee8 Sebastien Bourdeauducq: gateware: add QC1 docstring

02:36 <GitHub166> [artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vz0yX

02:36 <GitHub166> artiq/master dae63bd Sebastien Bourdeauducq: conda: add artiq-kc705-nist_clock

02:39 <sb0> whitequark, can you add that one to the buildbot plz?

02:39 <whitequark> one moment

02:40 <whitequark> the builds will become even slower...

03:00 <GitHub121> [buildbot-config] whitequark pushed 1 new commit to master: https://github.com/m-labs/buildbot-config/commit/e4fec5bfc7d26e35e1bd620faa8b724f652dba73

03:00 <GitHub121> buildbot-config/master e4fec5b whitequark: Add builder for artiq-kc705-nist_clock.

03:06 <GitHub189> [artiq] jordens pushed 1 new commit to ppp2: https://git.io/vz0QY

03:06 <GitHub189> artiq/ppp2 8cbb60b Robert Jordens: Merge branch 'master' into ppp2...

03:09 <cr1901_modern> rjo: ping

03:12 <cr1901_modern> I read your email. The main reason for me using a canvas- free zoom support- didn't work out. I've still been using a canvas mainly because it gives me free mouse handling/priority support and lets me create graphical objects like markers/num points easily. I've been thinking about going back to subclassing a slider however if I can figure out how to redraw the cursors.

03:13 <cr1901_modern> This is going to be necessay from a UI standpoint to distinguish max and min. Additionally, Qt, for whatever farfetched reason, let's you embed a standard widget into a canvas, so I could go a hybrid route if I so desired.

03:14 <rjo> "cursors" == "movable elements on the slider"?

03:14 <rjo> or handles?

03:14 <cr1901_modern> the former

03:15 <rjo> would be the same for me.

03:15 <rjo> something like http://stackoverflow.com/questions/17361885/range-slider-in-qt-two-handles-in-a-qslider looked like a reasonable approach to me.

03:16 <cr1901_modern> Well, I guess changing how the cursors paint themselves isn't absolutely necessary

03:16 <rjo> but i am also not really the most experienced here.

03:17 <rjo> but yes. free zooming should not be very helpful because of all the ticklabel adjustments necessary.

03:18 <cr1901_modern> If you're referring to how the labels get screwed up in my current design, there's a formatting string I can use to fix it

03:18 <cr1901_modern> but I don't remember it XD

03:19 <rjo> it is pretty tricky to implement useful automatic axis ticking and labeling. see the piles and piles of code matplotlib has for it.

03:19 <cr1901_modern> I guess your friends at NIST disagree? ;)

03:20 <rjo> anyway: even having two QSliders, one for start, one for stop, both properly linked and labeled would be fine with me.

03:20 <rjo> well we all knew that there are various tricky parts to it.

03:21 <cr1901_modern> Did you read my QtCentre post if sb0 forwarded you the email? It explains the source of the bugs

03:21 <cr1901_modern> (well the ones I know about)

03:21 <rjo> the others here have not commented much, nothing technical anyway.

03:22 <rjo> i don't think i have seen that mail.

03:22 <cr1901_modern> http://www.qtcentre.org/threads/64865-QGraphicsView-viewport-and-QGraphicsScene-View-SceneRect()-are-not-equal-after-resize

03:23 <cr1901_modern> TLDR: Something that I'm assuming is an invariant, when converting between pixels to "what's displayed on the spinbox", isn't holding during resize. This includes the resize when the application starts.

03:25 <cr1901_modern> Just to humor me, could you copy/paste the code sample in the linked thread, uncomment line 62, and tell me if you get an assertion failure on start?

03:25 <cr1901_modern> if not, resize until you do

03:26 <rjo> ah. that is probable also the underlying mechanism for the flip-flopping data if you switch between view-to-range and range-to-view

03:28 <cr1901_modern> Yes, that is what I believe as well. Sometimes they do coincide exactly (as they should)

03:32 <rjo> yes. that code asserts on resizing.

03:37 <rjo> for labeling an axis just imagine the case where you are viewing the range [1e12 - 1e-6, 1e12] and want to supply proper ticks and labels without messing everything up.

03:37 <rjo> and remembering that this widget should be very compact.

03:38 <cr1901_modern> Well, rjo, you gave me an idea for displaying ticks

03:39 <cr1901_modern> It's definitely possible w/ scientific notation that each major tick is so close together that with a certain displayed precision, they have the same value

03:39 <cr1901_modern> i.e. 5 major ticks displayed, all with the value 1e12

03:41 <rjo> well. again you may look at matplotlib how they do it. they try to figure out the offset and rewrite the labels accordingly, displaying the offset somewhere in a corner.

03:46 <cr1901_modern> matplotlib does what matlab does IIRC. Which is the major ticks all display the same value :P

03:47 <cr1901_modern> In any case, good to know that it fails on your machine too. At least I know the problem if anything

18:28 <rjo> cr1901_modern: no. matplotlib writes it as "1e-6 2e-6 3e-6 + 1e12

18:28 <rjo> "

21:20 <sb0> whitequark, why does CompileError need special treatment in worker_impl.py?

21:21 <sb0> can't the worker just "terminate with exception" like it does for all others?

21:21 <sb0> you want to suppress the traceback from inside the compiler?