<whitequark>
now we all wait for sb0 to do the soldering on kc705..
ylamarre has quit [Quit: ylamarre]
sb0 has joined #m-labs
<sb0>
whitequark, is the analyzer test failing due to a core device crash that is fixed by your cache_put commit?
sb0 has quit [Quit: Leaving]
larsc has quit [Remote host closed the connection]
<mithro>
whitequark: We have had problems with the sdram controller and ISE - the same input code seem to generate both working and non-working code, think we are missing some timing constraint
<mithro>
s
<GitHub85>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vavY4
<GitHub85>
artiq/master 59d7f5f Sebastien Bourdeauducq: test/coredevice/time_keeps_running: start new session to prevent now_mu save/restore
<cr1901_modern>
sb0: I forgot to push some changes from last wednesday after my last push, but whatever's on the todo list is what's left to do. I haven't worked on it much the past week. Strictly speaking, the only thing that's left to do that makes the widget feature-complete as per https://github.com/m-labs/artiq/issues/128 is overlapping sliders and shift+wheel event.
<cr1901_modern>
rjo added a number of extra features that he wants implemented.
<rjo>
cr1901_modern: did you fix the assertions so that it doesn't crash anymore?
<rjo>
cr1901_modern: what "number of extra features" did i add? the two improvements? they obviously don't affect the fixing of the crashes and usability consistency bugs.
<cr1901_modern>
rjo: All the drag modes
<rjo>
cr1901_modern: which of those were not in the original sketch?
<cr1901_modern>
rjo: The only thing that was in the original sketch was that "shift and mouse move changes the number of points"
<cr1901_modern>
you modified that to "shift and scroll wheel"
<cr1901_modern>
everything else was added since todo.md was made
sb0 has quit [Read error: Connection reset by peer]
<cr1901_modern>
rjo: I'm starting to remove assertions now
<rjo>
cr1901_modern: drag axis and drag groove are already in the photo. this is just more specific what should be draggable. drag handle is already done. shift-drag axis and groove that is an addition. shift-drag-handle is a nop. wheel on axis is already done, wheel on groove is optional.
sb0 has joined #m-labs
<rjo>
cr1901_modern: the only number of extra features" are the shift-drag axis and groove.
<rjo>
cr1901_modern: that is hardly a "number of extra features"
<rjo>
but if this is holding you up in any way, move them down to improvements.
<cr1901_modern>
rjo: Then I misunderstood. I thought everything under "drag modes" was extra.
<rjo>
cr1901_modern: if you look at the old photo, the drag modes are already there.
<cr1901_modern>
It's not that it's holding me up; all I was getting at is "the widget should be deployable once everything except drag modes and improvements is done"
<cr1901_modern>
I know sb0 wants this deployed; all I was saying is that "I feel you can deploy with confidence even if todo.md is not empty."
<rjo>
cr1901_modern: yes.
<cr1901_modern>
I'm sure sb0 and NIST has waited long enough lol
<rjo>
cr1901_modern: but when you work at the wheel behavior again, align it with #303
<rjo>
cr1901_modern: i did too.
<cr1901_modern>
Yes, you too
* cr1901_modern
grumbles that QGraphicsView wasn't up to the task
<cr1901_modern>
rjo: Make sure that the updated widget is to your liking
<rjo>
cr1901_modern: the current one or the to-be-done one?
<cr1901_modern>
rjo: The one currently uploaded to the repo
<rjo>
cr1901_modern: it is off by one.
<cr1901_modern>
rjo: What is off-by-one? Lemme guess... the number of points
<rjo>
yes
<cr1901_modern>
Is "one" a valid "number of points"?
<rjo>
we could do either of the following: a) behave like python and do [a,b[ and never scan the last point. or special case n=1 to mean only the first.
<rjo>
cr1901_modern: yes
<cr1901_modern>
if so, that as to be a special case
<cr1901_modern>
has*
<cr1901_modern>
brb
<rjo>
can also be python slicing style.
<rjo>
ok. we should behave like numpy.linspace does.
<rjo>
you should just use linspace to give you the locations.
<cr1901_modern>
rjo: that's fine. I was avoiding bringing in numpy as a dependency, but I guess it doesn't matter
<cr1901_modern>
that leaves the ticker assert and two commented asserts that I'm keeping around (acceptable failures)
<cr1901_modern>
There is also a bug at large zooms where the widget won't zoom anymore and... that's it! The widget is deployable after that
<rjo>
cr1901_modern: i did it already for the ticker
<cr1901_modern>
rjo: I know :P.
<rjo>
and the off-by-one needs to be fixed.
<cr1901_modern>
rjo: If using linspace, n=1 is no longer a special case.
<rjo>
trying to avoid using numpy in a data taking and processing application/framework/gui is not time well spent.
<rjo>
cr1901_modern: yes
<rjo>
cr1901_modern: i pushed a few pending moves that i had made. shouldn't matter for you.
<cr1901_modern>
rjo: My thought process re: numpy isn't important anymore. Point blank, it's fixed. 0 is not possible, even to input manually
<cr1901_modern>
the ticker assert is trickier b/c it will only be triggered while drawing. It's kinda too late by then to back out and refuse to honor the zoom
<cr1901_modern>
Bed time for me. I'll think about how to handle this while I'm away.
<rjo>
cr1901_modern: ack.
fengling has quit [Quit: WeeChat 1.4]
<rjo>
cr1901_modern: i would use bigger black dots as npoint visualization and black for the spinbox. full luminance green is really irritating.
<rjo>
cr1901_modern: you may need to validate the values after getting a value changed or wheel event but before drawing/painting.
<rjo>
cr1901_modern: and at some point you need to look at the way the values are initialized and set externally. i can currently trigger assertions easily the way the widget is hooked up in artiq_gui.
<GitHub29>
[artiq] jordens pushed 2 new commits to scanwidget: https://git.io/vafv7
<GitHub29>
artiq/scanwidget 7e99780 Robert Jordens: scanwidget: wire up signals better, set values late, take scanwidget from 7aa6397
<GitHub29>
artiq/scanwidget ef217f7 Robert Jordens: Merge branch 'master' into scanwidget...
<mithro>
sb0: Do you have any interest in RTEMS running on MiSoC? (Or does it already?)
<cr1901_modern>
rjo: Which assertions? (Can't sleep)
sb0 has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
sb0 has quit [Read error: Connection reset by peer]
<GitHub21>
artiq/master e809e89 Robert Jordens: pipistrello: adhere to pmod interface type 2 layout
<rjo>
whitequark: i would run the unittests (then including the hardware) in the bitstream recipe as well. then you fail early if the non-hw tests fail.
<rjo>
just run them twice, once w/o hardware once with. that breaks the dependency cycle nicely.
<rjo>
cr1901_modern: division by zero on Line 491 (newScale = self.slider.effectiveWidth()/(proportion*currRangeReal)) on "view range".
<cr1901_modern>
sonofa... erm, checking it out right now...
<rjo>
cr1901_modern: when initialized the axis also fails to follow the values: it draws the axis from -70 to 70 while the spinboxes and handles are ar +-1000
<rjo>
this is probably only because of the artiq_gui part and how it initializes the widget.
<cr1901_modern>
Cannot duplicate the latter on my end. Hrm...
<cr1901_modern>
Wait... are you calling fitToView in artiq_gui?
<cr1901_modern>
you need to call that as part of init
<cr1901_modern>
or zoomToFit... either should work
<rjo>
cr1901_modern: does it need to be after show()
<rjo>
cr1901_modern: show() is at a completely different layer of the widget hierarchy
<cr1901_modern>
I can reasonably blame Qt for this b/c the dimensions of the widget aren't really valid until after the widget is shown.
<rjo>
either you hook it up so that you get that event later or you figure out how to call fittoview before show.
<cr1901_modern>
In the scanwidget repo, if you query the widget size before it is shown, Qt will provide a default (640x480) that will immediately become invalid- WITHOUT a resize event sent- once the widget is shown
<rjo>
then have a flag that tells you wether you ran fit to view once.
<cr1901_modern>
I swapped fitToView and show() order in my repo. I'll see if I can figure out a better way to do this. I already fixed the zoomToFit divide by zero bug
<GitHub14>
artiq/master 9c11cda Robert Jordens: pipistrello: use ttl_simple for pmod[4:8]
bg has joined #m-labs
<larsc>
I have 16GB here and Vivado still runs out of memory
<rjo>
larsc: give it less! it seemed to be happy (but slow) on that 8G machine running three compilations in parallel and another ISE
<bg>
Hello!
<rjo>
4GB in fact.
<rjo>
bg: hello
<bg>
I'm here by curiosity.
<larsc>
rjo: hm, can I tell it the maximum allocation?
<rjo>
whitequark: why did lab.m-labs.hk have 8GB for a short while, then 5 and now 4GB again?
<rjo>
larsc: no idea. that remark was a bit cynical.
<rjo>
bg: UPMC? what do you do?
<bg>
I was having a look on www.ohwr.org/companies, and found m-labs by chance. Artiq seems to be an advanced version of a small project developed during my phd.
<bg>
Quantum optics expriments
<rjo>
with serge?
<bg>
You mean serge Reynaud?
<bg>
nope
<bg>
but his office is closeby
<rjo>
Haroche but yes...
<cr1901_modern>
rjo: Okay, I narrowed the problem; see line 531 of scanwidget.py for an explanation. You want the start/stop sliders to keep their initial values before being shown, correct?
<bg>
Second, I just finished my phd and I wonder if I can contribute to some open-hardware project, which led me here.
<rjo>
bg: good. others have been guarding their fiber pulling methods like trade secrets.
<cr1901_modern>
rjo: When the scanwidget object is being built, it's not synchronized to the spinboxes.
<cr1901_modern>
The scanwidget object expects to either have defaults set, at which point the widget will synchronize the spinboxes for you
<bg>
I didn't feel like having trouble finding the information I needed when I built my rig.
<cr1901_modern>
Or you manually do the initial synchronization when you do know the values the spinboxes should take
<rjo>
bg: i must have passed by your posters/talks at various conferences. i did fermionic quantum gasses in optical lattices for phd at ethz and ion trapping for postdoc at nist.
<cr1901_modern>
I understand some of those words :o
<rjo>
bg: yes. there was little open and well managed/maintained until a few years ago.
<rjo>
cr1901_modern: but when initializing you can just expose a method to set up the axis. explicitly.
<rjo>
no need to hope for a resize/fittoview/valid width.
<rjo>
bg: so you are staying with Julien for a postdoc?
<bg>
Nothing precise planned for now. I usefull here and funded until august.
<bg>
I guess you work full-time for m-labs now?
<rjo>
great. skimming through your thesis now.
<rjo>
bg: yes.
<bg>
rjo: anything unclear, feel free to ask
<cr1901_modern>
I think I misunderstand your issue, rjo. I cannot guarantee that the widget will paint itself correctly upon being shown for the first time b/c Qt doesn't provide enough information to do so (see line 531). So I suggested using FitToView or ZoomToFit afterwards to correct this. But you say that thiss is not possible and we need the widget to paint itself correctly the first time.
<rjo>
bg: congrats to your defense
<bg>
rjo: thanks
<rjo>
cr1901_modern: but what is the data you actually need at that point before receiving the first paint event?
<cr1901_modern>
To successfully paint the widget upon receipt of the first paint event, I need the leftmost axis position (given), and the scale (default of 1.0 in __init__).
<cr1901_modern>
Hmmm... need to think this over.
<rjo>
bg: we (m-labs) would also really like to make artiq interesting and applicable to experiments like yours.
<rjo>
cr1901_modern: scale is the axis scale (pixels per axis unit or the inverse)?
<cr1901_modern>
yes
<bg>
rjo: I don't realize in detail what's in artiq for now. Looking at the manual.
<cr1901_modern>
rjo: Why is requiring FitToView or ZoomToFit after show() "bad"?
<cr1901_modern>
Let's answer that q first
<bg>
rjo: In my experiment, the use of FPGAs is rather simple, but very usefull for now: send digital timing signals with low enough resolution, and acquire time-stamps.
<rjo>
cr1901_modern: how would i hook that up? what show() does that need to be? the main window?
<rjo>
cr1901_modern: look at how the gui is built in artiq/gui/experiment.py and how the scanwidget gets in there in artiq/gui/entries.py
<cr1901_modern>
rjo: Okay, will do. Next q: What information do you need to be "set" in the scanwidget by the time it is painted the first time?
<cr1901_modern>
just that the sliderss match the spinboxes?
<cr1901_modern>
And that the sliders are not necessarily centered or even in view?
<rjo>
bg: yeah. what you guys do should be well covered.
<rjo>
cr1901_modern: you get (start, stop, npoints) when building and you can expect the axis to be at least 300 (i think) pixels wide.
<rjo>
the view can be volatile. you can behave like "view range" was pushed.
<rjo>
well you should behave like it was pushed.
<cr1901_modern>
A resize event depends on the previous widget size to keep the sliders and the axis in sync.
<cr1901_modern>
If the previous widget size was invalid, the sliders and the axis go out of sync until they are manually resynchronized (or I force a resynchronization by handling that case specially).
<cr1901_modern>
I can force a "viewrange", but it will fail if the start value == stop value :/
<cr1901_modern>
If the axis resizes first, it will change the transformation used to get to pixel space, but the transformation from pixel to slider-handle space will be wrong until the slider widget resizes itself. But if the slider resizes itself first, the transformation from real to pixel space will be wrong
<cr1901_modern>
rjo: Thinking about what you're asking.
<rjo>
cr1901_modern: and if axis_range is unknown (because the widget is being built and it is volatile), just take what "view range" would give you.
<cr1901_modern>
rjo: That works only if start != stop. "view range" does nothing if start==stop to avoid div0
<rjo>
cr1901_modern: for resize you are guaranteed to receive both events, one for the axis, one for the groove, right?
<cr1901_modern>
rjo: Yes, but I don't know the order
<rjo>
cr1901_modern: no. axis_range is always positive.
<rjo>
cr1901_modern: then you can freely choose to ignore one of them.
<rjo>
always.
<sb0>
mithro, not so much. i'd rather see misoc docs...
<cr1901_modern>
I'm... still parsing this, rjo
<cr1901_modern>
rjo: "cr1901_modern: but is that the way to do it? isn't the scale much more simply: axis_range/axis_width? independent of what it was before?" axis_range is calculated on a as-needed basis. So to get the axis_range prior to resizing, you need the old width
<cr1901_modern>
To prevent variable/state hell, I only keep the minimum amount of state required to calculate the other information I need on-the-fly. In this case, that is the real-to-pixel transform
<cr1901_modern>
It appears I traded state hell for another type of hell...
<rjo>
cr1901_modern: i would have thought axis_range (the left and right limits of the axis) is the invariant that you want to keep. change axis_left/right on zoom. change axis_width on resize. orthogonalized invariants.
<rjo>
but that is from a three mile high view.
<cr1901_modern>
rjo: The TLDR of this is that the resizeEvent handling is very crappy. To do it correctly depends on guarantees that Qt can't provide (order of events), and the way I'm doing it depends on an invariant that's... not invariant (the sliders and the axis' perceived widths are the same at all times). I need to change it, and I'm mulling over how to do so.
<cr1901_modern>
When the widget is painted for the first time, the slider handles think the old width is still in effect. I can force the slider handles to use the new width by forcing a "View Range", but this only works if the start slider != stop slider. Otherwise "View Range" does nothing.
<rjo>
the later is correct behavior.
<cr1901_modern>
what's correct behavior? start slider never equals stop slider?
<rjo>
forcing "view range" early within the first paint when the previous range (or axis_range) is invalid is what i was proposing.
<rjo>
no. "view range" is a NOP if start == stop.
<rjo>
that's correct behavior.
<rjo>
there should be no situation where _you_ set start = stop.
<cr1901_modern>
Right, and if view range is a NOP when start == stop, then forcing view range in the first paint won't work- edge case
<rjo>
if you get an initial paint with start==stop, then you can assume that axis_range=1.
<rjo>
otherwise you will never get out of there.
<cr1901_modern>
Okay.
<cr1901_modern>
An alternate method is to make axis_range equal to the pixel width on initial paint, and manually move the sliders to match the spinboxes (with no regard to whether they are in range to be displayed or not).
<rjo>
but you want the sliders to be visible after the first paint without having to search for them. the "good" view after the first paint is "view range"
<cr1901_modern>
Okay. Thinking about a good comment for this mess.
<GitHub25>
artiq/master f33baf3 Robert Jordens: pipistrello: drop ttls on pmod, add leds back in
sb0 has joined #m-labs
<whitequark>
sb0: yes, the analyzer test is failing due to the crash
<whitequark>
mithro: yes, that sounds likely
<whitequark>
rjo: re unittests in bitstream recipe: bitstream recipe does not depend on main package. this has caused problems in the past.
<whitequark>
rjo: however, i do run unittests twice, once *before* building bitstream and once *after*
<whitequark>
rjo: re lab having strange memory size: it's the xen balloon driver. dom0 grabs all memory not allocated to VMs. if we run less VMs there's more memory for dom0. this is the default behavior.
<whitequark>
ballooning occasionally causes more problems than it solves but in general it's handy. i can turn it off if you want.
<rjo>
whitequark: i don't see why you can't run the hardware unittests after building the clock bitstream in the clock builder. the code is there. you just used it to build the package. otherwise instead of building the bitstreams from git, build them from the conda package. then you don't get that problem and you get priority inversions.
<whitequark>
it doesn't have the dependencies installed (and it cannot possibly have since the artiq package is not uploaded yet)
<rjo>
ah yes. i forgot about the way xen handles memory.
<whitequark>
even further, it may have run on another buildslave
<whitequark>
anyway I'm not sure why we're even discussing this, what i implemented already does what you want
<whitequark>
just in a slightly different way
<rjo>
before, the bitstream builds were triggered when the package was alsready uploaded
<rjo>
whitequark: you didn't even notice that it is completely broken?
<whitequark>
it's failing at artiq_flash.
<whitequark>
that's exactly what i expect.
<whitequark>
it's failing because without the backplane there's no loopback and with the backplane there's no functional JTAG
<whitequark>
i'm waiting for sb0 to come to the office and do whatever needs to be done to kc705 to disable that JTAG bypass thing
<whitequark>
or i guess i could do it myself if he trusts me enough
<whitequark>
rjo: i've verified that all tests (except the test_time_keeps_going) pass and the board is flashed properly after i set that up, by manually plugging in the backplane at just the right moment.
<rjo>
summary: it's broken. no bitstreams get built, no artiq package gets uploaded.
<whitequark>
yes.
<whitequark>
no packages are being uploaded.
<whitequark>
that doesn't mean that the code that i added for running unittests on hardware is broken. quite the opposite.
<rjo>
if we can't reliably and constantly provide a hardware test environment that doesn't block the CI testing, we should move the hardware tests out of that dependency tree
<cr1901_modern>
rjo: You closed 303. Did something change such that the shift+wheel I have is okay?
<rjo>
cr1901_modern: see the bug. shift+wheel is npoints, ctrl+wheel is zoom for general consistency with other apps and least amount of surprises.
<rjo>
and see the commit log. there are a few commits that contribute to the resolution.
<whitequark>
rjo: this should be fixed today. if not i'll consider spinning them off.
<rjo>
whitequark: also another (little) wrinkle is that the artiq builder now eats both slaves while one is not doing anything.
<whitequark>
yes. that should be easily fixable now because there's a global rwlock.
<whitequark>
(the trigger step doesn't need to hold the lock.)
<whitequark>
rjo: one real problem i anticipate is conflicts between using kc705 for automated tests and for manual tests
<whitequark>
there's a pipistrello plugged into lab.m-labs.hk but i don't know how useful is it
<rjo>
whitequark: yes. i think that lock on the hardware should be made explicit.
<whitequark>
i don't know how to do this properly.
<whitequark>
i am unaware of any robust hardware locking scheme, for that matter. tty locking is a damn disgrace, for example
<rjo>
whitequark: it can do pretty much everything apart from the dds readback stuff and the speed tests that depend on network speed.