sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
fengling has joined #m-labs
early has quit [Quit: Leaving]
early has joined #m-labs
fengling has quit [Ping timeout: 272 seconds]
fengling has joined #m-labs
evilspirit has joined #m-labs
ylamarre has joined #m-labs
ylamarre has quit [Quit: ylamarre]
kmehall has quit [Remote host closed the connection]
kmehall has joined #m-labs
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger has joined #m-labs
folkert has joined #m-labs
<whitequark>
sb0: you can do whatever you want to ssh on the second machine (:5901), btw
<whitequark>
though please still try not to get it infected with rootkits as it has full access to our internal network
evilspirit has quit [Ping timeout: 276 seconds]
<whitequark>
rjo: so I've been eyeing using OPAM further and further
<whitequark>
the idea now is to use OPAM while discarding most of the things it does, i.e. take a source package manager and treat it as a binary one
<whitequark>
just by virtue of never building anything.
<whitequark>
but the problem is, I recalled our last conversation on this topic and I wonder if we can switch from conda at all?
<whitequark>
you sounded like the one fundamental, irreplaceable benefit of conda was its anaconda metapackage and everything else it could grab in
<whitequark>
which means that in case we ever want to migrate from conda, we need to, uh, repackage everything our downstream users could ever want?
evilspirit has joined #m-labs
<whitequark>
because no matter what package management solution we figure out, there's no way it will be 1:1 compatible with conda
<sb0>
whitequark, how does OPAM fix the problem of the changing xcb path?
<sb0>
whitequark, by the way, the Qt installer lets you choose the installation directory on Linux as well ... and doesn't need you to set environment variables or anything
<whitequark>
the Qt installer probably uses the host libxcb
<whitequark>
er
<whitequark>
xkb
<whitequark>
it's not xcb.
<whitequark>
OPAM doesn't fix that problem, OPAM fixes having to deal with all the conda bugs
<sb0>
it's actually very painless, e.g. if you run its qmake (just by invoking it, nothing else required), it sets up everything so that your application builds and runs with that Qt from the installer
<whitequark>
does it place a qt.conf near your executable?
<whitequark>
anyway, yes, that's about what I'm expecting from Qt
<sb0>
I'm not sure what it does, but I was happy I didn't have to deal with any of the usual annoyances that come with linux installers.
<sb0>
it just works
<sb0>
and yes, it uses the host xkb library, and some other host x11 libraries. can we do the same?
<sb0>
I double checked a few of those, and they are *not* shipped in the qt install
<whitequark>
yup, sure, we can do that.
<sb0>
good. regarding qt4 + qt5 coexistence, can't the pyqt5 package be patched so that it sets the path to qt.conf upon import?
<sb0>
or have qt look for a different filename, e.g. qt5.conf
<whitequark>
we can probably build qt with a patch
<whitequark>
which is the only way if we want to get our package into conda...
<sb0>
ok
larsc has quit [Quit: Lost terminal]
larsc has joined #m-labs
Gurty has quit [*.net *.split]
_florent_ has quit [*.net *.split]
mazzoo_ has quit [*.net *.split]
cyrozap has quit [*.net *.split]
[florian] has quit [*.net *.split]
cyrozap has joined #m-labs
[florian] has joined #m-labs
[florian] has joined #m-labs
[florian] has quit [Changing host]
Gurty has joined #m-labs
mazzoo has joined #m-labs
_florent_ has joined #m-labs
_whitelogger has joined #m-labs
bb-m-labs has quit [*.net *.split]
bb-m-labs has joined #m-labs
<sb0>
rjo, whitequark, what do you think of the "dumb parallel" implementation for artiq-1.0? then there will be more leeway for whitequark to experiment with things and potentially break APIs in 2.0+ ...
<sb0>
2.0+ could fall back on the dumb parallel implementation when the user doesn't mark things as immutable
<whitequark>
that sounds like a horrible idea
<sb0>
(perhaps with a warning)
<sb0>
why?
<whitequark>
because they're not equivalent
<whitequark>
silently generate code with different semantics based on a fairly opaque set of constraints is a horrible idea
<sb0>
what exactly does that?
<whitequark>
'fallback'
_florent_ has joined #m-labs
<sb0>
so you'd turn the warning into an error?
<whitequark>
whether parallelization can be done is a nonlocal condition
<whitequark>
I'd make them different constructs
<whitequark>
something like `with dumb_parallel:`
<sb0>
ok. sounds good.
<whitequark>
or even `with parallel:` / `with interleave:`
<sb0>
good
<whitequark>
actually, silently falling back is even a worse idea than I initially thought
<whitequark>
because side effects in non-RTIO code are also reordered
<whitequark>
no, that's an absolute nonstarter
<sb0>
how about this: in 1.0, ``with parallel`` does the dumb parallel thing, and ``with interleave`` is an experimental feature that does what the current ``with parallel`` does
<whitequark>
sure
<sb0>
in 2.0+, ``with interleave`` is fully supported/documented and has this fancy immutable attribute support
<rjo>
sb0: are you distinguishing 'dumb parallel' from the transaction style parallel thing?
<rjo>
i would want to have 'with dumb_parallel:' be syntactic sugar on top of the explicit transaction style parallelism.
<rjo>
or 'with parallel:' as you just defined it.
<rjo>
whitequark: about packaging: yes. there is immense value in integrating into an existing python distribution that is widely used in virtually all labs. most of it gets forgotten: just the availability of an resonable python editor and some console, plus syntax checking makes all the difference for a windows-physicist.
<whitequark>
so, do you need all of conda or just spyder after all?
<whitequark>
because we could certainly package spyder.
<rjo>
sb0, whitequark: i am good with having 'with parallel:' be syntactic sugar on top of the explicit transaction style parallelism for 1.0 and then 'with interleave:' magic for 2.0
<rjo>
whitequark: lets take cython. thats a package we use a lot. it needs a C toolchain.
<whitequark>
i'm pretty certain conda doesn't ship a C toolchain.
<rjo>
whitequark: i don't think you can distill the requirements for a python distribution that easily.
<whitequark>
on Windows you can't even do that legally
<whitequark>
(well, not a C toolchain that easily works)
<rjo>
whitequark: you might want to have a look at how they get cython to work from conda.
<rjo>
whitequark: i don't know from the top oof my head. but it compiles C .dlls for you that work with python. and you don't have to install msvc or the cut down version of it.
<whitequark>
rjo: pretty sure you do.
<whitequark>
the package doesn't have any dependencies except python itself.
<whitequark>
oh yes, I see, the anaconda metapackage depends on mingw.
<rjo>
so mingw(64) can generate ABI compatible (with msvc*) objects for python?
<whitequark>
sorta.
<whitequark>
the debug info and exception handling is all different
<whitequark>
but the C code that cython generates is compatible.
<whitequark>
clang on the other hand aims for exact ABI compatibility, including for C++ code and the PDB format
<rjo>
lucky.
<whitequark>
they pretty much already have it for C++
<whitequark>
they have several hundred testcases for bug compatibility with MSVC, which must have been an insane feat
<whitequark>
(MSVC name mangling has a massive amount of bugs.)
<rjo>
like samba
<whitequark>
and the exception handling required LLVM to completely overhaul its IR
<whitequark>
well, the exception handling parts
<whitequark>
and after that they still had to write a transform that turns it inside out
<whitequark>
but quite impressively it works
<whitequark>
maybe will be fully usable by 3.9 or 3.10
<rjo>
but anyway. people will cry until they are easily able to install the following typical python packages on their windows machines in an environment where they can also use artiq: cython, qutip, ipython, ipython-notebook (and its dependencies), scipy, numpy, pandas, likely numba. those are from the top of my head.
<rjo>
spyder
<rjo>
that's about half of anaconda.
<whitequark>
ok. m-labs should not be in business of package management.
mithro has quit [*.net *.split]
whitequark has quit [*.net *.split]
<rjo>
to compete with continuum.io _and_ the python(x,y) people?
mithro has joined #m-labs
mithro has quit [*.net *.split]
cyrozap has quit [*.net *.split]
ysionneau has quit [*.net *.split]
mindrunner has quit [*.net *.split]
ysionneau has joined #m-labs
mindrunner has joined #m-labs
cyrozap has joined #m-labs
fengling has quit [*.net *.split]
mithro has joined #m-labs
<sb0>
rjo, let's not have the two "no interleave" mechanisms...
<sb0>
I propose we keep "with parallel", as it is consistent with the future "with interleave"
<sb0>
though, with support for the context managers in the compiler, you could have the transactional style easily
<sb0>
but having two ways to do the same thing will result in inconsistent code
<sb0>
regarding packages. after qt is fixed we're done with that, no?
<sb0>
spyder, cython, etc. aren't our problem
jaeckel has quit [*.net *.split]
<rjo>
sb0: there are a few good reasons to keep 'with Synchronous() as s: ... s.align() ...': it gets rid of the `with sequential`, it is much more explicit that 'with parallel:`, and i suspect that the implementation of 'with parallel:' would actually just translate to it.
<sb0>
qt4 + qt5 coexistence is as far as we should go
<rjo>
to me these are not ambiguous ways to do the same thing but different abstraction levels.
<sb0>
rjo, there are no AST-level transforms anymore so I'm not sure what witequark would think of implementing it that way
<rjo>
if we stick with conda, the other packages are not our problem. yes.
<sb0>
*whitequark
<rjo>
sb0: sure. i am just putting it on the table. i personally would use the explicit style much more often than the implicit style. let's leave it to him. if he translates implicit to explicit anyway, then we should also expose the explicit API.
<rjo>
whitequark: if you can find some time to look at the compilation speed isue with the transport example (see log), that would be great. is is blocking the pdq2 stuff currently, and that's a blocker for the labs. i basically want to know whether i have to rewrite all the Mediator/Frame stuff because it gets pulled into the compilation.
bb-m-labs has quit [*.net *.split]
[florian] has quit [*.net *.split]
evilspirit has quit [*.net *.split]
hozer has quit [*.net *.split]
kristianpaul has quit [*.net *.split]
kaalia has quit [*.net *.split]
balrog has quit [*.net *.split]
bb-m-labs has joined #m-labs
kaalia has joined #m-labs
hozer has joined #m-labs
evilspirit has joined #m-labs
jaeckel has joined #m-labs
kristianpaul has joined #m-labs
kristianpaul has joined #m-labs
attie has quit [*.net *.split]
gric has quit [*.net *.split]
tmbinc___ has quit [*.net *.split]
felix_ has quit [*.net *.split]
balrog_ has joined #m-labs
attie has joined #m-labs
fengling has joined #m-labs
tmbinc__ has joined #m-labs
gric has joined #m-labs
attie_ has joined #m-labs
felix_ has joined #m-labs
[florian] has joined #m-labs
rohitksingh has joined #m-labs
_whitelogger has joined #m-labs
awallin has joined #m-labs
mindrunner_ has joined #m-labs
mindrunner has quit [*.net *.split]
ysionneau has quit [*.net *.split]
_florent_ has quit [*.net *.split]
siruf has quit [*.net *.split]
kyak has quit [*.net *.split]
ysionnea1 has joined #m-labs
kyak has joined #m-labs
kyak has quit [Changing host]
kyak has joined #m-labs
siruf has joined #m-labs
balrog_ is now known as balrog
ylamarre has joined #m-labs
whitequark has joined #m-labs
_florent_ has joined #m-labs
ysionnea1 is now known as ysionneau
robtaylor has quit [*.net *.split]
robtaylor has joined #m-labs
<rjo>
sb0: re analyzer rtio exceptions: exceptions should be rather rare and only one can be read in a given tick. why do you want one exception channel per rtio channel?
<sb0>
hm, yes they can all be in one channel
FabM has joined #m-labs
<rjo>
nice. influxdb 0.10 has really gotten good at compact storage of time series. 2 bytes per (time, float64) pair on average.
evil_spirit has joined #m-labs
evilspirit has quit [Disconnected by services]
evil_spirit is now known as evilspirit
nico_____ has joined #m-labs
nico_____ has quit [Client Quit]
ylamarre has quit [Quit: ylamarre]
ylamarre has joined #m-labs
bb-m-labs has quit [Ping timeout: 255 seconds]
bb-m-labs has joined #m-labs
mithro has quit [Ping timeout: 240 seconds]
mithro has joined #m-labs
lars_ has joined #m-labs
mumptai has joined #m-labs
evilspirit has quit [Ping timeout: 268 seconds]
zoobab has quit [Ping timeout: 248 seconds]
zoobab has joined #m-labs
<sb0>
rjo, i suggest you open a issue regarding the slow compile times
<GitHub118>
[migen] sbourdeauducq pushed 2 new commits to master: https://git.io/vgxf2