<rjo>
sb0, whitewquark: i can't reproduce nor do i understand why it can't import pipe_ipc on the buildbot yet execute the test and why the test fails.
<rjo>
whitequark that is.
ylamarre has quit [Quit: ylamarre]
<whitequark>
no clue
<whitequark>
I've never used asyncio
<whitequark>
buildbot might have been confused by merge commits, it was created for SVN
<rjo>
whitequark: maybe we can throw a git status into the git step?
<whitequark>
rjo: what for?
<whitequark>
I mean, confused in who is to blame, not confused in checking out code
<rjo>
yeah. i don't care so much about the blame. more about the failure
<rjo>
whitequark: can i haz ssh for the buildbot, at least to satisfy my curiosity?
<whitequark>
rjo: sure, I thought you already had it...
<sb0__>
rjo: if you're motivated to clean things up, you may want to look into #69 ...
fengling has quit [Ping timeout: 272 seconds]
<cr1901_modern>
rjo: New slider is implemented. It's the libqxt one, but stripped down to the essentials. Slider min and max cannot be reversed. I'll connect the signals in a bit
<cr1901_modern>
i.e. libqxt reimplementation*
<sb0__>
cr1901_modern: looks good!
<sb0__>
whitequark: any update on the windows packaging?
<whitequark>
sb0__: i just woke up, working on it now
<cr1901_modern>
sb0__: Ty. Prob should have done this from the beginning. We're going to lose a bit of precision on the values that can be set w/ the sliders. It won't be pixel granularity anymore. Spinboxes are okay for fine tuning I guess.
<cr1901_modern>
rjo: By default, the maximum slider is the one that's chosen when they both have the same value, except for the case where the minimum is at the maximum possible value. This is so we don't end up in a case where you can't move either slider. Would you prefer me to change it to "last selected" slider in case of a tie (except for the above case)?
sb0__ has quit [Ping timeout: 252 seconds]
sb0__ has joined #m-labs
sb0__ has quit [Ping timeout: 252 seconds]
ylamarre has joined #m-labs
sb0__ has joined #m-labs
sb0__ is now known as sb0
fengling has joined #m-labs
fengling has quit [Read error: Connection reset by peer]
ylamarre has quit [Ping timeout: 272 seconds]
<GitHub48>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vz1df
<GitHub48>
artiq/master 6383253 Sebastien Bourdeauducq: protocols/pipe_ipc: autoclose pipe fds on process exit in AsyncioParentComm
<GitHub73>
[artiq] sbourdeauducq created worker_pipeipc (+1 new commit): https://git.io/vz1dC
<GitHub73>
artiq/worker_pipeipc a583a92 Sebastien Bourdeauducq: worker: use pipe_ipc (no log)
<GitHub138>
buildbot-config/master 591c0dc whitequark: Add a Windows builder.
<whitequark>
sb0: do we move Ubuntu packaging off Travis?
<whitequark>
this should be exactly no extra work past installing Ubuntu in Xen, and it would allow us to support whatever versions we want and simplify debugging those obscure bugs
sb0__ has joined #m-labs
<sb0__>
whitequark: what Ubuntu packaging? I don't think we should spend any time on that
<sb0__>
and I'm not aware of any obscure bug, except the numpy PYON failure on your machine
sb0 has quit [Ping timeout: 252 seconds]
<sb0__>
(at least, not any ubuntu-specific one)
<whitequark>
sb0__: the only remaining use of travis by m-labs is in the conda-recpies running on Travis
<whitequark>
I'm saying "Ubuntu" because it is not actually OS-independent, it has platform dependencies on libc, gcc, and a bunch of X garbage
<whitequark>
by obscure bugs I mean the ones that periodically crop up in the conda build process and are impossible to debug because you can't run Travis locally
<rjo>
sb0__: i did not see any error on the buildbot with resetting to the merge commit. it looked like it did the right thing. but anyway. seems ok now.
<rjo>
sb0__: i'll put #69 on my list.
evilspirit has quit [Ping timeout: 264 seconds]
<sb0__>
rjo: ok, thx
<sb0__>
i'll see what i can do for udp on windows. i've been digging into asyncio guts for a while now...
<rjo>
cr1901_modern: nice. looks good. i did not look at the code, but is it really difficult to have start to the left of stop?
<rjo>
cr1901_modern: yes. if it is not too difficult the last selected should be "on top".
<rjo>
sb0__: alternatively we could consider saying "no moninj on windows".
<sb0__>
you said that was a serious restriction...
<sb0__>
another thing that can be done is moving that restriction to the master
<sb0__>
the master would do udp with the core device, and sync_struct to clients
<sb0__>
or have the core device use TCP anyway...
<rjo>
if i was the user, i would consider it serious, yes. but maybe others don't.
<sb0__>
the main problem with TCP is lwip is horrible to use
<rjo>
sb0__: yep. proxy it through the master or go tcp...
<cr1901_modern>
rjo: start to the left of stop?
<sb0__>
and doing semi-complicated things like that becomes a mess
<rjo>
cr1901_modern: sorry. the other way around.
<cr1901_modern>
rjo: Yes, it's complicated. A lot of the code I stripped out was based on the assumption that the sliders cannot be swapped
<rjo>
sb0__: what other stacks did you have on the radar? picotcp as well?
<sb0__>
uIP, which is a worse lwip
<cr1901_modern>
I was under the impression that the sliders wouldn't have to be swapped
<sb0__>
I used RTEMS before, which is another can of worms
<whitequark>
sb0__: write our own?
<rjo>
cr1901_modern: so you are saying "allowing start to the right of stop" was enforced and there was a lot of code. but then allowing it should be pretty simple right?
<sb0__>
whitequark: in rust?
<whitequark>
sb0__: yes
<whitequark>
there's already some of work done
<whitequark>
libpnet
<sb0__>
i'd be okay with moving the whole runtime to something better than C
<sb0__>
especially if it needs to do complicated things like device-assisted scheduling of experiments
* rjo
tries hard to cage his cynicism... ;)
<whitequark>
I dunno what are you even talking about
<rjo>
can we delay that to >>> 3.0?
<whitequark>
we don't have to REWRITE the runtime
<whitequark>
we can plug a network stack into it
<rjo>
cr1901_modern: sorry. wrong wording again. "start > stop" was prohibited and there was a lot of code to do so, right?
<whitequark>
that said, I have no idea what your idea of scheduling even looks like, so maybe?
<cr1901_modern>
In libqxt start > stop is not prohibited. Me being able to strip out a lot of code is based on start > stop being prohibited
<cr1901_modern>
rjo: ^^
<sb0__>
yeah, I guess the loader/linker and such can stay in C
<rjo>
cr1901_modern: ah. well. the idea of start > stop is to scan from large to small values. that has many use cases.
<sb0__>
but it makes sense to use a higher level language for the network functions, that would become pretty hairy with DAS
<sb0__>
and converting moninj to TCP would be straightforward then
<rjo>
DAS?
<sb0__>
device-assisted scheduling
<cr1901_modern>
rjo: There must've been a miscommunication somewhere. It's fine if you want the ability to swap sliders. I can add it back in, but it'll take a bit more time. But I was under the impression that it was prohibited
<rjo>
and by that you are referring to more than just the "staging the next kernel" thing?
<sb0__>
cr1901_modern, rjo: reversed scans are not supported anywhere right now
<sb0__>
and if we want to support them, the easiest way is probably a "swap boundaries" button in the GUI
<whitequark>
sb0__: no, I don't mean that any parts *need* to stay in C
<sb0__>
rjo: you need to stage many kernels, look at their priority values, tell the different workers what to do
<whitequark>
practically all of them will benefit from Rust's features
<whitequark>
but we can replace them one by one instead of one huge rewrite
<sb0__>
rjo: this implies being able to accept connections from many workers, manage memory, etc.
<whitequark>
which will mean we'll be shipping something useful throughout the rewrite.
<sb0__>
rjo: all this is a huge PITA with lwip and C
<whitequark>
sb0__: oh also, it will be very easy to rewrite session.c so that packets could be fragmented if we use Rust
<whitequark>
it has excellent support for zero-copy streaming parsers, best in class probably
<sb0__>
whitequark: can't it support very large packets then, instead of fragmentation?
<rjo>
sb0__, whitequark: maybe. as usual i am just worried about underestimating the amount of work that will go into this.
<whitequark>
sb0__: we can make the buffers extra large right now, no?
<whitequark>
I thought you had some reason that wouldn't be good
<sb0__>
rjo: oh it will be a mess for sure
<sb0__>
whitequark: yes, memory limitations on pipistrello
<whitequark>
oh, I understood what you said
<whitequark>
yes, it would be just very large packets
<whitequark>
I meant "fragmentation" in the network sense
<whitequark>
not application layer sense
<sb0__>
originally, 8MB on ppro, we have 64MB now...
<cr1901_modern>
rjo: That's fine. But it's probably easier to just add a state var (checkbox) that tells which direction to scan when reverse scans are supported.
<rjo>
if that is compact, yes.
<cr1901_modern>
When sending data to the FPGA, artiq_gui will need to query this checkbox (i.e. I'll provide a public method isReversed()) before actually sending the data.
<rjo>
but at least in the representation of the scan, start > stop should be permitted. then there is also no other field necessary.
<cr1901_modern>
rjo: "then there is also no other field necessary." What do you mean?
<cr1901_modern>
rjo: Each slider is it's own entity. The slider on the left will always be the slider on the left, except the special case where they are equal. Ditto for right. It doesn't really matter if the slider on the left becomes the max, and the right slider becomes the min from ARTIQ's POV. But from the widget's POV, me being able to strip a lot of code relies on left always being left
<GitHub41>
artiq/worker_pipeipc 5aa4de8 Sebastien Bourdeauducq: refactor logging and implement in worker
<GitHub41>
[artiq] sbourdeauducq pushed 1 new commit to worker_pipeipc: https://git.io/vzD3q
<rjo>
cr1901_modern: you can tell the scan direction from the fact that start > stop.
<cr1901_modern>
rjo: Okay, so you want the widget itself to keep track of whether start > stop, and whether the min slider is > max slider. Is that correct?
<rjo>
cr1901_modern: no. you can do the additional checkbox to represent the scan direction. but in the backend and w.r.t. the parameters that are passed to the experiment, you don't need that additional variable.
<cr1901_modern>
Okay, I understand now. But the artiq GUI will still need to query the checkbox to know whether to swap the values it sends
<cr1901_modern>
will that be a problem?
<rjo>
cr1901_modern: not afaict. but as sb0__ says, there will be a problem further down.
<cr1901_modern>
AFAICT, that's inherent to supporting reverse scan tho ;)
<cr1901_modern>
not necessarily anything I can screw up
<rjo>
cr1901_modern: yes. but you should prepare your widget accordingly for when that will be fixed.
<rjo>
sb0__, whitequark: is suspect that DAS will be of reduced value because more staging means more lack of synchronization of parameters. I think we can handle one kernel being staged. but more might become very painful experimentally.
<sb0__>
rjo: staging more kernels is necessary to handle priority inversions
<sb0__>
rjo: also, parameter passing can happen through the core device cache
<rjo>
sb0__: https://github.com/tass-belgium/picotcp actually looks pretty clean. maybe next time somebody needs a networking stack in C, they should try that.
<rjo>
sb0__: if you get prio inversion, you can just cancel the staged kernel.
<cr1901_modern>
rjo: Very well, I'll add the checkbox and provide a helper function to query the state. When reverse scan is supported meaningfully, you query that checkbox to determine the scan direction.
<sb0__>
rjo: does it implement the window mechanism?
<rjo>
sb0__: that would mean synchronizing all or most of the dataset_db to the core device.
<rjo>
sb0__: tcp window?
<sb0__>
rjo: uIP, for example, supports only one unacked TCP packet, which makes it unusable for anything but the most trivial stuff
<cr1901_modern>
rjo, sb0__: It might not be as nice as sliders being able to cross each other from a GUI standpoint, but it's also less code that accomplishes the same thing. And code that's not there can't fail.
<cr1901_modern>
(Pretty sure that's sb0__'s philosophy anyway if I learned anything?)
<rjo>
sb0__: from the code it supports multiple packets in flight (unacked).
<rjo>
cr1901_modern: i am still surprised that crossing sliders is hard. might have to convince myself ;)
<rjo>
cr1901_modern: from a UI standpoint allowing the sliders to cross would be so much better than havint the checkbox.
<rjo>
sb0__: i don't think it does partial acks though.
<cr1901_modern>
rjo: It's not *that* hard to add, but I'll have to think about how to best do it
<rjo>
cr1901_modern: ack. do you want me to comment on the TODOs and questions you have in your code?
<cr1901_modern>
Please do when you get the chance. A number of them fell out during the last commit b/c strictly speaking, it was a rewrite :P
<cr1901_modern>
I'll need to add them back in.
<cr1901_modern>
libqxt's implementation is complete overkill; the parts I stripped out were mainly because I decided on the "sliders can't cross" invariant. This is because ARTIQ doesn't support reverse scans. I admit that I forgot that you said reverse scans are meaningful.
<rjo>
cr1901_modern: and you should follow PEP8 before somebody lynches you.
<cr1901_modern>
I ran it through autopep8, what else do you want :P?
<rjo>
cr1901_modern: if sliders move out of view during zoom, keep them there. do not move them.
<cr1901_modern>
Keep them there, as in "change the values displayed on the spinboxes"?
* cr1901_modern
needs to write some documentation for this widget so it's easy to modify
<rjo>
cr1901_modern: CamelCase for class names. not headLessCamels. the_rest_like_this
<rjo>
cr1901_modern: no. hide them.
<rjo>
sliders values should never change as a surprising sideeffect of zooming.
<cr1901_modern>
Okay, that's simple enough (just don't draw the sliders)
<cr1901_modern>
I need to fix the scientific notation problems w/ the axis as well
<rjo>
cr1901_modern: yes.
<cr1901_modern>
What I'm prob gonna do is change which power of 10 to use by querying how close the labels are to each other. If they nearly overlap, use the next power of 10
<rjo>
cr1901_modern: and about the granularity: just have at least as many slider positions as pixels.
<cr1901_modern>
That's not possible in the general case without things breaking. Qt only allows sliders to have up to 4096 different positions it can take before conversions start failing.
<cr1901_modern>
I have to convert from pixel to slider position whenever the spinboxes are updated, since the spinboxes can be used to increment to values that cannot be acheived using the sliders
<rjo>
cr1901_modern: 4096 sounds like plenty.
<cr1901_modern>
rjo: Okay. Just be warned that there's potential for breakage if you need more.
<rjo>
cr1901_modern: then make sure that if i enter a given value in the spinbox, it does not round/snap to slider values (until the slider is moved explixitly).
<rjo>
s/until/unless/
<rjo>
cr1901_modern: or phrased differently: the spinbox values should never snap to slider granularity, only if the slider is moved explicitly (which only happens on S-Wheel, LMB-drag slider, fit-sliders-to-view)
<cr1901_modern>
The spinbox values never do snap to slider granularity
<rjo>
cr1901_modern: good.
<rjo>
cr1901_modern: why do you need Fraction?
<cr1901_modern>
To prevent precision errors from creeping in during large zooms
<cr1901_modern>
rjo: There's three coordinate systems in play here: Numbers that the spinboxes show, pixels, and the set of integer values that the sliders can take on.
<rjo>
cr1901_modern: about the ticks: allowed mantissae are [1, 2, 5, 10...] all tick labels need to be shown with the same (decadic) exponent. there must be at least 2 and at most ~10 ticks over the view.
<rjo>
cr1901_modern: ok. if you really see rounding errors, Fractions are wise.
<cr1901_modern>
rjo: We need to back up before my current question gets lost, sorry
<rjo>
which question?
<cr1901_modern>
I'm looking for the relevant timestamp lol
<cr1901_modern>
Or just in the case where the conversion from pixelspace to sliderspace isn't guaranteed to work?
<rjo>
cr1901_modern: w.r.t. the three number scales: ack. there is also a natural hierarchy spinboxes > slider positions > pixels. snapping/rounding upwards that hierarchy happens only in very few very specific situations, downward happens "all the time" and dominates.
<cr1901_modern>
in other words, "the spinboxes are always right"
<rjo>
re your question: no. the spinboxes govern the sliders. only in the case where the sliders are moved the situation is reversed.
<rjo>
yes. spinboxes are always right.
<cr1901_modern>
What I was getting at is that I cannot promise that one integer increment in sliderspace will correspond to no more than one pixel increment in the general case
<rjo>
cr1901_modern: those are ethe things that come to mind and that i understand right now. anything else i overlooked?
<cr1901_modern>
rjo: I'm thinking. Not that I can think of. I just want to alleviate confusion with everything here before I start connecting signals and tuning
<rjo>
cr1901_modern: (unless the slider is LMB-dragged)
<rjo>
cr1901_modern: good.
<cr1901_modern>
I should perhaps write a document of priorities of coordinate systems and when they change.
<cr1901_modern>
(i.e. there's a default case, and there are special cases when it makes logical sense)
<rjo>
cr1901_modern: is there an easy way to prevent that "selection" of the slider being associated with the left slider only?
<cr1901_modern>
Well, I thought it was with the right :P. And it should be that difficult to add.
<cr1901_modern>
In the current committed code, right/max slider is always chosen except for the case where both sliders are at the max (so we don't end up w/ a case where you can't move either slider)
<rjo>
cr1901_modern: currently the motion range of a slider is hard-limited by the other slider. to me it seems you should either allow them to cross, or "push" the non-dragged slider if a slider hits the other one.
<cr1901_modern>
That was a side effect of not supporting reversing min and max
<rjo>
cr1901_modern: maybe it is with the right. the visual signalling is a bit unclear to me. i am just saying the two handles should not differ.
sb0__ has quit [Ping timeout: 252 seconds]
<rjo>
(in their highlighting)
<cr1901_modern>
Again, it can be done, but it requires me to look at how qxt did it and decide which code to add and which code to remove. qxt is overkill and supports a lot of things that I don't really need. There is a lot of code for handling the cases where the left slider moves to the right and vice-versa
<rjo>
cr1901_modern: ack. just food for thought. i'll leave you to it.
<cr1901_modern>
I am currently unsure how much of this "special case" code that I need, and whether it's even reasonable to make both sliders interchangeable.
<cr1901_modern>
(qxt itself distinguishes upper from lower)
<rjo>
cr1901_modern: the "required" additional code may just have come from terminology confusion: right-vs-left max-vs-min start-vs-top upper-vs-lower. might be worth sitting down and honing the terminology.
<rjo>
s/top/stop/
<cr1901_modern>
Start/Stop is the most accurate for this application, and there's no need to make this widget reusable by external projects. So perhaps I should use that terminology from now on
sb0___ has joined #m-labs
<cr1901_modern>
And simply default to start (blue) being on the left and stop (red)on the right when the widget is initially constructed.
<rjo>
cr1901_modern: ack.
<cr1901_modern>
rjo: Last thing: Why are the allowed mantissa not evenly spaced?
<whitequark>
hm, I don't remember the exact details though
<rjo>
sb0___: should we add a deprecating stub EnvExperiment to artiq/__init__.py to tell people what to do? i didn't because i think we can expect people to read the mailing list and/or the release notes.
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
bb-m-labs has joined #m-labs
<whitequark>
bb-m-labs: force build --props=package=levenshtein conda-win64
<bb-m-labs>
build #9 forced
<bb-m-labs>
I'll give a shout when the build finishes
<sb0___>
whitequark: your commit 6bf48e60badc52f67f16900c639a173528b68fa1 removed this info from the first line of the logs.
<sb0___>
and we want this info there, so that if someone is brave enough to mess around with QTreeView we can fold multiline log entries in the GUI and the first one (always displayed) will be more useful
<whitequark>
sb0___: it is entirely possible that i did not account for some case in that code
<whitequark>
feel free to restore old behavior
<sb0___>
I have done so, but your code displays this info twice in some cases (as in the paste), which makes 3 with the first line
<sb0___>
the old behavior didn't handle this parent_traceback you added
<whitequark>
ok, we have Windows conda package building up and running.
<whitequark>
I feel like there might be some fuckery going on
<whitequark>
ohhhh, nevermind, *conda*'s python is 64-bit
<sb0____>
ask on the ML if anyone really needs 32
<sb0____>
if so, there should be only 32, as those are also compatible with 64
<whitequark>
why don't we do the same for linux?
<sb0____>
are you building both 32 and 64 linux right now?
<whitequark>
sure, has been since travis was ever added
<sb0____>
iirc doing both 32 and 64 was easier on linux than on windows...
<whitequark>
it's exactly same
<whitequark>
I install 32-bit miniconda on a 64-bit system in addition to 64-bit miniconda
<whitequark>
done
<sb0____>
ok
<whitequark>
I personally think we should discourage people from using 32-bit packages
<whitequark>
there's not really any reason to use 32-bit systems in 2016
<sb0____>
old crappy drivers maybe
<sb0____>
this pxi6733 would be the usual suspect
<whitequark>
ugh
<sb0____>
but hey. maybe we should just drop this crappy card
<sb0____>
and replace it with the upcoming ARTIQ hardware :)
<sb0____>
but i'm not sure. maybe all-64 is okay.
<whitequark>
sb0____: please disable travis for m-labs/conda-recipes
<whitequark>
nevermind I can do that
<sb0____>
done
<cr1901_modern>
https://twitter.com/whitequark/status/692098789683957761 I do wish it was easier to make headway into LLVM's build system. Even with the cpu0 backend, it's quite overwhelming how many files I have to edit just to get started adding a "vanity" architecture :(.
<rjo>
we want 32 bit conda because we have a bunch of machines that have 32 bit windows because of old drivers.
<sb0____>
can 32-bit linux be dropped?
<rjo>
afaik yes
<whitequark>
bb-m-labs: force build --props=package=levenshtein conda-lin64
<bb-m-labs>
build #21 forced
<bb-m-labs>
I'll give a shout when the build finishes
<whitequark>
bb-m-labs: force build --props=package=levenshtein conda-win32
<bb-m-labs>
build #0 forced
<bb-m-labs>
I'll give a shout when the build finishes
<rjo>
sb0____: if i want to run the controllers for the testing, i want a lot of code from artiq_ctlmgr.Controller. OK to move that code to artiq.devices.ctlmgr?
<bb-m-labs>
Hey! build conda-win32 #0 is complete: Success [build successful]
<rjo>
whitequark: as a sidenote, I think that py_exn.__cause__ and __context__ are what we want to use for runtime_exn. see pep-3134.
<whitequark>
the ARTIQException class is not an exception
<whitequark>
not a Python exception that is, it is a representation of the core device exception
<whitequark>
so, putting it into those attributes is incorrect
<rjo>
i don't see anything that would make that incorrect.
<whitequark>
>>> NameError().__context__ = 1
<whitequark>
TypeError: exception context must be None or derive from BaseException
<whitequark>
...... oh
<whitequark>
that was conda cloning LLVM from git
<whitequark>
obviously, it does not display any progress, because who would ever want to see that their build is not just hung??
<whitequark>
bb-m-labs: force build --props=package=llvm-or1k conda-win64
<bb-m-labs>
build #12 forced
<bb-m-labs>
I'll give a shout when the build finishes
<whitequark>
bb-m-labs: force build --props=package=llvm-or1k conda-win32
<bb-m-labs>
build #1 forced
<bb-m-labs>
I'll give a shout when the build finishes
<rjo>
is it impossible to have CoreException be an Exception/implement its interface?
<whitequark>
rjo: it has to derive from BaseException, and that makes no sense.
<whitequark>
you're shoehorning it into a mechanism that was designed for a different problem
<whitequark>
it's not a context or a cause, it's the *same* exception in a different representation
<rjo>
but then i don't see the need for that metadata encapsulating object at all. just merge thr tracebacks, name should be the class, message and params go Exception.args.
<whitequark>
you cannot merge tracebacks
<whitequark>
python does not provide facilities for this
<whitequark>
you can do several very hacky things by binding and poking python internals using cpython, but they are gross and also non-portable and the existing code that does that (eg in jinja2) is also poorly written
<whitequark>
that is not all, ARTIQ Python tracebacks provide more information than python has space for
<whitequark>
specifically, column numbers, and less importantly addresses
<whitequark>
column numbers are quite helpful if you have e.g. several indexing operations on one line and you want to know which one broke eveyrthing without restarting your experiment and waiting.
<rjo>
ok. then i am happy with the metadata object.
<rjo>
still. IME the "better traceback info with column number" is a technicallity. in practice the amount of information to digest is -- in most cases -- much more than you need to guess the error. then it takes you longer to fix something in most cases even if for a few cases the additional info is very helpful.
<whitequark>
huh?
<whitequark>
what do you mean by "much more than you need to guess the error" ?
<rjo>
the diagnostic messages are way to technical, detailed, synthetic and verbose. IME just saying: "there is a problem with this line: `line....`" is good enough: you look at the line, see the error and fix it. all the babbling of the compiler can actually be irritating.
<rjo>
if i tested a few of these diagnostic messages on physicists, most of them would not lead to any understanding/insight.
<whitequark>
i see, python stockholm syndrome
<rjo>
or just the case of a somewhat simplistic, naive, superficial understanding and trial-and-error practice of coding.
<whitequark>
that said, "technical" and "synthetic" are almost certainly valid concerns
<whitequark>
I have tried to formulate the diagnostics in a graspable way but I had neither time nor feedback to do it really well
<whitequark>
I fully expect to improve them once I do get feedback
<rjo>
i personally actually like the diagnostics because they help me figure out e.g. the scoping and lifetime constraints of ARTIQ-Python. but for "simple errors" i have to force myself to ignore them.
<whitequark>
i think i would consider that a bug and an indication that a diagnostic must be improved.
<whitequark>
so, feel free to submit issues
<cr1901_modern>
rjo: What do you mean by merging tracebacks?
<rjo>
merging the runtime segment and the python traceback into one to be shown somewhat coherently.
<rjo>
whitequark: will do.
<whitequark>
I'd really rather merge tracebacks, to be honest
<whitequark>
I've spent like a day trying out various sane methods of doing it, but no, that does not work
<rjo>
cr1901_modern: not just the runtime part, but also the ARTIQ-Python part.
<cr1901_modern>
Ahhh, so the python subset that makes up artiq and the standard python interpreter can display a single traceback leading all the way up to where the error actually occurred?
<cr1901_modern>
Sorry, if I explained poorly
<rjo>
whitequark: i just inspected sys.exc_info()[3] and it looks very internal. i see the problem.
<rjo>
cr1901_modern: and the runtime that is written in C. yes. ideally they could be one traceback.
<cr1901_modern>
Yea, that sounds involved, even w/o knowing how the artiq python subset and standard python interact. Just wondering in any case
<whitequark>
rjo: the problem is not that, but that you cannot construct these objects.
<whitequark>
or rather, you can sort of construct them, but you cannot put them into an exception so that it remains there after raising.
<rjo>
whitequark: take http://paste.debian.net/369679/ reading that second 'note' sounds somewhere between wrong (should it be "is not supported _here_"?) and redundant.
<rjo>
whitequark: ack
<rjo>
whitequark: and why "trip count" and not "iteration count"?
<whitequark>
oh yes, "here" is missing
<rjo>
whitequark: and then the underlying issue is the "with parallel" which is never mentioned: maybe something like "this loop can not be used within `parallel` because its iteration count is indeterminate"
<whitequark>
"trip count" is a common compiler term. I will replace it with "iteration comment"
<whitequark>
er
<whitequark>
count
<whitequark>
yes, I will also point to the "with parallel:" I think
<whitequark>
because this can happen several nestings long and it's not immediately obvious which "with parallel:" it is
<rjo>
whitequark: ack. but maybe fine tweaking the compiler in this way should be delayed for later...
<whitequark>
rjo: it's a five minutes work...
<whitequark>
LLVM is going to hog the bot for a hour anyway
<whitequark>
bb-m-labs: force build --props=package=llvm-or1k conda-win32
<bb-m-labs>
build #2 forced
<bb-m-labs>
I'll give a shout when the build finishes
<whitequark>
bb-m-labs: force build --props=package=llvm-or1k conda-win64
<bb-m-labs>
build #13 forced
<bb-m-labs>
I'll give a shout when the build finishes