BCL skeleton

Developer
Feb 4, 2009 at 4:11 AM
I know Phil, a while ago, started on a skeleton BCL. I forget why, at
the time. None of the other projects seem to depend on it. And Visual
Studio's IntelliSense has this horrid knack for parsing that BCL's
System namespace, even when the solution doesn't depend on it. Unload
that project, and suddenly all of your base types go away. Load it back
in, and because not all methods are stubbed out, you get equal numbers
of squiggly red lines. Makes for a pretty Christmas scene on my screen,
as I use both IntelliSense and Resharper (which uses green squigglies)
extensively. :)

Can we either remove this from the solution, or should I go ahead and
stub out all the other BCL classes and methods, according to ECMA-335
Partition IV Kernel Profile?

--S
Coordinator
Feb 4, 2009 at 4:17 PM
Can you do both?
Developer
Feb 4, 2009 at 6:01 PM
Err... I guess. So you want the BCL to be in its own solution file? If so, it'd probably be a good idea to extend that line of thought to other "separate" MOSA projects, like Pictor, some of the standalone helper tools, etc.

tgiphil wrote:

From: tgiphil

Can you do both?

Developer
Feb 4, 2009 at 7:59 PM
So uh, where is this stubbing going to come from? Obviously, my suggestion is going to be Mono... Compatible license, and some trivial compile-time method and class patching. (Granted, we have to implement whatever we are going to be patching it with.)

Thoughts?




Developer
Feb 4, 2009 at 8:55 PM
I meant stubbing in the sense of simply creating the empty methods for now, from the signature definitions in the ECMA-335 spec, simply to shut Visual Studio and similar IDEs up. Actual content for those methods will be added later, agreed likely from Mono. As a parallel, this is how jNode maintains their own tree of the Java standard class libraries. They have their own tree, which is largely a mirror of icedTea and Classpath, with their own changes as necessary.

Hope that clears up what I meant for stubbing. I don't mean stubbing in the sense of a compiler override, like our Native.cs and intrinsics. I meant stubbing in the sense of create-empty-methods-to-be-filled-in-later.

--S

illuminus86 wrote:

From: illuminus86

So uh, where is this stubbing going to come from? Obviously, my suggestion is going to be Mono... Compatible license, and some trivial compile-time method and class patching. (Granted, we have to implement whatever we are going to be patching it with.)

Thoughts?





Developer
Feb 4, 2009 at 9:13 PM
Oh, I know what you meant. And I'm glad we've got the same outlook on using Mono. (/bigsigh)

I just didn't know *how* you were planning on stubbing those empty methods. (Are they provided somewhere? Are you autogenerating by replicating the publicly exposed Mono/M$ BCL, etc.) Just thought it might be *easier* to put something like Mono in place than by manually typing in stubs for the entire BCL...
Developer
Feb 4, 2009 at 10:11 PM
ECMA provides an XML file for download with the signatures and documentation for the BCL classes. Creation of a program to stub out c# source files shouldn't be a problem.

illuminus86 wrote:

From: illuminus86

Oh, I know what you meant. And I'm glad we've got the same outlook on using Mono. (/bigsigh)

I just didn't know *how* you were planning on stubbing those empty methods. (Are they provided somewhere? Are you autogenerating by replicating the publicly exposed Mono/M$ BCL, etc.) Just thought it might be *easier* to put something like Mono in place than by manually typing in stubs for the entire BCL...

Coordinator
Feb 5, 2009 at 3:04 AM
I think we all agree that we will use the Mono's BCL classes. However, in the short-term I think we might need mini-scaled down BCL to actually get off MOSA supported OS off the ground. It'll also help us develop the API between the Kernel and BCL.
Coordinator
Feb 5, 2009 at 3:19 AM
Someone already wrote the program to parse the CLILibraryTypes.xml file:

http://www.codeplex.com/Cosmos/Thread/View.aspx?ThreadId=33479

I'll contact the author.