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
<sb0>
rjo, reload for what exactly?
<rjo>
reloading a module.
<rjo>
of an experiment.
<rjo>
the gui process or (controllers with number crunching) can not restart (unlike the core device worker)
<sb0>
hmm, the problem with the shared filesystem (as you pointed out several times) is it needs to be set up... and would it become a strong dependency of the GUI then?
<sb0>
the main issue I see with remote imports, besides importlib being a mess, is that they won't integrate with asyncio
<sb0>
you'd do the network access with asyncio, but the import statement cannot yield
<sb0>
it's kinda annoying how poorly integrated asyncio is with the rest of Python, generally
<sb0>
so the GUI would have to spawn a thread. maybe an asyncio executor would work.
<rjo>
importlib has seen lots of cleanup in py3k. the code that i read looked good.
<rjo>
imho the dependency on the share filesystem is ok. if i had to estimate, more than half of the labs would have the gui and the master on the same machine.
<rjo>
but the required features for the remote import almost a complete remote read-only filesystem by itself (dir list, file modes, file times, reading)
<rjo>
plus you need a local bytecode cache.
<sb0>
yes, that's totally reinventing a network fs... but a low-performance one written in python shouldn't be hard to write, and that would simplify installations
<sb0>
you could just install the conda packages on a machine and be ready to use the GUI with just the IP of the master...
<rjo>
in that case the cheapest server side would be exposing the repo per http and then implementing a http-importlib thing for for the client
<sb0>
why http? there's already the rpc server
<rjo>
in all the machines here we already share a filesystem...
<rjo>
because for http the server and client sides are done.
<rjo>
just needs the importlib hooks.
<rjo>
doing it ontop of the rpc server would not be much more additional work but it would be some.
mumptai has quit [Remote host closed the connection]
<cr1901_modern>
sb0: Rebased patch from me has arrived. Only 3 days after I said I would do it because I can't stay focused to save my life.
<GitHub42>
[artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vUJDB
<GitHub42>
artiq/master a36c51e Sebastien Bourdeauducq: DDS over RTIO (batch mode not supported yet)
<sb0>
rjo, I'm planning to reset the DDS in the idle experiment, is that OK?
<sb0>
in other words, the idle experiment is responsible for resetting every DDS channel and loading registers such as the frequency divider disable (with all the details of a "reset" handled by the runtime)
<sb0>
this means the DDS will be reset every time the idle experiment is invoked
<sb0>
hmm, that could cause problems if the idle experiment is stopped in the middle of a reset
<sb0>
what about having the runtime ensure that the idle experiment gets at least e.g. 100ms of CPU time every time it is invoked?
<GitHub77>
[pyparser] whitequark pushed 1 new commit to master: http://git.io/vUJHa
<GitHub77>
pyparser/master a470d6b whitequark: Don't crash in lexer on closing delimiter if it was never opened.
<GitHub137>
[pyparser] whitequark pushed 1 new commit to master: http://git.io/vUJ7F
<GitHub137>
pyparser/master 3f61113 whitequark: Make default error reporting rule work again.
<GitHub56>
[pyparser] whitequark pushed 1 new commit to master: http://git.io/vUJAj
<GitHub56>
pyparser/master ab67bb8 whitequark: Factor out pyparser.parse.
<GitHub146>
[pyparser] whitequark pushed 2 new commits to master: http://git.io/vUUvN
<GitHub146>
pyparser/master 3650f5c whitequark: More consistent documentation.
<GitHub146>
pyparser/master 0266a52 whitequark: Lex comments as whitespace.
<GitHub56>
[pyparser] whitequark pushed 1 new commit to master: http://git.io/vUUki
<GitHub56>
pyparser/master f0ddee7 whitequark: Check that lhs of assignment or deleted expression is valid.
<GitHub134>
[artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vUULi
<sb0>
what is the braid for? containing explosions?
<whitequark>
I dunno, actually
<whitequark>
it might be load-bearing
<whitequark>
it is load-bearing on polymeric hoses but these hoses (PTFE-lined) are unsuitable for my application
<whitequark>
because it's based on static pressure and the effusion rate of He is just too high
<sb0>
hmm... would a kf16 bellows hose be dangerous if it blows up?
<whitequark>
aha
<whitequark>
The flexible stainless steel braiding protects the formed bellows from abrasion or impact produced by component movement or vacuum cycling and also protects the hose from excessive bending.
<whitequark>
if it blows up... hm
<whitequark>
first, there is another issue
<whitequark>
the o-rings on kf-style centering rings are blown out by pressure
<whitequark>
to avoid that you can add an additional retaining ring, similar to those on larger ISO centering rings
<whitequark>
but rigid, of course
<whitequark>
I really don't think the KF flange is a good idea for operation under pressure solely by its leak characteristics
<whitequark>
"ISO-KF connections are suitable for pressures up to 10-8 hPa and can also be used for over pressures up to 1,500 hPa."
<whitequark>
so, 1.5 atm at most
rjo has quit [Read error: Connection reset by peer]
rjo has joined #m-labs
<whitequark>
sb0: I'm considering just using the usual HVAC approach
<whitequark>
brazed copper refrigerant lines
<whitequark>
and some custom fittings
mumptai has joined #m-labs
antgreen has joined #m-labs
antgreen has quit [Read error: No route to host]
<rjo>
resetting dds in idle is ok for most things (would be just a < µs outage) but for clocks and if you drive your trap with that rf it's a no-no.
<rjo>
i had alluded to idle vs default, default just running once (resetting and leaving ttl's open), and idle doing actual cooling-detection cycles with data returned.
<rjo>
oh. i had remembered that the fud was global. a non-global fud is a bad idea imho. we should fix that.
<rjo>
but as long as the fud is per-dds, i would do the first fud at the batch_enter timestamp and the others as close as possible afterwards (correcting for phase).
<rjo>
and since most use cases will in fact have a rf switch with it, it makes sense to me to attach the ttl channel to the dds nonetheless, just to clean up the namespace a bit (bd_dds, bd_sw -> bd).
<rjo>
oh. and i was also always opposed to the term "ttl" (because among other things, that is just a signalling standard) but the only alternative that i can come up with would be "pin"...
<rjo>
"ttl" is ok by me. people seem to use it consistently.
<GitHub26>
[misoc] enjoy-digital pushed 2 new commits to master: http://git.io/vUtoR