<sb0>
mh, so why does it crash when the master does it?
<sb0>
should we have codenames for releases like ubuntu/debian does? though i'd pick a list of nuclear incidents or something like that
<acathla>
\o/
<whitequark>
(releases) I don't really care one way or another
<whitequark>
as for why it crashes, hm
fengling has joined #m-labs
<rjo>
sb0: ok. that amounts to just removing the initial 0.
fengling has quit [Ping timeout: 272 seconds]
<rjo>
you already had 0.0, thus i'll start with tags/v1.0 and a v1.x branch for the pre-new-py2llvm stuff. and we can do v2.0 once the heaviest bugs are done in the current master but before the qt5-dock rewrite and maybe before the scheduler changes
sb0 has quit [Quit: Leaving]
fengling has joined #m-labs
<rjo>
whitequark: can't we mv lit-test/test artiq/test/lit and move the other three things in lit-test to artiq/test?
<whitequark>
why?
<whitequark>
I mean, you can, I just don't see any point
<rjo>
because that stuff should be with the other testing things and it clutters up the top level directory.
<rjo>
the top level is not the best place for lit-test
<rjo>
whitequark: ok if i move the lit-test stuff? will update buildbot-config as well.
<whitequark>
rjo: sure
<whitequark>
as long as it still works afterwards...
<rjo>
whitequark: you may unleash your wrath then ;)
<whitequark>
I wonder if we should add a push hook to buildbot-config, so that it reloads itself
<whitequark>
it's not really designed to do that
<rjo>
imho lots of the rigging of the tests (like running lit) should go into the respective repository. then buildbot-config would need fewer updates. but i don't think it matters much.
<whitequark>
that won't really work because buildbot has custom support for lit
<whitequark>
it knows how to display lit failures nicely and such
<rjo>
but it would also be nice to run the lit stuff as part of the standard testsuite
<whitequark>
'standard' ?
<rjo>
the one from "setup.py test"
<whitequark>
sure, but I don't know how to hook that up
<rjo>
when browsing through "lit" i saw some lit-to-unittest.TestCase adapter.
<rjo>
whitequark: those two tests worked fine when i tested before pushing...
<rjo>
i'll fix it. time to understand this compiler thing a bit better.
<whitequark>
rjo: why did you remove /test*.py from .gitignore?
<whitequark>
it was there for a reason
<rjo>
which reason?
<whitequark>
I put various test files to run with artiq_run in the root of the repo so that I don't have to switch directories between testing and using git
<rjo>
can't we figure out a better way enable that?
<rjo>
what you have is essentially an experiment repository, right?
<whitequark>
I emphatically do not want to put them anywhere except the root of ARTIQ repository
<whitequark>
it's just annoying, I end up putting them in the ARTIQ root anyway, and then accidentally committing them.
<whitequark>
after the second time I put them in .gitignore.
<rjo>
sure. developing test experiments from within the artiq repo is good.
<rjo>
i do the same. but i keep them in examples/master/repository. same problem with them appearing as to-be-tracked.
<rjo>
why don't we designate /run as the location for the local collection of experiments, device_db.pyon etc?
<whitequark>
because I do not want to cd back and forth from /run
<whitequark>
most git commands are ergonomic only when run from the repository root
<whitequark>
python setup.py test, too
<whitequark>
lit
<whitequark>
etc
<rjo>
then we need to teach artiq_run to cwd to a repository root instead/in addition to taking --device-db and --dataset-db
mumptai has joined #m-labs
<whitequark>
I really don't understand the opposition to one line in .gitignore
mumptai has quit [Read error: Connection reset by peer]
<rjo>
it's not just one line. there is also all the related crap that needs to be ignored.
<whitequark>
ok, three.
<whitequark>
by far less lines and bugs than teaching artiq_run to do something, *and* solves my problem better
<rjo>
usually you are not somebody that shies away from going the long route to get a more generic and cleaner solution.
<whitequark>
that is true, but I know, for a fact, that I will commit garbage into the repository root again
<rjo>
just excluding test*.py is pretty narrow minded. you will want to be able to have a full tree of experiment modules in there.
<whitequark>
/test*, to also grab the test.so from artiq_compile,
<whitequark>
but I never split my test experiments into modules, because the whole point of doing this dance is being able to quickly minimize a testcase.