[libre-riscv-dev] [Bug 217] create a "ring" system which allows pad locations to be specified conveniently

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=217

--- Comment #13 from Jean-Paul.Chaput at lip6.fr ---
(In reply to Jean-Paul.Chaput from comment #12)
> (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.

(In reply to Jock Tanner from comment #11)
> (In reply to Luke Kenneth Casson Leighton from comment #9)
> > ok - don't leave it several days.  we don't have time for "i can't get it to
> > work therefore i'm going to keep quiet and spend time because i'm
> > embarrassed to admit i can't get it to work".
> 
> Roger that. But I can't say I'm much embarrassed (though maybe I should be),
> because I've seen several such big projects, which seemed cryptic and
> incomprehensible at first, but opened up with time and observation. Except
> that this time I seemed to underestimate the domain.
>  
> > > First of all, I'm not sure what the result of the 'doAlu16.py' script should
> > > be, and how running of the script relates to running 'make' with different
> > > targets. 
> > 
> > you need to run "make lvx" then "make view".  nothing else: absolutely
> > nothing else.
> > 
> > you *might* have to run "make clean" if something has not worked because
> > occasionally the intermediary files are modified such that on subsequent
> > runs they affect ongoing output.
> 
> Wait a minute, Luke. I'm doing 'make lvx' and 'make view', and it gives me
> pretty picture and no errors. But I also run the script itself
> ('doAlu16.py'), because I remember you said somewhere that we must be able
> to get the results without GUI. That's where I get the 'No track near axis'
> error. Should I run it or not?

  You cannot (yet) run the script directly. However to run in text mode:
  you can use:
    cgt --script=doAlu16
  (assuming the environment as been correctly set)

  I will make the necessary changes so the script can be run by itself
  (need to request configuation loading).

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