Way COOL!
C PATCH: new abi rtti support
(class_type_node, get_identifier ("type_info"), 1);
if (flag_honor_std)
pop_namespace ();
! if (!new_abi_rtti_p ())
! {
! tinfo_decl_id = get_identifier ("__tf");
! tinfo_decl_type = build_function_type
(build_reference_type
(build_qualified_type
(type_info_type_node, TYPE_QUAL_CONST)),
void_list_node);

Monikers in the Bonobo Component System. We recently reimplemented and fully revamped the the Moniker support in Bonobo. This work has opened a wide range of possibilities: from unifying the object naming space, to provide better integration in the system. Note: on this document I have ommited exception environments handling for the sake of explaining the technology.

Bonobo Components: Architecture and Application Bonobo is the component technology that is part of the GNOME desktop environment. This paper discusses the architecture of Bonobo, and the way it can be used to write software. Also, it takes a look at the current state of Bonobo, and some of the future developments.

[Mono-list] GCC front-end? > On the roadmap, it seems to imply that y'all are working on a
> completely new "JIT" compiler for the CLI. I'm curious about why this
> is a better plan than writing a Gcc front-end for CLI bytecode.

I've been seriously thinking about doing that for quite a while now; since
long before Mono was announced. Technically I think it is a very good idea.

The main drawback, from my perspective, is that doing so would increase
the acceptance of .NET, which would be good for Microsoft, which would
increase world-wide income inequity, and concentrate too much power in
the hands of too few, and that would be bad.

I remember when I first heard of C ; it was from Bell Labs, same place
as C, and it had some nice technical improvements to C. But it was a
new language, and it didn't have the same degree of vendor support that
C had. Was it really worth writing code in this new language?
I first became convinced that C would become popular when I heard
that there was a GNU C implementation. The existence of a free
software implementation can be quite important to people's decisions
as to whether or not to adopt a particular piece of technology.

[Mono-list] GCC front-end? > On the roadmap, it seems to imply that y'all are working on a
> completely new "JIT" compiler for the CLI. I'm curious about why this
> is a better plan than writing a Gcc front-end for CLI bytecode.

I've been seriously thinking about doing that for quite a while now; since
long before Mono was announced. Technically I think it is a very good idea.

The main drawback, from my perspective, is that doing so would increase
the acceptance of .NET, which would be good for Microsoft, which would
increase world-wide income inequity, and concentrate too much power in
the hands of too few, and that would be bad.

I remember when I first heard of C ; it was from Bell Labs, same place
as C, and it had some nice technical improvements to C. But it was a
new language, and it didn't have the same degree of vendor support that
C had. Was it really worth writing code in this new language?
I first became convinced that C would become popular when I heard
that there was a GNU C implementation. The existence of a free
software implementation can be quite important to people's decisions
as to whether or not to adopt a particular piece of technology.

Question 4: Should someone work on a GCC front-end to C#?
I would love if someone does, and we would love to help anyone that takes on that task, but we do not have the time or expertise to build a C# compiler with the GCC engine. I find it a lot more fun personally to work on C# on a C# compiler, which has an intrinsic beauty.
We can provide help and assistance to anyone who would like to work on this task.
Question 5: Should someone make a GCC backend that will generate CIL images?
I would love to see a backend to GCC that generates CIL images. It would provide a ton of free compilers that would generate CIL code. This is something that people would want to look into anyways for Windows interoperation in the future.
Again, we would love to provide help and assistance to anyone interested in working in such a project.
Question 6: What about making a front-end to GCC that takes CIL images and generates native code?
I would love to see this, specially since GCC supports this same feature for Java Byte Codes. You could use the metadata library from Mono to read the byte codes (ie, this would be your "front-end") and generate the trees that get passed to the optimizer.
Ideally our implementation of the CLI will be available as a shared library that could be linked with your application as its runtime support.
Again, we would love to provide help and assistance to anyone interested in working2

Daniel Berlin - Re: libtool (was Re: [patch] releases.html) Zack Weinberg" writes:

> Yes, libbackend.so might be nice just to reduce disk consumption.
> (Didn't HJ have patches for this a long, long, time ago?) Wouldn't
> it cause arguments about opening loopholes for non-free front ends,
> though?

Can we get over this yet?

SGI already did it with the backend. They go directly from trees to
WHIRL, using gcc/g as a front end.

If someone wants to do it with the frontend, we aren't making it that
much easier by using a shared library.

Would any respectable company really want to try to make a compiler
when the legal status of doing a non-free frontend is pretty shaky?

And are we going to be able to really stop unrespectable companies
from doing it anyway?

Why should we not be able to further the usefulness and usability of a
free software project because someone, somewhere, might find it
slightly easier to integrate into something that may make it illegal,
or not illegal, for them to redistribute it.

--Dan

Daniel Berlin - Re: libtool (was Re: [patch] releases.html) Zack Weinberg" writes:

> Yes, libbackend.so might be nice just to reduce disk consumption.
> (Didn't HJ have patches for this a long, long, time ago?) Wouldn't
> it cause arguments about opening loopholes for non-free front ends,
> though?

Can we get over this yet?

SGI already did it with the backend. They go directly from trees to
WHIRL, using gcc/g as a front end.

If someone wants to do it with the frontend, we aren't making it that
much easier by using a shared library.

Would any respectable company really want to try to make a compiler
when the legal status of doing a non-free frontend is pretty shaky?

And are we going to be able to really stop unrespectable companies
from doing it anyway?

Why should we not be able to further the usefulness and usability of a
free software project because someone, somewhere, might find it
slightly easier to integrate into something that may make it illegal,
or not illegal, for them to redistribute it.

--Dan

Re: Converting the gcc backend to a library?
To: gcc at gcc dot gnu dot org
Subject: Re: Converting the gcc backend to a library?
From: Richard Stallman
Date: Mon, 17 Jan 2000 19:51:25 -0700 (MST)
Reply-to: rms at gnu dot org



Companies often try to make software non-free, and some would write
non-free add-ons to GCC if we let them. The reason we have free C
and Objective C support is because the companies which wrote these
front ends had no *feasible* way to use them without making them part
of GCC, where the GPL required them to be free. It is vital that we
preserve this situation.

Anything that makes it easier to use GCC back ends without GCC front
ends--or simply brings GCC a big step closer to a form that would make
such usage easy--would endanger our leverage for causing new front
ends to be free.

Because of this, the GNU Project will in all probability not install
such changes, should they be available. This statement reflects a
firm conclusion based on a decade of thought.

I ask anyone who would like to make such changes in GCC to please
contact me privately. I would like to talk with you about the ideas
you are interested in working on, to look at the magnitude of their
potential benefits, and consider other possible ways of achieving
them. Please think about the importance of future free front ends,

3.04 Why don't you use the LGPL for libraries?

Using GPL plus linking exception has several advantages. One is
that this makes it more convenient to reuse parts of the code
(possibly with modification) in GPL-licensed files.

Also, you can exclude native methods from the linking exception.
This is done in the license on the C# library, "pnetlib", which
is distributed under these terms:

The source code for the library is distributed under the
terms of the GNU General Public License, with the following
exception: if you link this library against your own
program, then you do not need to release the source code
for that program. However, any changes that you make to the
library itself, or to any native methods upon which the
library relies, must be re-distributed in accordance with
the terms of the GPL.

We call this the "GPL plus linking exception", which is also
used by the GNU Classpath project.

We aren't trying to restrict the use of the library by any kind of
commercial entities. However, a proprietary software company could
produce their own proprietary runtime engine that has
"enhanced" native method support of some kind. Under the terms
of the LGPL, they would be obligated to release the
declaration of the native method in

The DotGNU FAQ Licensing issues
~~~~~~~~~~~~~~~~

3.00 What software licenses does DotGNU use?

All official software development projects of the DotGNU
meta-project use the GNU General Public License (GNU GPL).
For Libraries which are intended to be linked with third-party
programs that may not have a GPL-compatible license, as a special
exception such linking is allowed.


3.01 Does the linking exception carry over to derivative works?

If you create a derivative work of pnetlib or any library which is
licensed as "GPL plus linking exception", then it is up to you
whether want the linking exception to carry over to your derivative
work. If you leave the exception in the text, then it applies to
your version.


3.02 What about programs which access each other through network
protocols. Is that a form of linking?

No. A GPL'd program can use any kind of webservice regardless
of how the webservice software is licensed, and GPL'd webservice
software can be used by any program regardless of that program's
license.