[Top][All Lists]
[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.
- Re: [DotGNU] Oberon.net compat, (continued)
- Re: [DotGNU] Oberon.net compat, Rhys Weatherley, 2003/01/13
- AW: [DotGNU] Oberon.net compat, Patrick Pletscher, 2003/01/13
- Re: AW: [DotGNU] Oberon.net compat, Rhys Weatherley, 2003/01/13
- Re: AW: [DotGNU] Oberon.net compat, Gopal V, 2003/01/15
- Re: AW: [DotGNU] Oberon.net compat, Gopal V, 2003/01/18
- Re: AW: [DotGNU] Oberon.net compat, Gopal V, 2003/01/14
Re: [DotGNU](no subject),
Rhys Weatherley <=