[libre-riscv-dev] [Bug 217] create a "ring" system which allows pad locations to be specified conveniently
bugzilla-daemon at libre-riscv.org
bugzilla-daemon at libre-riscv.org
Tue Mar 17 00:19:34 GMT 2020
http://bugs.libre-riscv.org/show_bug.cgi?id=217
--- Comment #12 from Jean-Paul.Chaput at lip6.fr ---
(In reply to Luke Kenneth Casson Leighton from comment #10)
Answering here about showPythonTrace():
I created it because:
* I wanted a more compact displaying of the trace (no line wrap because
to read more quickly as I debug).
* The script can be executed in three contexts:
1. GUI
2. Text with cgt (--script=...)
3. Direct command line.
I wanted especially the GUI to be able to recover after
an exception is raised, to do some forensic.
It is far from perfect but did help me much while debugging.
> (In reply to Jean-Paul.Chaput from comment #8)
>
> > Obviously. Because it works on my end. I will redo the whole install
> > process under Debian 10 in the next few days to see if I can reproduce
> > your problem.
>
> i forgot to say, jean-paul: i have debian/10 now as well. the "export
> LD_LIBRARY_PATH=....lib export LD_LIBRARY_PATH= ... lib64" hack shown here
> makes the install "work" with no mods needed to alliance/coriolis2
> https://libre-riscv.org/HDL_workflow/coriolis2/
My latest commit should correct that, but I will confirm when I check
it under Debian 10.
> > but ranting about "this is badly written" do not help. I flatter myself
> > to have the "scientific spirit", so if you pinpoint me badly written code
> > and *why* it is so (with reference), I will improve it in my futur code
> > and progressively rewrite the old one.
>
> none of the python code is pep8 compliant, jean-paul. the 2-spaces
> indentation is extremely hard on the eyes for anyone used to the pep8
> standard (because the smaller indentation makes "code blocks" that much
> harder to visually identify).
I understand, I'm accustomed to it and have no problem with it.
This is because sometime the nesting could be very deep, and I
did not want things to go too much to the right.
I will switch to 4 spaces.
> and the use of commas at the *beginning* of the line on a parameter list,
> rather than the usual place at the *end* of the line, is very difficult to
> get used to. i find that, automatically, i add the comma at the end
> (because that is the pep8 standard) and of course it creates a syntax error
> because there is a *second* (unexpected) comma at the start of the next line.
Funny thing, I did put the comma at the beginning because I kept
forgetting to put it at the end. I find it also much more clear as it
makes one straight column below the opening parenthesis and is
more convenient for rectangular selection. And finally it helps
keep thing vertically aligned so you immediately notice if a
comma is missing (tabulating at the end is possible but tedious
because of the variable length or the arguments).
I understand it goes against a lot of habits and automatism,
but I think I will keep it.
> a single run of autopep8 will "fix" that however any lines that have to be
> wrapped (due to length over-run) can be "mashed" somewhat in an
> inappropriate fashion, by putting function parameters onto a single line
> (forcibly).
>
> this is done in a lot of places anyway (single line per function parameter)
> so it may not be so bad.
>
> however... i haven't mentioned any of this because i felt it was more
> important to get working "stuff" within the context of what time you have
> and also knowing that you have... "memorised" the python code in this
> (unusual, non-standard) format... and moving to strict pep8 would be quite
> disruptive and time-consuming (for you to get used to).
Yes, and time is always at a premium.
> it would need careful scheduling because, really, you need to hit the entire
> codebase with a single carefully-reviewed autopep8 update and commit, and
> not do *anything* else in between.
Yes and perform complete regression tests.
> if there is a good time to schedule that, we can have several people help
> out with it.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-riscv-dev
mailing list