<sb0>
rjo, whitequark: TTL updated, bug-free C flterm compiled and put in /usr/local/bin
<sb0>
is flterm always busy-waiting or what?
<sb0>
_florent_, ^
<sb0>
_florent_, you copy-pasted the "bidirectional terminal with threads" code (and its bugs) from a pyserial example, right?
<sb0>
that would sound like another reason to trash pyserial...
evilspirit has quit []
<sb0>
whitequark, if you want autoboot from serial without erasing the runtime from the flash, please just change the boot order/mechanism in the BIOS (e.g. remove the interactive menu that doesn't work due to the special keys portability clusterfuck, and make serialboot sensitive to ESC for aborting boot). there is already one magic string for serialboot, there is no need to hack another one into flterm
<GitHub135>
[misoc] sbourdeauducq pushed 2 new commits to master: https://git.io/v2c4E
<whitequark>
AssertionError: 0.0011601418870386666 not less than 0.001
<whitequark>
your timing tests are incredibly broken by design
<whitequark>
I had to hack every single one of them to fit different network conditions
<whitequark>
like this one fails because I'm on WiFi that either has interference or just high latency because I'm streaming mp3's
<sb0>
whitequark, how do you suggest designing them?
<whitequark>
not run them except in known, controlled conditions
<sb0>
sounds like a mild solution to fix something you claimed is "incredibly broken by design"
<whitequark>
it's not a solution, it's a workaround
<whitequark>
well, I was going to reply with "remove them", but something tells me you won't like that
<whitequark>
essentially, the brokenness is that they're meaningless. you're testing the entire stack including OS, lossy and unreliable networks, on top of CPUs that can be variably loaded
<whitequark>
for example, those "controlled conditions" will not be present on the buildbot; we cannot run those tests on CI
<whitequark>
because when it's building bitstreams in parallel, you're going to blow all your timings
<whitequark>
the worst part is that even if they pass, there's no guarantee that our specific conditions are at all representative of what will be e.g. at NIST
<whitequark>
actually, I do lean to "just remove them" on second thought
<whitequark>
yep, I cannot make them reliably pass on my laptop unless I raise stddev to 30ms
<whitequark>
which makes it completely meaningless
bb-m-labs_ has joined #m-labs
bb-m-labs has quit [Ping timeout: 255 seconds]
<whitequark>
sb0: TestLda doesn't work
<whitequark>
lda_controller dies with OSError: [Errno 98] Address already in use
<rjo>
if you can't do rpcs with reasonable low jitter, something is not ok. your setup, the runtime, the lwip stack, the wires, the gateware. but the unittest will show you that.
<rjo>
don't remove that test.
<rjo>
you have abigger problem. 30ms is unlikely just your wireless. the unittest exposed that.
<whitequark>
rjo: no, 30ms is my wireless
<whitequark>
I can verify it by pinging the router
<whitequark>
this is actually by far not the worst as WiFi goes, I've seen much higher
<whitequark>
but that's not even relevant because if I run tests from outside the lab, everything goes out the window
<rjo>
the unittests are not broken. i suspect you just didn't understand them and spoke to soon. if you have a slow link, other problems appear. the watchdogs will kick in etc.
<whitequark>
yes, and I had those problems in the past
<whitequark>
this WiFi link is not slow, it has very variable latency. so it breaks the stddev test
<rjo>
well. in short: reasonably low and stable latency is an assumption. it's correct that we have unittests for it.
<whitequark>
when I worked from RU, I had a link with a constant but high latency (and better WiFi). it broke tests that put limits on RTT.
<whitequark>
no, it's unacceptable to have unittests that randomly fail because of things I cannot affect in any way
<rjo>
sure you can affect them. fix your network. don't run intercontinental artiq sessions.
<whitequark>
no.
<whitequark>
I'm not going to change how or where I work simply to appease a badly written unittest.
<rjo>
oh. feel free to "fix" them and write them in a different way. but make sure that these features (rpc latency etc) _are_ tested for.
<whitequark>
I'll make them skipped by default, which will fix both my use case and the CI (when we do run unittests on CI)
<rjo>
no. don't do that.
<rjo>
then you will break them again but you won't notice because you have no way of testing them.
<whitequark>
from my perspective the test provides no useful information anyway
<rjo>
it won't "fix" your usecase.
<rjo>
then ignore them.
<whitequark>
as it currently is.
* whitequark
shrugs
<whitequark>
a test that is ignored is useless
<whitequark>
there's no difference.
<rjo>
ignore them when you look at your terminal. if you can't set up a CI that can achieve the expected latency and stability, you should not bother doing it at all.
<whitequark>
you do realize that running them from Travis would indeed be an "intercontinental ARITQ session"?
<whitequark>
that's on top of Travis' already overloaded infrastructure
<rjo>
nobody would do it that way. i called out to a machine that is local to the core device.
<whitequark>
anyhow, there is a way to do what you want with our CI. specifically, a global lock has to be taken, which will prevent anything else from running concurrently with these tests
<whitequark>
and I will set that up, it's not hard
<rjo>
yes. you can not test for low latency using a travis client and a remote core device.
<rjo>
doesn't really fix your wifi.
<whitequark>
it doesn't. the test will be skipped by default to make the pass/fail status of -m unittest discover actually useful.
<whitequark>
having it run on CI is more than enough
<whitequark>
rjo: did you do something to our core device?
<whitequark>
hm
<whitequark>
no, probably not
<rjo>
no
<whitequark>
it crashed and doesn't seem to do anything after reset
<whitequark>
weird
<whitequark>
hm, came up after power-cycling
<rjo>
you can (and should) use artiq_flash for that
<whitequark>
for what?
<rjo>
"power-cycling"
<rjo>
or "reset"
<whitequark>
by "reset" I meant "I did the magic openocd thing that resets the FPGA"
<whitequark>
I think it's the same as what artiq_flash does
<whitequark>
on second thought I think I was wrong about it not coming back up because I was looking at wrong ttyUSBn
<whitequark>
rjo: are you aware of "nose" test runner for python?
<rjo>
yes. and py.test.
<whitequark>
I found "nose" to be somewhat more pleasant to use, especially in the way it grabs the logs
<rjo>
whitequark: should i expect that other (unwind/llvm) bug to affect me?
<whitequark>
are you raising exceptions? then yes.
<whitequark>
llvm build -3 fixes it.
<rjo>
i am not. but the runtime might.
<rjo>
it also crashes completely. not just the kernel cpu.
<whitequark>
does it print "Watchdog expired" before?
<whitequark>
because I'm encountering that crash right now
<whitequark>
rjo: oh, I forgot to mention.
<whitequark>
you need to rebuild the runtime with the -3 build of LLVM to get rid of that bug
<cr1901_modern>
rjo: Resize and fitToView idempotency fixed, except for floating point precision errors (I hope)
<rjo>
nah. i don't think i have a watchdog.
<rjo>
will reduce the test that exposes it.
<whitequark>
ok, that's irrelevant then. interesting. i don't know why it should crash the coredevice.
<rjo>
whitequark: is that 156MB vs 30MB in llvm still due to debugging? why do the windows people get no debugging? do we remove that before/for release?
<whitequark>
rjo: let me see
<whitequark>
rjo: figured it out. the linux build uses static libraries, and consequently massive binaries of clang etc.
<whitequark>
clang alone is 100MB
<whitequark>
and the windows build simply does not include clang
<whitequark>
with debug info, it would be not 150MB but more like 2GB.
<whitequark>
so I don't think anything can be done about this; if we switch to dynamic libraries then llvmlite-artiq will depend on llvm-or1k
<whitequark>
which will increase the amount to download for the common case.
<whitequark>
which reminds me, I need to rebuild llvmlite-artiq with new llvm.
<whitequark>
bb-m-labs_: force build --props=package=llvmlite-artiq conda-all
<bb-m-labs_>
build forced [ETA 1h29m44s]
<bb-m-labs_>
I'll give a shout when the build finishes
<whitequark>
my impl is correct. the tests require interleaving.
<whitequark>
actually, hm, not with the second one
<sb0>
test_rtt is a very special one
FabM has quit [Quit: ChatZilla 0.9.92 [Firefox 44.0.2/20160210153822]]
<cr1901_modern>
Stripe...Hmm, that's an interesting link. Not sure I would take the risk personally, but that does seem like a quick way to get started.
<rjo>
cr1901_modern: thanks. code looks nicer now. i did another pass anyway.
<cr1901_modern>
rjo: I'm not sure if true idempotency of FitToView/ZoomToFit is possible. This IS close, but not perfect.
<rjo>
sb0: yes. i ignored stripe when i didn't find HK in the list of countries
<cr1901_modern>
rjo: I'm assuming you and sb0 are providing the spinboxes from pyqtgraph. Do yoiu want me to subclass QSpinbox to remove more of pyqtgraph?
<rjo>
cr1901_modern: that's fine. as long as it is idempotent at the order of magnitude of the machine precision, we are good.
<rjo>
don't bother with the spinboxes.
<rjo>
the qtgraph ones are crap IMHO. something like from that link i added should be good enought.
<cr1901_modern>
Oh I totally didn't click the link lol
<rjo>
cr1901_modern: np. as long as my fix is correct.
<cr1901_modern>
I still need to modify it, but at least with your fix, it no longer crashes
<GitHub184>
[artiq] jordens pushed 3 new commits to master: https://git.io/v2Wis
<GitHub184>
artiq/master d807398 Robert Jordens: examples/transport: int arguments
<GitHub184>
artiq/master f2acf95 Robert Jordens: pdq2.mediator: err on short segments
<GitHub184>
artiq/master aa50c5b Robert Jordens: pdq2.mediator: minor tweaks
<rjo>
i am impressed that it crashes with a core dump. they could have made the C->python callback behave nicely.
<sb0>
cr1901_modern, there should be no pyqtgraph in the main artiq gui
<rjo>
whitequark: could you please have a look at #293 and #276 before you do the CI stuff?
<sb0>
if you need parts of pyqtgraph, hygienize them thoroughly and copy into your code
<rjo>
sb0: it's being handled.
<whitequark>
rjo: sure, I was not doing anything with CI anyway as it is not a part of 1.0 milestone.
<whitequark>
currently figuring out why test_loopback is broken.
<rjo>
whitequark: ack. that's the same level of priority to me.
<rjo>
sb0: any idea why mandelbrot has become so slow? i remember it being much faster (like 5x) when it was first demo'ed. i see it doing a lot of rpc. maybe that's it.
<sb0>
whitequark, when you get e.g. a RTIOSequenceError, how is it supposed to end up running CoreException.__str__?
<sb0>
RTIOSequenceError does not derive from CoreException
<sb0>
rjo, probably intercontinental RPC
<sb0>
let me test it...
<sb0>
or are you running it locally?
<whitequark>
sb0: ah, that should derive from CoreException as well, methinks.
<whitequark>
though it works for me somehow.
<sb0>
hmm yes it looks rather slow, and this is a new problem. it wasn't slow a few days ago
<sb0>
whitequark, it works in artiq_run, not in artiq_master
<sb0>
how's that?
<whitequark>
sb0: damn if I know
<sb0>
well you wrote that code
<whitequark>
oh
<whitequark>
except Exception as exn:
<whitequark>
if hasattr(exn, 'artiq_core_exception'):
<sb0>
rjo, then I don't know. I confirm it has become slow here as well. and iirc it wasn't slow last week.
<cr1901_modern>
sb0: That's fine. My intent was that the scanwidget, when it's committed into artiq, was that artiq-gui would provide the spinboxes. Do you want me to provide the spinboxes as part of the widget proper instead?
<rjo>
sb0, whitequark: your ISP doesn't give you IPv6, does it?
<whitequark>
sadly, no
<whitequark>
I hoped it would.
<rjo>
and sixxs is in complaint mode. otherwise i could have given you a tunnel.
<rjo>
vnhan01.sixxs.net is 39 ms away. could have been worse
<whitequark>
I can set up a tunnel alright
<whitequark>
probably using 6to4
<whitequark>
do you want it? it's trivial on openwrt
<whitequark>
hm, yeah, I wonder why it never occurred to me before that I can just use a tunnel
<rjo>
with the flaky ip address that's no fun.
<sb0>
cr1901_modern, yes, artiq-gui provides the spinboxes. but your widget must provide appropriate signals and controls so that it can be used in synch with spinboxes
<rjo>
ipv4
<whitequark>
ah right.
<whitequark>
sb0: can you figure out static IP with the ISP finally?
<rjo>
sb0: why are the artiq_gui spin boxes so out-of-shape and large?
<sb0>
whitequark, that's Stewart's task.
<whitequark>
sb0: I asked him several days ago but he doesn't seem to care.
<sb0>
rjo, which ones? those in the argument editor? because Qt lays them out that way by default when you put them into a QTreeWidget, for some reason.
<cr1901_modern>
That's already done, and is the main point of me having created a main.py in the first place (to show how they connect).
<rjo>
sb0: hmm. ack.
<rjo>
i would expect the spin boxes to stay part of the scanwidget, like it is now. why would you do spinboxes separately in artiq_gui and hook them up?
<rjo>
good lord. google dns still has lab.m-labs.hk at 20ks with the old ip. there is something wrong there.
<rjo>
maybe my isp is intercepting that anycast.
<rjo>
if i ask -t any i get the correct current one. if i ask -t a i get the old one
<sb0>
rjo, for the same reason that a QSlider doesn't contain a QSpinBox.
<cr1901_modern>
rjo: ViewRange stops zooming in properly at about 1e-10. Looking into it now
<sb0>
the scan widget and the spinboxes are two complete and independent representations/controls of the same data
<cr1901_modern>
Actually wait. Want to test something first
<rjo>
sb0: but what's the actual reason there? you might use the slider without the spinbox?
<GitHub120>
[artiq] whitequark pushed 2 new commits to master: https://git.io/v2WSh
<GitHub120>
artiq/master 4426730 whitequark: compiler: setting ARTIQ_DUMP_* dumps to a file instead of stderr.
<cr1901_modern>
Okay yes, can confirm that I need to work on this
<sb0>
potentially, or play with their layout
<sb0>
e.g. slider in one tab, spinboxes in the other
<whitequark>
rjo: I figured out the DNS problem
<sb0>
not saying this is what we should do, just pointing out that this architecture is more flexible and better separated
<whitequark>
ns1.serverraum.org returns the correct IP, ns{2,3}.serverraum.org return the old one
<whitequark>
no wonder everything broke
<rjo>
sb0: ok. but if there is a more compact and intuitive layout where the spinboxes are inside the scanwidget, i would want that.
<sb0>
ok
<rjo>
whitequark: axfr/ixfr not happening?
<whitequark>
no idea how serverraum.org is set up
<whitequark>
possibly yes
<rjo>
sb0: but yes. we should go with separate widgets first.
<GitHub177>
[artiq] whitequark pushed 1 new commit to master: https://git.io/v2WHN
<GitHub177>
artiq/master a829b8a whitequark: Commit missing parts of cf41890.
<whitequark>
ok, this is much better. I can now at least see *where* test_loopback fails.
<rjo>
cr1901_modern: zooming behaves so wildly for me that i can't even guess what's wrong with it. it only ever zooms out afaict.
<cr1901_modern>
rjo: Not the zoom. I KNOW that needs work. What I'm referring to is moving the sliders close together, clicking "View Range", moving the sliders close again, clicking "View Range", etc
<whitequark>
sb0: test_loopback is OK. test_loopback_count also requires interleaving.
<whitequark>
oh, you actually mentioned that in your comment
<whitequark>
ok, so what do we do with test_loopback and maybe test_rtt?
<sb0>
if we want to keep the convenience, at the expense of slightly dirty tests, use with interleave or manual interleave
<rjo>
cr1901_modern: that works fine here down to 1e-12
<whitequark>
sb0: now you have all the contact details for the ISP, and also I presume you have account details.
<cr1901_modern>
rjo: Does it break at 1e-12, or did you just stop there b/c "good enough"?
<cr1901_modern>
B/c it breaks here
<rjo>
i could not see anything wrong with it. at some point you get that division by zero.
<rjo>
cr1901_modern: but let's get the general coordinate mapping between the components right and then bother with the extremes.
<rjo>
do you need that QTransform thing? in 1D any affine transform has just two parameters: an offset and a scale.
<cr1901_modern>
rjo: No. It was for convenience. And it did a terrible job at it too.
<GitHub163>
[artiq] whitequark pushed 1 new commit to master: https://git.io/v2WAv
<GitHub163>
artiq/master 652c2a1 whitequark: test: rewrite tests using ttl_inout to use loop_{in,out} (#265).
gric has quit [Remote host closed the connection]
<whitequark>
sb0: I'm not sure what to do with test_time_keeps_running
<whitequark>
currently it fails because all tests in an ExperimentCase are executed in one session
<whitequark>
and within one session, now is saved and restored
<whitequark>
thus on the first transition into kernel mode it's initialized with the RTIO counter, but on the second transition it's just restored from the value stored in the session
<whitequark>
which appears to be explicitly intended behavior
<whitequark>
rjo: test_handover succeeds over herer.
<whitequark>
how does it fail for you?
<rjo>
whitequark: with an underflow with slack roughly -now+5ms
<rjo>
cr1901_modern: and now the zooming is actually not crazy anymore.
<whitequark>
(blinks the LED twice per second, too)
<rjo>
whitequark: hmm. will check
<rjo>
whitequark: ack. timing problem on my end. it can't compile and upload that kernel in time.
<whitequark>
the python process is hovering around 50%cpu on my machine.
<whitequark>
(laptop i7)
<rjo>
cr1901_modern: i don't know what changed. but now this is in almost usable condition.
<rjo>
whitequark: laptop i7 here as well but ppp over 115200 baud.
<whitequark>
ah i see.
<whitequark>
we could send binary diffs.
<rjo>
but the fact that you are 50% busy with doing two trivial kernels per second worries me a lot.
<whitequark>
I told you a long time ago that expecting to compile kernels in realtime is not reasonable
<cr1901_modern>
rjo: cr1901_modern: i don't know what changed. but now this is in almost usable (sic?) condition. :P
<rjo>
yes. before it was useless here.
<whitequark>
I also outlined several ways we can avoid compiling kernels repeatedly.
<cr1901_modern>
Oh, I expected the worst
<cr1901_modern>
TLDR; Until my most recent commit, the parameters being passed in to recalculate the realToPixel transform were garbage.
<rjo>
whitequark: but we should look into the low hanging fruits in parsing/transforms/compilation.
<whitequark>
rjo: I believe I already picked all of it
<whitequark>
(a while ago I spent some time on it)
<whitequark>
that _unify_attributes problem in transport.py doesn't count, it's an outright pathologic behavior
<rjo>
ok. i remember looking at that dominator tree of yours and there were a couple of asserts in the one of the transformers that used it that looked like they could be expensive. but that was a very superficial glance.
<whitequark>
I'm looking into the profile now.
<whitequark>
~30% is spent in LLVM passes. ~5% is spent parsing llvmlite's assembly alone
<whitequark>
IIRC around 30% more is spent concatenating strings in llvmlite. llvmlite's design is, uh, what's the opposite of optimal, for our use case
<rjo>
oh.
<whitequark>
ah, 40% in LLVM even.
<rjo>
yes. i had defined it for myself as a weird templating language.
<whitequark>
only 10% overall is spent in PyEval_EvalFrameEx
<rjo>
40% in llvm-proper?
<rjo>
yeah. i also had the feeling that the compilation of the runtime is surprisingly slow. much slower than i am used to for this stuff.
<whitequark>
50.91% if I sum over all LLVM DSOs
<whitequark>
the rest is spent in /usr/bin/python.
<rjo>
this is transport.py?
<whitequark>
no, this is your handover example
<rjo>
ah. ok. so for realistically large things (>> transport.py) it could easily be very different...
<whitequark>
transport.py is not large, it has a bug in the unifier
<whitequark>
which causes it to perform quadratic work or something like that
<whitequark>
oh, you mean, much larger than transport.py.
<whitequark>
....
<whitequark>
rjo: you'll like this.
<whitequark>
we build LLVM with -DCMAKE_BUILD_TYPE=Rel
<whitequark>
"Rel" is not a valid build type.
<whitequark>
it should be "Release".
<whitequark>
let me check, but I'm pretty sure it's built in debug mode
<rjo>
... and it defaults to DebugWithAllAssertsAndVerificationAndSelfConsistencyAndProfOfCorrectness
<whitequark>
nah, it defaults to -O1 or something
<whitequark>
in case of LLVM that's more than enough to completely destroy performance
<whitequark>
oh
<whitequark>
and I personally run an explicitly debug build because I, well, debug it
<whitequark>
"what happens is that requesting an unknown CMAKE_BUILD_TYPE is
<whitequark>
equivalent to not requesting one at all"
<whitequark>
which means Debug, and we enable assertions explicitly
* rjo
is looking forward to llvm-or1k 3.5.0-4
<whitequark>
I think I'll try turning off assertions in it
<whitequark>
I don't think that so far they have caught anything whatsoever of value when running outside of my own environment
<whitequark>
and the LLVM IR emission code is reasonably solid
<whitequark>
bb-m-labs_: force build --props=package=llvm-or1k conda-all
<bb-m-labs_>
build forced [ETA 49m02s]
<bb-m-labs_>
I'll give a shout when the build finishes
<rjo>
ack. what did we say about moving or1k over to newer llvm releases way back when we discussed this?
<whitequark>
it should probably be done (and then upstreamed)
<whitequark>
but that will take a nontrivial amount of time that I cannot predict beforehand
<whitequark>
LLVM tends to break 3rd party code a lot
<rjo>
yes. that's what i remember as well. anyhow. let's not think about this now.
<whitequark>
exactly as I expected, I ran a compilation and the test died with an underflow
<rjo>
whitequark: about that static clang in llvm-or1k on linux: can't we build that package dynamically linked but still have llvmlite statically linked?
<rjo>
and: what does llvm-or1k contain (on windows) if it doesn't contain clang just headers and libs?
<whitequark>
on linux: not really, we need 2 packages then.
<whitequark>
on windows: yes.
<whitequark>
headers and static libs and a few of llvm's internal executables like llc
<rjo>
libs for what? for compiling llvmlite-artiq?
<whitequark>
exactly
<whitequark>
actually, no, not even llc
<whitequark>
just headers and libs.
<rjo>
whitequark: for linux, why do we need two packages? llvm-or1k contains libllvm.so and .a and clang dynamically linked. then llvmlite-artiq statically links libllvm.a.
<whitequark>
llvm cannot be built into a .so and a .a at the same time.
<rjo>
hrm
<whitequark>
you build it either dynamically or statically. these modes are incompatible.
<whitequark>
the primary reason is the llvm-config utility that should be used to link any downstream code
<rjo>
does that do more than pkg-config et al.?
<whitequark>
not more, but it does different things.
<whitequark>
though not all that different.
<rjo>
but pkg-config tells you everything you want to know whether you link statically or not.
<rjo>
but anyway. i should not try to understand this too deeply.
<whitequark>
the static and dynamic builds of LLVM are different.
<whitequark>
e.g. there are different ways to link backends
<whitequark>
the purpose of a static build is to be embedded in some utility (like ARTIQ)
<rjo>
i'll leave it to you. maybe dynamically linking everything and requiring llvm-or1k for llvmlite-artiq would be ok.
<whitequark>
the purpose of a shared build is to be a component of a distro.
<whitequark>
I'm not sure.
<whitequark>
it's going to be around 50M of downloads.
<whitequark>
if you are OK with that I will switch to that model.
<rjo>
ok. let's leave it as it is. but at some point a windows user will want to build the runtime...
<whitequark>
I doubt it, our Makefiles will not work on Windows anyway
<rjo>
true.
<whitequark>
I mean, maybe they will *want* it.
<rjo>
ok. then let's leave it.
<rjo>
whitequark: by the way. we can turn of automatic triggering of the pipistrello and kc705-{nist_qc1,nist_qc2} bitstreams. we can build them on request (still buildbot, but on-demand). you have the nist_clock adapter, right?
<rjo>
... or we can leave them for now and turn them of if we get the multiplication of bitstream through spi peripherals.
<whitequark>
rjo: I'm not sure if we can
<whitequark>
the problem is dependencies
<whitequark>
although, you don't need to have the bitstreams to use ARTIQ...
<GitHub17>
buildbot-config/master ad03809 whitequark: Do not build bitstreams after a successful ARTIQ build.
<rjo>
whitequark: nono. you need to build at least one bitstream.
<rjo>
the one that we do CI testing or "manual frequent testing"
<rjo>
cr1901_modern: do "View Range" and "Snap Range" sound good to you? i could never figure out what the previous button labels meant.
<cr1901_modern>
FitToView fits the handles to the view, ZoomToFit zoomed in w/o changing the handle/spinbox values until the handles are positioned symmetrically across the slider/axiss
<rjo>
yes. i know. but the label "Fit to View" did not say what was fitted. and "Zoom to Fit" did not say what was zoomed to fit what.
<rjo>
"View Range" seems clear: you get to "view the range". unambigously, at least to me.
<rjo>
same for "Snap Range"
<cr1901_modern>
Yea, it's a fair name
<rjo>
but anyway. if they become keyboard shortcuts (if possible) and context menu entries (necessary) then they can become more prosaic.
<rjo>
cr1901_modern: if you zoom in now at high dynamic range ("1 + 1e-7*") then you get floating point problems. so there is some single precision floating point stuff going on in qt.
<rjo>
that's fine. we can live with that.
<rjo>
to get rid of that and move the problem to "1 + 1e-14", you probably need to replace that QTransform with your own code.
<rjo>
cr1901_modern: i'll rig the QScientificSpinbox now.
<cr1901_modern>
rjo: Yes, was just playing around with that. https://github.com/m-labs/scanwidget/blob/master/todo.md Also, the first entry of this list may also be a Qt precision problem w/ mapping slider handles that are extremely out of range
<cr1901_modern>
For instance, if I keep the handles at their default position of +/- 50 and zoom in to about 1e-6 or thereabouts, Qt thinks the Upper slider should be placed at pixel 0
<cr1901_modern>
My guess is that it's trying to invert a matrix that ends up being singular due to floating point stuff
<rjo>
i don't think there are matrices involved. just (1 + 1e-9) - 1 == 0
<cr1901_modern>
(Well, it's gonna be multiplied by a pixels-per-unit-increment factor before being sent to Qt, which becomes obscenely large at deep zooms)
<cr1901_modern>
I'll start implementing the number of points in a bit.
<rjo>
whitequark: could you please enable the trigger of the bitstream that you have the coredevice for?
<rjo>
cr1901_modern: don't worry about the problems at float machine precision. that scientificspinbox will, must, and should crap out earlier. it just does 6 significant figures
<whitequark>
rjo: ok. I rebuilt LLVM as Release. now on my machine, less than 10% of time is spent inside LLVM DSOs
<whitequark>
quite impressively 6% overall is spent in libc(!)
<whitequark>
anyway, now I'm down to ~30%CPU overall
<whitequark>
rjo: please test the -4 llvm-or1k and see if you get any improvement.
<whitequark>
in runtime build times, I mean.
<rjo>
will do.
<rjo>
shouldn't i look for a new llvmlite-artiq?
<whitequark>
mhm
<rjo>
whitequark: but compiling the runtime is about 30x faster.
<whitequark>
exactly what I would expect
<rjo>
maybe 20x. but significantly.
<rjo>
whitequark: i guess llvmlite-artiq needs a version bump
<whitequark>
you are unlikely to see significant improvement there
<whitequark>
but sure
<whitequark>
bb-m-labs_: force build --props=package=llvmlite-artiq conda-all
<bb-m-labs_>
build forced [ETA 1h05m39s]
<bb-m-labs_>
I'll give a shout when the build finishes
<rjo>
sb0: another aesthetic and HIG-related reason why one wants much more linkage between the spin boxes and the scanwidget is e.g. the representation of numbers. they should all similar formatting. not 0.002 in one spinbox and 3.234e-4 in the other and 1.3e-2 on the scanwidget axis.
<bb-m-labs_>
Hey! build conda-all #15 is complete: Success [build successful]
<rjo>
whitequark: that lowers the cpu time to compile the handover example by a factor of 2-3 afaict.
<rjo>
argh. the focus sequence on Tab/S-Tab in artiq_gui is horrible.
<rjo>
cr1901_modern: feel free to cross of the first two float precision related bullets. i don't see any real bugs there.
<whitequark>
hm, I wonder if I can hook up LLVM's infrastructure to reduce testcases automatically.
<cr1901_modern>
rjo: Ack. My energy's failing me right now. I'll continue working in a bit
<rjo>
cr1901_modern: thats fine. looks really good now. get well soon.
<rjo>
sb0: give the scanwidget a try. imho we can work with this already and move it over to artiq.
<cr1901_modern>
rjo: tyvm. Also sb0: Yes, I'm sick again. It's been an interesting year. I haven't had a cold since... 2012 I think?
<whitequark>
wow, I broke lwip
<whitequark>
Assertion "pbuf_free: p->ref > 0" failed at line 687 in /home/whitequark/Work/artiq-dev/artiq/artiq/runtime/liblwip/../lwip/src/core/pbuf.c
<rjo>
whitequark: did you update it?
<whitequark>
update it to what?
<rjo>
whitequark: please don't unless they have fixed ppp
<rjo>
whitequark: update the lwip revision we use
<whitequark>
no, I didn't
<whitequark>
rjo: how do I use artiq_Flash?
<whitequark>
it fails as follows:
<whitequark>
auto erase enabled
<whitequark>
Error: Unknown flash device (ID 0x00000000)
<whitequark>
Error: auto_probe failed
<whitequark>
ah, needs proxy
<whitequark>
I have a nasty bug where certain patterns in compiled code hard-crash the hardware we test this on.
<GitHub133>
[artiq] whitequark pushed 2 new commits to master: https://git.io/v2lpK