[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