On Nov 19, 2007 4:50 AM, Jonathan Chayce Dickinson <[EMAIL PROTECTED]>
wrote:
> Hey Bruce,
>
> Can you put those stubs up somewhere? I will be happy to start coding them
> (the ones that we don't need to discuss ATM at least).
>
> Regards,
> Jonathan Chayce Dickinson
>
Well, you can build and run time RuntimeCop tool, which is in
/trunk/Tools/RuntimeCop . It basically just outputs the list of all the
stubs. Under Windows, you can obviously use the stream redirection symbol
">>" to put it in a text file for easy scrolling.
The problem is, I'm not sure how to translate a Mono.Cecil's
ParameterDefinition into something I can print back out as a C# paramater
definition - and its an issue, because the signatures have to be exactly
correct. (We don't want to have to re-gen after we've filled in the stubs,
because that will be too much maintenance.)
The specific issue I'm having is, delineating the difference between by-ref,
(in C#, "ref " prefix on parameter definition), and pointers (obviously, the
"*" suffix on the type in the parameter definition.) I can't figure out the
difference, (if any), in the eyes of Mono.Cecil.
While I think the AOT doesn't have to care, I know the C# compiler does. For
one thing, byref is 'safe', pointers are not, (and neither are CLS
Compliant, but thats neither here nor there.) I really need DarxKies' input
on how the AOT handles these things, (and how we want it to in the future),
before we can start fleshing out any code auto-generated by my tool.
And it may be a moot point. Byref parameters, and pointers as parameters,
may in fact AOT/JIT to be the exact same thing - but I honestly have no
idea. And it also might be a moot point simply because we don't compile
our normal .NET libraries against these stubs, because the AOT/JIT will
match them. But if there is a binary difference, we need to figure it out
now.
Once I do commit the stubs, I will probably put the whole of them in
/Kernel/MonoInterop/ , and as we decide things need to be moved into
/Kernel/Core/Runtime/ , we'll move them over. I'm not sure yet how we'll get
the AOT to track down these methods, but I can't imagine it being a road
block.
> -Bruce / illuminus
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
