[libre-riscv-dev] development workflow

[Jacob Lifshay]

I have multiple monitors instead of one really high resolution one. That
can be less expensive (I got a 1080p monitor for $18 once). I'm currently
using 3 1080p monitors. I don't have space to use all of my monitors, so I
have some left unused right now. This also means I can get a 144Hz monitor
for games without having to pay a huge amount.

Unfortunately, not all editors support multiple monitors properly. :(

Jacob

On Sat, Feb 16, 2019, 12:00 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> btw aleksander, i thought perhaps the attached screenshot might give
> you some insight into how i work so fast.  i've been buying
> increasingly higher-resolution laptops over the past 20 years, this
> one is 3200x1800 and i use *all* of it, to maximum impact.
>
> the reason i'm writing this is because when i went to work for an
> unethical company with "top developers" i was shocked to find how
> prevalent it has become to dominate the entire screen with a single
> editor window - this on screens of size 24 inches and above with
> resolutions of 4000 x 1800 pixels - with the ENTIRE right hand side
> *and the middle* of that editor window entirely blank and utterly
> wasted.
>
> the reason why i have such a high resolution laptop is because i feel
> a need to get as much information on-screen simultaneously as i can
> possibly manage (i then run 24 virtual desktops, in a 6x4 grid
> pattern, so that i can switch "working contexts" without shutting
> anything down).
>
> so in this screenshot, that's ten 80x60 xterms, it's "only" 10 because
> i've put gtkwave in the bottom right corner @ around 1200x700 pixels
> in size.  yes, really, 5 out of the top 6 xterms contain *relevant*
> information, they are:
>
> * fpbase.py - the base class i cut out of the add.py file, earlier today
> * nmigen_div_experiment.py - the div class i worked on this evening.
> * test_div.py - the unit test file for the div.py file.
> * divider.v - jon dawson's original verilog.
> * a "diff -uwbB adder.v divider.v > /tmp/f" which i then opened up with vim
>
> so those five editor windows give me *simultaneous* side-by-side
> access to all the information i need [none of this "full screen let's
> open one file at a time, hooray" crap]
>
> here's the justification for why all those files are open:
>
> it's absolutely essential to have the fpbase.py open *at the same
> time* as the div.py file... because otherwise, how am i going to know
> what the function being called actually does?  i need to know the
> contents of the function.  i might actually need to *add* a function
> to the base file.  i might need to *correct* that function.  why would
> i close the frickin files to do that, when i *know* i will need to
> open it 15-30 seconds later??
>
> the unit test file is open next to the div.py file, because, duh, i
> want to add unit tests and then check the results.  i don't want to
> *close* the unit test file just because it was edited, that would be
> silly: it would be a waste of my time, requiring extra commands to be
> typed.
>
> divider.v is open because i can do a visual SIDE-BY-SIDE comparison of
> the div.py with the divider.v.
>
> the diff file from adder.v and divider.v is open because i originally
> made div.py a copy of add.py, and the diff of the *VERILOG* files
> tells me where i should be focussing attention to make changes on the
> PYTHON files.
>
> specifically: any parts of the adder.v and divider.v that are
> identical tells me that i do *NOT* need to make *ANY* changes to the
> corresponding div.py PYTHON file.
>
>
> in addition, in the bottom left corner, i have some of nmigen edited
> and open, because i am finding that i often need to refer to the
> actual source code, particularly to check what arguments some of
> nmigen's classes take.
>
> next to that window, you can see evidence that i recently installed
> yosys :)   next to _that_ you can see i had to apt-get install
> libffi-dev (one of yosys's dependencies).
>
> finally, i decided to open fmul.py just... because :)  so in that
> window, i can help you out with code review... *without* losing any of
> the context in the 5 windows above.
>
> i also use the trick of *not* exiting editors, i *background* them.
> this is the list of jobs in the window in which test_div.py is open:
>
> lkcl at fizzy:~/src/libreriscv/ieee754fpu/src/add$ jobs
> [1]   Stopped                 vi s_addMagsF32.c  (wd:
> ~/src/libreriscv/ieee754fpu/berkeley-softfloat-3/source)
> [2]+  Stopped                 vi f.v
> [3]   Stopped                 vi test_add.py
> [5]   Stopped                 vi pipeline.py
> [6]   Stopped                 vi pipeline_example.py
> [7]   Stopped                 vi README.md  (wd:
> ~/src/libreriscv/ieee754fpu)
> [8]-  Stopped                 vi test_div.py
>
> f.v is the output from running the nmigen-to-verilog command.
> test_add.py is open in case i want to go back to adding some more add
> unit tests.  i developed the pipeline class in the same window, and
> also edited the README.md and added some notes, and s_addMagsF32.c i
> left open, from conversations we had last week.  it proved useful to
> keep it open as it helped me to determine what the canonical
> representation for INF is, and other things.
>
> it's quite involved, and it's absolute hell to re-establish if ever
> the laptop crashes... and here's why:
>
> $ ps auxw | grep "vi " | wc
>     451    5418   38670
>
> yes, really, on this laptop, i have *451* vim sessions open, the
> majority of them backgrounded.  many of those are still open from work
> done on spike-sv, from several months ago: uptime is currently 156
> days (wheww).
>
> yes i've had people look over my shoulder and their eyes pop out :)
> it's not for everyone, this approach, and yes it's taken 20 years to
> refine.  just some food for thought :)
>
> l.
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>