Extracting the abstract syntax tree from GCC
lwn.net
lwn.net
https://github.com/bedatadriven/renjin/blob/master/tools/gcc...
This little plugin simply dumps GCC's gimple to JSON, yielding for example:
https://github.com/bedatadriven/renjin/blob/master/tools/gcc...
LLVM's design looks very attractive, but for scientific computing Fortran is really important, and AFAICT, LLVM doesn't have an intermediate representation comparable to Gimple: LLIR seems to be at the level of the registers rather than the nice abstract Gimple, but perhaps I just haven't looked deep enough.
This is the actual point of debate: RMS wants to keep these APIs moving targets in order to discourage Intel or whoever from writing a compiler that just shells out to gcc to handle all of the parsing.
Unfortunately, fully GPL'd, open-sourced projects like our own (and who knows how many others that were never even started because of these artificial hurdles) are the ones most affected.
LLVM variables are sometimes called registers but they are machine independent. The bit width is arbitrary (e.g., you can create a 129-bit integer). The use of the term register is a misleading analogy; often LLVM-IR is compared to assembly language so the use of the term register was also used.
I do not know GIMPLE and couldn't find a good description of the IR instructions. But, it seems that LLVM IR is somewhat similar to low GIMPLE.
Gimple variables have types comparable with C types - you get pointers, arrays.
For example:
int sum10(int values[10]) {
int i;
int sum = 0;
for(i=0;i<10;++i) { sum += values[i]; }
values[0] = 342;
return sum;
}
sum10 (int * values)
{
long unsigned int D.1598;
long unsigned int D.1599;
int * D.1600;
int D.1601;
int D.1602;
int i;
int sum;
sum = 0;
i = 0;
goto <D.1595>;
<D.1594>:
D.1598 = (long unsigned int) i;
D.1599 = D.1598 * 4;
D.1600 = values + D.1599;
D.1601 = *D.1600;
sum = D.1601 + sum;
i = i + 1;
<D.1595>:
if (i <= 9) goto <D.1594>; else goto <D.1596>;
<D.1596>:
*values = 342;
D.1602 = sum;
return D.1602;
}If Emacs were enhanced to support a standardized file format which contains the relevant information, then it could accept this format from any tool. The GCC plugin could output this format, as could Clang/LLVM. Because the format is universal, it likely would be mainlined.
Then, it's up to the user. If the user wants to integrate the two, the user can apply the appropriate patch to GCC to incorporate this independent plugin. Likely, many downstream package maintainers would add this as a standard option if demand were high enough. This is the very freedom that RMS has advocated for. It can be done without poking the bear.
The only outstanding threat to fork that I know of is coming from a GNU Emacs maintainer, to I believe fork GNU Emacs. Again. Oh boy, again to support C++ development! How could I have forgotten that?!?!?!!!
But you're right, arguing with RMS on this is likely to be completely unproductive. But it is morally necessary before potentially disastrous forking of GNU Emacs and maybe GCC.
RMS wishes to restrict possible proprietary use of the GCC front-end. That's his prerogative. However, he can't prevent the existence of such a tool. He can only prevent it from being mainlined.
EDIT: Also, it may be easier to make a case for mainlining if the functionality is demonstrable. As I've learned throughout my career, it's often better to ask forgiveness than to ask permission. RMS excels in the idealistic and theoretical. If he has to consider the practical -- such as whether to mainline already existing functionality -- then he may find ways of suggesting changes to the plugin than ways of saying "no."
Except everyone who knows RMS well enough knows he'd be extremely obstructionist and indeed GNU would refuse to maintain/mainline such an GNU Emacs enhancement. That's one of the reasons I believe the GNU Emacs maintainer threatened to fork it, he obviously knows RMS well enough.
(So do I in the 1979 to late '80s period, and he's not changed in this sort of thing. And he was reliably reported to be like this before I showed up on the scene, by among others one of the two initial ITS TECO EMACS beta-testers. And others I knew less well.)
One could argue that Stallman is not acting within the spirit of this right by being deliberately obstructive and obfuscatory.
If he is so opposed to proprietary software using GCC output why not use a license that prohibits that? Its not even too late for new versions since the FSF owns the copyright to all GCC code.
On a practical level, if people wanted to execute that particular "misuse" (IE use it in non-GPL software, which I would just call a "use"), they would obviously use clang. Clang is basically better at this point anyway.
Basically what I'm trying to say is that RMS is a nutcase.
When your freedom reduces the global "freedom", the sum of everyone's freedoms after your action, it might make sense to prevent it.
In spite of, and because: freedom.
Not saying the way RMS is doing it is good, that's a different matter. But restricting freedom, for freedom? Yes, very possible.
RMS may be nuts, that doesn't stop him from being right. Which, by the way, he turns out to have been on many more counts than some of us initially thought.
John Locke said on the subject of liberty: "Freedom is constrained by laws in both the state of nature and political society. Freedom of nature is to be under no other restraint but the law of nature. Freedom of people under government is to be under no restraint apart from standing rules to live by that are common to everyone in the society and made by the lawmaking power established in it. Persons have a right or liberty to (1) follow their own will in all things that the law has not prohibited and (2) not be subject to the inconstant, uncertain, unknown, and arbitrary wills of others."
This is extremely misleading: Copyleft is about making sure everyone has the same rights.
> Basically what I'm trying to say is that RMS is a nutcase.
And here you prove you have no serious argument, by devolving to insults.
Many of us who know him well would not object to the essential meaning of that word, even if we don't ourselves use it.
In theory... except in this case, the point is ensuring that people who don't share his political leanings can't use the product in a way he doesn't like (to generate an AST). It's not even about modifying gcc in this context, he doesn't want people to "misuse" it. It's entirely about telling people what they can and can't do with their software. Where is the freedom in that?
> And here you prove you have no serious argument, by devolving to insults.
I'm calling him a nutcase because he's being paranoid by crippling his own software to prevent a thing that people can already easily do with a competitor (clang). It's not like people are like "oh no gcc can't emit an AST I guess I'll give up and forget the entire venture" they just go "well I guess I'll go use clang instead"
I should have the "freedom" to block off my street at night, because the traffic keeps me awake. But dang society (and laws) don't let me do that! Clearly, my "freedom" is being impinged by others! Right?
/s
Don't move into such a place.
If it becomes such a place, leave (it'll be more valuable, so you should be able to make a profit if an owner, or pay less in rent).
If it's people illicitly making too much noise, sic the authorities on them (although now in the US I'd hesitate to do that unless the situation is life and death, and often even not then).
If I take a piece of software and keep my changes to myself, it would be fair to say that I'm antisocial and selfish, but overall I have not negatively impacted anything -- I've simply refused to reciprocate the benefit I've received. That makes me a jerk, but objectively nothing bad has happened. Whereas if you were to block off your street, you're actively depriving people of a service, etc.
In this case RMS is actively refusing a feature that would be a boon for many people, because he want's to make sure it doesn't help people he dislikes. IMO, that's on the same level of companies obfuscating file formats so people can't build off their products. That's not defending freedom, it's just being a prick.
The GPL explicitly allows you to be a jerk in this way.
It just doesn't allow you to then jerk other people around by sending the software you've modified to other people without the same rights that you exercised in order to be a jerk in the first place. Because then something objectively bad would have happened.
> In this case RMS is actively refusing a feature that would be a boone (sic) for many people, because he want's to make sure it doesn't help people he dislikes.
Phrasing this emotionally ("dislikes") is weak. These are not people rms (or anyone else) "dislikes", they are people who want to remove your freedom to use software.
> That's not defending freedom, it's just being a prick.
Well no. It's preventing non-free software from being written. Which is defending freedom.
You're simply arguing for different collateral damage. rms is happy to have less software written if it prevents the production of non-free software. He's preventing harm. You're happy to have more software written but don't care if that includes software that doesn't let people use it freely. You're allowing harm.
Neither of you is being a prick, at least not in your politics.
How is disallowing a feature for political reasons any different than this? This is a useful feature that he's refusing, that people want, because it might help out the bad guys. He's basically willing to screw over his customers (the users), to make a point.
> You're happy to have more software written but don't care if that includes software that doesn't let people use it freely. You're allowing harm.
Lol. I make software. I want people to use it, and I want to make money for my efforts. I have zero interests in their politics. To me, that's freedom. If that's "allowing harm" I will happily do it.
Let me give some credentials here. I make a plugin for unity 3d. I sell it. It's not my day job, but I do make some money from it. When I sell it, I also include the source code, because I realize that developers are sometimes going to need to customize this product for their own needs. Even if they distribute what they do (which I hope they do! That's the point right?), I don't ask that they contribute their changes back, because that was their blood sweat and tears and they already paid their due (IE, the price of the product). Good for them. I'd be incredibly appreciative if they contributed their changes back, but they already paid their due, so I ask nothing of them. To me, although this particular thing is not the BSD license, I feel like it's in the spirit of that. "Here's some code, contribute back if you can". The GPL license on the other hand seems pretty un-inclusive. It's basically like, "here's some software... You can use it I guess but we mostly meant this for people that follow our cause..." The entire thing seems incredibly political, which makes me uninterested since I don't subscribe to their cause for various reasons.
He is opposed to proprietary software using his code which he gave to the world on the condition that it, and derivative work, remains open for its users to view and modify.
The work belongs to the FSF, so it's ultimately their decision what happens with it, in pursuit of the goal of software which you can legally inspect and modify for yourself.
The compiler's AST isn't usually an output. This does seem like a dated issue, 20 years ago, there weren't as many C and C++ parsers, now there are a number of free ones. I feel pretty confident that 20 years ago, there would have been some proprietary compilers derived from GCC if they could emit the AST in an unrestricted sort of way. On more than a couple embedded projects I worked on some vendor distributed an absolutely PoS compiler because they had to to sell their parts and couldn't or wouldn't play ball with GCC. Honestly, now I'd think GCC's real value is in the optimizer, not so much the parser.
Seems like a fairly simple addendum to the license could GPL the GCC intermediate representation and their usage outside of GCC. That does create a logical loophole in that you don't want code compiled with GCC to be considered intermediate output and then GPLed by definition.
Your confidence is 100% justified, because Open64 exists. It always has been possible to emit AST from GCC by simply modifying GCC yourself to do so. GCC is a free software after all. Open64 did that, and AMD used to sell a compiler using GCC frontend together with highly optimizing proprietary backend. More on http://tirania.org/blog/archive/2004/Apr-18.html
What has not been possible is not to emit AST from GCC, but to emit AST from GCC and continue to benefit from GCC changes after that.
That's a bit saddening.
Free, open-source software has helped considerably in the last twenty years. That's why I think licenses like MIT or BSD help keep software free and truly open: Use it for what you see fit without any obligation on your part.
That's free.
"misuse of GCC front ends"
I'm someone who has experience with what can be done in terms of extending/modifying software even without any source code, so my perspective on things like this are more like... "you have the source and an explicit license to modify it, and no intention of keeping your changes proprietary, so just do it!"
Either that or move to clang/LLVM, which I think would be better in the long term.
I could write a program that compiles your gcc-produced AST for a new architecture, and not GPL it because the AST itself probably isn't GPL protected. That's the fear.
And that seems to have been the whole intention behind this. Make sure no non-GPL backend can be used because god forbid it's better than ours. The shame!
It is done in sports. Most sports forbid you from taking drugs that enhance your performance, or are seggregated by sex in order to account for the "natural" (?) unequal distribution of muscular mass across sexes, because we think these would be unfair advantages.
The idea here is that the big proprietary software companies are not playing on a level field, since they are not disclosing their source code. The GPL, as I understand rms's intentions, is designed to inhibit that advantage and force everyone to play fairly: if you take code, you must give back code.
I don't understand much about the particulars of this case, and public opinion seems to be heavily slanted against rms. Nobody seems to agree with him here, but he's been considered a fool in the past when he was more of a Cassandra. His positions usually come from past experiences he's had.
Someone else mentioned elsewhere in this thread that historically the fear was of Intel using gcc as a frontend for icc. Seeing how Intel still contributes code to gcc and how they still maintain icc and how they still love publishing non-free software, perhaps this is still a valid fear. Or perhaps everyone is just using LLVM already for this purpose and it's not likely they would use gcc instead. I don't know.
I don't want to cast an opinion on this case beyond what I've already said. Maybe rms is wrong or maybe he's right.
That's not the intention. It's a forward mechanism, not a backwards one. If you distribute code to person/company/entity X then you must also distribute the source code, or provide a way for X to get the source code.
If you make changes but never distribute the code then you don't need to distribute your modified code to anyone. If you only provide a service then you don't need distribute the code to anyone. Even if you modify gcc, sell me a copy, and distribute the changed source code to me, that doesn't mean you or I need to give the changes back to the gcc project.
The "fear", as I understand it, is that the Linux kernel and gcc are the two biggest GPL-based projects. If gcc is diminished, then fewer people will be aware of, much less agree with or advance, the ideals of software freedom. The technical advantages of gcc are used as marketing for software freedom.
Hiding GNU projects behind commercial and proprietary solutions front-ends reduces the marketing. Hence also the issue about "GNU/Linux" as "Linux" diminishes the marketing of the GNU project.
Throw a proprietory module on the end which relies on his work but gets around the GPL, and you've lost that right. That's not acceptable to him.
Quoting from the Free Software Definition page at https://www.gnu.org/philosophy/free-sw.html :
> You should also have the freedom to make modifications and use them privately in your own work or play, without even mentioning that they exist. If you do publish your changes, you should not be required to notify anyone in particular, or in any particular way.
There is nothing that obligates giving back code. Rather, that obligation is against the four freedoms of the free software. Hence, "if you take code, you must give back code" is not, as jordigh understood, one of rms's intentions.
> If gcc is diminished, then fewer people will be aware of, much less agree with or advance, the ideals of software freedom. The technical advantages of gcc are used as marketing for software freedom.
But he's also now considered a fool in the past when he indeed turned out to be a fool. GNU has 3-4 marque projects, GCC etc., Gnu Emacs, userland, and HURD, and he has total control over at least the first two (and he personally has used the third only for ill, "GNU/Linux").
His stewardship of them has been all but catastrophic, he could have earned a lawsuit that he would have lost from how he started GNU Emacs (fortunately the rightsholders were menches). Both have had painful forks and are facing that again.
From https://software.intel.com/en-us/blogs/2009/05/27/why-we-cho...
--- LLVM is distributed under the Illinois Open Source License, which is nearly identical to the BSD license and is very open for use both by open-source and proprietary projects. Some other projects, such as Open64, are licensed under more restrictive licenses like the GPL, which were not compatible with our own licensing model. ---
So, what RMS feared is exactly what's happening with Clang, and he's right in terms of pushing the GPL to prevent this sort of thing.
Now, whether or not this is actually bad is another question. Personally, I think this sort of bleeding between proprietary and open source ultimately improves the ecosystem as a whole.
You are free to compete, but have run the whole marathon.
The debate hinges on a very subtle point: GCC does not commit to keeping the plugin API nor the AST structure stable between releases, making it difficult to maintain any software that relies on a specific shape of the plugin API or the ASTs.
I realise that such a system would probably scare the hell out of RMS, but he should know well enough that any obfuscatory changes are easily undone. In some ways, it's like the war between software protections and crackers - once the crackers developed tools to analyse and automatically bypass any local serial-number type protections, they solved the problem generally and DRM was forced to go online. I'd be interested to see what RMS would try if faced with such a solution...
One problem here is that RMS is not a C++ programmer (not an entirely unwise decision!), the languages he programs in, to the extent he does anymore, don't require this sort of thing, and apparently doesn't appreciate how this is a deal breaker for modern C++ programming. Or doesn't care, and how that's decreasing GCC mindshare as well.
Because of this policy with GCC, 99.999% plus of the the academic mind share is with LLVM, and the only thing keeping it from taking over is it's relative paucity of backends.
If it were so easy it would have happened by now. One can only conclude gcc and its stewardship have no real desire to allow for such a thing to occur at all.
Which means llvm will likely be the future for being able to handle large complex code bases and interactivity with editors like emacs or vim, or whatever else. Why we have to reparse c/c++ in every editor alive when the compiler already does such things and would just need to dump out the information needed to understand it is beyond me.
I only see 2 solutions to this situation. First is gcc gets left behind as a backwater compiler that won't interact with the real world due to religious reasons. Second is it gets forked and like ecgs before it, the fork becomes the canonical version (likely ignored by the gnu/fsf folks as being a heathen fork or whatever).
Oh, if only they'd ignore the heathen fork of one of their marque projects. Not going to happen with EMACS, 99+% of its greatness is due to RMS by universal acclimation as of the very early '80s.
It's a pity because it is quite an enjoyable IDE to use every single day for my C++ work (I'm on 6.1.1, doesn't crash unlike the 6.0 series), but missing a feature like that stinks.
Not that I've ever had need to use it so far, but still, it is a pity.
Am I the only one who finds it ironic that purported "free as in freedom" software is/was being held back because of fears of what someone can do with that freedom?
Though once useful, the GPL and especially the AGPL are harmful, restrictive licenses that have outlived their usefulness and in no way represent "freedom".
Although that's not a binary thing, I have the natural and legal right to kill in legitimate self-defense. In rare situations, stealing is allowed to prevent a greater loss.
In this case, most of us, even those of us who don't like the GPL in practice like me, are not primarily arguing the GPL, but RMS's stewardship of GCC and GNU Emacs about something that's allowed in I believe every FOSS license.
Just not in these two projects under the aegis of the FSF. Unless and until they fork, or RMS is somehow convinced, whic history says is not the way to bet.
However, people are making the argument that this proves that GPL<BSD, and so it needs to be rebutted until they stop making it. Speaking of which, it's particularly strange for people to take the position that RMS's behaviour here is anti-freedom and thus obnoxious, and therefore GPL sucks. It shouldn't be necessary to point out that he could pull the same stunt just as easily if GCC were under a BSD license. In fact he could achieve the same effect even more easily, because he wouldn't have to rely solely on constantly changing the AST interface, or the threat of doing that: he could put future official versions of GCC under a new license which tried to put up legal barriers to AST access, or threaten to do so. More broadly, it's hard to imagine any consistent position under which RMS attempting to exert some de facto proprietary control over GCC is tyrannical, but licenses which would have given him the authority to make future official GCC versions de jure completely or semi-proprietary are upholding freedom! Of course, you can argue that RMS' behaviour here proves that he is being hypocritical when he denounces others for exercising proprietary control of software, through proprietary works derived from FOSS software or by other means. But just as obviously, catching someone in hypocrisy doesn't necessarily mean that they were wrong.
Moreover, it needs to be addressed not only because people are drawing incorrect conclusions about GPL vs. BSD, but because it shows that they don't understand what's going on here. The problem here isn't licensing terms, it's Too Big To Fork https://news.ycombinator.com/item?id=6810259 . "Freedom of the press is guaranteed only to those who own one." Speaking of which, it's strange. Here RMS is using his position to exert some de facto proprietary control over GCC, a big, hard-to-replace hairball of code with lots of clients locked in to its interface, and widespread anger is (quite appopriately) the result. Yet the Web browser vendors have honed this kind of behaviour into a routine, regularly exerting their de facto power over the Web, and sometimes in nakedly self-serving and destructive ways, and people have been conditioned to hail and venerate this as the Open Web.
But I hope I've made it very clear that I indeed view this solely as a stewardship issue that could be true under any FOSS licence, and I repeat that the GPL is a tolerable licence for something like the GCC (well, it might doom serious Ada to the proprietary world, but, eh).
Nope. My taking BSD code and producing a proprietary, closed source product it in no way impacts someone else's freedom to do the same, nor does it remove some freedom they previously had.
The GPL nerd imagination in play here is as the ridiculous as the imagination of crypto nerds[1].
[1]: http://xkcd.com/538/
If so this seems like a very strange position to take to me.
To extend the analogy: if picking cotton was only economically viable if done with slave labour, then most people would agree we are better off not picking cotton at all. Similarly the FSF position is that if solving a problem using computers is only possible in a way that uses or enables non-free software, then we are better off not using computers to solve that problem at all.
This GCC stuff is very much a shades of grey situation in practice.
It never did function bodies, but then we never needed it to.
This was over 10 years ago now; frustrating that GCC has ever made clang necessary :(
Since then LLVM came along and made the whole point moot, since it has a modular front end which can parse all the gcc extensions.
See here:
That said, personally, I think the GPL has both helped and harmed the evolution of computing.
There's something fundamentally weird about the whole dev ecosystem wrt developer productivity. Next time you're sitting in front of an 8 CPU box with an SSD trying to solve a CPAN or library dependency, watching one C file compile once every three seconds, perhaps think about why things always wind up like this.
I super respect Stallman's position but at some point you have to look around (and beyond!) and say "why are we working with crippled tools?" With few exceptions all the core projects are uncontributable at this point. And RMS isn't even the worst; he's just the most consistent and predictable.
Compiling crazy c++ codebases are painful for everyone, and in fact were a primary inspiration for the handful of people at Google who created Go, with a primary goal of fast compiles, at some reasonable expense to disk and run-time efficiency.
If he did open it up for a proprietary component to make its way into GCC (while avoiding the licensing terms), and it becomes mainstream, you have lost that right to view and modify the software that runs on your box, and that is something he does not view as acceptable.
Ultimately, it's his decision; it's based on his work, and the contributors agreed to his terms. That he makes it freely available with the condition that it remains freely available is a bonus, not a right.
And yet, the referenced discussion breaks down into RMS on one side and people who want to make gcc work better for themselves on the other.
At the risk of someone building a closed backend off an artifact of the GCC frontend; at the risk of someone profiting off RMS' work without following his conditions for making that work free.
It's important to remember that he isn't against Emacs getting the information it needs to do its work. In fact, this mirrors a common discussion in computer security, and system administration in general: you give applications and users only the permission they need, to protect against bad actors. If Emacs doesn't need the full AST, why would you give it to them?
Then why are "we" all still using his software (which was given a license to match his philosophy) and complaining when he maintains his "clear, consistant position on the matter" and refuses to compromise his beliefs.
To use a poor analogy, it's like going to church and complaining when they talk about God.
There are lots of other options out there for editors, compilers, and OSes. If "we" really do understand his position, and disagree with it to the point that "we" want to make changes incompatible with his position, "our" time and energy would be better served working with an OS and software which better matches "our" ideology (like FreeBSD; awesome software under the BSD license).
> The issue is that, by his own admission, he doesn't understand the other side.
That seems like his problem, not ours. And he's not making it our problem; we're making it our problem by trying to use FSF software in a way other than what they intended.
EDIT: Scare quotes around We and Our are used because I, personally, agree with RMS. I didn't used to, but over the years I have grown to appreciate the GPL, the FSF, and the openness these extreme ideologies have brought about for us.
RMS popularity among newer programmers is always low (for the exact reasons outlined here, his software isn't "free" enough), and yet I find that after years of experience, we begin to appreciate that without his staunch support, we would be developing software in a very different world.
A world which we have a taste of now, in the Apple, Microsoft, Google and Facebook walled gardens: I don't know how Swift works. I can't fix bugs in Swift's implementation, and I can't build upon Swift for the betterment of all, should I so desire.
I don't support the FSF, I do support access to source code, and the freedom to extend the source code. Sometimes the FSF supports our shared goal, sometimes the FSF sees it other ways than I do, but that doesn't mean that I'm going to stop using emacs because I disagree with poor management of GCC.
The world is big enough for a plurality of ideologies.
Responding to your edit: >RMS popularity among newer programmers is always low (for the exact reasons outlined here, his software isn't "free" enough), and yet I find that after years of experience, we begin to appreciate that without his staunch support, we would be developing software in a very different world.
I find this to be an exceptionally unconvincing argument, because my experience has always been exactly the reverse. Newer programmers get excited about having access to source code, and they see RMS as the one saying the most about it, and just assume that RMS is responsible. After a while, they learn about the history of BSD and open source and realize that shared access to source code is a very natural way for software projects to develop. Without RMS being a frontman, we'd still the BSDs, we'd probably still have Linux. We'd have needed a compiler like GCC, but that void would probably have been filled sooner than Clang did it.
Or complaining that your baker won't make bagels because he's doesn't approve of using lye on human consumables.
> The fundamental issue is that for RMS (and perhaps you?), using software is like going to church and accepting the the moral code of whomever produced that software
RMS and the FSF are pretty lenient in this case (there are licenses which literally wrap the use of the software in a moral code); you have no need to accept his moral code when you use the software. His licensing (and moral code) only matter when you want to change the code and distribute those changes.
Fortunately for all of us, there are plenty of licenses, and plenty of tools which use licenses which better match the "free with no restrictions whatsoever" point of view.
Using products like those does not mean you have to accept or endorse the the moral code that the products represent. However, for most people, morality do play a part of why they pick those products.
Because the range of ways people might want to process code is vast. It's impossible to predict in advance what all those possibilities might be. The only way to allow the full range of transformations is to provide the full AST. Denying people the ability to manipulate code using code is to deny them a very important and powerful tool in computing. It reminds me a lot of when Apple tried to restrict what languages people could use when developing for iOS.
It's mind boggling that this even needs to be explained. I get the sense that rms doesn't really grok the Emacs philosophy anymore.
This would be terrible, for as far as I'm concerned, his single greatest contribution to computing is the EMACS philosophy that he developed out of a primitive set of TECO macros. (I believe everything else would have happened more or less, e.g. without Linux, BSD would be ruling now after a 2 year pause for that AT&T lawsuit.)
They say nothing about the existing limits on your ability to re-distribute software or media (in fact, the FSF and GPL depend on copyright protections).
And don't one or more of the BSDs have problems with the GLPv3 GCC? It's just not eeevil Apple (and that's part of why I swore off their products in 1987).
For Stallman a program/tool is "defective" if it enables programmers to limit end users access to code, .e.g. by enabling proprietary addons to the compiler.
This is bad news for everyone because competition is good. I want two solid open source compilers. Look what happened with gcc error messages when Clang showed up: they were horrendous compared to what LLVM/Clang had to offer. So gcc had to catch up. But if it's impossible to compete in the race because RMS doesn't want to - everyone gets screwed. But I guess that for RMS it's a win-win situation: he'll have his proof that BSD-licensed software can kill one on GPL.
Why did it? Emacs is a great development environment. It allows you to focus on the code and supports debugging right next to your code, same as an ide. It is an ide.
Emacs lacks some features of xcode/eclipse et al but in exchange it has power they lack. Why shouldn't it gain some of their features?
(I am assuming you loled because you considered emacs weaker. My apologies if I got the sense backwards).
There's stuff I miss about emacs, and I'll keep using it for text files and r code and other stuff (it's still my primary python editor until I get around to trying pycharm), but by and large I think I'm done with it for c/c++.
What's wrong with xcode? It has static analysis complete with annotations, integration with instruments for thread / network / CPU / memory monitoring, integration with lldb, code completion, code folding, quick navigation, details about callers and callees from any function, details about generated code (so you can look at the preprocessed code), the same with assembly (if you so desire!), test integration, class hierarchies, documentation for relevant functions (same as man, documentation for Apple SDKs) but IS missing refactoring for C++ (it does C and Obj-C).
Which bit about all of that is missing?? (other than refactoring C++)
I am using 6.1.1 and I haven't had it crash for the past 6 months, using it 7.5 hours a day (and 3 hours a night too). 6.0 was buggy as anything but 6.1.1 is rock-solid for me.
We'll really know things are at a tipping point when LLVM starts to acquire a bunch of solid back ends. I will personally count it as all over if/when Atmel AVR 8 bit is supported.
So, yeah, I should gather my robes and prepare to deliver a Biblical "Repent, sinner, for the end is nigh!"
"llvm cant build a working Linux kernel from unmodified sources, using the .config from a major distribution"
It's getting closer; I believe it won't be long until clang/llvm can build a Linux kernel from unmodified sources (getting Linus to accept the remaining patches is a valid tactic).