* clang/emacs/ecb/semantic @ 2012-11-29 16:32 Ramneek Handa 2012-11-29 19:59 ` clang/emacs/ecb/semantic Dmitry Gutov 2012-11-30 2:51 ` clang/emacs/ecb/semantic Richard Stallman 0 siblings, 2 replies; 46+ messages in thread From: Ramneek Handa @ 2012-11-29 16:32 UTC (permalink / raw) To: Emacs-devel [-- Attachment #1: Type: text/plain, Size: 545 bytes --] Would anyone like to collaborate on an advanced c++ browsing capabilities in emacs using clang? I have some basic code ready which can provide very intrusive data about a program which can be used to build a source file outline, semantic highlighting, jump to declaration , jump to definition et all.. i am not very good with elisp and don't have much time to devote on it.. I would be very happy if i can find like minded developers who would like to get it done.. -- Ramneek Handa Sent with Sparrow (http://www.sparrowmailapp.com/?sig) [-- Attachment #2: Type: text/html, Size: 805 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-11-29 16:32 clang/emacs/ecb/semantic Ramneek Handa @ 2012-11-29 19:59 ` Dmitry Gutov 2012-11-29 20:27 ` clang/emacs/ecb/semantic David Engster 2012-11-30 2:51 ` clang/emacs/ecb/semantic Richard Stallman 1 sibling, 1 reply; 46+ messages in thread From: Dmitry Gutov @ 2012-11-29 19:59 UTC (permalink / raw) To: Ramneek Handa; +Cc: Emacs-devel Ramneek Handa <ramneekhanda@gmail.com> writes: > Would anyone like to collaborate on an advanced c++ browsing capabilities in > emacs using clang? > > I have some basic code ready which can provide very intrusive data about a > program which can be used to build a source file outline, semantic highlighting, > jump to declaration , jump to definition et all.. i am not very good with elisp > and don't have much time to devote on it.. > > I would be very happy if i can find like minded developers who would like to get > it done.. According to this, there already is a semantic-clang.el in the CEDET trunk: http://sourceforge.net/mailarchive/message.php?msg_id=27383453 You should write to cedet-devel, there are more knowledgeable people there. --Dmitry ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-11-29 19:59 ` clang/emacs/ecb/semantic Dmitry Gutov @ 2012-11-29 20:27 ` David Engster 2012-11-29 20:38 ` clang/emacs/ecb/semantic Óscar Fuentes 0 siblings, 1 reply; 46+ messages in thread From: David Engster @ 2012-11-29 20:27 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Ramneek Handa, Emacs-devel Dmitry Gutov writes: > Ramneek Handa <ramneekhanda@gmail.com> writes: > >> Would anyone like to collaborate on an advanced c++ browsing capabilities in >> emacs using clang? >> >> I have some basic code ready which can provide very intrusive data about a >> program which can be used to build a source file outline, semantic highlighting, >> jump to declaration , jump to definition et all.. i am not very good with elisp >> and don't have much time to devote on it.. >> >> I would be very happy if i can find like minded developers who would like to get >> it done.. > > According to this, there already is a semantic-clang.el in the CEDET > trunk: http://sourceforge.net/mailarchive/message.php?msg_id=27383453 That one only does completion. It was more or less a proof-of-concept and I'm not sure if it's working with latest clang binaries. This is also the reason why this feature isn't available in the CEDET version that ships with Emacs. Regarding the OP's mail: There are already projects out there using libclang for code completion and navigation: https://github.com/Andersbakken/rtags https://github.com/Golevka/emacs-clang-complete-async I did look into using libclang and also libtooling for better C++ support in CEDET. Its main drawback is that it isn't fault-tolerant at all. If you're editing a C++ file and an #include cannot be found, or a closing brace is missing, you cannot get a proper AST to visit. Also, I think libtooling is more flexible than libclang, but compiling stuff with it is *really* cumbersome. What I would be very interested in is to have a parser based on libclang or libtooling, which can output a simplified AST from C++ files. Maybe I should just try gcc-xml again... -David ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-11-29 20:27 ` clang/emacs/ecb/semantic David Engster @ 2012-11-29 20:38 ` Óscar Fuentes 2012-11-29 20:49 ` clang/emacs/ecb/semantic David Engster 2012-11-30 2:52 ` clang/emacs/ecb/semantic Richard Stallman 0 siblings, 2 replies; 46+ messages in thread From: Óscar Fuentes @ 2012-11-29 20:38 UTC (permalink / raw) To: emacs-devel; +Cc: David Engster David Engster <deng@randomsample.de> writes: [snip] > What I would be very interested in is to have a parser based on libclang > or libtooling, which can output a simplified AST from C++ files. Maybe I > should just try gcc-xml again... gcc-xml is frozen since a few years ago. The author recommends using clang. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-11-29 20:38 ` clang/emacs/ecb/semantic Óscar Fuentes @ 2012-11-29 20:49 ` David Engster 2012-11-30 2:52 ` clang/emacs/ecb/semantic Richard Stallman 1 sibling, 0 replies; 46+ messages in thread From: David Engster @ 2012-11-29 20:49 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes writes: > David Engster <deng@randomsample.de> writes: > > [snip] > >> What I would be very interested in is to have a parser based on libclang >> or libtooling, which can output a simplified AST from C++ files. Maybe I >> should just try gcc-xml again... > > gcc-xml is frozen since a few years ago. The author recommends using > clang. I just saw that there's now a github repository for it with at least a tiny bit of activity, so I had hopes. While clang can theoretically output something similar, I still coulnd't find a tool which just does it. -David ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-11-29 20:38 ` clang/emacs/ecb/semantic Óscar Fuentes 2012-11-29 20:49 ` clang/emacs/ecb/semantic David Engster @ 2012-11-30 2:52 ` Richard Stallman 2012-11-30 6:34 ` clang/emacs/ecb/semantic Pascal J. Bourguignon 2012-11-30 6:46 ` clang/emacs/ecb/semantic Helmut Eller 1 sibling, 2 replies; 46+ messages in thread From: Richard Stallman @ 2012-11-30 2:52 UTC (permalink / raw) To: Óscar Fuentes; +Cc: deng, emacs-devel gcc-xml is frozen since a few years ago. The author recommends using clang. That recommendation works to the detriment of the GNU Project, so maybe we want to find someone else to take it up again. What exactly does gcc-xml do? -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-11-30 2:52 ` clang/emacs/ecb/semantic Richard Stallman @ 2012-11-30 6:34 ` Pascal J. Bourguignon 2012-11-30 15:15 ` clang/emacs/ecb/semantic David Engster 2012-11-30 20:11 ` clang/emacs/ecb/semantic Richard Stallman 2012-11-30 6:46 ` clang/emacs/ecb/semantic Helmut Eller 1 sibling, 2 replies; 46+ messages in thread From: Pascal J. Bourguignon @ 2012-11-30 6:34 UTC (permalink / raw) To: emacs-devel Richard Stallman <rms@gnu.org> writes: > gcc-xml is frozen since a few years ago. The author recommends using > clang. > > That recommendation works to the detriment of the GNU Project, so > maybe we want to find someone else to take it up again. > > What exactly does gcc-xml do? Something that should have been merged into gcc a long time ago. It generates the parse tree as xml. http://www.gccxml.org/ Unfortunately, it doesn't support all the language front ends, and since it's not incorporated into gcc itself, it lags, and therefore cannot be used in practice to analyse sources compiled with the latest versions of gcc. Llvm and clang provide natively a way to get the parse tree (and other phases information), and therefore they can be used easily in IDE. http://clang.llvm.org/features.html#applications -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-11-30 6:34 ` clang/emacs/ecb/semantic Pascal J. Bourguignon @ 2012-11-30 15:15 ` David Engster 2012-11-30 15:25 ` clang/emacs/ecb/semantic ramneek 2012-11-30 20:11 ` clang/emacs/ecb/semantic Richard Stallman 1 sibling, 1 reply; 46+ messages in thread From: David Engster @ 2012-11-30 15:15 UTC (permalink / raw) To: Pascal J. Bourguignon; +Cc: emacs-devel Pascal J. Bourguignon writes: > Llvm and clang provide natively a way to get the parse tree (and other > phases information), and therefore they can be used easily in IDE. > http://clang.llvm.org/features.html#applications Since v4.5.0 GCC does that, too, via its plugin interface: http://gcc.gnu.org/wiki/plugins I'm not really qualified to compare it to libclang and libtooling, but at least from what I saw, it's not as well documented and probably requires some knowledge of gcc's internals to be really usable. However, the existing python plugin looks very interesting, since it seems to nicely wrap gcc's tree data structure: https://gcc-python-plugin.readthedocs.org/en/latest/tree.html The real task is to condense this structure to something simpler, which is usable by tools like Semantic. -David ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-11-30 15:15 ` clang/emacs/ecb/semantic David Engster @ 2012-11-30 15:25 ` ramneek 2012-12-01 4:44 ` clang/emacs/ecb/semantic Richard Stallman 0 siblings, 1 reply; 46+ messages in thread From: ramneek @ 2012-11-30 15:25 UTC (permalink / raw) To: Pascal J. Bourguignon, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1980 bytes --] I haven't looked at gcc plugin interface much but i have picked up clang's lib tooling interface pretty quickly and want to make my experience with emacs better. I looked at rtags project mentioned in this mail chain and think it looks good however it failed a bit for me and doesn't provide all that i need. (i do intend to write to the author). I have started some work on creating mini apps which will output in json format which i plan to write elisp extensions for. Since i have limited time in hands i would appreciate if someone facing similar issues can join forces and we can get it done. Basic requirements i have are: 1. fast semantic completions 2. jump to declaration and definition 3. provide a help window for if there are comments on the function under the cursor all of the above are doable by clang and more (i was told that gcc sat doesn't contain the comments info, i am not sure how true that is). I want to make it simple on the first cut and see how it looks and then proceed further.. So anyone? Regards, Ramneek On Friday, 30 November, 2012 at 11:15 PM, David Engster wrote: > Pascal J. Bourguignon writes: > > Llvm and clang provide natively a way to get the parse tree (and other > > phases information), and therefore they can be used easily in IDE. > > http://clang.llvm.org/features.html#applications > > > > > Since v4.5.0 GCC does that, too, via its plugin interface: > > http://gcc.gnu.org/wiki/plugins > > I'm not really qualified to compare it to libclang and libtooling, but > at least from what I saw, it's not as well documented and probably > requires some knowledge of gcc's internals to be really usable. > > However, the existing python plugin looks very interesting, since it > seems to nicely wrap gcc's tree data structure: > > https://gcc-python-plugin.readthedocs.org/en/latest/tree.html > > The real task is to condense this structure to something simpler, which > is usable by tools like Semantic. > > -David [-- Attachment #2: Type: text/html, Size: 3166 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-11-30 15:25 ` clang/emacs/ecb/semantic ramneek @ 2012-12-01 4:44 ` Richard Stallman 2012-12-04 17:04 ` clang/emacs/ecb/semantic David Engster 0 siblings, 1 reply; 46+ messages in thread From: Richard Stallman @ 2012-12-01 4:44 UTC (permalink / raw) To: ramneek; +Cc: pjb, emacs-devel If you would like us to install it in Emacs, or support it in any way, please use our compiler -- GCC. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-01 4:44 ` clang/emacs/ecb/semantic Richard Stallman @ 2012-12-04 17:04 ` David Engster 0 siblings, 0 replies; 46+ messages in thread From: David Engster @ 2012-12-04 17:04 UTC (permalink / raw) To: rms; +Cc: pjb, ramneek, emacs-devel Richard Stallman writes: > If you would like us to install it in Emacs, or support it in any way, > please use our compiler -- GCC. The problem is that GCC simply does not provide the needed features; most prominently, showing completion candidates for C++ code. There is a project by Tomohiro Matsuyama, called gccsense (see [1]), which uses a modified GCC to provide this feature. However, requiring users to compile a modified GCC is a big barrier. According to Tomohiro Matsuyama, implementing this feature as a GCC plugin also is not feasible, which is why he asked for help on the GCC mailing list in 4/2010 (see [2]), but the feedback he got was not very encouraging. -David [1] http://cx4a.org/software/gccsense/ [2] http://gcc.gnu.org/ml/gcc/2010-04/msg00433.html ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-11-30 6:34 ` clang/emacs/ecb/semantic Pascal J. Bourguignon 2012-11-30 15:15 ` clang/emacs/ecb/semantic David Engster @ 2012-11-30 20:11 ` Richard Stallman 2012-11-30 21:02 ` clang/emacs/ecb/semantic Óscar Fuentes 2012-11-30 21:50 ` clang/emacs/ecb/semantic Pascal J. Bourguignon 1 sibling, 2 replies; 46+ messages in thread From: Richard Stallman @ 2012-11-30 20:11 UTC (permalink / raw) To: Pascal J. Bourguignon; +Cc: emacs-devel Something that should have been merged into gcc a long time ago. It generates the parse tree as xml. http://www.gccxml.org/ Do you mean, the entire parse tree in full detail? Would it be conceivable to feed this into a nonfree back-end? Would this mean that nonfree backends could take advantage of our free front-ends? If so, it is very dangerous -- it would open the door to a terrible setback for our defense of users' freedom. Namely, the use of free software as part of compilers that are partly nonfree. I don't remember, but I would guess that is why we have refused to merge it into GCC. Llvm and clang provide natively a way to get the parse tree (and other phases information), and therefore they can be used easily in IDE. LLVM and Clang open the door to the same terrible setback. Since they are not copylefted, their front-ends can be used with nonfree back-ends and vice versa. They are being developed by people who don't care about users' freedom, funded by the worst enemy of users' freedom (Apple). -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-11-30 20:11 ` clang/emacs/ecb/semantic Richard Stallman @ 2012-11-30 21:02 ` Óscar Fuentes 2012-12-01 19:30 ` clang/emacs/ecb/semantic Richard Stallman 2012-12-01 19:30 ` clang/emacs/ecb/semantic Richard Stallman 2012-11-30 21:50 ` clang/emacs/ecb/semantic Pascal J. Bourguignon 1 sibling, 2 replies; 46+ messages in thread From: Óscar Fuentes @ 2012-11-30 21:02 UTC (permalink / raw) To: Richard Stallman; +Cc: Pascal J. Bourguignon, emacs-devel Richard Stallman <rms@gnu.org> writes: > Something that should have been merged into gcc a long time ago. > > It generates the parse tree as xml. http://www.gccxml.org/ > > Do you mean, the entire parse tree in full detail? > Would it be conceivable to feed this into a nonfree back-end? > Would this mean that nonfree backends could take advantage > of our free front-ends? No. The output does not contain the actual body of functions, for instance. It is useful for knowing "what's the type of this global variable?", "where is this type defined?", "how many arguments has this function? what's their types?", "what's the data members of this struct?", "what's the methods of this class?" etc It is enough for automatically generating function and type wrappers for using C/C++ code from other languages through their FFIs, but absolutely insufficient for compiling such C/C++ code. > If so, it is very dangerous -- it would open the door to a terrible > setback for our defense of users' freedom. Namely, the use of free > software as part of compilers that are partly nonfree. I don't > remember, but I would guess that is why we have refused to merge it > into GCC. > > Llvm and clang provide natively a way to get the parse tree (and other > phases information), and therefore they can be used easily in IDE. > > LLVM and Clang open the door to the same terrible setback. Since they > are not copylefted, their front-ends can be used with nonfree > back-ends and vice versa. Yes. > They are being developed by people who don't care about users' > freedom, funded by the worst enemy of users' freedom (Apple). Apple is, possibly, the main founder, but there are several other parties involved (Google and FreeBSD, for instance) and all those are very interested on keeping the status quo. If Apple tried to hinder the other actors on any way, the project would fork in no time. And, the project lider is all for keeping LLVM & Clang as they are, no matter he is an Apple employee. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-11-30 21:02 ` clang/emacs/ecb/semantic Óscar Fuentes @ 2012-12-01 19:30 ` Richard Stallman 2012-12-01 19:30 ` clang/emacs/ecb/semantic Richard Stallman 1 sibling, 0 replies; 46+ messages in thread From: Richard Stallman @ 2012-12-01 19:30 UTC (permalink / raw) To: Óscar Fuentes; +Cc: pjb, emacs-devel > Do you mean, the entire parse tree in full detail? > Would it be conceivable to feed this into a nonfree back-end? > Would this mean that nonfree backends could take advantage > of our free front-ends? No. The output does not contain the actual body of functions, for instance. It is useful for knowing "what's the type of this global variable?", "where is this type defined?", "how many arguments has this function? what's their types?", "what's the data members of this struct?", "what's the methods of this class?" etc In that case, it seems like a fine feature as far as I can see. I will ask the GCC developers about it. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-11-30 21:02 ` clang/emacs/ecb/semantic Óscar Fuentes 2012-12-01 19:30 ` clang/emacs/ecb/semantic Richard Stallman @ 2012-12-01 19:30 ` Richard Stallman 1 sibling, 0 replies; 46+ messages in thread From: Richard Stallman @ 2012-12-01 19:30 UTC (permalink / raw) To: Óscar Fuentes; +Cc: pjb, emacs-devel Apple is, possibly, the main founder, but there are several other parties involved (Google and FreeBSD, for instance) and all those are very interested on keeping the status quo. If Apple tried to hinder the other actors on any way, the project would fork in no time. And, the project lider is all for keeping LLVM & Clang as they are, no matter he is an Apple employee. That won't stop someone else from writing a nonfree front-end or back-end for it. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-11-30 20:11 ` clang/emacs/ecb/semantic Richard Stallman 2012-11-30 21:02 ` clang/emacs/ecb/semantic Óscar Fuentes @ 2012-11-30 21:50 ` Pascal J. Bourguignon 2012-12-02 4:15 ` clang/emacs/ecb/semantic Richard Stallman 1 sibling, 1 reply; 46+ messages in thread From: Pascal J. Bourguignon @ 2012-11-30 21:50 UTC (permalink / raw) To: emacs-devel Richard Stallman <rms@gnu.org> writes: > Something that should have been merged into gcc a long time ago. > > It generates the parse tree as xml. http://www.gccxml.org/ > > Do you mean, the entire parse tree in full detail? > Would it be conceivable to feed this into a nonfree back-end? > Would this mean that nonfree backends could take advantage > of our free front-ends? > > If so, it is very dangerous -- it would open the door to a terrible > setback for our defense of users' freedom. Namely, the use of free > software as part of compilers that are partly nonfree. I don't > remember, but I would guess that is why we have refused to merge it > into GCC. I can understand this reasonning. But in practice the conclusion is that Apple switches to llvm/clang, and llvm/clang as a lot of momentum everywhere. Wouldn't have been better to accept gcc-xml and have gcc cover 99% of the "market", rather than rejecting it, and eventually have gcc left with only 10% of the mind share, and clang/llvm 90%? I'm afraid this might end like that. > Llvm and clang provide natively a way to get the parse tree (and other > phases information), and therefore they can be used easily in IDE. > > LLVM and Clang open the door to the same terrible setback. Since they > are not copylefted, their front-ends can be used with nonfree > back-ends and vice versa. Definitely. It's bad they're not GPL, and it's bad they're used in non GPL environments. But that's how things are. llvm and clang are providing a superior alternative to gcc for tool and IDE builders. > They are being developed by people who don't care about users' > freedom, funded by the worst enemy of users' freedom (Apple). I don't know if Apple funds LLVM. AFAIK it started as a normal university project. Would a good alternative (for freedom) to be that free compilers (GPL) provide the exact formal grammar they parse, so that tool builders could use it to write compatible parsers to use in their tools? For example, now emacs has with cedet several parser generators (bovinator, Wysent, etc), but they are not widely (easily) applied to a large number of languages, because the grammars (of specific implementations) are often not so easy to retrieve in a usable form. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-11-30 21:50 ` clang/emacs/ecb/semantic Pascal J. Bourguignon @ 2012-12-02 4:15 ` Richard Stallman 2012-12-02 5:13 ` clang/emacs/ecb/semantic Daniel Colascione ` (2 more replies) 0 siblings, 3 replies; 46+ messages in thread From: Richard Stallman @ 2012-12-02 4:15 UTC (permalink / raw) To: Pascal J. Bourguignon; +Cc: emacs-devel Wouldn't have been better to accept gcc-xml and have gcc cover 99% of the "market", rather than rejecting it, and eventually have gcc left with only 10% of the mind share, and clang/llvm 90%? I'm afraid this might end like that. We do not look at software users as a market. Our goal is something more than popularity. What matters is users' freedom, and copyleft as a weapon to defend it with. GCC vs LLVM is important mainly as an instance of fighting for copyleft. Would a good alternative (for freedom) to be that free compilers (GPL) provide the exact formal grammar they parse, so that tool builders could use it to write compatible parsers to use in their tools? If "tool builders could use it to write compatible parsers to use in their tools", is that good or is it bad? You seem to think it is always good. I think it is good if the tools are free, and bad if the tools are nonfree. Nonfree tools (like any nonfree programs) are an injustice. Part of the reason why clang/llvm weakens our commnity, compared with GCC, is that the clang front ends can feed their data to nonfree tools. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-02 4:15 ` clang/emacs/ecb/semantic Richard Stallman @ 2012-12-02 5:13 ` Daniel Colascione 2012-12-03 0:02 ` clang/emacs/ecb/semantic Richard Stallman 2012-12-02 9:04 ` clang/emacs/ecb/semantic Stephen J. Turnbull 2012-12-02 13:59 ` clang/emacs/ecb/semantic Pascal J. Bourguignon 2 siblings, 1 reply; 46+ messages in thread From: Daniel Colascione @ 2012-12-02 5:13 UTC (permalink / raw) To: rms; +Cc: Pascal J. Bourguignon, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1551 bytes --] On 12/1/12 8:15 PM, Richard Stallman wrote: > If "tool builders could use it to write compatible parsers to use in > their tools", is that good or is it bad? You seem to think it is > always good. I think it is good if the tools are free, and bad if the > tools are nonfree. Nonfree tools (like any nonfree programs) are an > injustice. That's absurd. Software freedom should never be at odds with interoperability. Freedom and trust are inseparable. You can't use free software to make paternalistic decisions about non-free software for the user. You have to trust users to act in their own interest and choose not to use non-free tools that might interoperate with free software. Denying users this choice is the precise opposite of freedom: it's ideology-driven authoritarianism. A free program provides no actual freedom when there are no users around to enjoy that freedom. Deliberately crippling interoperability between free software and the rest of the world actually undermines the viability of free software as an alternative to commercial software. When Clang eclipses gcc, it will just suggest, perhaps incorrectly, that GPL is merely a drag on software development and encourage developers to leave copyleft behind. gcc-xml should have been merged a long time ago. The only thing the gcc project will have accomplished by preventing gcc's use as a decent back-end for a proprietary system is to ensure that users use development environments in which neither the front nor the back end is truly free. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 235 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-02 5:13 ` clang/emacs/ecb/semantic Daniel Colascione @ 2012-12-03 0:02 ` Richard Stallman 2012-12-03 1:42 ` clang/emacs/ecb/semantic Daniel Colascione 0 siblings, 1 reply; 46+ messages in thread From: Richard Stallman @ 2012-12-03 0:02 UTC (permalink / raw) To: Daniel Colascione; +Cc: pjb, emacs-devel That's absurd. Software freedom should never be at odds with interoperability. Freedom and trust are inseparable. You can't use free software to make paternalistic decisions about non-free software for the user. We use the GNU GPL to make sure that our code is not included in nonfree programs that violate users' freedom. We develop software as a campaign for freedom, and recognizing that some people might try to include it in nonfree combinations, we use copyleft to stop them. This is what we are doing here. If you think standing up for freedom is "paternalistic", you don't have to participate. There is a lot of other confusion in your message. Some of it is easy to explain: for instance, contrasting free software with commercial software. (See http://www.gnu.org/philosophy/words-to-avoid.html.) Some of it would require long analysis, such as the values and goals that show through in the words. What is clear is that you hate copyleft so much that you would relish our defeat simply to replace a copylefted program with a noncopylefted one. If that is how you feel about the GNU Project, you are entitled to your views, of course, but don't state them on this list. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-03 0:02 ` clang/emacs/ecb/semantic Richard Stallman @ 2012-12-03 1:42 ` Daniel Colascione 2012-12-03 17:08 ` clang/emacs/ecb/semantic Eli Zaretskii 2012-12-03 19:34 ` clang/emacs/ecb/semantic Richard Stallman 0 siblings, 2 replies; 46+ messages in thread From: Daniel Colascione @ 2012-12-03 1:42 UTC (permalink / raw) To: rms; +Cc: pjb, emacs-devel [-- Attachment #1: Type: text/plain, Size: 3909 bytes --] On 12/2/12 4:02 PM, Richard Stallman wrote: > That's absurd. Software freedom should never be at odds with > interoperability. Freedom and trust are inseparable. You can't use > free software to make paternalistic decisions about non-free software > for the user. > > We use the GNU GPL to make sure that our code is not included in > nonfree programs that violate users' freedom. We develop software as > a campaign for freedom, and recognizing that some people might try to > include it in nonfree combinations, we use copyleft to stop them. > > This is what we are doing here. If you think standing up for freedom > is "paternalistic", you don't have to participate. We must consider utilitarian calculus; that is, we must choose the actions will lead to the greatest good for the greatest number. By choosing to limit gcc's potential for interoperability, its developers have limited the number of users who can benefit from the good provided by gcc's freedom. gcc's monolithic design hinders integration of free and non-free software alike. It's equally impractical to integrate a GPLv3 system (like Emacs) with gcc and to integrate a EULA-encrusted tool with gcc; thus, gcc did not (and to a large extent, does not) meet legitimate user needs. The Clang developers met this pent-up demand and found tremendous support: if current trends continue, there will be more Clang users than gcc users. I know you argue that software freedom is not a market, but if that's true and user counts don't matter, why work on free software at all? Users matter because software cannot suffer. The only freedom that matters is freedom that real people enjoy. We should show the world that need be no choice between programs that are free and programs that are useful. While it is true that a hypothetical modular gcc could be integrated with non-free parts (e.g., a proprietary IDE or a proprietary back-end), the GPL would force developers of the non-free components in the system to communicate with this modular gcc over well-defined protocols, making it easily to substitute free components for the proprietary ones. On the other hand, while Clang itself is free software, Clang's permissive licensing makes it practical to tightly couple free and non-free components of a system together into inscrutable monoliths, and any free replacement for one of these monoliths would have to be built from scratch. Additionally, Clang's permissive licensing will eventually encourage the development of non-free extensions, derivatives, and machine-target back-ends for Clang itself, leading to ecosystem fragmentation and significant impairment of end-user freedom. gcc's users howled for certain features, and for a very long time, gcc's developers ignored these pleas for fear that the needed features might somehow aid proprietary software. In the end, this stubbornness merely drove users to non-copyleft software that actually met their needs. The people who blocked needed gcc features didn't stand up for software freedom: actually, they neglected it. > What is clear is that you hate copyleft so much that you would relish > our defeat simply to replace a copylefted program with a noncopylefted > one. If that is how you feel about the GNU Project, you are entitled > to your views, of course, but don't state them on this list. I'm disappointed to see you resort to an ad hominem attack against someone who largely shares your positions and goals. From you, of all people, I expected more nuance. I "hate" copyleft and free software about as much as you do, and it troubles me that you've interpreted our minor difference of opinion as major malice on my part. Throughout history, a hallmark of a troubled organization has the characterization of loyal dissent as treason. It saddens me to see this phenomenon here. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 235 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-03 1:42 ` clang/emacs/ecb/semantic Daniel Colascione @ 2012-12-03 17:08 ` Eli Zaretskii 2012-12-03 17:21 ` clang/emacs/ecb/semantic Chong Yidong 2012-12-03 19:34 ` clang/emacs/ecb/semantic Richard Stallman 1 sibling, 1 reply; 46+ messages in thread From: Eli Zaretskii @ 2012-12-03 17:08 UTC (permalink / raw) To: Daniel Colascione; +Cc: pjb, rms, emacs-devel > Date: Sun, 02 Dec 2012 17:42:27 -0800 > From: Daniel Colascione <dancol@dancol.org> > Cc: pjb@informatimago.com, emacs-devel@gnu.org > > We must consider utilitarian calculus; that is, we must choose the > actions will lead to the greatest good for the greatest number. By > choosing to limit gcc's potential for interoperability, its developers > have limited the number of users who can benefit from the good > provided by gcc's freedom. I'm sorry, but this comes across as a straw man argument, and I'm sure you didn't mean that. "... greatest good for the greatest number." I don't think you will find here anyone who won't agree with that aspiration. But that is not the issue here. The issue is how far to go in limiting freedom of others. And limit you must, because "your liberty to swing your fist ends where my nose begins." You want to limit the freedom of the Bad Guys to abuse the freedom against you and your goals. That's why we have the GPL. It is this deceptively simple issue -- where to draw the line -- that is the single most important _practical_ issue that is at stake here. It is also what distinguishes between what we call "free society" and a dictatorship. I'm sure you know all that. And yet you never mention this crucial detail, and instead insist on maximizing freedom. It's small surprise that Richard interpreted that as an attack on the GPL: after all, the GPL also limits certain freedoms, and thus leaves less people happy. More to the point, you seem to say that the line was drawn in the wrong place in this matter. But you never say why it was wrong, in practical terms, nor explain why in your POV the line should have been drawn elsewhere, or how that would benefit the free software without hurting its goals. There's no point in talking about this without discussing these _practical_ issues. Slogans, however laudable, won't cut it, because they don't provide any practical guidance that alone matters. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-03 17:08 ` clang/emacs/ecb/semantic Eli Zaretskii @ 2012-12-03 17:21 ` Chong Yidong 2012-12-03 17:56 ` clang/emacs/ecb/semantic Eli Zaretskii 0 siblings, 1 reply; 46+ messages in thread From: Chong Yidong @ 2012-12-03 17:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: pjb, Daniel Colascione, rms, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > More to the point, you seem to say that the line was drawn in the > wrong place in this matter. But you never say why it was wrong, in > practical terms The practical terms are in the subject of this thread, i.e. the fact that there is no GPL'ed compiler which can provide the parse data needed by a modern IDE. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-03 17:21 ` clang/emacs/ecb/semantic Chong Yidong @ 2012-12-03 17:56 ` Eli Zaretskii 2012-12-03 18:14 ` clang/emacs/ecb/semantic Daniel Colascione 0 siblings, 1 reply; 46+ messages in thread From: Eli Zaretskii @ 2012-12-03 17:56 UTC (permalink / raw) To: Chong Yidong; +Cc: pjb, dancol, rms, emacs-devel > From: Chong Yidong <cyd@gnu.org> > Cc: Daniel Colascione <dancol@dancol.org>, pjb@informatimago.com, rms@gnu.org, emacs-devel@gnu.org > Date: Tue, 04 Dec 2012 01:21:09 +0800 > > Eli Zaretskii <eliz@gnu.org> writes: > > > More to the point, you seem to say that the line was drawn in the > > wrong place in this matter. But you never say why it was wrong, in > > practical terms > > The practical terms are in the subject of this thread, i.e. the fact > that there is no GPL'ed compiler which can provide the parse data needed > by a modern IDE. And there wasn't a GPL'ed text editor that supported bidirectional editing 2 years ago. So what? All it means that no one stepped forward and did that in a way that was acceptable. It certainly doesn't mean the FSF should fall for the first opportunity out there, just because there's no other solution. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-03 17:56 ` clang/emacs/ecb/semantic Eli Zaretskii @ 2012-12-03 18:14 ` Daniel Colascione 2012-12-03 18:50 ` clang/emacs/ecb/semantic Eli Zaretskii 2012-12-04 0:41 ` clang/emacs/ecb/semantic Richard Stallman 0 siblings, 2 replies; 46+ messages in thread From: Daniel Colascione @ 2012-12-03 18:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: pjb, Chong Yidong, rms, emacs-devel [-- Attachment #1: Type: text/plain, Size: 2112 bytes --] On 12/3/12 9:56 AM, Eli Zaretskii wrote: >> From: Chong Yidong <cyd@gnu.org> >> Cc: Daniel Colascione <dancol@dancol.org>, pjb@informatimago.com, rms@gnu.org, emacs-devel@gnu.org >> Date: Tue, 04 Dec 2012 01:21:09 +0800 >> >> Eli Zaretskii <eliz@gnu.org> writes: >> >>> More to the point, you seem to say that the line was drawn in the >>> wrong place in this matter. But you never say why it was wrong, in >>> practical terms >> >> The practical terms are in the subject of this thread, i.e. the fact >> that there is no GPL'ed compiler which can provide the parse data needed >> by a modern IDE. > > And there wasn't a GPL'ed text editor that supported bidirectional > editing 2 years ago. So what? All it means that no one stepped > forward and did that in a way that was acceptable. It certainly > doesn't mean the FSF should fall for the first opportunity out there, > just because there's no other solution. There was no GPLed text editor supporting bidirectional editing because the work hadn't been done. (Thanks again for doing that work.) The gcc situation is different: multiple parties stepped forward to do the work required to integrate gcc with other tools, and the gcc developers refused to accept it. I don't think there is any technical that would satisfy both the technical requirements of external tools and the political requirements of the gcc developers. Licensing is one thing, but a modular gcc, covered by the GPL, would itself be just as free as today's gcc. (As would an Emacs with an FFI, for that matter.) Technical restrictions are something else. Reducing functionality can *never* serve the cause of software freedom. Free programs should be as technically strong as possible, even if that means they can talk to non-free programs. It's up to developers to produce free software so good that users choose to use free programs together, and crippling free software so that it can't interoperate with *anything*, be it free or non-free, is a "see no evil" approach that's not only a strategic blunder, but an affront to users. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 235 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-03 18:14 ` clang/emacs/ecb/semantic Daniel Colascione @ 2012-12-03 18:50 ` Eli Zaretskii 2012-12-03 19:37 ` clang/emacs/ecb/semantic Stefan Monnier 2012-12-04 0:41 ` clang/emacs/ecb/semantic Richard Stallman 1 sibling, 1 reply; 46+ messages in thread From: Eli Zaretskii @ 2012-12-03 18:50 UTC (permalink / raw) To: Daniel Colascione; +Cc: pjb, cyd, rms, emacs-devel > Date: Mon, 03 Dec 2012 10:14:19 -0800 > From: Daniel Colascione <dancol@dancol.org> > CC: Chong Yidong <cyd@gnu.org>, pjb@informatimago.com, rms@gnu.org, > emacs-devel@gnu.org > > There was no GPLed text editor supporting bidirectional editing > because the work hadn't been done. That's not what really happened. There were at least 2 previous attempts, 10 years ago, to provide such an Emacs. They were rejected (for technical reasons, not ideological ones, but that's not important for the point I'm making). Someone could claim that by rejecting working solutions, Emacs delayed its bidi support by 10 years, and drove potential users to other, perhaps non-free, editors. The point is that the mere fact that a certain important requirements is not fulfilled might well have very good reasons. It is not enough to say "this niche is still empty" to prove that the decision to reject an existing solution was wrong. > Reducing functionality can *never* serve the cause of software > freedom. Free programs should be as technically strong as possible, > even if that means they can talk to non-free programs. It's up to > developers to produce free software so good that users choose to use > free programs together, and crippling free software so that it can't > interoperate with *anything*, be it free or non-free, is a "see no > evil" approach that's not only a strategic blunder, but an affront to > users. That's the same exaggerations and non-practical absolute terms again, sorry. I'm not convinced. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-03 18:50 ` clang/emacs/ecb/semantic Eli Zaretskii @ 2012-12-03 19:37 ` Stefan Monnier 2012-12-04 0:51 ` clang/emacs/ecb/semantic joakim 2012-12-04 1:04 ` clang/emacs/ecb/semantic joakim 0 siblings, 2 replies; 46+ messages in thread From: Stefan Monnier @ 2012-12-03 19:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: pjb, Daniel Colascione, rms, cyd, emacs-devel >> Reducing functionality can *never* serve the cause of software >> freedom. While I'm not sure we can say that in absolute terms like you do, I generally agree with you that I do believe it hurts the Free Software movement to self-inflict restrictions in this way. [ I'm thinking of restrictions such as the FFI thingy for Emacs. BTW, now that we have the green light for the FFI, I really would be delighted to see movement on this front. ] Stefan ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-03 19:37 ` clang/emacs/ecb/semantic Stefan Monnier @ 2012-12-04 0:51 ` joakim 2012-12-04 2:17 ` clang/emacs/ecb/semantic Stefan Monnier 2012-12-04 1:04 ` clang/emacs/ecb/semantic joakim 1 sibling, 1 reply; 46+ messages in thread From: joakim @ 2012-12-04 0:51 UTC (permalink / raw) To: Stefan Monnier Cc: rms, cyd, emacs-devel, pjb, Eli Zaretskii, Daniel Colascione Stefan Monnier <monnier@IRO.UMontreal.CA> writes: >>> Reducing functionality can *never* serve the cause of software >>> freedom. > > While I'm not sure we can say that in absolute terms like you do, > I generally agree with you that I do believe it hurts the Free > Software movement to self-inflict restrictions in this way. > [ I'm thinking of restrictions such as the FFI thingy for Emacs. > BTW, now that we have the green light for the FFI, I really would > be delighted to see movement on this front. ] Just a quick reminder, there is Gnome Object Introspection(GIR) support in the xwidget branch. (not that its super finished or anything, but its there anyway). > > > Stefan -- Joakim Verona ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-04 0:51 ` clang/emacs/ecb/semantic joakim @ 2012-12-04 2:17 ` Stefan Monnier 0 siblings, 0 replies; 46+ messages in thread From: Stefan Monnier @ 2012-12-04 2:17 UTC (permalink / raw) To: joakim; +Cc: rms, cyd, emacs-devel, pjb, Eli Zaretskii, Daniel Colascione > Just a quick reminder, there is Gnome Object Introspection(GIR) support > in the xwidget branch. (not that its super finished or anything, but > its there anyway). Could you submit it as a separate patch? Stefan ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-03 19:37 ` clang/emacs/ecb/semantic Stefan Monnier 2012-12-04 0:51 ` clang/emacs/ecb/semantic joakim @ 2012-12-04 1:04 ` joakim 1 sibling, 0 replies; 46+ messages in thread From: joakim @ 2012-12-04 1:04 UTC (permalink / raw) To: Stefan Monnier Cc: rms, cyd, emacs-devel, pjb, Eli Zaretskii, Daniel Colascione Stefan Monnier <monnier@IRO.UMontreal.CA> writes: >>> Reducing functionality can *never* serve the cause of software >>> freedom. > > While I'm not sure we can say that in absolute terms like you do, > I generally agree with you that I do believe it hurts the Free > Software movement to self-inflict restrictions in this way. > [ I'm thinking of restrictions such as the FFI thingy for Emacs. > BTW, now that we have the green light for the FFI, I really would > be delighted to see movement on this front. ] Well, it seems rational to review past choices now and then. IMHO the risk of someone combining a non-free compiler backend with a free frontend is not great today, which maybe it was at some point in time. I base this on observations of the companies I work with. So the policy to not merge the mentioned features might have provided benefit to the project at one time, but not so much anymore. > > > Stefan -- Joakim Verona ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-03 18:14 ` clang/emacs/ecb/semantic Daniel Colascione 2012-12-03 18:50 ` clang/emacs/ecb/semantic Eli Zaretskii @ 2012-12-04 0:41 ` Richard Stallman 1 sibling, 0 replies; 46+ messages in thread From: Richard Stallman @ 2012-12-04 0:41 UTC (permalink / raw) To: Daniel Colascione; +Cc: pjb, eliz, cyd, emacs-devel The GNU Project campaigns for freedom, not functionality. Sometimes freedom requires a practical sacrifice, and sometimes functionality is part of that sacrifice. You don't have to agree, but if you want to argue against the GNU Project's position, don't do it in this list. Raise the issue somewhere else if you wish. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-03 1:42 ` clang/emacs/ecb/semantic Daniel Colascione 2012-12-03 17:08 ` clang/emacs/ecb/semantic Eli Zaretskii @ 2012-12-03 19:34 ` Richard Stallman 1 sibling, 0 replies; 46+ messages in thread From: Richard Stallman @ 2012-12-03 19:34 UTC (permalink / raw) To: Daniel Colascione; +Cc: pjb, emacs-devel I won't spend time debating you over basic decisions of the GNU Project. They have always been controversial, and my policy for people who disagree is to go ahead anyway. If you start your own project, you can decide its basic practices for yourself. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-02 4:15 ` clang/emacs/ecb/semantic Richard Stallman 2012-12-02 5:13 ` clang/emacs/ecb/semantic Daniel Colascione @ 2012-12-02 9:04 ` Stephen J. Turnbull 2012-12-02 13:48 ` clang/emacs/ecb/semantic Helmut Eller 2012-12-03 0:02 ` clang/emacs/ecb/semantic Richard Stallman 2012-12-02 13:59 ` clang/emacs/ecb/semantic Pascal J. Bourguignon 2 siblings, 2 replies; 46+ messages in thread From: Stephen J. Turnbull @ 2012-12-02 9:04 UTC (permalink / raw) To: rms; +Cc: Pascal J. Bourguignon, emacs-devel Richard Stallman writes: > Part of the reason why clang/llvm weakens our commnity, compared > with GCC, is that the clang front ends can feed their data to > nonfree tools. Is that true, though? GCC can produce not only GIMPLE trees but also various forms of annotated RTL and dump them to files. I believe that it also accepts some of these representations as input. Is it possible to stop people from writing nonfree tools that use those representations of programs? I don't see how, unless you write a Microsoft-style EULA that restricts use as well as distribution. Ie, people can write non-free assemblers that use the assembly output of GCC, people can write non-free compilers that target the gas assembly language, and so on, all in conformance with the letter of the GPL. What am I missing? ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-02 9:04 ` clang/emacs/ecb/semantic Stephen J. Turnbull @ 2012-12-02 13:48 ` Helmut Eller 2012-12-03 0:02 ` clang/emacs/ecb/semantic Richard Stallman 2012-12-03 0:02 ` clang/emacs/ecb/semantic Richard Stallman 1 sibling, 1 reply; 46+ messages in thread From: Helmut Eller @ 2012-12-02 13:48 UTC (permalink / raw) To: emacs-devel On Sun, Dec 02 2012, Stephen J. Turnbull wrote: > Richard Stallman writes: > > > Part of the reason why clang/llvm weakens our commnity, compared > > with GCC, is that the clang front ends can feed their data to > > nonfree tools. > > Is that true, though? GCC can produce not only GIMPLE trees but also > various forms of annotated RTL and dump them to files. I believe that > it also accepts some of these representations as input. GCC can also produce debug information in Dwarf format, i.e. nonfree debuggers can be used with GCC. It would also not suprise me if the debug info is similarly detailed to what gcc-xml extracts. Helmut ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-02 13:48 ` clang/emacs/ecb/semantic Helmut Eller @ 2012-12-03 0:02 ` Richard Stallman 2012-12-03 16:02 ` clang/emacs/ecb/semantic Burton Samograd 0 siblings, 1 reply; 46+ messages in thread From: Richard Stallman @ 2012-12-03 0:02 UTC (permalink / raw) To: Helmut Eller; +Cc: emacs-devel GCC can also produce debug information in Dwarf format, i.e. nonfree debuggers can be used with GCC. Yes, of course, but you've changed the subject. The subject is this: > Part of the reason why clang/llvm weakens our commnity, compared with > GCC, is that the clang front ends can feed their data to nonfree tools. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-03 0:02 ` clang/emacs/ecb/semantic Richard Stallman @ 2012-12-03 16:02 ` Burton Samograd 2012-12-04 0:40 ` clang/emacs/ecb/semantic Richard Stallman 0 siblings, 1 reply; 46+ messages in thread From: Burton Samograd @ 2012-12-03 16:02 UTC (permalink / raw) To: emacs-devel Richard Stallman <rms@gnu.org> writes: > GCC can also produce debug information in Dwarf format, i.e. nonfree > debuggers can be used with GCC. > > Yes, of course, but you've changed the subject. The subject is this: > > > Part of the reason why clang/llvm weakens our commnity, compared with > > GCC, is that the clang front ends can feed their data to nonfree > > tools. Is not the production of executable binaries that run on nonfree operating systems the 'feeding of data to nonfree tools'? Where does one draw the line regarding the various forms of output of gcc/binutils? It seems AGPL covers the output from the program; if gcc was AGPL could it's output binaries only be used by GPL operating systems as well? -- Burton Samograd ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-03 16:02 ` clang/emacs/ecb/semantic Burton Samograd @ 2012-12-04 0:40 ` Richard Stallman 2012-12-04 14:05 ` clang/emacs/ecb/semantic Miguel Guedes 0 siblings, 1 reply; 46+ messages in thread From: Richard Stallman @ 2012-12-04 0:40 UTC (permalink / raw) To: Burton Samograd; +Cc: emacs-devel Is not the production of executable binaries that run on nonfree operating systems the 'feeding of data to nonfree tools'? It is a moot question, because you've taken my words out of context. The context in which I said them was that of using free front-ends with nonfree back-ends. You are focusing on the words I said, and ignoring what they meant. It seems AGPL covers the output from the program; No, the AGPL covers the case of giving people remote access to use a program. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-04 0:40 ` clang/emacs/ecb/semantic Richard Stallman @ 2012-12-04 14:05 ` Miguel Guedes 2012-12-05 11:49 ` clang/emacs/ecb/semantic Richard Stallman 2012-12-05 17:21 ` clang/emacs/ecb/semantic Paul Eggert 0 siblings, 2 replies; 46+ messages in thread From: Miguel Guedes @ 2012-12-04 14:05 UTC (permalink / raw) To: emacs-devel On 04/12/12 00:40, Richard Stallman wrote: > No, the AGPL covers the case of giving people remote access to use a > program. > Shouldn't an effort then be made to create a software license or tweak/upgrade an existing one to ensure free software cannot be used in ways that go against its very philosophy? I understand your wish to ensure free software remains free not matter what, but restricting the freedom of users of free software should not be the solution; in fact this sounds like a contradiction in itself. How can placing restrictions on what's supposed to be free ever be part of the solution? -- Miguel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-04 14:05 ` clang/emacs/ecb/semantic Miguel Guedes @ 2012-12-05 11:49 ` Richard Stallman 2012-12-05 17:21 ` clang/emacs/ecb/semantic Paul Eggert 1 sibling, 0 replies; 46+ messages in thread From: Richard Stallman @ 2012-12-05 11:49 UTC (permalink / raw) To: Miguel Guedes; +Cc: emacs-devel Shouldn't an effort then be made to create a software license or tweak/upgrade an existing one to ensure free software cannot be used in ways that go against its very philosophy? We're limited by copyright law and by 28 years of our own history, so it is not really an option. I understand your wish to ensure free software remains free not matter what, but restricting the freedom of users of free software should not be the solution; in fact this sounds like a contradiction in itself. Those words are a paradox, and a misrepresentation of what we do. Copyleft protects users' essential freedoms, for all users, by restricting acts by X that might deny essential freedoms to Y. See http://www.gnu.org/philosophy/copyleft.html for an explanation of copyleft. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-04 14:05 ` clang/emacs/ecb/semantic Miguel Guedes 2012-12-05 11:49 ` clang/emacs/ecb/semantic Richard Stallman @ 2012-12-05 17:21 ` Paul Eggert 1 sibling, 0 replies; 46+ messages in thread From: Paul Eggert @ 2012-12-05 17:21 UTC (permalink / raw) To: Miguel Guedes; +Cc: emacs-devel On 12/04/2012 06:05 AM, Miguel Guedes wrote: > I understand your wish to ensure free software remains > free not matter what, but restricting the freedom of users > of free software should not be the solution; in fact this > sounds like a contradiction in itself. We all declare for liberty; but in using the same word we do not mean the same thing. With some, the word liberty may mean for each man to do as he pleases with himself, and the product of his labor; while with others the same word may mean for some men to do as they please with other men and the product of other men's labor. Here are two, not only different, but incompatible things, called by the same name, liberty. And it follows that each of the things is by the respective parties called by two different and incompatible names---liberty and tyranny. The shepherd drives the wolf from the sheep's throat, for which the sheep thanks the shepherd as his liberator, while the wolf denounces him for the same act, as the destroyer of liberty, especially as the sheep was a black one. Plainly the sheep and the wolf are not agreed upon the definition of liberty. -- Abraham Lincoln, Address at Sanitary Fair, Baltimore, April 18, 1864. Above quote is transcribed from Lincoln's Complete Works (Nicolay JG, Hay J, eds.), New York, The Century Co. (1920), volume 2, page 513. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-02 9:04 ` clang/emacs/ecb/semantic Stephen J. Turnbull 2012-12-02 13:48 ` clang/emacs/ecb/semantic Helmut Eller @ 2012-12-03 0:02 ` Richard Stallman 1 sibling, 0 replies; 46+ messages in thread From: Richard Stallman @ 2012-12-03 0:02 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: pjb, emacs-devel > Part of the reason why clang/llvm weakens our commnity, compared > with GCC, is that the clang front ends can feed their data to > nonfree tools. Is that true, though? GCC can produce not only GIMPLE trees but also various forms of annotated RTL and dump them to files. What I am concerned about is _back ends_. I'm sorry if this was not sufficiently clear in that once sentence, but I did say it explicitly before. GCC RTL dumps are not sufficient to serve as input to a back end. You can't feed them into a nonfree back end. I have never heard of GIMPLE trees. I hope that they are not suitable for fueling a nonfree back end. Ie, people can write non-free assemblers that use the assembly output of GCC, people can write non-free compilers that target the gas assembly language, and so on, all in conformance with the letter of the GPL. That it is a different issue. The issue here is combining free front-ends with nonfree back-ends, and vice versa. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-02 4:15 ` clang/emacs/ecb/semantic Richard Stallman 2012-12-02 5:13 ` clang/emacs/ecb/semantic Daniel Colascione 2012-12-02 9:04 ` clang/emacs/ecb/semantic Stephen J. Turnbull @ 2012-12-02 13:59 ` Pascal J. Bourguignon 2012-12-03 0:02 ` clang/emacs/ecb/semantic Richard Stallman ` (2 more replies) 2 siblings, 3 replies; 46+ messages in thread From: Pascal J. Bourguignon @ 2012-12-02 13:59 UTC (permalink / raw) To: emacs-devel Richard Stallman <rms@gnu.org> writes: > Wouldn't have been better to accept gcc-xml and have gcc cover 99% of > the "market", rather than rejecting it, and eventually have gcc left > with only 10% of the mind share, and clang/llvm 90%? I'm afraid this > might end like that. > > We do not look at software users as a market. Our goal is something > more than popularity. What matters is users' freedom, and copyleft as > a weapon to defend it with. GCC vs LLVM is important mainly as an instance > of fighting for copyleft. > > Would a good alternative (for freedom) to be that free compilers (GPL) > provide the exact formal grammar they parse, so that tool builders could > use it to write compatible parsers to use in their tools? > > If "tool builders could use it to write compatible parsers to use in > their tools", is that good or is it bad? You seem to think it is > always good. I think it is good if the tools are free, and bad if the > tools are nonfree. Nonfree tools (like any nonfree programs) are an > injustice. > > Part of the reason why clang/llvm weakens our commnity, compared with > GCC, is that the clang front ends can feed their data to nonfree tools. Agreed. Nonetheless, this is a very delicate question. I can't see a significant difference between: - the features of LLVM which could be used by a programmer to write a closed source IDE, that would deprieve its users of some freedom, and - the use of emacs as an editor to write a diktat depriving some population of its freedom. Why did you write emacs if it can be used to write freedom depriving laws and degrees? </rethorical> The GPL license (contrarily to Apple's license) doesn't forbid the use of the licensed software to develop nuclear power plants or nuclear weapons. So GPL software can be used to build nuclear weapons that can deprive both users and non users of their life. If we must consider the (possible) ultimate goals of (some of) the users of our software, should we continue letting them have those freedoms? Wouldn't it be better to keep our software secret? Or may we be a little more optimistic, and think that some of those tools developed from the data exported from LLVM or gcc will be distributed under the GPL? It is indeed unfortunate that not more enterprises and programmers use the GPL, but chose instead mere Open Source licenses. But in a situation where there LLVM (OSS) that allows to write tools (could be proprietary, OSS or even GPL), it seems to be that if there was gcc (GPL) that allows to write the same tools (could be proprietary, OSS or even GPL), would still help promote GPL, since people using LLVM (OSS) will probably distribute their tools as OSS, while people using gcc (GPL) will probably distribute their tools in GPL, therefore providing users the choice between an OSS and a GPL, in addition to the potential proprietary tools that could be developed with either LLVM or gcc. I've got the impression that the existence and use of GPL software makes more to promote GPL. So providing GPL alternatives seems to me to be more important than trying to forbid proprietary or OSS solutions. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-02 13:59 ` clang/emacs/ecb/semantic Pascal J. Bourguignon @ 2012-12-03 0:02 ` Richard Stallman 2012-12-03 0:02 ` clang/emacs/ecb/semantic Richard Stallman 2012-12-03 0:02 ` clang/emacs/ecb/semantic Richard Stallman 2 siblings, 0 replies; 46+ messages in thread From: Richard Stallman @ 2012-12-03 0:02 UTC (permalink / raw) To: Pascal J. Bourguignon; +Cc: emacs-devel I can't see a significant difference between: - the features of LLVM which could be used by a programmer to write a closed source IDE, that would deprieve its users of some freedom, and - the use of emacs as an editor to write a diktat depriving some population of its freedom. I see the difference. I won't try to make you see it. (For anyone seriously interested in the issue of freedom to run a program, I refer you to the article http://www.gnu.org/philosophy/programs-must-not-limit-freedom.html. 'Nuff said.) If we must consider the (possible) ultimate goals of (some of) the users of our software, should we continue letting them have those freedoms? Wouldn't it be better to keep our software secret? That's a straw man argument. It consists of distorting and exaggerating what I said, producing something invalid that has nothing to do with the issue. I'm willing to explain GNU Project policies on this list, and show and why they lead to the decisions I have made, but arguing against them is misuse of the list. If you want to argue against our position, we have a list for such discussions: gnu-misc-discuss@gnu.org. Please take it there. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-02 13:59 ` clang/emacs/ecb/semantic Pascal J. Bourguignon 2012-12-03 0:02 ` clang/emacs/ecb/semantic Richard Stallman @ 2012-12-03 0:02 ` Richard Stallman 2012-12-03 0:02 ` clang/emacs/ecb/semantic Richard Stallman 2 siblings, 0 replies; 46+ messages in thread From: Richard Stallman @ 2012-12-03 0:02 UTC (permalink / raw) To: Pascal J. Bourguignon; +Cc: emacs-devel It is indeed unfortunate that not more enterprises and programmers use the GPL, but chose instead mere Open Source licenses. This seems to be an instance of a common misunderstanding. Many people think that "open source" (why capitalize it?) means "not the GPL. In fact, all free software licenses we know about are open source licenses. And all the commonly used open source licenses are free software licenses. See http://www.gnu.org/philosophy/open-source-misses-the-point.html for more explanation of the difference between free software and open source. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-12-02 13:59 ` clang/emacs/ecb/semantic Pascal J. Bourguignon 2012-12-03 0:02 ` clang/emacs/ecb/semantic Richard Stallman 2012-12-03 0:02 ` clang/emacs/ecb/semantic Richard Stallman @ 2012-12-03 0:02 ` Richard Stallman 2 siblings, 0 replies; 46+ messages in thread From: Richard Stallman @ 2012-12-03 0:02 UTC (permalink / raw) To: Pascal J. Bourguignon; +Cc: emacs-devel It is indeed unfortunate that not more enterprises and programmers use the GPL, but chose instead mere Open Source licenses. This seems to be an instance of a common misunderstanding. Many people think that "open source" (why capitalize it?) means "not the GPL. In fact, all free software licenses we know about are open source licenses. And all the commonly used open source licenses are free software licenses. See http://www.gnu.org/philosophy/open-source-misses-the-point.html for more explanation of the difference between free software and open source. Unfortunately, the rest of your message is pervasively based on this misunderstanding, so I can't follow it. I can only say that we never proposed to "prohibit" people from writing other compilers. It is not even a real issue. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-11-30 2:52 ` clang/emacs/ecb/semantic Richard Stallman 2012-11-30 6:34 ` clang/emacs/ecb/semantic Pascal J. Bourguignon @ 2012-11-30 6:46 ` Helmut Eller 1 sibling, 0 replies; 46+ messages in thread From: Helmut Eller @ 2012-11-30 6:46 UTC (permalink / raw) To: emacs-devel On Fri, Nov 30 2012, Richard Stallman wrote: > What exactly does gcc-xml do? It makes the parse tree of C/C++ programs available in XML format. The idea is that tools can do useful things with the XML data without needing to know the internals of GCC. Helmut ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: clang/emacs/ecb/semantic 2012-11-29 16:32 clang/emacs/ecb/semantic Ramneek Handa 2012-11-29 19:59 ` clang/emacs/ecb/semantic Dmitry Gutov @ 2012-11-30 2:51 ` Richard Stallman 1 sibling, 0 replies; 46+ messages in thread From: Richard Stallman @ 2012-11-30 2:51 UTC (permalink / raw) To: Ramneek Handa; +Cc: Emacs-devel Would anyone like to collaborate on an advanced c++ browsing capabilities in emacs using clang? If we are going to develop new Emacs facilities to work with a compiler, we should use GCC, not clang. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call ^ permalink raw reply [flat|nested] 46+ messages in thread
end of thread, other threads:[~2012-12-05 17:21 UTC | newest] Thread overview: 46+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-11-29 16:32 clang/emacs/ecb/semantic Ramneek Handa 2012-11-29 19:59 ` clang/emacs/ecb/semantic Dmitry Gutov 2012-11-29 20:27 ` clang/emacs/ecb/semantic David Engster 2012-11-29 20:38 ` clang/emacs/ecb/semantic Óscar Fuentes 2012-11-29 20:49 ` clang/emacs/ecb/semantic David Engster 2012-11-30 2:52 ` clang/emacs/ecb/semantic Richard Stallman 2012-11-30 6:34 ` clang/emacs/ecb/semantic Pascal J. Bourguignon 2012-11-30 15:15 ` clang/emacs/ecb/semantic David Engster 2012-11-30 15:25 ` clang/emacs/ecb/semantic ramneek 2012-12-01 4:44 ` clang/emacs/ecb/semantic Richard Stallman 2012-12-04 17:04 ` clang/emacs/ecb/semantic David Engster 2012-11-30 20:11 ` clang/emacs/ecb/semantic Richard Stallman 2012-11-30 21:02 ` clang/emacs/ecb/semantic Óscar Fuentes 2012-12-01 19:30 ` clang/emacs/ecb/semantic Richard Stallman 2012-12-01 19:30 ` clang/emacs/ecb/semantic Richard Stallman 2012-11-30 21:50 ` clang/emacs/ecb/semantic Pascal J. Bourguignon 2012-12-02 4:15 ` clang/emacs/ecb/semantic Richard Stallman 2012-12-02 5:13 ` clang/emacs/ecb/semantic Daniel Colascione 2012-12-03 0:02 ` clang/emacs/ecb/semantic Richard Stallman 2012-12-03 1:42 ` clang/emacs/ecb/semantic Daniel Colascione 2012-12-03 17:08 ` clang/emacs/ecb/semantic Eli Zaretskii 2012-12-03 17:21 ` clang/emacs/ecb/semantic Chong Yidong 2012-12-03 17:56 ` clang/emacs/ecb/semantic Eli Zaretskii 2012-12-03 18:14 ` clang/emacs/ecb/semantic Daniel Colascione 2012-12-03 18:50 ` clang/emacs/ecb/semantic Eli Zaretskii 2012-12-03 19:37 ` clang/emacs/ecb/semantic Stefan Monnier 2012-12-04 0:51 ` clang/emacs/ecb/semantic joakim 2012-12-04 2:17 ` clang/emacs/ecb/semantic Stefan Monnier 2012-12-04 1:04 ` clang/emacs/ecb/semantic joakim 2012-12-04 0:41 ` clang/emacs/ecb/semantic Richard Stallman 2012-12-03 19:34 ` clang/emacs/ecb/semantic Richard Stallman 2012-12-02 9:04 ` clang/emacs/ecb/semantic Stephen J. Turnbull 2012-12-02 13:48 ` clang/emacs/ecb/semantic Helmut Eller 2012-12-03 0:02 ` clang/emacs/ecb/semantic Richard Stallman 2012-12-03 16:02 ` clang/emacs/ecb/semantic Burton Samograd 2012-12-04 0:40 ` clang/emacs/ecb/semantic Richard Stallman 2012-12-04 14:05 ` clang/emacs/ecb/semantic Miguel Guedes 2012-12-05 11:49 ` clang/emacs/ecb/semantic Richard Stallman 2012-12-05 17:21 ` clang/emacs/ecb/semantic Paul Eggert 2012-12-03 0:02 ` clang/emacs/ecb/semantic Richard Stallman 2012-12-02 13:59 ` clang/emacs/ecb/semantic Pascal J. Bourguignon 2012-12-03 0:02 ` clang/emacs/ecb/semantic Richard Stallman 2012-12-03 0:02 ` clang/emacs/ecb/semantic Richard Stallman 2012-12-03 0:02 ` clang/emacs/ecb/semantic Richard Stallman 2012-11-30 6:46 ` clang/emacs/ecb/semantic Helmut Eller 2012-11-30 2:51 ` clang/emacs/ecb/semantic Richard Stallman
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.