<GitHub154>
buildbot-config/master 90b9a01 whitequark: Ping the board after flashing to make sure it's up.
bb-m-labs has joined #m-labs
<sb0>
cr1901_modern, the sliders should probably disappear progressively when they are moved out of the view, instead of being hidden suddenly
<sb0>
it's just a detail, but I wonder if you are implementing this right...
<cr1901_modern>
sb0: I don't know if that's possible to tell qt to hide part of the slider, short of hacking qt internals (whatever backend is called by the QStyleOption class)
<cr1901_modern>
The dual slider works b/c Qt exposes enough information to let me control the order and the number of subcontrols (handles, groove, etc) manually. But I don't actually get to choose the pixel location that the slider is drawn; Qt does (sliderValueFromPosition/sliderPositionFromValue). And it will map the minimum possible value the slider can take to coincide with the left side of the groove.
<cr1901_modern>
What's even worse is that on Windows Vista and above, Qt doesn't actually draw the widgets; it defers to Windows to do so, and I'm not aware of anything in the Windows API that lets you draw a slider with the behavior you want
<sb0>
bb-m-labs, force build artiq
<bb-m-labs>
build #380 forced
<bb-m-labs>
I'll give a shout when the build finishes
<cr1901_modern>
Now, if QGraphicsView worked, we wouldn't have this problem.
* cr1901_modern
grumbles
<cr1901_modern>
sb0: I understand/agree with the behavior you want. But this is a limitation of using a slider widget to model effectively infinite ranges. What I COULD do is extend the slider so that if the slider disappears while the mouse is held, the new position is still honored (so dragging a slider to the edge of the screen and then releasing will effectively place the slider there)
<sb0>
this behavior is consistent with other UIs I think ?
<sb0>
is that hard to implement, and will it require arbitrary sizes that may break on high-resolution or multi-screen configurations?
<sb0>
also, when scrolling, ideally, the sliders should also appear and disappear progressively
<cr1901_modern>
sb0: this behavior is consistent with other UIs I think ? <-- unsure. I don't know of many (any?) projects which uses a slider where out of bounds graphically is a valid value.
<cr1901_modern>
sb0: is that hard to implement, and will it require arbitrary sizes that may break on high-resolution or multi-screen configurations? <-- Two part answer: 1. The way I intended to implement this only depends on Qt returning valid x-coordinates relative to the left side of the widget, while the mouse is outside of the widget.
<sb0>
whitequark, it doesn't receive the pulse at all.
<sb0>
weird
<whitequark>
the cable is there, if it fell off, then another test would start failing
<whitequark>
test_loopback_count
<sb0>
didn't that work before?
<cr1901_modern>
2. If you have a slider that's more than 4096 pixels wide, things will start breaking
<sb0>
cr1901_modern, why?
<whitequark>
sb0: it worked with ttl_inout
<whitequark>
that's probably related somehow
<sb0>
is with parallel/sequential doing the right thing?
<whitequark>
I've tested it fairly extensively..
<sb0>
e.g. if the gate opening is borderline due to problems with that it can fail intermittently
<sb0>
alternatively
<sb0>
loop_out is left in a high state by a previous test
<sb0>
let me try
<cr1901_modern>
sb0: Because Qt's functions from mapping from a slider value to pixel value do not work correctly if the slider has more than 4096 positions.
<cr1901_modern>
I think what I should do is figure out "why" by probing the source
<GitHub197>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vatpt
<GitHub197>
artiq/master d0cf589 Sebastien Bourdeauducq: test/rtio/Loopback: ensure loop_out is low before starting test
<cr1901_modern>
"This function can handle the entire integer range without overflow, providing that span is less than 4096." :/
<sb0>
cr1901_modern, that limitation is only if you actually use the entire integer range AFAICT
<cr1901_modern>
sb0: I assume the desired behavior you want is that the slider should always be movable by one screen pixel, regardless of your monitor setup/the size of the widget?
<sb0>
yes, but assuming size < 4096 for this widget sounds reasonable
<sb0>
however, mouse drag-and-drop may be more than 4096 pixels
<sb0>
bbl
sb0 has quit [Quit: Leaving]
<cr1901_modern>
"sb0: also, when scrolling, ideally, the sliders should also appear and disappear progressively" <-- Non-trivial to implement b/c QStyle will clamp the sliders to within the widget when drawing. I will mull this over, but I feel like this is going to be A LOT of work. At the very least, reimplementing small parts of QStyle in pyQt.
<GitHub155>
buildbot-config/master e121958 whitequark: Trigger artiq-win64-test from artiq.
sb0 has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
<sb0>
rjo, bah, of course I looked at the commit log.
<sb0>
okay so what is left for 1.0 now is a few compiler details (232, 311), qc2, hardware tests for spi/pdq/i2c/dds, fancy scan widget, analyzer buffer bugfix
<whitequark>
hopefully i'll do both 232 and 311 tomorrow
<GitHub55>
[misoc] sbourdeauducq pushed 1 new commit to master: https://git.io/vaqCn
<GitHub150>
[misoc] sbourdeauducq deleted asyncserial at 5422d4b: https://git.io/vaqCW
cr1901_modern has quit [Read error: Connection reset by peer]
<_florent_>
sb0: I'm not sure changing stream API and removing EOP is a good idea
<_florent_>
that's maybe useful for the analyzer, but for others application that's making things complicated (ex liteeth_mini)
<GitHub49>
[migen] sbourdeauducq pushed 1 new commit to master: https://git.io/vaqlG
<GitHub49>
migen/master 8a514e9 Sebastien Bourdeauducq: use https url for m-labs.hk
<sb0>
_florent_, where did I say EOP should be removed?
<_florent_>
I think we should keep stream like that but maybe introduce a kind of protocol for the analyzer
<sb0>
my proposed change was to disable data transfer when EOP=1
<sb0>
so that you can know the lenght of the packet after the fact, which is what the analyzer needs to flush its buffer correctly
<_florent_>
ah, sorry then I missunderstood
<sb0>
*length
<sb0>
the disadvantage of this protocol is, it is slower when packets are short
<sb0>
since you need another cycle for EOP
<sb0>
but AFAICT that's not an issue for ethernet and video
<_florent_>
yes that's acceptable in must cases
cr1901_modern has joined #m-labs
<_florent_>
is it what you want to do: keep stb/ack behaviour for data/eop, stb=1, eop=0 --> it's a data, stb=1, eop=1, it's an eop
<_florent_>
or do you want to simply ignore stb when eop=1
<sb0>
so the analyzer shutdown procedure would be: CPU writes to the stop CSR, in response the MessageEncoder stops sending data and generates EOP, the converter flushes and finishes writing whatever it had in memory, and shutdown is complete when the dataflow network isn't busy anymore
<sb0>
one should be careful that busy goes 1 as soon as the stop CSR is written, to avoid a nasty race condition
<sb0>
I prefer to keep a single qualification signal, so ignore eop when stb=0
<sb0>
(but that's a detail)
<_florent_>
ok
<sb0>
_florent_, do you think the analyzer can work that way?
<_florent_>
yes that seems fine
<_florent_>
but before working on the analyzer, I'd like to: change the behaviour of eop on misoc and adapt liteeth_mini
<_florent_>
and before that it would be nice to merge the patch I sent you that clean up the converter
<sb0>
ok. just want to make sure this change will be useful and we could use the same dataflow in the analyzer and your designs in the end
<sb0>
i'll look at your patch shortly, either this evening or tomorrow hkt
<_florent_>
ok thanks
<GitHub63>
[misoc] sbourdeauducq pushed 1 new commit to master: https://git.io/vaq44
<GitHub63>
misoc/master 7bc827a Sebastien Bourdeauducq: flterm: use our asyncserial
<_florent_>
but for my designs, I found the actual behaviour of eop easier
<_florent_>
and I'd like to convert them to axi stream in the future (stb/ack/eop --> valid/ready/last)
<sb0>
whitequark, can you add a serial port on the win7-experimental machine (not urgent)?
<_florent_>
where last is asserted on the last data (same behaviour as we have actually)
<sb0>
so this cannot work with the analyzer.
<_florent_>
yes the analyser is particular on that point...
<_florent_>
is it really un-convenient with the analyzer to generate an eventual dummy data at the end?
<sb0>
whitequark, the purpose of this is to test asyncio with serial port, it doesn't need to be an actual hardware port. in fact something like a TCP would be better
<GitHub145>
artiq/master a618a6d Robert Jordens: hardware_testbench: better message when skipping
<rjo>
cr1901_modern: got time to work on the scanwidget?
<cr1901_modern>
rjo: I do
<cr1901_modern>
Want to give me feedback to help knock it out?
<rjo>
cr1901_modern: sure. you said last time you needed time to think.
<rjo>
cr1901_modern: do you have artiq_gui running?
<cr1901_modern>
rjo: No, let me pull and do that
<GitHub39>
[artiq] jordens pushed 1 new commit to scanwidget: https://git.io/vaq5Q
<GitHub39>
artiq/scanwidget bc92034 Robert Jordens: Merge branch 'master' into scanwidget...
<rjo>
sb0: did you test moninj with the dds bus changes?
<cr1901_modern>
rjo: Getting errors while trying to run artiq... something's probably not up to date (it's been a while since I last pulled artiq) >>
<cr1901_modern>
Does "TypeError: getaddrinfo() argument 1 must be string or None" ring a bell?
* cr1901_modern
hasn't use bisect/blame in ages lol
<rjo>
cr1901_modern: could be anything.
<rjo>
cr1901_modern: cd examples/master; artiq_master & wait a bit and then artiq_gui
<cr1901_modern>
Let's try that; I'm using a batch script that I wrote some time ago
<cr1901_modern>
Same error... something's not right here
<cr1901_modern>
brb
<cr1901_modern>
back
<rjo>
cr1901_modern: we can work with the bare main.py of yours. no need for artiq_gui currently.
<cr1901_modern>
Alright, I'll fix it later (but I would prefer that it's fixed on my end. artiq_master doesn't like my command line params for some reason)
<rjo>
you shouldn't need any
<cr1901_modern>
I don't have any; but line 100 in artiq_master is failing anyway
<rjo>
cr1901_modern: i don't know all that much about qt signals. but is it ok that the signals are class attributes (as opposed to instance attributes)?
<rjo>
cr1901_modern: and are you sure about your eventFilter hierarchy? proxy is filtering _for_ axis and axis is filtering _for_ slider. but axis is also using the events for itself.
<cr1901_modern>
rjo: Not sure about the former. I did it b/c that's what I remember seeing PyQt examples doing. I'll get back to you.
<cr1901_modern>
rjo: The latter, I've been meaning to spin that into its own class
<cr1901_modern>
I don't care for how it looks (eventFilter is a method of QObject, so I can just subclass that)
<rjo>
cr1901_modern: maybe strip axis down so that it doesn't handle anything other than painting itself. and have the proxy mess with it.
<cr1901_modern>
axis needs proxy information to paint itself. I don't think it should be the axis' responsibility to keep a copy of the proxy's state.
<cr1901_modern>
So I just keep a ref to the proxy to get the desired information
<rjo>
as i read the qt docs, it seems that an event is first targetted at the lowest level widget and then travels up the hierarchy if that widget ignore()s the event.
<rjo>
cr1901_modern: axis only needs a few attributes (left, right, start, stop, npoints), right? proxy can mess with them.
<cr1901_modern>
I guess I could make proxy a container for the axis, so any time there's a paint event, it propogates to the axis via the proxy. The proxy doesn't reserve space on the screen as it is now, so it will never receive a paint event
<rjo>
yeah. naively i would make the proxy the container that groups the axis and the sliders/groove
<cr1901_modern>
I've been trying to apply OOP principles to keep the code base easy to modify, so there are times it looks like I'm doing things the "hard way" to prevent changes from breaking unrelated parts of the widget.
<cr1901_modern>
I agree that the axis perhaps should have no knowledge of the proxy and should be concerned with only painting itself. Your naive way will probably work fine, where I pass in the values required
<cr1901_modern>
rjo: Line 91 in artiq_master.py, could you print out the value of bind for me
<cr1901_modern>
? It's a list on my machine, and I don't think that's right
<rjo>
cr1901_modern: list is fine.
<rjo>
cr1901_modern: but you need a recent python.
<rjo>
and a recent quamash
<rjo>
in short, verify that you have at least the versions that we use for the packages.
<rjo>
cr1901_modern: i am itching a bit to refactor a few things in there and move stuff around. do you have changes pending? do you have anything that you would like me to comment on?
<cr1901_modern>
Unsatisfiable package specifications. Uggggh, this is going to be hell
<cr1901_modern>
rjo: Nothing in particular. Just let me know when you're done refactoring so I can work again. I wanted to move some things to separate files
<rjo>
cr1901_modern: go ahead with that. i'll suppress my urge.
<cr1901_modern>
I really need to fix artiq first. My tolerance for dealing with conda is... low
<cr1901_modern>
I'll have to wait for sb0 to come back. Something broke when I updated artiq to the last version and getaddrinfo is failing no matter what I pass into it (WTF?!).
<cr1901_modern>
whitequark: When I last built artiq, a number of Windows packages were missing that I had to build from source. And some of them I had to hack to get to work b/c it's like they've never heard of MSVC 2015. Are there any packages that you are aware of that still have to be built from source?
<rjo>
cr1901_modern: what do you need sebastien for?
<rjo>
cr1901_modern: yes. i know how to reproduce the crash.
<cr1901_modern>
rjo: cr1901_modern: what do you need sebastien for? <-- Figured maybe he's seen the "getaddrinfo" error before on Windows since he maintains a Windows VM
sb0 has joined #m-labs
<sb0>
cr1901_modern, your python is too old. artiq requires 3.5.1.
<sb0>
rjo, I did not
<sb0>
(test moninj)
<sb0>
just checked that the GUI can still pull the data from the DDB
sb0 has quit [Read error: Connection reset by peer]
<rjo>
sb0: #325 maybe the issue is with the configuration. i did not investoagte further.
<rjo>
cr1901_modern: as i said.
<cr1901_modern>
rjo: I'm sorry I doubted you.
<cr1901_modern>
rjo: Would you object to making a directory for scanwidget code?
<rjo>
cr1901_modern: i'd take a directory with 50 files over 10 subdirectories with 5 files each any time. also. e.g. the scientific_spinbox.py and maybe even ticker.py would not be in that hypothetical scanwidget directory.
<cr1901_modern>
rjo: Ack. Still thinking over the "slider and axis mutually depend on each other's sstate during initialization/resize" problem
<rjo>
cr1901_modern: let's summarize this: 1) the information known form the beginning (before any drawing, painting, events) is: (start, stop, npoints). 2) from that you initialize (left, right). 3) then once you need to draw the axis or the slider, you have to figure out the width and the axis_range_in_scan_units/axis_width_in_pixels = (right - left)/axis_width scale (let's define that as _the_ scale). 4) slider and axis need the six numbers and can draw themselve
<rjo>
(well the sliders don't need npoints but they need the other five numbers)
<cr1901_modern>
rjo: Yes. The problem is that during a resizeEvent the slider and axis for a brief period don't "see" the same numbers. I need something like a "postResizeEvent" where the slider and axis redraw themselves after the resize is said and done
<rjo>
wohoo. half of the issues for 1.0 are waiting for testing. this is fine for doing release candidates. once the other five are lined up we can push 1.0rc1
<rjo>
cr1901_modern: can't slider and axis ignore the event and have the proxy handle it and update everythin in one go, then trigger axis and slider paints?
<cr1901_modern>
rjo: I can't control the order of events, and within a layout, they can be sent in any order
<cr1901_modern>
so even if I used the proxy as a container, there's no guarantee it'll receive the event last
<rjo>
if slider and axis ignore the event the order doesn't matter. only one of them will get the event initially and when they ignore it, it will propagate to the upper widget (the layout/proxy).
<rjo>
well yes. if a lower widget ignores an event, then the event travels upwards. that's what i concluded
<cr1901_modern>
The event propogates regardless of whether I ev.accept() or ev.ignore() (presumably b/c the layout is calling setGeometry() behind the scenes for all child and parent widgets)
<cr1901_modern>
The layout is what handles the resizing and deciding whether to call setGeometry and consequently send a resizeEvent
<cr1901_modern>
It's fine if I can't control the order of events, but I need to be able to detect when everything's done resizing so I can force a repaint
<cr1901_modern>
(and force the sliders to update to the new geometry)
<rjo>
do you ev.ignore() + return True?
<cr1901_modern>
rjo: No, can't say that I did
<rjo>
but for wheel events i think this is how you make your enclosing widget receive the event.
<rjo>
maybe not for resizes.
<rjo>
probably not.
<cr1901_modern>
TypeError: invalid result from ScanAxis.resizeEvent()
<cr1901_modern>
It pains me to say this, but the easiest way to accomplish what I want is most likely to filter resize events from both the slider and the axis, and keep a state variable that checks whether both events have been seen in succession. The proxy then forces the relevnt update and resets the state.
<rjo>
ok. then it sounds like you want to _not_ handle any resize events in axis and sliders, just in the proxy. and then you tell them to repaint.
<cr1901_modern>
I absolutely HATE this solution though. It's the wrong way to accomplish what I want. I really shouldn't be in a situation where order of events matter
<rjo>
cr1901_modern: no. ev.ignore(); return True in eventfilter. this is at least what sb0 did in the rest of the gui to prevent deep widgets from grabbing scroll events so that higher ones can see and handle them.
<cr1901_modern>
Oh...
<rjo>
if you want to handle resizeEvent in both axis and sliders, then they both need to be able to figure out the new axis_width independent of each other and independent of whether the other has already been resized.
<cr1901_modern>
And that is the core of the problem; proxy can't update its transforms until it knows the new axis width, and the slider needs to know the new axis width to appropriately position the sliders. This works if slider_width is always in sync with the changes in axis_width, but its not (as can be seen by the bad initialization)
<cr1901_modern>
So there's a nasty state problem
<cr1901_modern>
and ev.ignore()/ev.accept() doesn't work; the parent widget will receive a resizeEvent no matter what, and it's not always the last to receive it
<rjo>
that could probably be expected.
<rjo>
about the state: the only way to do this independently is then to ensure that axis and slider come up with the same number independently. is that number something like new_widget_width - some_padding?
<cr1901_modern>
I believe so. At the very least, they have the same left coordinate. I fixed an old assertion failure that detected this.
<cr1901_modern>
Looking at the Qt forums, there is no "resize done" event
<rjo>
it doesn't even matter what some_padding is. i would think that in the layout both the axis and the slider have exactly the same width. then completely ignore padding and assign "left" to the shared left side of both widgets and "right" to the shared right side of both widgets. ignore the fact that left and right are unreacahble and invisible.
FabM has quit [Quit: ChatZilla 0.9.92 [Firefox 45.0/20160303134406]]
<rjo>
hold on to the fact that they are both well defined and the same in both widgets.
<rjo>
the slightly weird behavior on resize that would result if you pay a lot of attention (because of the constant padding) is completely acceptable imho.
<rjo>
right and left being in scan units here. not pixels.
<cr1901_modern>
Be back in a bit. Getting closer. I'm a little shocked that Qt doesn't have a nice way to handle this...
<rjo>
i would think that sharing geometry across widgets is very uncommon
sb0 has quit [Ping timeout: 260 seconds]
<cr1901_modern>
Okay no way around it. There's no way to make the resizes independent; the slider depends on the proxy to feed it the new slider positions when moving the sliders, and this can only occur after the proxy transforms, the slider width, and the axis width have been updated.
<cr1901_modern>
I am going to accept that I'm doing something that Qt is not meant to do, and work around it
<cr1901_modern>
or maybe it is possible... hmmm...
<rjo>
you can break that path as well.
<cr1901_modern>
Well, there's something I haven't tried: I can subclass layout, and overload the setGeometry function. At the very end of that function, I can post an event with INT_MIN priority to ensure that the resizeEvents are done first (requires Qt 4.3)
<cr1901_modern>
this custom event can be the "end of resize, back to consistent state" event
<rjo>
i don't see why you would have to do any of the above when moving a handle. they are all invariant.
<rjo>
the only thing that changes is the position of the handle, and the axis needs to know the new stop.
<cr1901_modern>
B/c Qt provides the handle-to-pixel mapping, and I don't know if it takes anti-aliasing or other crap into account that makes it so that the handle doesn't move proportionally during a resize
<rjo>
you mean "normalized handle position" to pixel mapping?
<cr1901_modern>
"0 to 1023" to pixels mapping
<rjo>
so you get a "handle moved" event when doing a resize?
<rjo>
during
<cr1901_modern>
No I don't. The only handle move events are due to mouse movement
<rjo>
cr1901_modern: i refactored a bit. could you check the last couple commits?