<whitequark>
"The problem is that conda picks the cygwin path (ignoring what is PATH environment variable)"
<sb0>
" Deleting the cygwin directory worked for me:"
<sb0>
hahaha
<kyak>
there are many Windows products that ship various unix utilities or set crazy environment flags that break shit
<kyak>
another that comes in mind is QNX
<kyak>
it sets MAKEFLAGS (like it's the one and only IDE in the world) and breaks many things, starting from Visual Studio and ending with Code Composer Studio
<kyak>
setting SHELL environment variable to their liking also seems like a good practice
<sb0>
mithro, you may want to post it on the qi-hardware list too (if anyone is still around...)
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
FabM has joined #m-labs
<mithro>
sb0: okay, will do
FabM has quit [Client Quit]
FabM has joined #m-labs
<GitHub0>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vaBAS
<GitHub0>
artiq/master 8a6873c Sebastien Bourdeauducq: analyzer: use EOP, flush pipeline on stop
<whitequark>
I mean... given that you explicitly have a raise there
<sb0>
yes, and if an exception is raised, then r is not actually used.
<whitequark>
oh, right
<whitequark>
yep that's a bug.
<sb0>
it's fine if the compiler isn't capable of determining this, just want to make sure this situation is understood and there aren't some bugs hiding
<whitequark>
no, it shouldn't do this. the existing algorithm is supposed to be smart enough.
<sb0>
there is the case where the exception is caught (if there were an except clause), and execution continues to return, the case where the except clause re-raises
<sb0>
it's kinda tricky
<whitequark>
no, not really.
<whitequark>
it operates on the CFG, where this is never ambiguous.
<whitequark>
I'm quite puzzled as to why it can't determine this, as I mentioned.
<whitequark>
so, please open an issue
<cr1901_modern>
sb0: Have you ever used Avalon?
<sb0>
cr1901_modern, not really
<sb0>
just ran the altera soc gui a couple times
<sb0>
whitequark, another thing. @kernel should use self.core
<whitequark>
it doesn't?
<sb0>
it doesn't do it consistently, e.g. if object A has a kernel that calls a kernel in object B, and object B doesn't have a 'core' attribute, there is no error atm
<sb0>
it should actually test for "A.core is B.core"
<whitequark>
ah yes
<sb0>
what to do if not - throw an error, RPC - is fine right now, we don't really have real-world multi-core-device setups yet
<GitHub92>
[artiq] sbourdeauducq pushed 2 new commits to master: https://git.io/vaR0S
<GitHub170>
buildbot-config/master 3b82734 whitequark: Limit concurrency via locks rather than max_builds.
<whitequark>
now I allow for 2 concurrent builds, unless low-latency step is executing, then it is one.
<whitequark>
and trigger steps aren't counted.
<sb0>
_florent_, the EOP trick is nice. thanks!
<_florent_>
great if it works!
<sb0>
whitequark, isn't qt supposed to display a horizontal scroll bar in the log, when words are too long to be wrapped?
<sb0>
it does, miserably, display a horizontal scrollbar sometimes (at inappropriate times)
<whitequark>
it's supposed.
<sb0>
the layout of table columns seems to be particularly loaded with bugs. like window embedding. now they are coming back in the schedule ...
<sb0>
Qt SerialBus
<sb0>
New module for general purpose serial bus access with initial implementation for Controller Area Network (CAN) bus and Modbus
<sb0>
wtf
<sb0>
they'd better fix the table bugs instead of this mission creep
<whitequark>
lol yes
<whitequark>
well, maybe not so much mission creep, Qt Embedded has existed for almost a decade
<whitequark>
maybe not even almost
<cr1901_modern>
Surprised that one of realStart/realStop was set but not the other (NoneType is only during init. It shouldn't be there by the time the widget is shown)
key2 has joined #m-labs
<sb0>
rjo, how should we call the new ARTIQ hardware?
<cr1901_modern>
sb0: I have to create a new conda environment for python 3.5.1 (if it will even let me) before I can fix this bug
<sb0>
cr1901_modern, that should work fine, no? everything artiq is packaged now
<cr1901_modern>
Well, conda, being the hot trash that it is, won't let me upgrade python to 3.5.1
<cr1901_modern>
But I'm glad that everything's packaged now. Building HDF5 from ssource wasn't fun
mumptai has quit [Remote host closed the connection]
mumptai has joined #m-labs
mumptai has quit [Remote host closed the connection]
mumptai has joined #m-labs
rohitksingh has quit [Ping timeout: 250 seconds]
<cr1901_modern>
rjo: Refactoring part one is done
<cr1901_modern>
rjo: I removed the layout and now the scanwidget manually handles the slider's dimensions and ensures that its width and position are correct. Axis class was collapsed into scanwidget.
<cr1901_modern>
I'm not prepared to remove handleWidth(). It really is important to make a distinction between the slider's actual width and the width that is usable for moving the slider.
<cr1901_modern>
rjo: resizeEvent is also fixed: range is preserved
key2 has quit [Ping timeout: 240 seconds]
<cr1901_modern>
rjo (Last thing for now): I do not feel I should get rid of the slider class. I feel that it is better as a separate entity whose geometry/layout is manually controlled by a parent.
<cr1901_modern>
sb0: On your Windows VM, which Miniconda or Anaconda do you install? The default installer wants to install 2.7? I can't remember if I had this problem last time I installed conda or not
<rjo>
sb0: that depends on what it is. if it is just the generic drtio part (fast serial link to fpga) then i would call it drtio-amc. if it is split drtio-aio4 (4 dacs, some adcs) and drtio-dio64 for the 64 ttls. but maybe that is to specialized already and the "drtio" should be dropped alltogether...
<rjo>
cr1901_modern: there is miniconda3 and a miniconda installer. they are different.
<cr1901_modern>
rjo: Thank you. Now let's see if conda actually LETS me install Python 3.5.1
<rjo>
cr1901_modern: yes. you still need the handle width. but not the way you did it before. isn't the divergence of widths and offsets between the sliders and the axis coordinates the root of all evil? why do you need that separation? all the event forwarding and method wiring is just boilerplate code.
<rjo>
cr1901_modern: the ten or so times that i did it it was fine.
<cr1901_modern>
rjo: I'm a strong adherent to Single Responsibility Principle. Seems like that backfired on me
<cr1901_modern>
axis widget should handle painting axis. ticker should handle figuring out tick divisions. slider should handle slider state. proxy handles linear transforms. scanwidget encapsulates everything else
<cr1901_modern>
IMO, doesn't sound like a bad idea on paper
<rjo>
that sounds like another phrase for encapsulation. but if you need to forward signals it already breaks the concept. for the ticker it works because you can define the interface and encapsulate it.
<rjo>
then write a class that does linear transforms. but not one that does linear transforms _and_ forwards signals to/from the sliders
<cr1901_modern>
Fair enough.
<cr1901_modern>
Okay everything's installed. When I try to run artiq, I consistently get ConnectionRefusedError: [WinError 1225] The remote computer refused the network connection (WTAF?!)
<cr1901_modern>
it's fucking localhost. Why would my own computer refuse a connection?
<rjo>
you need to start an artiq_master.
<cr1901_modern>
I did... that's the problem
<rjo>
what is "run artiq" for you?
<cr1901_modern>
rjo: Hold that thought... Windows thinks the port is still in use
<cr1901_modern>
even though I killed artiq
<cr1901_modern>
rjo: Fixed. This was my own incompetence, sorry
<cr1901_modern>
Killed the wrong python instance
<cr1901_modern>
(And took down my IPython notebook server in the process ._.)
mumptai has quit [Quit: Verlassend]
<rjo>
cr1901_modern: now it doesn't render at all in artiq_gui
<cr1901_modern>
What do you mean? I haven't fixed the bug yet
<cr1901_modern>
that causes a crash. Are you telling me that the changes I made broke the widget AGAIN?!
<cr1901_modern>
I swear to God, I cannot believe nobody on Qt forums knew how to make QGraphicsView keep the viewport anchored
<cr1901_modern>
rjo: What revision of artiq are you ussing and what version of the scanwidget?
<rjo>
master and master. i patched the crash by explicitly setting the scanwidget values. i guess the paint gets triggered before the other pending signals.
<rjo>
it's not necessarily breakage, maybe now it's just exposing another bug that was already there.
<cr1901_modern>
rjo: I'm sorry, I'm just fatigued with the bugs, and it showed just then.
<cr1901_modern>
If QGraphicsView wasn't broken in that ONE way, the widget would've been done a month ago
<cr1901_modern>
rjo: Can you try with bb12fa582?
<cr1901_modern>
^scanwidget revision*
<rjo>
i did a while back. what do you want to know.
<rjo>
?
<cr1901_modern>
Does it ALSO not paint anything?
<rjo>
that worked fine.
<cr1901_modern>
%PYTHONPATH% isn't picking up my local copy of artiq, naturally
<cr1901_modern>
(when has PYTHONPATH ever worked correctly?)
<cr1901_modern>
rjo: How'd you force your conda environment to use the git artiq? Did you just install all the dependencies but not artiq itself?
<rjo>
pretty much. it is actually easy to install it, then uninstall just artiq and then setup.py develop
<cr1901_modern>
Which is what I'm doing now and Cython is generating about 10,000 file
<rjo>
no need for pythonpath trickery.
<cr1901_modern>
yea, I've found PYTHONPATH really doesn't work like I expect it to 90% of the time anyway. In any case, problem solved, back to work
<cr1901_modern>
rjo: Presumably, you also took out the disable_scroll_wheel(scanner.axis) code when testing?
<cr1901_modern>
rjo: Yes, can confirm what you are seeing. So let's figure out the "why" part...
<rjo>
yes
<cr1901_modern>
paintEvent is never being called for the widget. Makes perfect sense