This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC + libJIT + Domain Specific Languages Concept Integration
- From: Joe Buck <Joe dot Buck at synopsys dot COM>
- To: Kirill Kononenko <kirill dot kononenko at gmail dot com>
- Cc: Mark Mitchell <mark at codesourcery dot com>, David Edelsohn <dje dot gcc at gmail dot com>, Diego Novillo <dnovillo at google dot com>, Ian Lance Taylor <iant at google dot com>, Dave Korn <dave dot korn dot cygwin at googlemail dot com>, Chris Lattner <clattner at apple dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 17 Apr 2009 12:34:37 -0700
- Subject: Re: GCC + libJIT + Domain Specific Languages Concept Integration
- References: <b21f6d8e0904171210v4f9abb3co6e7a952763da8c93@mail.gmail.com>
On Fri, Apr 17, 2009 at 12:10:27PM -0700, Kirill Kononenko wrote:
> One of the many options is in using the Common Intermediate Language
> and .NET to store portable programs. Does this sound like a good idea
> to you?
To the extent that the effect is to create a portable binary format,
I expect that the FSF would say "no, this is not a good idea at all!".
This is because they seem to promote the sharing and modification of
source code, not bytecodes for .Net or JVM. Others might disagree.
You might have better luck working with the Mono developers if you're
a .NET champion.
> You should understand that it is not the best way of handling of other
> people work with a way that in the very first email other people work
> is treated as to be not worthy. As you did with libJIT and my work.
You have responded to all criticism by taking it personally and replying
with a hostile attitude. That's tended to produce hostility in response.
There really aren't many successful free software projects where the
response to a newcomer proposing a different approach is to say, "Yes,
thank you! We will implement your ideas and commit your patches
instantly! It's beautiful just the way you presented it! Just make more
vague suggestions and we'll code it right up for you!" Rather, the burden
is on you as the proposer to convince skeptics, and, for difficult
changes, contribute actual patches, but be willing to change those patches
based on critiques from reviewers. Skepticism is key to quality control.