--> t3rmin4t0r (address@hidden) has joined #dotgnu
--- Topic for #dotgnu is <S11001001:#dotgnu> things are heating up on [bizplan] :)
--- Topic for #dotgnu set by ChanServ at Tue Jan 29 19:37:03
<t3rmin4t0r> hi rhysw
<t3rmin4t0r> sorry I'm late
--- You have new mail (3 messages, 9200 bytes total).
<rhysw> hello 
* t3rmin4t0r had a power failure
<rhysw> So, what's on your mind?
<t3rmin4t0r> Ok, now how do I get on to implementing the native file methods
<rhysw> rightio...
<t3rmin4t0r> after doing the Unxi API emulations....ILFileOpen(),ILFileRead()
<t3rmin4t0r> stuff, where should I go ?
<rhysw> StepYou need to create a native method in the engine ...
<rhysw> e.g. "lib_file.c"
<t3rmin4t0r> yep lib_file.c 
--- You have new mail (4 messages, 13341 bytes total).
<t3rmin4t0r> Ok, I read the Platform.FileMethods
<rhysw> first, create a table of method mappings from the names in "Platform.FileMethods" to the actual functions that implement each.  Look in "lib_platform.c" at "DirMethods" for an example of this.
<rhysw> IL_METHOD_BEGIN(_ILPlatformDirMethods)
<rhysw>     IL_METHOD("GetPathInfo", "()vPlatform.PathInfo;",
<rhysw>               Platform_DirMethods_GetPathInfo)
<rhysw>     IL_METHOD("GetSystemDirectory", "()oSystem.String;",
<rhysw>               Platform_DirMethods_GetSystemDirectory)
<rhysw> IL_METHOD_END
<rhysw> That's the DirMethods version.  You need to create something similar for "FileMethods".
<t3rmin4t0r> Ok, the export map !
<rhysw> Yup - the args are "name", "signature", and "function".  The signature uses a Java-like string encoding, which is explained in "lookup.c"
<t3rmin4t0r> Yes, 
<rhysw> I'll work through a simple example with you: "FileMethods.Close".
<t3rmin4t0r> that's better
<rhysw> Here's the table:
<rhysw> IL_METHOD_BEGIN(_ILPlatformFileMethods)
<rhysw>     IL_METHOD("Close", "(j)Z",
<rhysw>               Platform_FileMethods_Close)
<rhysw> IL_METHOD_END
<rhysw> The "j" is the "IntPtr" parameter (it's an IL thing).  The Z is the "bool" result type.
<t3rmin4t0r> yeah I've the lookup.c up here 
<t3rmin4t0r> seems like easy to me..
<rhysw> should be - I designed it around Java's syntax because it was so easy.
<t3rmin4t0r> yeah Ljava/lang/String; !
<t3rmin4t0r> looks like oSystem.String
<rhysw> yeah - I took out the ugly / syntax from Java, because it was silly. :)
<rhysw> Besides, IL uses "/" as a separator for nested types.
<rhysw> Anyway, the code for Close:
<rhysw> static ILBool Platform_FileMethods_Close
<rhysw>         (ILExecThread *thread, ILNativeInt handle)
<rhysw> {
<rhysw>     return ILFileClose(handle);
<rhysw> }
<rhysw> TA DA!
<rhysw> (actually, there is one more step)
<t3rmin4t0r> But one "small" prob, does Win32 use Int for file pointers ?
<rhysw> The "IntPtr" is big enough to hold an "integer the same size as a pointer", and Windows uses pointers as handles.
<t3rmin4t0r> So what about ILNativeInt ?
<rhysw> Now, to hook the method through to the rest of the engine, we need to go into "internal.c"
<rhysw> (ILNativeInt is the engine type that corresponds to "IntPtr" - same size).
<rhysw> In "internal.c", we declare the table as:
<rhysw> extern ILMethodTableEntry const _ILPlatformFileMethods;
<rhysw> And then add it to the "internalClassTable" with:
<rhysw>     {"FileMethods", "Platform",     &_ILPlatformFileMethods},
<rhysw> Note: the table must be sorted into ascending order of class name (ignoring the namespace), so insert it in the right position.
<rhysw> That's basically it.
<rhysw> Rinse and repeat for all the other internalcall methods.
<t3rmin4t0r> Ok 
<t3rmin4t0r> but I cannot compile pnetlib, to test this :-(
<rhysw> The FileMethods stuff should already be hooked through from "System.IO.FileStream", which is part of the precompiled library.  Adding new internalcall's will be a problem.
<t3rmin4t0r> I think your mscorlib doesn't have System.IO ?
--> arun (address@hidden) has joined #dotgnu
<rhysw> should be there - "ilfind" picked up "FileStream" just now.
<rhysw> hi arun
<arun> hi rhys how r u
<rhysw> doing ok - taking it easy for a few days.
<arun> ya, thats good, 
<arun> rhys what is the status of hacker docs planed ?
<rhysw> pnetlib is done, the intro on pnet is done, and the rest is up in the brain waiting to be typed up
<arun> i think you should put the pnetlib part online; it can help get more people for contributing
<t3rmin4t0r> rhysw: how can I test my code without recompiling Platform.FileMethods
<t3rmin4t0r> into mscorlib.dll
* t3rmin4t0r can see no way out
<rhysw> err ... have you added more methods to "FileMethods", or are you just implementing what is already declared?
<rhysw> The C code I explained earlier is in the engine only - it doesn't need pnetlib to be recompiled unless you add a new InternalCall.
<rhysw> arun: the pnetlib one is in the source.  Isn't that enough?
<t3rmin4t0r> Ok, so where are the stub internalcalls declared ?
<t3rmin4t0r> (the dummy calls)
<rhysw> stub internalcalls?
<rhysw> I still don't get what you mean.
<t3rmin4t0r> yeah the [MethodImpl(MethodImplOptions.InternalCall)]
<t3rmin4t0r>         extern public static bool CheckHandleAccess
<t3rmin4t0r>                         (IntPtr handle, FileAccess access);
<t3rmin4t0r> method's InternalCall
<rhysw> The C code I gave you earlier _is_ the implementation of the InternalCall.  Adding it to the table in "internal.c" makes sure that everything gets hooked through.
<t3rmin4t0r> So if an internal call is *not* implemented, it gets ignored ?
<rhysw> "MissingMethodException"
<t3rmin4t0r> Ok, I get it. Unless I call the method the .dll works fine
<rhysw> absolutely - on-demand loading of InternalCall methods.
<t3rmin4t0r> Wow !
<rhysw> Of course - it probably would be useful for someone to write a Perl/Python script to grep the code to make sure that all InternalCall's in pnetlib have a corresponding implementation in pnet.
<rhysw> Perhaps something extra for the "class status" script that says "this internalcall not implemented in the engine".
<t3rmin4t0r> seems possible 
<t3rmin4t0r> run ctags on lib_*.c and ... parse using python
<rhysw> Something like that - it would probably be easier to grep for "IL_METHOD".
<t3rmin4t0r> ok, the export table ?
<t3rmin4t0r> I'll look into it
<rhysw> yup
<rhysw> thanx
<rhysw> On to other matters ... I'm thinking of opening up the CVS server for more people to submit code.  It would improve the turn-around on patches.  What do you think?
<t3rmin4t0r> I don't have much experience with CVS, I prefer patches ;-)
<t3rmin4t0r> less chance of breaking the build
<t3rmin4t0r> by some foolish kid (/me) 
<rhysw> You'd only do that once - after I'd sent Bubba around to deal with you, you'll never do it again. :)
<t3rmin4t0r> Anyway, I think it is a good idea to announce about the 
<t3rmin4t0r> internal call stuff... most people would jump at such an
<t3rmin4t0r> idea of extensibility
<rhysw> Since you're inside there at the moment, how about drafting a "how to add an InternalCall" section for "engine/HACKING" and I'll put it in and then announce it.
<t3rmin4t0r> I'm game !