dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU](no subject)


From: Rhys Weatherley
Subject: Re: [DotGNU](no subject)
Date: Mon, 13 Jan 2003 07:37:18 +1000
User-agent: KMail/1.4.3

On Sunday 12 January 2003 11:57 pm, Patrick Pletscher wrote:

> - The compiler itself is also written in Oberon.NET, and it only runs with
> mono, but I think that is because it
> uses System.Diagnostics.Process, which isn't implemented in DotGNU, but I
> think thats no problem, because the
> developer will might change a little bit his code and so it should work
> with both, mono and DotGNU Portable
> .NET.

That should not be necessary.  We will implement the "Process" class instead.  
We needed to do that eventually anyway.  Now is as good a time as any. :-)

> metadata error in token 0x0A000005: member 'System.String..ctor' not found
> ./test.exe: invalid metadata in image

Gopal's fix should address this issue for "newobj", although I don't really 
like the fix.  The Oberon compiler should be inserting the "instance" flag 
itself because it is part of the method's signature.  Similar issues apply to 
"callvirt".

I'll poke around in the ECMA spec and try to figure out what the rule is so 
that "callvirt" can be fixed too.  There is a rule that "instance" should be 
added automatically to method definition signatures, but this is a method 
reference instead.  More care is needed for references.

> So if I understand you right, the developer of the compiler has to change
> some parts of his code and than it
> should work also under linux, or did I misunderstood you?

Gopal was referring to something unrelated - my plan to improve load-time 
memory usage in the system by loading metadata as it is used, not all at once 
at startup time.  That probably won't affect compiling Oberon programs.  Try 
not to confuse the poor boy Gopal. :-)

However, Portable.NET's assembler in general assumes that the compiler knows 
what it is doing and just believes what it says.  So we sometimes get cases 
like this "instance" problem where third party compilers assume that the 
assembler "just works".

I'll look into the method reference issue later tonight.

Cheers,

Rhys.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]