Announcement

Collapse
No announcement yet.

GCC Is Still Months Away From Transitioning To Git, Reposurgeon Being Ported To Golang

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • GCC Is Still Months Away From Transitioning To Git, Reposurgeon Being Ported To Golang

    Phoronix: GCC Is Still Months Away From Transitioning To Git, Reposurgeon Being Ported To Golang

    2018 sadly wasn't the year that the GNU Compiler Collection (GCC) transitioned to a Git workflow for developing this flagship open-source compiler... But Eric S Raymond does continue making progress on being able to convert the GCC tree from SVN to Git...

    http://www.phoronix.com/scan.php?pag...on-Py-To-Go-90

  • paulpach
    replied
    Originally posted by AndyChow View Post

    You're looking at the old Python one. The new one has 21K LOC.

    But yes, I've looked at some of the code, and see no issue.
    Here is the go version
    https://gitlab.com/esr/reposurgeon/b...reposurgeon.go

    * 21K LOC in single file. Why not split this into multiple files? having files larger than 500 LOC is already a smell, 21K is very hard to navigate.
    * very high cognitive complexity. There are functions there that go 8-10 levels of nested ifs and fors. Should be refactored into multiple functions

    That said, the code does look better. He no longer have such massive functions and he names his variables better.

    Leave a comment:


  • AndyChow
    replied
    Originally posted by paulpach View Post

    Have you seen reposurgeon code? https://gitlab.com/esr/reposurgeon/b...er/reposurgeon A cursory look shows:

    * The entire thing rests in a single 14K LOC file. Very hard to navigate.
    * 8-10 levels of nested ifs and fors.
    * Variable names such as "r" and "v" that give you no clue wtf they are.
    * Wheel reinvention such as "class Date(object):"
    You're looking at the old Python one. The new one has 21K LOC.

    But yes, I've looked at some of the code, and see no issue.

    Leave a comment:


  • Blahblah
    replied
    Yeah, why aren't they just tossing out 20+ years of commit history, what a mystery.... Perhaps it's because GCC isn't just some fly-by-night toy project, and they care about being able to properly bisect issues later on? I also reject this idea that "rarely updated portion of GCC" means "unimportant part of GCC to users".

    Leave a comment:


  • paulpach
    replied
    Originally posted by AndyChow View Post
    Good code doesn't rot. Banks still run the same Fortran code that they did in the 80's, just on larger mainframes.

    I maintain my original comments about reposurgeon. It's worth the wait.
    Have you seen reposurgeon code? https://gitlab.com/esr/reposurgeon/b...er/reposurgeon A cursory look shows:

    * The entire thing rests in a single 14K LOC file. Very hard to navigate.
    * 8-10 levels of nested ifs and fors.
    * Variable names such as "r" and "v" that give you no clue wtf they are.
    * Wheel reinvention such as "class Date(object):"

    This code is _nasty_, it is write only, hardly "worth the wait" IMO.

    Leave a comment:


  • Michael_S
    replied
    Originally posted by jntesteves View Post
    By the time he finishes, git itself will have been superseded by something with a much superior design. Possibly pijul.
    git will be around for decades due to the network effect.

    Plus, even though people in tech love to mock mom and dad and grandpa and cousin Jane for refusing to learn Linux, shell, etc... the truth is that far too many people inside the tech industry fought like hell against the move from CVS to SVN, fought like hell against the move from SVN to git, and will fight again when git is superseded. It doesn't matter whether the replacement is an improvement, they just don't wish to learn something new when they're comfortable with something they already know.

    Leave a comment:


  • L_A_G
    replied
    Originally posted by AndyChow View Post
    Currently: C, C++, Objective-C, Objective-C++, Java, Fortran, Ada, and Go. That's 8. And they have variants in the standards (ex C89, C99, C11, C18). For the architectures, I'll let you do the research.
    You do realize that C/C++ and Objective-C/C++ are really just base languages with an extended variant? They don't count as two separate languages. Also, the developers finished completely nuking GCJ (Java) from the codebase over two years ago, which kind of questions on your research on the subject.

    Good code doesn't rot. Banks still run the same Fortran code that they did in the 80's, just on larger mainframes.
    At what point did I claim anything to the contrary? Because the issue here was a major project sticking to a bad tool because they want to keep in a decade and a half of version history for the very rare occasions they need to go back more than a couple of years to track down bugs.

    Also, the reason why you still see banks running their old mainframes with Fortran code is the cost of not only moving to something more maintainable, but also the rather extreme consequences of potential business interruptions as they move to something more maintainable. However the reality is that these systems will all have to simple be retired or moved to something more modern for the simple reason that most of the people with the skills necessary to maintain them have retired years ago.

    It really doesn't matter how well you document your code when there's nobody with the specific skills necessary to pick up where you left...
    Last edited by L_A_G; 12-19-2018, 05:48 AM.

    Leave a comment:


  • jntesteves
    replied
    By the time he finishes, git itself will have been superseded by something with a much superior design. Possibly pijul.

    Leave a comment:


  • AndyChow
    replied
    Originally posted by L_A_G View Post
    I'm having a hard time believing that those 8 languages and 21 architectures are ones that are currently being supported.

    As for why the move should be done within any reasonable time frame, it's probably for the same reason they're moving away from SVN in general. SVN is very widely considered an inferior tool to Git and in many places considered as being only just better than no dedicated source control tool and an all round awful tool. Worse yet, most of it's use is considered to come from people who don't know better and projects that adopted before superior alternatives like Git and Mercurial came out.
    Currently: C, C++, Objective-C, Objective-C++, Java, Fortran, Ada, and Go. That's 8. And they have variants in the standards (ex C89, C99, C11, C18). For the architectures, I'll let you do the research.

    Good code doesn't rot. Banks still run the same Fortran code that they did in the 80's, just on larger mainframes.

    I maintain my original comments about reposurgeon. It's worth the wait.

    Leave a comment:


  • brrrrttttt
    replied
    Originally posted by milkylainen View Post

    Could not agree more.
    I see very little point in keeping the entire history in comparison to the apparent drawback.
    At what point do you stop dragging around all your history in one repo? Forever? That'd be ridiculous.
    I'd split it, just as you are suggesting. I find it the only sane option.
    To much luggage does not make anyone happy.

    To me, this looks more like a crusade than a reasonable move.
    It's totally worth it. Have you ever worked on a large old code base? The people who know why things were done a certain way are gone, the history is all you have to go off.

    Leave a comment:

Working...
X