<rjo>
sb0: as i said, those instructions are not really aimed at your case. and they seem to be out of date way more often than the recipes and way to often.
<sb0>
then there should be a process to keep them up to date
<sb0>
I check them from time to time already
FabM has joined #m-labs
<rjo>
yes. if we want to keep them. and for the majority of typical artiq users additional conda based "install from source" instructions would simplify things.
larsc has quit [Quit: Lost terminal]
<rjo>
bah. sb0, whitequark: whoever upgrades conda-build somewhere also needs to do it everywhere.
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 252 seconds]
<rjo>
sb0, whitequark: who upgraded conda-build on slave64 but missed slave32?
<sb0>
I'm not touching the windows build VMs, so not me
<GitHub156>
conda-recipes/master 5288ae8 Robert Jordens: Revert "qt5: use the tar.gz"...
<sb0>
anyone using migen with python < 3.5?
* cr1901_modern
raises hand hesitantly? I mean, I'm stuck with 3.4 on an Ubuntu netbook I use for Migen dev when I travel
<cr1901_modern>
I guess I could just compile 3.5 tho
sb0 has quit [Quit: Leaving]
<whitequark>
rjo: I think that was my fault
<whitequark>
I didn't upgrade slave64, I think I've reinstalled slave32 conda
<whitequark>
but yeah, same effect
<rjo>
whitequark: ok. i have downgraded it. the newer conda adds a few directories to the build path which breaks due to a too long filename (somehow).
fengling has joined #m-labs
fengling has quit [Ping timeout: 268 seconds]
<whitequark>
"somehow" ?
<whitequark>
windows has a 240 char (iirc) limit on filename length
<whitequark>
well, strictly speaking, it doesn't, but you have to use UNC (\\?\...) paths everywhere if you want to exceed it
<whitequark>
and most software is sloppily written.
<rjo>
yeah seen that. is that the entire path or per component
<rjo>
?
<whitequark>
entire pat
<rjo>
really? so the winapi kills all the ntfs features?
<whitequark>
sorta, yes
<whitequark>
amazingly even Explorer doesn't properly use UNC paths everywhere
<whitequark>
so if you *do* create such a path through software, you'll discover that you actually cannot e.g. delete files deep inside it...
<rjo>
yeah. but then that's a nice coincidence between conda-build becoming a bit more organized and the qt source having very long pathnames in it.
<whitequark>
yes.
<rjo>
qt 5.6 and pyqt 5.6 are in the "standard" conda channels by the way. and they work for me here. might be a convenient time to kill several birds with one stone.
<whitequark>
do we still have patches for pyqtgraph?
<whitequark>
or pyqt?
<rjo>
nothing relevant that i can see
<whitequark>
ok
<rjo>
and afaict we might be testing the transition already: the python side is the same. if somebody installs qt and pyqt (5.6) after installing artiq, they will be using those with artiq. conda doesn't detect the filename collisions among pyqt{5,} and qt{5,}
fengling has joined #m-labs
fengling has quit [Ping timeout: 268 seconds]
fengling has joined #m-labs
fengling has quit [Ping timeout: 268 seconds]
sandeepkr has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
<larsc>
rjo: "The latency is deterministic for each channel (DAC). However, it is possible that the latency matching between channels could be off by 1 DAC clock cycle. This latency matching can change form one power cycle to the next."
<larsc>
whatever that means
<larsc>
I feel lik the first and the last sentence contradict each other
FabM has quit [Quit: ChatZilla 0.9.93 [Firefox 45.4.0/20160921204512]]
fengling has joined #m-labs
fengling has quit [Ping timeout: 268 seconds]
fengling has joined #m-labs
cr1901_modern has quit [Ping timeout: 258 seconds]