Announcement

Collapse
No announcement yet.

A Proposal To Allow Python Scripting Within The GCC Compiler, Replacing AWK

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

  • A Proposal To Allow Python Scripting Within The GCC Compiler, Replacing AWK

    Phoronix: A Proposal To Allow Python Scripting Within The GCC Compiler, Replacing AWK

    A SUSE developer is seeking feedback and interest on the possibility of allowing a scripting language -- most likely Python -- to be used within the GCC compiler code-base. This would primarily be used for replacing existing AWK scripts...

    http://www.phoronix.com/scan.php?pag...C-Awk-Proposal

  • dimko
    replied
    Originally posted by Weasel View Post
    The advantage of awk is that it's installed on virtually every Linux distro, has no shitty version incompatibility (python2 vs python3), and is lightweight. I'm not talking about the script itself, but the executable and runtime which will have to get loaded now (yeah some of us don't use python at all except when needed, in cases like this).

    So I guess compiling GCC (and MinGW) will become more tedious with this dependency on a bloated scripting language, if you're used to do it from a container like me.

    Hopefully it won't come to pass, but I'm no GCC dev so I doubt my word would have merit even if I did post in that thread. So I can only hope.
    I misunderstood article. I am in the wrong here. Ignore last message all together. At work, and have limited time to read, even less to comprehend. Sorry.

    Leave a comment:


  • dimko
    replied
    Originally posted by Weasel View Post
    The advantage of awk is that it's installed on virtually every Linux distro, has no shitty version incompatibility (python2 vs python3), and is lightweight. I'm not talking about the script itself, but the executable and runtime which will have to get loaded now (yeah some of us don't use python at all except when needed, in cases like this).

    So I guess compiling GCC (and MinGW) will become more tedious with this dependency on a bloated scripting language, if you're used to do it from a container like me.

    Hopefully it won't come to pass, but I'm no GCC dev so I doubt my word would have merit even if I did post in that thread. So I can only hope.
    Python is installed on every Distro I know.(may be not android, if you count it as such)
    Compatibility issues, does happen for good reason(language grows, become more mature and functional). There is simple work around for it, to have both python 2 and 3 which implemented even in Gentoo.
    Python I understand is relatively light weight on size and resources if done right. It's choice of noobs in programming, because it allows to have shit done, as such 0 optimisation generally, but it's not language problem. It's overall skills problem. Don't blame hammer if you hit your fingers with it all the time.(not you, but generally)

    Not sure what container you talk about.
    I have been compiling GCC on my Gentoo for years, it's very rarely ever fails to compile itself. So you are complaining about things that have not even happened yet.

    So far non of your complaints had any merit.
    For someone as seasoned as you are, it should be no brainer. At time of compilation of GCC disable whatever languages you don't need with appropriate variables. Don't like python - disable it at compile time, problem solved? How does this affect you then?

    I am for one - happy to see python in GCC. I am not a programmer, just trying thing or two, by making a few simple programs for personal consumption(copy paste app between android and my Linux box that doesn't depend on 3rd party services + little remainder that tells em to drink water).

    Leave a comment:


  • Weasel
    replied
    Originally posted by Redfoxmoon View Post
    Adding python as a hard dependency to GCC would make it an even worse mess to compile, *especially* on mingw-w64. Christ WTF?
    Exactly my point. GCC is the only compiler I use even on Windows and yes I patch it also to enable plugins so I have to compile it myself.

    Leave a comment:


  • Filiprino
    replied
    I don't have much experience with AWK and Python. But I know they are two languages with two different purposes.
    Python is more of an object oriented programming language like Java, GNU R or JavaScript.
    On the other hand AWK is a language oriented to text processing. It's simple, it has a reduced set of commands which are handy for string processing.
    http://www.grymoire.com/Unix/Awk.html#uh-0
    Why is AWK so important? It is an excellent filter and report writer. Many UNIX utilities generates rows and columns of information. AWK is an excellent tool for processing these rows and columns, and is easier to use AWK than most conventional programming languages. It can be considered to be a pseudo-C interpretor, as it understands the same arithmatic operators as C. AWK also has string manipulation functions, so it can search for particular strings and modify the output. AWK also has associative arrays, which are incredible useful, and is a feature most computing languages lack. Associative arrays can make a complex problem a trivial exercise.
    AWK in GCC is used to parse files with constants, configuration flags and ISA definitions. Using Python for that I think it would add a dependency which doesn't pay off.

    Other scripts use AWK but probably shouldn't be written in AWK. For example, this script pointed out in the mail list: https://gcc.gnu.org/git/?p=gcc.git;a...en.awk;hb=HEAD

    There's a case for using an OO language there. But instead of Python, why don't you use Smalltalk? https://news.ycombinator.com/item?id=9023138
    Smalltalk has a GNU implementation, you are still using GNU packages, something which I think is one of the purposes of GNU, having a GNU system (except X11 :P). Smalltalk influenced Python and many other languages. Was the first OO language to provide reflection.
    And probably one great quality of Smalltalk is that it has been standardised. It is an ANSI standard.

    But if one goes back to the basics, why don't use AWK and build data structures providing the needed functionality.
    AWK even allows you to use TCP/IP: https://www.gnu.org/software/gawk/ma.../gawkinet.html

    The copy&pasted code of the AWK script mentioned above could be replaced with a function and a single parameter. I think that the script was made "quick&dirty" and who knows if they used Yasnippet from Emacs or whatever :P
    Maybe instead of replacing one language by another and adding an additional dependency the current state of the scripts can be improved (refactored) in order for them to be more maintainable.

    Other questions arise, like Python runtime use of resources compared to AWK. The other day there was a post saying developers did not have enough memory in their server.
    Last edited by Filiprino; 07-18-2018, 12:03 AM.

    Leave a comment:


  • hgoldfish
    replied
    GCC is a so heavy project, that we do not need to consider how heavy python is. And python 2.x is gone.

    Leave a comment:


  • kenjitamura
    replied
    Originally posted by Weasel View Post

    Pure and simple, extra burden compared to a good language like AWK. You don't have to rewrite awk code as it's (mostly) backwards compatible (unless you use special GNU extensions or w/e, maybe).

    With this precedent, who said there won't be a python 4? Imagine if they write so many build scripts on it and then they'll have to rewrite them, again and again. What a nightmare.
    There WILL be a python 4 however a core developer had this to say about it:

    My current expectation is that Python 4.0 will merely be "the release that comes after Python 3.9". That's it. No profound changes to the language, no major backwards compatibility breaks - going from Python 3.9 to 4.0 should be as uneventful as going from Python 3.3 to 3.4 (or from 2.6 to 2.7). I even expect the stable Application Binary Interface (as first defined in PEP 384) to be preserved across the boundary.

    At the current rate of language feature releases (roughly every 18 months), that means we would likely see Python 4.0 some time in 2023, rather than seeing Python 3.10.

    Update: After this post was originally written back in 2014, subsequent discussions on the core python-dev mailing list led to the conclusion that the release after 3.9 will probably just be 3.10. However, a 4.0 will presumably still happen some day, and the premise of this article is expected to hold for that release: it will be held to the same backwards compatibility obligations as a Python 3.X to 3.X+1 update.
    I don't think they dare break backward compatibility again because it was so much of a nightmare and generated bad press they realize will never go away.

    Leave a comment:


  • cochise
    replied
    IMHO, if some people likes AWK so much, they should step up an maintain the AWK code. If who is doing he job wants to change to another language it's fine, as they are doing the job. Is not that "the person should learn AWK", but "the person who do the job chooses the tools".
    We need some compromises, as it is a collective work and the toll affect the final bundle, but this is what the developer is doing starting a discussion in the mailing list.

    Leave a comment:


  • Redfoxmoon
    replied
    Adding python as a hard dependency to GCC would make it an even worse mess to compile, *especially* on mingw-w64. Christ WTF?

    Leave a comment:


  • kpedersen
    replied
    I have recently had the experience of building both GCC and Clang on Windows to build Emscripten/fastcomp.

    I have to say that Clang was much easier due to its CMake build system. GCC is sticking with autotools (which isn't an issue on UNIX-like platforms) but is already extremely fiddly.

    Lua would be my preferred choice. It is < 40 .c files and requires no other dependencies than C99.
    And it wouldn't need maintaining. Just call it GCC-lua and leave it frozen at version 5.3. This constant keeping up with upstream versions is killing FOSS. Just look at Gtk+.
    Last edited by kpedersen; 07-17-2018, 06:01 PM.

    Leave a comment:

Working...
X