[libre-riscv-dev] [Bug 316] bperm TODO

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=316

--- Comment #60 from Cole Poirier <colepoirier at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #58)
> (In reply to Jacob Lifshay from comment #55)
> > (In reply to Cole Poirier from comment #54)
> > > Ah yes, appreciated, I will grep first in the future. For clarification, the
> > > way to run the tests is by cd'ing to the soc/decoder directory then running
> > > 'python3 test/{test_file.py}' for each of the files in the tests directory?
> 
> because i run ctags in one directory (usually the top level or close to it)
> and stay there.
> 
> i generally run e.g. python3 fu/alu/test/test_pipe_caller.py or something.
> constantly doing "cd" i find very annoying.
> 
> to find previously-run commands is a matter of running "history" followed by
> !inserthistorynumber
> 
> this saves typing the command out repeatedly - also very annoying.
> 
> lots of annoyingness... :)

Ah that sounds radically better than my 'dumb' bog-standard online/corporate
unix training method of cd .. cd cd cd cd ..... ahhhh!!! I'll have to do a
quick read of what ctags is and how to use it as you've specified tomorrow. And
go back and reference your email to me from march that outlined how I could set
up my computer as you have yours set up.

> > > Or do I cd to the top level soc directory, and run 'sudo python3 setup.py
> > > test'?
> > 
> > Definitely don't use `sudo`.
> 
> yep.  it will result in test output that, on return as the ordinary user,
> you will not be able to overwrite.  to "fix" that, do this:
> 
> soc/src$ sudo bash
> soc/src# chown -R colepoirier .
> soc/src# exit
> soc/src$
> 
> that will ensure that all files are owned by you (not root) in the entire soc
> locally checked out repository.
> 
> a "dumb" way to achieve the same effect is to completely destroy the entire
> checkout.  this is wasteful of both time and bandwidth.

Perfect. Worked.

> > I cd to the top level and run either `python3 setup.py test` or `nosetests`.
> 
> this runs every single test, which consumes a lot of time however is a good
> idea.
> 
> to get a "faster development cycle" i tend to run only the test that is
> needed.
> delays in that cycle - by running tests that have nothing to do with the
> task at
> hand - i also find annoying.
> 
> however *after* that fast-iterative cycle (explicitly running only the
> relevant
> test), it is kinda important to run more (nosetests3, python3 setup.py test)
> just
> to make absolutely sure you didn't break anything unrelated.  don't tell
> no-one
> i tend not to do that very often... :)

Hmm will try to do as you preach not as you practice then :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.