<cr1901_modern>
Oh fuck me... that might be part of it
<sb0>
"wheelEvent() is called whenever the user turns the mouse wheel **while the widget has the focus.**"
<sb0>
can your widget receive focus?
<cr1901_modern>
I don't know. The widget is part of a layout; I wonder if the layout has default focus rules
<sb0>
more precisely, ScanAxis
<cr1901_modern>
Could you do me a favor and add a printf line at line 49 and then try zooming?
<cr1901_modern>
That way I know whether wheelEvent is even being called on your machine. Regardless, I should be either accepting the event or calling the superclass wheelEvent, so that should be changed.
<sb0>
cr1901_modern, oh, actually zoom works
<sb0>
but you have to be on the axis
<sb0>
cr1901_modern, can you forward the slider scrollwheel events to the axis?
<sb0>
cr1901_modern, the zoom point should be centered on the mouse cursor. it's somewhat off...
<cr1901_modern>
sb0: That's deliberate; it's so that if your mouse is near the edge, it won't have a tendency to knock one of the sliders off the screen, but I'll change it if you want.
<sb0>
how would it knock a slider?
<sb0>
the mouse wheel should do nothing on sliders
<cr1901_modern>
By knock off, I mean "the slider is out of range, so hide it"
<cr1901_modern>
not that the actual value repr by the slider changes
<sb0>
ok, and what is the problem with hiding sliders while the mouse is over them?
<sb0>
cr1901_modern, re. zoom centering. let's say I'm in a situation where I'm so zoomed out that both sliders are shown at the same position, even though they have different value
<sb0>
what I want is: by pointing at the overlapped sliders with the pointer and zooming in, they will be shown separated, both at the same time, after a while
<sb0>
for all its faults, pyqtgraph does this well
<cr1901_modern>
That's the intended behavior, and it does work on my end
<sb0>
cr1901_modern, constantly zooming in crashes the program with
<sb0>
File "/home/sb/scanwidget/ticker.py", line 18, in step
<sb0>
assert i > 0
<sb0>
AssertionError
<sb0>
cr1901_modern, there is some tendency to re-center the sliders or something
<cr1901_modern>
that's b/c of floating point precision limitations
<cr1901_modern>
sb0: Yes, I see what you're saying now. I screwed up/I'll fix it.
<sb0>
then block zooming or something - it should not crash
<cr1901_modern>
sb0: Just to reiterate, the behavior you want is that if you zoom the mouse if the cursor is in the center of two overlapped sliders, the sliders should separate equal distance (in pixels) relative to the center of your zoom
<sb0>
yes
<sb0>
sounds good.
<cr1901_modern>
I'm trying to visualize what happens then if you try to zoom at any other point besides "the center of the sliders".
<sb0>
look at pyqtgraph... it may not be a reference for code quality, but its plot UX is pretty good IMO
<cr1901_modern>
sb0: My main concern is the following: What if you want to center a specific point in the axis view, and then click "fit to view"? Is that an operation you expect to be doing?
<sb0>
fit to view should simply position the sliders at 1/3 and 2/3 of whatever the axis view is at the moment
<cr1901_modern>
Right. FitToView does that already. I'm asking whether the main use for that is to center the sliders about a desired point?
<cr1901_modern>
actually nevermind, if it's a problem we can discuss it later. I'll just code
<sb0>
that's equivalent, the desired point is the middle of the axis as 1/3 and 2/3 are symmetric
<sb0>
FitToView seems to be working fine, except that when clicking it twice there are some situations where a slider moves the second time, which is weird
<sb0>
the button should be much smaller (see pyqtgraph) or be a context menu though
<cr1901_modern>
Maybe a context menu might be better since we agreed to drop pyqtgraph, and I had to discard QGraphicsView
<cr1901_modern>
Fit to view should never move a slider twice if they are already at the correct position. Hmmm...
<cr1901_modern>
sb0: Can you give me an approximate axis range where this happens? If I get desperate, I'll have to make a debug var for it
<cr1901_modern>
rjo: Thoughts on fit to view/zoom to fit being a context menu?
<rjo>
cr1901_modern: to save space?
<whitequark>
sb0: why did you install cygwin on the buildserver?..
<whitequark>
cygwin puts lots of crap into global scope, I specifically avoided having it
<rjo>
yes. please don't build any packages with cygwin.
<whitequark>
sb0: basically, stop fucking with the buildserver
<whitequark>
until I provision a new, separate one specifically for experiments
<cr1901_modern>
rjo: B/c it's what sb0 wants :P
<whitequark>
this one should now be reinstalled from scratch, as if there wasn't enough headache
<whitequark>
siiiiigh
<whitequark>
though it's my bad too, I should have made a clean snapshot from it.
<rjo>
cr1901_modern: then it is probably because i mentioned that the scanwidget should be more compact. well. if you want to set up a scan range, then you look for the range by zooming and dragging. only then i would want to snap the sliders to view. (1/n and (n-1)/n relative (view) position where n ~ 6 maybe).
<rjo>
i would use fit-to-view pretty frequently. fit-view-to-range less so.
<rjo>
but ok. if (and only then) it makes the widget more compact, hide it in the context menu.
<cr1901_modern>
rjo: The slider and axis are two separate widgets. Unless I combine them into a single custom widget, I can't really compact them much more
<cr1901_modern>
which I can do, but it'll take time (I'm sensing a pattern here)
<cr1901_modern>
rjo: Please keep in mind that because I was unable to leverage QGraphicsView, I am now handling a lot of state and coordinate conversions manually that were done for me automatically.
<cr1901_modern>
rjo: I thought we agreed snap-sliders to view would be 1/3 and 2/3 (I can change this)
key2 has quit [Ping timeout: 252 seconds]
<whitequark>
anyway, I put the old VM on port 5901
<whitequark>
sb0: ^
<whitequark>
now you can fuck it up all you want...
<rjo>
cr1901_modern: having the axis and the sliders different widgets is fine.
<rjo>
cr1901_modern: 1/3 and 2/3 seems to waste a bit of visually important axis space outside the sliders. maybe n ~ 6-10 is actually better
<rjo>
but looks good. i like the arrangement.
<sb0>
whitequark, how does one get ssh otherwise? and how does installing cygwin damage a system?
<whitequark>
windows has native openssh now
<sb0>
no, that's not released yet
<whitequark>
and cygwin puts its crap everywhere in the PATH
<whitequark>
just like mingw and most other devtools
<cr1901_modern>
rjo: Alright. Ack
<sb0>
what problem does that cause exactly?
<whitequark>
really, it's not just cygwin, all windows devtools are braindead like that, so having a separate buildbot system is long overdue
<whitequark>
wrong binaries are invoked
<whitequark>
I'm not going to wait until it causes some specific problem, it's not worth the time to debug it
<rjo>
cr1901_modern: the zooming seems very fast (here). i seem to be getting into nasty 1+e60 territory quickly.
<sb0>
can't you just reset the path for those scripts that are sensitive to it?
<whitequark>
I'm just going to provision a new system right now
<whitequark>
no
<whitequark>
I'm not going to.
<whitequark>
'just'
<whitequark>
just ... no
<cr1901_modern>
rjo: That shouldn't be happening at all o.0;
<sb0>
whitequark, has there been *any* real-world problem caused by cygwin so far?
<cr1901_modern>
It's the same zoom factor as previous
<sb0>
not just hypotheticals
<whitequark>
not that I'm aware of
<sb0>
ok. so please fix qt5 and then move on to the long overdue compiler problems.
<whitequark>
what do I proceed to next, RTIO log as you wrote in that email?
<sb0>
yes
<whitequark>
ok
<whitequark>
btw do I close issues when fixed or comment there and wait for you to close?
<rjo>
close them when they are fixed.
<sb0>
if the GUI actually runs, and you can talk to the core device, then close
<whitequark>
well, let's wait until rjo tests it on linux
<whitequark>
and I can't close the other one because conda install artiq does not in fact work
<whitequark>
because of that conda bug...
<rjo>
for the conda-build version issue (GIT_*), if we want to use that we should wait a bit (few days) until the dust settles in conda-build.
<rjo>
otherwise we can rig it a bit and use substitution variables in gitattributes.
<rjo>
... if we need packages before that.
<sb0>
730 conda issues open. will that one get fixed?
<sb0>
:)
<whitequark>
conda-build has only 243.
<whitequark>
also, I would really want to know why didn't you apply this logic when you were selecting conda...
<rjo>
whitequark: me?
<whitequark>
no, sb0
<whitequark>
you didn't choose conda...
<sb0>
he did
* whitequark
stares at rjo
<rjo>
whitequark: well i proposed it in the beginning. if there is a better way to package all the packages for win and linux, that would be an alternative.
<rjo>
is there?
<whitequark>
literally distributing tarballs manually is a better way
<whitequark>
well, building
<rjo>
are you sure? how do you upgrade? how do you downgrade? just for starters?
<whitequark>
rm
<rjo>
how do you make a python environment whith those?
<whitequark>
conda doesn't do anything special, it builds python with a known prefix and then fixes shebang
<whitequark>
you don't even have to fix shebang during installation time if you do /usr/bin/env, it's enough to put bin/ in PATH
<whitequark>
I did this many times for portable linux (and windows, obviously) packages
<whitequark>
like, I'm not being facetious when I say building tarballs is a better way, it would mean less wasted time for sure
<rjo>
and plain tarballs don't play with any other packaging system. not pip, not conda.
<rjo>
rm what? where do you get the list of files to remove?
<whitequark>
they play with pip in the same way conda does: by providing a python environment
<whitequark>
rm the entire installation, download a new version, unpack.
<whitequark>
it's under 100M compressed
<whitequark>
or is NIST that low on bandwidth?
<whitequark>
as for other packaging systems... it'd be trivial to wrap the tarball in a .deb that puts it in /opt/artiq
<rjo>
you might be overlooking that most people want a bunch of additional packages in that python installation.
<whitequark>
and whatever was for windows (nuget?)
<whitequark>
hm.
<whitequark>
right, I forgot about that.
<whitequark>
sb0: this actually would break stewart's favorite idea, to use nixos
<whitequark>
since it would also not play well with pip in presence of upgrades, unless someone wraps all those packages in nix
<whitequark>
which is... unfortunate, as I hoped to use nix once it gets free of cygwin on windows
<rjo>
can we downgrade conda-build to 1.18.1 on the builders?
<whitequark>
sure
<rjo>
and turn the upgrading off?
<whitequark>
let me
<whitequark>
er
<whitequark>
I don't think conda can do that
<whitequark>
but fortunately, it should not get auto-upgraded either way
<whitequark>
because that doesn't happen for the root environment during normal builds
<rjo>
ok.
<rjo>
but i think it should be fine with not upgrading conda-build itself.
<sb0>
nix doesn't seem to support wndows very well, too
<cr1901_modern>
nix is Linux only I believe?
<whitequark>
sb0: I asked and it should work for our use-case right now, but unfortunately, cygwin
<whitequark>
and adding cygwin is almsot as bad as having conda
<whitequark>
rjo: idea.
<whitequark>
what if we go with tarballs, but do the same thing as pip install --user does
<whitequark>
except instead of installing into ~/.pip it would install into /opt/artiq/user-packages
<cr1901_modern>
I almost feel like a heretic for asking, but why can't we say f*** it to the Unix hierarchy and just let all of artiq and it's dependecie live in a subdirectory of /opt /
<whitequark>
you get the idea
<cr1901_modern>
Or... basically what whitequark just said
<whitequark>
cr1901_modern: that's already what happens
<whitequark>
with conda
<whitequark>
it has its own prefix
<cr1901_modern>
Oh, I was not aware of that (on Windows)
<whitequark>
I don't actually use conda at all for development and I'm fine with just Debian packages
<whitequark>
so I'm not entirely convinced we actually need conda on linux
<whitequark>
(in fact, as you may have seen above, conda does not work in my machine, and no one gave a fuck about the bug I reported...)
<cr1901_modern>
I don't think tarball releases are bad as long as they're kept in a central location and the users don't try to do anything goofy like mix and match library versions
<whitequark>
conda is basically the same as tarball releases
<whitequark>
except more finely-grained
<rjo>
whitequark: what do you do if a user installs qt (let's say 4) with conda and we have qt (5)?
<whitequark>
and with many more bugs
<cr1901_modern>
Yea, I was about to say, seems the functionality it adds is brittle
<whitequark>
rjo: can you elaborate? we have where?
<whitequark>
in the tarball?
<rjo>
whitequark: yes
<whitequark>
python in the tarball is linked with appropriate rpath, so it will pick up only its own qt
<whitequark>
in fact it will never even look into /usr/lib unless it cannot find a library in its own prefix
<whitequark>
which should never happen
<whitequark>
well, for libraries we ship with it
<whitequark>
it should look up stuff like X guts on the host system
<sb0>
wow, qt's docking system doesn't seem completely lousy with bugs
<sb0>
surprising
<whitequark>
the rpath it's linked for is relative. $ORIGIN/../lib
<rjo>
if you have e.g. pyqtgraph in /opt/artiq/user-packages and in ~/src/conda/envs/stuff ?
<whitequark>
so we don't have to do patchelf shit conda does
<whitequark>
that's irrelevant
<whitequark>
qt is a native library, so it will only be picked depending on the location of python executable
<cr1901_modern>
sb0: Did you start on replacing the docking system or are you just doing a proof of concept?
<whitequark>
oh, you mean which pyqtgraph would be picked?
<rjo>
or replace that by any of the other packages that we have.
<rjo>
and where would you install qt then anyway?
<sb0>
been replacing it
<whitequark>
conda will not *combine* with the tarballs, it's an either-or, just like conda and system python today
<whitequark>
tarballs provide their own separate environment
<rjo>
system python also has package overlap with us.
<whitequark>
sure
<whitequark>
tarball python will not look into system python directories at all
<whitequark>
well, unless you want it for some reason, i guess? either option is trivial to do, but not looking seems safer
<whitequark>
there's the C extensions
<whitequark>
they're prone to breakage due to ABI change and those are obscure
<rjo>
i don't see how i can install additional packages in that artiq-python distribution.
<whitequark>
you add it to your PATH and then do `pip install whatever`
<whitequark>
which goes into user-packages.
<rjo>
but those packages will then be found before the artiq ones or after (there are problems in either case).
<whitequark>
depending on how I set up search paths, either case is possible
<rjo>
and both are bad ;)
<whitequark>
but we have the exact same situation with conda
<rjo>
because pip installing pyqtgraph (or accidentally as a dependency) will break ours and the other way around.
<whitequark>
that will also happen with our today's setup
<rjo>
whitequark: no. because conda has (or is supposed to have) dependency management.
<whitequark>
it does not integrate with pip
<whitequark>
hell, try it
<whitequark>
like I'm saying, conda is a glorified tarball unpacker
<whitequark>
it just puts its own stuff into search path, it doesn't even try to cooperate with pip
<rjo>
exactly. a tarball unpacker with many tarballs. tarballs that people want. tarballs that artiq-python-distribution does not have.
<whitequark>
no, not really
<whitequark>
because pyqt's API has changed, anything installed from anaconda.org's repos that depends on, say, pyqt
<whitequark>
will either break during installation (because they specified the version) or when you run it (because they did not)
<whitequark>
this is not true for all our dependencies, but probably for a good chunk of them.
<rjo>
yes. that's why i begged ysionneau to make llvmlite_artiq coexist with llvmlite.
<whitequark>
they simply cannot be used together in any way whatsoever
<whitequark>
just like conda doesn't break system python...
<rjo>
whitequark: if conda-python happens to be in PATH and artiq-user-packages in sys.path, it does.
<whitequark>
why would they be in sys.path? the config that puts them in search path is specific to the prefix
<whitequark>
I can't imagine any reason it would be accidentally picked up
<whitequark>
it's hard enough to do it on purpose
<whitequark>
btw, almost every argument you can invent about artiq-python-distribution also applies to system python
<rjo>
i am not suggesting that using system-python would work at all.
<whitequark>
well, it works very well for me, better than conda in fact
<whitequark>
but that's not what i'm saying
<rjo>
after all it is not portable ;)
<whitequark>
i'm saying that if system python does not interfere with conda, there's no reason artiq-distribution python would
<rjo>
what is system-python on windows if not conda-python?
<whitequark>
huh? python distributes msi's for windows
<rjo>
ah. so you also want to build numpy etc?
<whitequark>
`pip install numpy`
<whitequark>
you don't even need full MSVC, MS distributes a stripped-down MSVC specifically for building python extensions
<rjo>
that won't work well.
<whitequark>
why?
<whitequark>
the installation procedure is not more complex or even substantially different from installing conda
<rjo>
how do you enforce that that numpy matches the one that a cython is built against? and how do you enforce that they are all built by sufficiently compatible msvc (stripped or not)
<whitequark>
er, what?
<rjo>
look at why conda encodes numpy and msvc versions into the packages.
<whitequark>
oh, cython, not cpython
<rjo>
yes.
<whitequark>
so, speaking of MSVC first, there is exactly 1 version of MSVC that will work, the one used to build the main python executable
<whitequark>
anything else will simply not link because msvcrt is incompatible
<rjo>
how do you get the corresponding numpy build? "pip install numpy" is unlikely to work, right?