<whitequark>
it's a miscompilation that puts one argument too many on the stack in the *exact conditions* that the first argument is a 64-bit integer and there are at least two before a vararg in a function call that's compiled with PIC
<whitequark>
... basically, it triggers exclusively on a function like rtio_log
<whitequark>
oh, and you have to load something via the GOT. (now in our case)
<whitequark>
I'm impressed with how laser-guided this bug is
cr1901_modern has quit [Ping timeout: 260 seconds]
mithro has joined #m-labs
FabM has quit [Ping timeout: 256 seconds]
FabM has joined #m-labs
key2 has joined #m-labs
sb0 has quit [Quit: Leaving]
evilspirit has quit [Read error: Connection reset by peer]
FabM has quit [Quit: ChatZilla 0.9.92 [Firefox 44.0.2/20160210153822]]
FabM has joined #m-labs
evilspirit has joined #m-labs
FabM has quit [Quit: ChatZilla 0.9.92 [Firefox 44.0.2/20160210153822]]
Gurty has quit [Quit: Kooll ~o~ datalove <3³\infty]
Gurty has joined #m-labs
Gurty has joined #m-labs
sb0 has joined #m-labs
<rjo>
sb0: why did you choose the explorer as the central widget? i would have taken the area where the experiment editors are (literally central in the way most people will lay out their ui).
<sb0>
rjo, that would be good if there were a simple way to detach the experiment editors
<sb0>
Ting Rei explicitly requested that multiple experiment editors be visible at the same time in order to easily compare values between them
<sb0>
look at the figure in "Qt Main Window Framework"
<sb0>
you have one docking area on each of the 4 sides of the central widget
<rjo>
yes. i know. that is what i was referring to a few days ago.
<sb0>
in the two vertical ones, docks are stacked one on top of each other
<rjo>
so the central widget can not hold docks?
<sb0>
in the horizontal ones, they are side by side
<sb0>
and that's all. the pyqtgraph docking system was aimed at providing more flexibility (badly)
<sb0>
not as far as I can tell
<sb0>
it's designed for this MDI Area
<sb0>
maybe it's good enough, or even better than the docks...
<sb0>
rjo, the essential limitation of QMdiArea is all experiment docks will have to be confined within the main window. let me ask Ting Rei what he thinks about that
<rjo>
yes. if i look at it, the QMdiArea would be fine. Actually dragging MsiSubWindows outside of the MdiArea and un-pinning them is not all that needed in practice (and it would be tricky).
<rjo>
if you can fill your screens with all the docks, you are happy. then you have one screen (or a window spannning multiple screens) holding more or less only the MdiArea with the experiment editors.
<sb0>
Joe spoke about docking experiment plots with their editor, which QMdiArea would preclude, but that's perhaps not essential either
<rjo>
i can answer that for him.
<sb0>
(and the Qt docking system doesn't support that anyway either)
<rjo>
yes. i think slapping windows together from docks and hoping it would magically work is a dream.
<sb0>
I wouldn't be that pessimistic, afaict the issues with pyqtgraph are 1) a lot of plain bugs 2) usability issues with the implementation of drag and drop
<rjo>
let's stick with what we can do efficiently in Qt. that also has the huge advantage that the UI will be easily understandable and somewhat future-proof. i am pretty certain that Joe and Ting Rei are underestimating this advantage.
<sb0>
e.g. if the window is detached immediately when the drag and drop starts (like google chrome and qt do), then reorganizing docks is a lot easier
<rjo>
if you drag a tab within its row, nothing detaches.
<sb0>
yes, there are details like this, but the window is detached as soon as you move outside the row
<sb0>
whereas pyqtgraph only detaches when you drop
<sb0>
(and reattaches. the "double click to detach permanently" was another usability mistake)
<rjo>
sure. also a reason why pyqtgraph has roughly the same fate as Qwt.
rohitksingh has joined #m-labs
mithro_ has joined #m-labs
mithro has quit [*.net *.split]
mithro_ is now known as mithro
<cr1901_modern1>
rjo: Do you have my code handy for the widget? Would you be willing to add a print statement just above line 49 in scanwidget.py and query angleDelta.y() ?
<cr1901_modern1>
if angleDelta is less than 120 on your touchpad, indeed that's where I screwed up.
cr1901_modern1 is now known as cr1901_modern
<sb0>
whitequark, I'm going to contact spyder and see if we can use a common qt package. you said you improved upon theirs? what should I tell them exactly?
<cr1901_modern>
sb0: I cannot duplicate your fitToView bug, where it will move the slider twice when clicked twice. Can you give me an approximate range where that happens? The bug you're seeing should not be possible b/c fitToView works strictly in slider coordinates (0 to 99); fitToView should do nothing after the first application.
<whitequark>
sb0: the most important part was that their package missed the correct qt.conf
<whitequark>
the less important part is that they require a ton of crap like m4 and gstreamer to be packaged in conda, and it's not in any conda channel i can see
<whitequark>
so I just removed the m4 and such deps from conda deps, and disabled qtmultimedia entirely, removing the need to package gstreamer
<sb0>
can you elaborate on the missing qt.conf? I need to argue to them why they should use our package
<whitequark>
because you need dozens of other packages to do it
<whitequark>
flex, bison, m4, I think even gcc
<whitequark>
well, you've seen the bug with missing platform plugin, right?
<sb0>
oh, yes
<whitequark>
that's the problem.
<sb0>
so their package doesn't work either?
<whitequark>
I built their package as-is originally
<whitequark>
I don't know if the exact version installed from their channel will work, never tried
<whitequark>
note that the current version of our package is far from perfect and probably shouldn't be used exactly
<whitequark>
I'm not sure if their goal of qt4+qt5 coexistence is actually possible, but I haven't looked into it enough to convincingly make an argument either
<whitequark>
I suspect that it isn't, because there is only one qt.conf and the versions of qt.conf for qt4 and qt5 are mutually incompatible
<sb0>
whitequark, I get this garbage in the console http://paste.debian.net/389183/ but otherwise your qt/artiq packages works, on linux. thanks!
<whitequark>
oh yeah that was yet another problem with their package
<whitequark>
they do the conda prefix replacement thing in binaries
<whitequark>
which broke if the full path to the installed qt prefix was longer than 80 chars
<whitequark>
I ripped it off, which is the reason you see this garbage on the console
<sb0>
oh, that breaks the keyboard in the GUI...
<whitequark>
yes
<whitequark>
you need to set QT_XKB_CONFIG_ROOT to what it wants.
<whitequark>
hm, might be exposed in qt.conf
<sb0>
if there's no better way of fixing it, artiq_gui should set it
<sb0>
as well as artiq.applets.simple, I guess
<sb0>
they typically inherit the environment from artiq_gui, but running them standalone is an option too
<sb0>
how do distros package qt and fix this QT_XKB_CONFIG_ROOT? fakeroot and similar tricks?
<whitequark>
no
<whitequark>
it has nothing to do with qt
<whitequark>
it's xkb
<whitequark>
and distros always put xkb in the prefix it was compiled for
<whitequark>
so, the path that's embedded in libxkbcommon is correct, unlike our case
<sb0>
ah, and that's not compatible with conda envs?
<whitequark>
exactly
<sb0>
mh
<whitequark>
like I say, conda has a binary patcher that changes libxkbcommon in-place to fix the path
<whitequark>
but it's broken too
<whitequark>
if we enable it, buildbot cannot install qt
<sb0>
whitequark, do we conflict with the full anaconda? if so, we should probably tell users to install miniconda in the doc ...
<whitequark>
I believe we currently do, although I have not checked.
<rjo>
cr1901_modern: ha. very different behavior with our qt 5.5 now (i was using current ubuntu qt 5.5)
<rjo>
the delta is 120 for our qt.
<cr1901_modern>
what the hell lol. That'ss the delta I expected
<cr1901_modern>
but in any case, my wheelEvent was wrong (TM), so I will correct it.
<rjo>
but i have no idea where the difference comes from. but it is significant. both are supposedly 5.5.1
<whitequark>
configuration, possibly
<rjo>
whitequark: qt.conf?
<cr1901_modern>
I keep hearing about that file. Guess it's a *nix thing
<rjo>
... or presence/absence of fancy touchpad plugins.
<whitequark>
no
<whitequark>
and no, it's not a *nix thing, it's on Windows too
<rjo>
my system qt does not have qt.conf
<whitequark>
it does not have it because it's installed in its configured prefix
<whitequark>
so, all default values are valid
<rjo>
sb0: we can't tell people that artiq breaks anaconda. that doesn't fly. artiq needs to coexist.
<rjo>
whitequark: where is qt configured?
<whitequark>
rjo: ./configure call in bld.bat/build.sh in conda recipe
<whitequark>
in case of conda, no single configuration value is valid, because conda relocates qt
<whitequark>
so, you need qt.conf.
<rjo>
there is no runtime config?
<whitequark>
qt.conf is the runtime config.
<rjo>
whitequark: where would system qt differ from your qt re touchpad stuff/wheel events?
<whitequark>
I don't know exactly, but I think it uses Qt-internal XInput or something like that
evilspirit has joined #m-labs
<whitequark>
that might or might not be related, it's been a while since I looked at XInput closely.
<rjo>
but that would probably be a compile-time feature
<whitequark>
yes.
<whitequark>
sorry, too many conversations to follow at once. qt.conf only configures paths.
<whitequark>
there is no runtime config for all other features.
<rjo>
there are also other differences between my system qt5 and artiq qt5: fonts, sizes, and what looks like AA.
<whitequark>
oh.
<whitequark>
yeah, that makes sense, it does not pick up your DE configuration
<sb0>
rjo, thankfully, the new docking system doesn't do silly things when you change dpi or font sizes
<whitequark>
so that's likely the reason for the touchpad problem as well
<whitequark>
I continue to suggest that we just use the system Qt on Linux...
<whitequark>
this will solve all our problems in one large sweep.
<whitequark>
specifically Qt is a good choice for this, because Qt is ABI-stable within a major version upwards *and* downwards
<rjo>
do we have qt5 etc for ubuntu 14.04? would we also use system pyqt5?
<sb0>
what about qt 5.6 and python 3.5.1?
<whitequark>
14.04 has qt5.2
<sb0>
quite likely artiq will soon need python 3.5.2 as the multibind patch that finally made it to 3.5 has the localhost bind problem
<sb0>
anaconda tracks python closely, distros tend not to
<whitequark>
yes, I do not suggest doing the same for python
<whitequark>
the problem is that even if we do build Qt for Conda, it still loads local libraries provided by DE
<whitequark>
except that doesn't work, because conda package is broken in yet another way
<whitequark>
i.e. it should provide libxkbcommon itself
<sb0>
whitequark, actually, what prevents usage of the system libxkb stuff on linux?
<whitequark>
hm
<whitequark>
good question
<sb0>
i remember you said earlier its ABI stability was good
<sb0>
and this way, no binary patch hack is needed
<whitequark>
this:
<whitequark>
-xkb-config-root $PREFIX/lib \
<whitequark>
and this:
<whitequark>
-qt-xkbcommon \
<whitequark>
yes, it should be fine to build conda qt with host libxkb/libxcb even
<whitequark>
rjo: ahhhh yes I think I found your touchpad issue
<whitequark>
-no-libudev \
<whitequark>
ah sorry no nevermind, it doesn't use that for input devices.
<whitequark>
it's for IOKit
<rjo>
is libxcb API stable wnough? what happens if the target system uses wayland? ;P
<whitequark>
if the target system uses wayland and our Qt is built with Wayland, Wayland will be used...
<whitequark>
but it is not built with Wayland.
<whitequark>
I'm not sure if embedding would work on Wayland at all though, I don't think Wayland has any equivalent for it at all
<whitequark>
lol
<whitequark>
they suggest making your application run an embedded Wayland instance and then being a compositor (!!)
<whitequark>
alternatively they suggest communicating GEM (Linux low-level graphics API) buffer names over DBus or whatever
<whitequark>
right, the latter one doesn't handle input
<whitequark>
to embed the flash player, Firefox becomes a Wayland compositor.
<whitequark>
this is fucking insane.
<rjo>
will HTML6 have native wayland client support?
<whitequark>
there will be no HTML6
<whitequark>
HTML5 is a rolling release.
<cr1901_modern>
Sounds like Wayland is doing a great job of reducing the entry barrier for low level window system operations, just like X did /s
<rjo>
cr1901_modern: afaict the left edge of both markers is the relevant one w.r.t. the axis. that should be the center of the markers if at all possible.
<rjo>
cr1901_modern: i feel like there is probably code from you in the pipeline addressing some of the things from last time. should i wait?
<cr1901_modern>
sure
<rjo>
cr1901_modern: out-of-view sliders etc
<cr1901_modern>
(ssorry "S" key is going out to lunch)
<rjo>
context menu
<cr1901_modern>
rjo: Not possible in the general case. For specific qt backends I can change it, but the Windows Vista and 7 backends provide no opportunity to change it.
<rjo>
maybe "lunch residue S key"?
<rjo>
cr1901_modern: which one?
<cr1901_modern>
That would be funny if it werent true (S key).
<cr1901_modern>
The sliders cannot be centered like that in all backends
<cr1901_modern>
I cannot change the graphic of the sliders in the Vista/7 bakend
<cr1901_modern>
What I COULD do is perhaps move the axis instead
<cr1901_modern>
so the center of the slider points to the desired point
<cr1901_modern>
I cannot change the graphic of the sliders in the Vista/7 backend because Qt itself provides no opportunity to do so before it calls into Window's rendering functions to display each subcontrol (widget portion)
<sb0>
so uninstalling a package in conda doesn't even warn when other packages depend on it?
<sb0>
blergh
<cr1901_modern>
Maybe I can look into sstylessheets again too
<sb0>
whitequark, even though spyder has a qt5 package in their repository, their IDE uses qt4.
<rjo>
cr1901_modern: ah. i see. let's be pragmatic. if offsetting/scaling the axis does it, that's fine.
<sb0>
let me double check that...
<sb0>
reinstalling a new miniconda right now as of course, caches, channels etc. are global in conda, and fucking my env fucked the whole install
<rjo>
cr1901_modern: also there is some tricky resize behavior. the axis resizes wrongly if the window size changes.
<cr1901_modern>
The *axis* resizes wrongly?
<cr1901_modern>
Ahhh, you want the same range to be displayed after a resize
<cr1901_modern>
Okay, screw it. I'm using QTransforms. Sick of manually calculating them
<rjo>
yes. i want the axis to match where the sliders are.
<rjo>
and can you increase the resolution of the sliders by about ~10. you said that max is 4096 positions, right?
<cr1901_modern>
The max is 4096 positions before a function that I depend on starts failing to return valid values*. Perhaps I can discuss more in a bit after I fix the transforms.
<cr1901_modern>
before a Qt function*
<rjo>
and arbitrary combinations and iterations among the set-view-to-range and set-range-to-view actions should be idempotent (modulo rounding errors).
<rjo>
now you have 100 positions. 1024 should be good.
<cr1901_modern>
Idk what behavior sb0 saw. I can't duplicate it, and fitToView should be idempotent b/c it only queries values in slider space
<cr1901_modern>
(0 to 99, or 0 to 1024. We get the range of valid slider values, multiply by 1/3 and 2/3, and then set the sliders to the relevant position. That should be idempotent)
<cr1901_modern>
I'll write a small document on how the widget works, so if some poor soul doesn't remember their linear algebra, they can know what coordinate systems the widget works in.
<rjo>
set-range-to-view is idempotent here.
<rjo>
but toggling between the two is not.
<cr1901_modern>
That's expected right now; the view-to-range is broken
<cr1901_modern>
Let me figure out all the coordinate systems required and then modify my proxy class to fix current issuess.
<rjo>
and both my system qt and artiq qt have momentum in my scroll wheel. if i go fast i still get to 1e-12 in one swipe.
<cr1901_modern>
Even when te delta iss 120?!
<rjo>
and if i do that, the rounding errors make the sliders flip sides repeatedly.
<cr1901_modern>
yes, that'ss a bug I know about
<cr1901_modern>
Is the delta 120 during your touchpad swipes? We have a big problem if that's so
<cr1901_modern>
angleDelta.y()
<GitHub18>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vgHrm
<rjo>
yes. all 120. but as with all exponential things stuff grows pretty quickly.
rohitksingh has quit [Ping timeout: 276 seconds]
<cr1901_modern>
The problem isn't the exponential growth. It's that ith a ssingle touchpad swipe you are receiving hundreds of wheelEvents with the same magnitude as on my machines in the time that I receive maybe a dozen
<rjo>
cr1901_modern: yes. there are maybe 90 events for one swipe.
<cr1901_modern>
What you suggessted was my next idea until rjo mentioned the displacement. Qt docs say that angledelta of 120 is "standard"/not smooth scrolling.
<sb0>
whitequark, yeah, at least since the new server setup, modifying the m-labs.hk dns is trivial.
<whitequark>
no, I meant my workaround for the RTIO core bug
<whitequark>
did you restart the buildbot?
<sb0>
no, how do I do that?
<whitequark>
I have a script for that, might as well put it into the repo
<rjo>
i think angleDelta is the right thing to look at. but just in case, i would zoom by 0.05/120*angleDelta().y()
<whitequark>
what's the new hostname?
<sb0>
bme.m-labs.hk
<whitequark>
me ?
<whitequark>
*bme?
<sb0>
bme
<whitequark>
couldn't you have called it buildbot.m-labs.hk?
<rjo>
whitequark: i just restarted the buildmaster. was that wrong?
<whitequark>
and I'll remove the /buildbot/ in the path
<rjo>
or build.m-labs.hk
<sb0>
build or buildbot?
<GitHub86>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vgH6L
<sb0>
ok. saved. now it'll just take a bit of time for the server's cron job to pick up the change, and maybe for dns records to propagate...
<whitequark>
nah, there's no dns propagation for the new records
<whitequark>
there isn't any intrinsic propagation time for 2nd-level domains too, by the way
<rjo>
cr1901_modern: ah. and the printing of the axis values themselves: should be "%g" style. but with the added wrinkle that they should all be with the same decisions made (same exponent, same %f or %e decision).
<whitequark>
especially if you don't have any garbage intermediares that cache NXDOMAIN but even if you do, just don't ping your domain before buying it
<sb0>
there are some funny cache issues sometimes, since I have a catchall that sends to the webserver
<whitequark>
ah.
<whitequark>
yeah.
<rjo>
cr1901_modern: and i can't seem to edit the spin boxes.
<sb0>
cronjob runs every 10min
<rjo>
so nonody look at that url in the next ten minutes...
<sb0>
?????
<sb0>
I deleted miniconda3 folder
<sb0>
did not configure the m-labs repos
<whitequark>
yes
<whitequark>
.condarc is in ~
<cr1901_modern>
And I just lost another fucking laptop key after I made an order to purchase replacement. Great.
<sb0>
alright. let's try this again...
<sb0>
whitequark, yes. it's qt4.
<cr1901_modern>
rjo: They should be connected. But in any case... can you add a print to wheel event that does: print(ev.source)?
<sb0>
at least it installs qt4
<whitequark>
sb0: that makes no sense
<sb0>
maybe for ipython? it also installs that
<sb0>
after that install finishes, i'll check precisely what it imports
<rjo>
cr1901_modern: what's connected?
<cr1901_modern>
rjo: signals to spinboxes
<rjo>
cr1901_modern: i meant keyboard editing
<sb0>
maybe it's qt5, embedding qt4, that talks over 5 TCP sockets plus zeromq to a python interpreter
<sb0>
isn't modern software awesome
<cr1901_modern>
Hmm, it works on my end
<rjo>
cr1901_modern: works on my system qt but not in artiq qt.
<rjo>
cr1901_modern: that bug sounds very different to my behavior.
<rjo>
cr1901_modern: the behavior is fine. i usually don't give swipes that much momentum. but even for mice i would think that 20% per wheelEvent is way too much.
<cr1901_modern>
I'll lower it to 5% then
<whitequark>
wow, win7 with 1G is *slow*.
<whitequark>
"slow" doesn't even begin to describe it
<cr1901_modern>
rjo: My main concern is that it behaves differently on different machines, and just changing the zoom factor won't solve the real problem.
<sb0>
cr1901_modern,
<sb0>
units: 1.5983352577618037e-16
<sb0>
bias: 48.75000164550451
<sb0>
realCenter: 48.750001645504554
<sb0>
then click fit to view twice
<sb0>
and the cursors will move twice
<sb0>
keep zooming in, and it crashes after a while...
<cr1901_modern>
Okay, that must be a precision thing creeping in
<cr1901_modern>
Yes,I need to fix that- it's an assertion failure in the ticker
<sb0>
er actually it's
<sb0>
units: 5.623642243179056e-18
<sb0>
bias: -31.249999999998195
<sb0>
realCenter: -31.249999999998195
<sb0>
but yes, sounds like FP precision problem
<rjo>
cr1901_modern: i don't think it behaves differently. my touchpad zoom is just a tad sensitive.
<rjo>
and apparently so is sb0's/
<rjo>
.
<cr1901_modern>
Then I guess it'smy netbook and laptop that are wrong
<rjo>
whitequark: where do i look for /munin/ now?
<cr1901_modern>
hmmm...
<cr1901_modern>
I think that's ssomeone my mutuals follow on the Twitters?