Sander van Rossen wrote:
> Oops, completely missed the meeting... can anyone post the log of the
> meeting?
>
>
> On Dec 9, 2007 3:45 AM, Bruce Markham <[EMAIL PROTECTED]> wrote:
> > From reading the log, and stopping by to say my own 2 cents, I
> > gather that the meeting was a good success!
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: Check out the new SourceForge.net
> Marketplace. It's the best place to buy or sell services for just
> about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________ SharpOS-Developers
> mailing list SharpOS-Developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sharpos-developers
>
I'm not sure if it's complete.
(07:13:59 PM) Broudy [EMAIL PROTECTED] entered the room.
(07:18:58 PM) {DarxKies} [EMAIL PROTECTED] entered the room.
(07:20:24 PM) illuminus: [DarxKies]/{DarxKies} : I committed a couple
more string tests to emulate a bug I am encountering with the kernel,
except they pass fine when run in the Tests Kernel and NUnit. But not
the original ones that I put in the kernel, so I committed all of them,
and I need you to take a look when you get the chance.
(07:21:32 PM) {DarxKies}: sure just tell me where the bug in the trunk
kernel occurs
(07:21:35 PM) {DarxKies}: and i will take a look at it
(07:22:01 PM) illuminus: Foundation.ByteString.__RunTests() will show
you what I'm dealing with - I'm comparing "US"[1] to "SK"[0] (more or
less), and its failing.
(07:22:31 PM) {DarxKies}: ok i will take a look at it
(07:23:20 PM) illuminus: I first noticed this issue when using the
version of xfury's ByteString.Compare() that compares a byte string to
one of these specially embedded string const, and it kept failing.
(07:24:27 PM) illuminus: Which means CString8->IndexOf() fails too...
(07:27:26 PM) illuminus: {DarxKies}: thx
(07:27:27 PM) {DarxKies}: great more stuff to fix
(07:27:30 PM) {DarxKies}: :D
(07:27:46 PM) illuminus: Is it a bug? Or a mistake of mine?
(07:28:04 PM) {DarxKies}: i am not sure yet as i didn't get to get a
look at it
(07:28:11 PM) {DarxKies}: but i will do it very soon
(07:28:13 PM) illuminus: oh, I misunderstood you then
(07:28:27 PM) ***illuminus points pretend gun at self
(07:28:32 PM) illuminus: "Don't make me do it!"
(07:28:59 PM) illuminus: Oh well folks, I'll be back, in spirit if
nothing else, as soon as I can...
(07:29:05 PM) {DarxKies}: hahahahaha
(07:29:23 PM) illuminus left the room (quit: "Leaving.").
(07:37:28 PM) [DarxKies] left the room (quit: Read error: 110
(Connection timed out)).
(08:36:34 PM) {DarxKies}: so when should we start the meeting?
(08:36:36 PM) {DarxKies}: in 30 mins?
(08:36:38 PM) {DarxKies}: is that ok?
(08:38:14 PM) himek: I'm here all the time..
(08:38:50 PM) {DarxKies}: me too i just hoped the others will come too :D
(08:48:38 PM) himek: I'm very happy that AOT compiles the kernel out of
the box with mono and vmware :)
(08:49:43 PM) {DarxKies}: xfury too for sure ;)
(09:00:14 PM) {DarxKies}: i guess it's time for the meeting?
(09:01:34 PM) [EMAIL PROTECTED]: {DarxKies} has changed
the topic to: SharpOS Project | http://sharpos.sf.net | Meeting in
Progress :D
(09:01:34 PM) {DarxKies}: hi everybody
(09:01:34 PM) {DarxKies} is now known as DarxKies
(09:02:33 PM) DarxKies: Illuminus moved yesterday the new AOT to the
trunk so please give it a try and report any bugs, even better please
try to write testcases
(09:04:05 PM) DarxKies: I am trying to implement the runtime type
information (MethodTable + EEClass from .NET) and the question is how
much from the .NET reflection functionality will we need for the kernel
internal classes
(09:04:50 PM) DarxKies: I thought of perhaps writing the Metadata of the
kernel + korlib together to the resulting binary
(09:05:12 PM) DarxKies: and then using the cecil to decode it at runtime
(09:05:56 PM) DarxKies: the problem with that approach is that cecil
uses classes and that means it needs object support and that leads to
the chicken & egg problem
(09:11:15 PM) DarxKies: another way to solve it would be to encode the
type information into the data section of the binary like it would be an
instance (actually lots of) on the heap
(09:12:01 PM) DarxKies: just like the way the .net strings are encoded
right now instead of allocating an object on the heap
(09:12:27 PM) DarxKies: what do you guys think?
(09:12:33 PM) DarxKies: is there another way?
(09:12:35 PM) DarxKies: any ideas?
(09:17:16 PM) xfury: oy
(09:17:23 PM) xfury: i seem to have made it?
(09:18:03 PM) DarxKies: it looks like that :D
(09:18:18 PM) xfury: coool
(09:19:38 PM) xfury: it seems that the second option woujld be easier
(09:21:01 PM) DarxKies: the downside of that option is that it will be a
bit hard to implement the full reflection
(09:21:43 PM) DarxKies: and then we have a class (MethodTable/EEClass)
that holds all the infos to that class, fields, methods, constructors,
properties
(09:23:15 PM) xfury: well we dont have to implement it all at once do we?
(09:23:18 PM) DarxKies: and encoding the data for a class holding all
that data so that it works at runtime like it was an object on the heap
will be a bit tricky and error prone
(09:23:47 PM) DarxKies: i guess no only piece by piece
(09:23:51 PM) xfury: why does it have to be in classes?
(09:24:03 PM) xfury: simple structures would fit the purpose, using
static pointers and all
(09:24:18 PM) DarxKies: but the most important question is only, how
much of the reflection will we need for the structures in the kernel
(09:24:42 PM) xfury: i would imagine anything that can be used by EDC
(09:25:24 PM) xfury: and, do we try to draw a line somewhere or have EDC
capable of accessing all EIC interfaces?
(09:25:26 PM) DarxKies: struct will do it as well only that sooner or
later we will need that data on the heap too for the loaded
assemblies/modules
(09:25:38 PM) DarxKies: and that means having to box the valuetypes (struct)
(09:26:06 PM) xfury: yeah
(09:26:22 PM) xfury: how do we plan to go about with boxing?
(09:27:55 PM) DarxKies: boxing is actually allocating an object on the heap
(09:28:08 PM) DarxKies: copying the struct data to that object
(09:28:22 PM) DarxKies: and setting the typehandle so that it knows that
it is related to that struct
(09:28:24 PM) DarxKies: that is all
(09:28:30 PM) xfury: yrsh
(09:28:31 PM) xfury: yeah*
(09:29:29 PM) DarxKies: so i think if we want all the type information
of the kernel and the loaded files to work side by side we need to
implement it as classes
(09:29:52 PM) DarxKies: and make sure that the encoded data and the
class fields mach
(09:30:26 PM) DarxKies: an advantage of that option is that the kernel
will be up and running very fast as well
(09:30:39 PM) xfury: huh-- how so?
(09:30:47 PM) xfury: you mean speed to boot?
(09:30:52 PM) DarxKies: yes
(09:31:07 PM) DarxKies: after setting up the memory manager
(09:31:32 PM) DarxKies: real objects can be created directly on the heap
(09:32:13 PM) DarxKies: and the type handle of an object is actually not
a pointer to an object on the heap
(09:33:01 PM) DarxKies: but to the memory that is the encoded in the
kernel binary and mimics an object on the heap
(09:33:47 PM) xfury: so, it would use all the class front end stuff, but
actually be stored statically
(09:34:03 PM) DarxKies: right
(09:34:34 PM) xfury: so, would that mean that to get this special
reference we would need a new API, or do we construct the AOT to
recognize new Type()
(09:34:49 PM) DarxKies: somehow like a serialized instance
(09:35:10 PM) xfury: as in the .NET serialize apis?
(09:35:17 PM) DarxKies: yes
(09:35:41 PM) DarxKies: about the new API
(09:35:45 PM) xfury: oooh now thats a plan worthy of the great DarxKies :-P
(09:36:11 PM) DarxKies: that brings us to the interface that a kernel
should have in order to be generated
(09:36:12 PM) xfury: itd be badass
(09:36:13 PM) DarxKies: :D
(09:36:33 PM) DarxKies: i thought about what you said like IRuntimeHelper
(09:36:44 PM) DarxKies: IKernel (for the bootentry method)
(09:36:59 PM) DarxKies: and IRuntimeHelper for all the AOT related stuff
(09:37:13 PM) xfury: that would allow us to implement the runtime stuff
in a different class
(09:37:20 PM) xfury: definitely avoid partial classes too
(09:37:21 PM) DarxKies: i agree
(09:39:06 PM) xfury: and what for the new stuff in IRuntimeHelper then
(09:39:29 PM) xfury: how do we divide between the AOT's work and natural
kernel implementation of reflection
(09:39:57 PM) xfury: and heap interface we already can guess of course
(09:41:07 PM) DarxKies: what would be an appropriate name for the class
holding the type information
(09:41:48 PM) DarxKies: i guess it would work like this
(09:42:14 PM) DarxKies: the AOT knows the TypeHandle of every type and
when a newobj is found in the CIL
(09:42:43 PM) DarxKies: then it generates a call to the kernel class
that implements the IRuntimeHelper and it passes as parameter the TypeHandle
(09:43:25 PM) DarxKies: and that method is then responsible to allocate
the object on the heap using the type information that is encoded in the
kernel binary
(09:43:39 PM) DarxKies: hmmm shit the whole stuff starts to sound more
and more confusing
(09:43:50 PM) DarxKies: hopefully it is still understandable :D
(09:45:01 PM) DarxKies: another method that should be in IRuntimeHelper
is the one that can gets an object and is supposed to call a virtual
method and that can be done only at runtime
(09:46:45 PM) xfury: i understand
(09:46:57 PM) xfury: am making some ramen
(09:47:14 PM) xfury: but yeah
(09:47:33 PM) xfury: but then to read the class data the IKernelHelper
class must be EDC?
(09:58:46 PM) illuminus|log is now known as illuminus
(09:58:48 PM) DarxKies: hmmm I think yes
(09:58:49 PM) xfury: wb
(09:58:53 PM) illuminus: thx
(09:59:05 PM) illuminus: partial classes shouldn't be a problem, since
they are just a C# compiler issue
(09:59:36 PM) DarxKies: true
(09:59:39 PM) xfury: i meant avoiding having the kernel as a partial class
(09:59:44 PM) xfury: just cuz its messy
(10:00:02 PM) illuminus: so IKernel and IRuntimeHelper, the interfaces
themselves, should probably be defined in AOT.Core
(10:00:21 PM) xfury: aye
(10:00:22 PM) DarxKies: yes just like the x86 stubs
(10:00:46 PM) DarxKies: i guess the classes that hold the type
information too?
(10:00:54 PM) illuminus: In my runtime experimentation, I've been
tagging mono corlib stub implementors with a "VesICallAttribute"
(10:01:51 PM) illuminus: and the AOT can use the metadata to link our
minimal set of mono corlib types, in our korlib, to the stubs, at AOT time.
(10:04:49 PM) illuminus: I don't have any code in front of me, but
basically, it would be like:
(10:04:49 PM) illuminus:
[VesICall(typeof(System.Object),ICallType.Instance)]
(10:04:49 PM) illuminus: public unsafe static int
GetHashCode(MonoObject* self) { }
(10:06:02 PM) illuminus: where MonoObject = whatever we want to call our
representation of a managed object on the heap
(10:06:18 PM) DarxKies: it would be great if the list was somewhere in
the repository
(10:06:56 PM) illuminus: of the stubs?
(10:07:03 PM) DarxKies: yes
(10:07:15 PM) illuminus: yea, well, xfury wrote that RuntimeCop tool,
which is in the repo, that makes the list
(10:07:28 PM) DarxKies: i see
(10:07:38 PM) illuminus: I started on, (but have temporarilly stalled),
a tool that would generate code files with husks that implement the stubs
(10:07:55 PM) xfury: awesome use of the word husk btw
(10:08:02 PM) illuminus: Thx ;-)
(10:08:44 PM) illuminus: I can't continue it until we decide how we want
to represent certain types in EIC
(10:08:52 PM) illuminus: like our equivalent of MonoArray.
(10:09:15 PM) illuminus: Granted, in that specific case, it should be
easy. But I need to aggregate a list of other types to deal with, too.
(10:10:30 PM) illuminus: At first, I also stupidly assumed that all
stubs were static
(10:12:23 PM) illuminus: But my tool is going to have to translate
managed types (in the stub signatures) into our EIC equivalents, using
attribute metedata I imagine (same way the AOT would, I imagine). So the
tool will have to use reflection on the kernel, in able to generate the
husks *for* the kernel...
(10:12:38 PM) illuminus: *Unless* we want to do it all by hand...
(10:13:14 PM) illuminus: Which is technically feasible. I haven't
counted the stubs, but there are probably between 50 and 100 of them.
(10:13:46 PM) illuminus: Array.GetLength() is a good example of an
instance stub
(10:13:50 PM) DarxKies: over 560 ;)
(10:14:15 PM) illuminus: ah
(10:14:17 PM) illuminus: well then
(10:14:23 PM) illuminus: that settles it. ;-)
(10:14:27 PM) illuminus: tool it is!
(10:14:27 PM) DarxKies: hahaha
(10:14:59 PM) illuminus: oh well, I have to run and do work. keep the
conversation alive, and I'll read some more of the log later.
(10:15:01 PM) illuminus: peace out!
(10:15:06 PM) illuminus is now known as illuminus|log
(10:15:26 PM) xfury: yeah theres a ridiculous number
(10:15:35 PM) xfury: i sometimes wonder if its all really necessary
(10:16:17 PM) xfury: but it probably is
(10:16:40 PM) DarxKies: i wonder too if all are necessary
(10:16:59 PM) xfury: id have to take a closer look at the list
(10:17:25 PM) DarxKies: i generated one against the 1.2.6 version
(10:17:29 PM) DarxKies: if you want i can send it to you
(10:19:36 PM) xfury: hey, that list in the repo only covers mscorlib
(10:19:42 PM) xfury: there's also calls in System and the others
(10:20:17 PM) DarxKies: hmmm
(10:20:48 PM) xfury: i got 614 between mscorlib/System
(10:23:09 PM) DarxKies: that will be alot of work
(10:23:26 PM) xfury: yeah we've got to reduce em a bit
(10:24:20 PM) xfury: but, the Object class has 8
(10:24:25 PM) xfury: we could start there
(10:24:41 PM) xfury: ooops
(10:24:42 PM) xfury: less
(10:24:46 PM) xfury: 4
(10:24:51 PM) DarxKies: we will need MonoType
(10:25:01 PM) xfury: one of em is obj_address
(10:25:05 PM) DarxKies: MonoType is actually what we talked above if i
am not wrong
(10:25:59 PM) xfury: huh, as a real class, or for accessing class data
from EIC?
(10:26:16 PM) xfury: type data*
(10:26:39 PM) DarxKies: it is for acessing the type data
(10:27:12 PM) DarxKies: but it wraps the Class that we will need to
contain the type information
(10:27:58 PM) DarxKies: i count 29
(10:30:03 PM) xfury: for Object?
(10:30:33 PM) DarxKies: you mean MonoObject i think
(10:30:37 PM) DarxKies: but i mean the MonoType
(10:30:44 PM) DarxKies: MonoType contains the information to a type
(10:30:50 PM) xfury: where is that in the mono source?
(10:30:54 PM) xfury: i see MonoTypeInfo but
(10:31:01 PM) DarxKies: and MonoObject just contains the type handle and
the data belonging to that object
(10:33:22 PM) DarxKies: mcs/class/corlib/System/MonoType.cs
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
