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
rohitksingh has quit [Ping timeout: 256 seconds]
ylamarre has joined #m-labs
<rjo> but i think there are several usages of list_targets() that need to be made slice-accurate
ylamarre has quit [Quit: ylamarre]
evilspirit has joined #m-labs
<sb0> whitequark, is the source somewhere?
<sb0> those figures look surprising and i'd like to do a quick check ...
<whitequark> asked
<sb0> rjo, hmm there are also slices of slices (though i think verilog will break for those too)
<sb0> rjo, and btw i never thought about having a signal appear in both comb and sync - even if it's different slices of it. not sure if other things break if you do that...
<sb0> (appear as target)
rohitksingh has joined #m-labs
ylamarre has joined #m-labs
ylamarre has quit [Ping timeout: 250 seconds]
rohitksingh has quit [Ping timeout: 246 seconds]
<acathla> from migen.fhdl.std import * does not work anymore...
<acathla> ok, from migen import * is ok
<cr1901_modern> acathla: There was an API change a few months back
<acathla> cr1901_modern, is there any doc about it?
<acathla> except the README?
<cr1901_modern> Yes, but it's incomplete. Lemme find t
<cr1901_modern> it*
<acathla> I'm starting again the tutorial and adaptation to the avnet board
<acathla> cr1901_modern, thank you.
<cr1901_modern> np... I have code that I need to rewr- err, update for the new imports myself :P
ylamarre has joined #m-labs
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 260 seconds]
ylamarre has quit [Ping timeout: 240 seconds]
rohitksingh has joined #m-labs
ylamarre has joined #m-labs
<GitHub113> [artiq] jordens pushed 1 new commit to master: http://git.io/vua0z
<GitHub113> artiq/master 358ad2e Robert Jordens: artiq_flash: drop redundant instruction, tweak doc
<GitHub162> [artiq] jordens pushed 1 new commit to master: http://git.io/vua0j
<GitHub162> artiq/master 73b4aff Robert Jordens: README: drop old travis badge
<rjo> sb0: if it is really that uncommon (to have signals split between comb/sync), maybe migen (at least in the simulator) should enforce that. also seems needed to optimize the execution of fragments (modified subset of the signal dependency graph).
<rjo> whitequark: can you give me push access to the buildbot or auto-trigger the builds?
<rjo> whitequark: also how is the hostname for that machine coming along?
evilspirit has quit [Ping timeout: 260 seconds]
<whitequark> sb0: ^
<rjo> whitequark: let's do this here.
<rjo> whitequark: ic.
<rjo> whitequark: anyway. once there is a DNS entry, we should not auto-upload the conda packages. that should still need forcing.
<whitequark> why so? the dev channel exists specifically for auto-uploading.
<whitequark> they shouldn't appear on the main channel though.
<rjo> fine. then the documentation should differentiate between the two.
<whitequark> sure.
<rjo> (it doesn't)
<whitequark> I think that's because artiq/migen/misoc haven't really had any useful releases yet.
<whitequark> they should, but I'm afraid it's not my call as to when make one.
<rjo> and imho recommending conda envs with date metadata in the env name is asking for trouble. just a conda install artiq the next day will make that meaningless.
<rjo> and iirc the main channel (by itself) was broken last i checked. but i forgot what was missing.
<whitequark> yes, it does not have any artiq releases in it.
<rjo> "when it's ready" ...
<whitequark> as for conda envs with date metadata in the name, iirc the docs tell to not do anything with the environment after it's created.
<whitequark> but it's probably true that this advice will be disregarded and it might not be the best way to manage environments
<whitequark> if I remember correctly, I wrote that after someone asked for a way to make sure that upgrading artiq always leaves a way to go back to a working version.
<whitequark> since conda does not include version lockfiles, like any other decent package manager in existnece (bundler, npm, cargo, ...), it does not seem to me that there is a way to do this apart from what I currently suggest in the docs
<rjo> then i would do artiq-prod and artiq-(dev|stage|test) and act accordingly.
<whitequark> ideally, conda would remember the versions of packages used to successfully run tests and put them in some file
<rjo> the trigger for a rollback in the lab is likely not a failing unittest
<whitequark> oh, yeah, I phrased that poorly. I meant "the latest versions of packages at build time"
<rjo> doesn't "freeze" do that?
<rjo> or whatever it's called?
<whitequark> what is "freeze"?
<rjo> conda list
<whitequark> ahh, conda list --export. I see.
<rjo> and for the buildbot the trigger-graph is migen->misoc->artiq->artiq-* ?
<whitequark> yes
<whitequark> the config is public here: https://github.com/m-labs/buildbot-config
<rjo> was "pip freeze" iirc
<rjo> yep. had seen it before.
<GitHub98> [artiq] jordens pushed 1 new commit to master: http://git.io/vuVYj
<GitHub98> artiq/master 0bbe886 Robert Jordens: doc/manual: umask warning and openocd installation refinement
bb-m-labs has quit [Ping timeout: 240 seconds]
bb-m-labs has joined #m-labs
awallin_ has joined #m-labs
awallin has quit [Ping timeout: 240 seconds]
<GitHub100> [artiq] jordens pushed 1 new commit to master: http://git.io/vuVhe
<GitHub100> artiq/master 87dd09a Robert Jordens: gateware: compress bitstreams
ylamarre has quit [Ping timeout: 264 seconds]