[Mono-dev] greetings (new here)... a few things...
BGB
cr88192 at hotmail.com
Mon Jan 5 20:11:22 EST 2009
sorry if I have not looked over the mono codebase enough to really know all
this for myself.
how much does mono depend on the specifics of its existing CLI / JIT
implementation?...
how much does it depend on Boehm and like?...
this is in the context of both technical, and in terms of project politics
(what is the "essence" of the project and so on).
for example, would it be "compatible" with the project for someone to
substitute in their own implementation of EMCA-335 and like, and have much
expectation that everything on top of this will continue working (for
example, as far as all the libraries are concerned, the CLI implementation
is a "black box"), or is it more the case that there is some important
dependency on the internals of the CLI implementation?
(I wouldn't think there would be "that" much dependency, but I could easily
be wrong...).
more so, if one were to swap out for a different CLI implementation
(assuming it is within reasonable technical limitations), would it still be
classified as "the same project", or as "some other project making use of
the libraries and tools".
well, ok, a little context:
I have my own framework, and "may" do an implementation of the CLI as well
(provided time and direction), but if it is possible to do this within the
confines of being "cooperative" with the project, this would be good.
my project also does not use Boehm, rather, I do my own GC. it is currently
conservative, but I have considered the possibility of later implementing a
"hybrid" conservative/precise GC (preciseness would be added as a set of
extensions and alterations to the existing GC, and would be intended mostly
to allow improving performance and reducing garbage creation).
I am also not all that likely to re-use the existing CLI engine, as
personally I find the code... displeasing...
FWIW, all my stuff is currently generally being developed under the LGPL.
or such...
More information about the Mono-devel-list
mailing list