clang/emacs/ecb/semantic

clang/emacs/ecb/semantic

[Ramneek Handa]

[-- 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 --]

Re: clang/emacs/ecb/semantic

[Dmitry Gutov]

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

Re: clang/emacs/ecb/semantic

[David Engster]

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

Re: clang/emacs/ecb/semantic

[Óscar Fuentes]

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.

Re: clang/emacs/ecb/semantic

[David Engster]

Ó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

Re: clang/emacs/ecb/semantic

[Richard Stallman]

    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

Re: clang/emacs/ecb/semantic

[Pascal J. Bourguignon]

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 {}.

Re: clang/emacs/ecb/semantic

[David Engster]

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

Re: clang/emacs/ecb/semantic

[ramneek]

[-- 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 --]

Re: clang/emacs/ecb/semantic

[Richard Stallman]

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

Re: clang/emacs/ecb/semantic

[David Engster]

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

Re: clang/emacs/ecb/semantic

[Richard Stallman]

    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

Re: clang/emacs/ecb/semantic

[Óscar Fuentes]

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.

Re: clang/emacs/ecb/semantic

[Richard Stallman]

    > 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

Re: clang/emacs/ecb/semantic

[Richard Stallman]

    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

Re: clang/emacs/ecb/semantic

[Pascal J. Bourguignon]

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 {}.

Re: clang/emacs/ecb/semantic

[Richard Stallman]

    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

Re: clang/emacs/ecb/semantic

[Daniel Colascione]

[-- 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 --]

Re: clang/emacs/ecb/semantic

[Richard Stallman]

    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

Re: clang/emacs/ecb/semantic

[Daniel Colascione]

[-- 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 --]

Re: clang/emacs/ecb/semantic

[Eli Zaretskii]

> 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.

Re: clang/emacs/ecb/semantic

[Chong Yidong]

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.

Re: clang/emacs/ecb/semantic

[Eli Zaretskii]

> 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.

Re: clang/emacs/ecb/semantic

[Daniel Colascione]

[-- 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 --]

Re: clang/emacs/ecb/semantic

[Eli Zaretskii]

> 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.

Re: clang/emacs/ecb/semantic

[Stefan Monnier]

>> 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

Re: clang/emacs/ecb/semantic

[joakim]

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

Re: clang/emacs/ecb/semantic

[Stefan Monnier]

> 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

Re: clang/emacs/ecb/semantic

[joakim]

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

Re: clang/emacs/ecb/semantic

[Richard Stallman]

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

Re: clang/emacs/ecb/semantic

[Richard Stallman]

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

Re: clang/emacs/ecb/semantic

[Stephen J. Turnbull]

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?

Re: clang/emacs/ecb/semantic

[Helmut Eller]

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

Re: clang/emacs/ecb/semantic

[Richard Stallman]

    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

Re: clang/emacs/ecb/semantic

[Burton Samograd]

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

Re: clang/emacs/ecb/semantic

[Richard Stallman]

    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

Re: clang/emacs/ecb/semantic

[Miguel Guedes]

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

Re: clang/emacs/ecb/semantic

[Richard Stallman]

    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

Re: clang/emacs/ecb/semantic

[Paul Eggert]

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.

Re: clang/emacs/ecb/semantic

[Richard Stallman]

     > 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

Re: clang/emacs/ecb/semantic

[Pascal J. Bourguignon]

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 {}.

Re: clang/emacs/ecb/semantic

[Richard Stallman]

    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

Re: clang/emacs/ecb/semantic

[Richard Stallman]

    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

Re: clang/emacs/ecb/semantic

[Richard Stallman]

    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

Re: clang/emacs/ecb/semantic

[Helmut Eller]

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

Re: clang/emacs/ecb/semantic

[Richard Stallman]

    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