[Mono-dev] Is the `sizeof` opcode doing the right thing?
Hi, I've been messing with building a rather low-level datastructure
to avoid the Large Object Heap.
One thing this required of me was to write a very small library
directly in IL. The function I implemented is this:
.method public static hidebysig
default int32 SizeOf () cil managed
{
.maxstack 1
sizeof !!T
ret
}
And I then test this using this:
class MainClass
{
public static void Main (string[] args)
{
Console.WriteLine(BareMetal.SizeOf());
Console.WriteLine(BareMetal.SizeOf());
Console.WriteLine(BareMetal.SizeOf());
Console.WriteLine(BareMetal.SizeOf()); //this is
of concern
Console.ReadKey();
}
}
struct Foo
{
int a, b;
byte c;
object foo;
}
class Bar
{
string foo;
string bar;
AssemblyLoadEventArgs meh;
DateTime d;
}
I got expected results in Microsoft's implementation with reference
values being stored as either 4 or 8 depending on platform
However, with Mono I get very surprising results. when getting the
sizeof `Bar`, it reports 32 on a 64-bit platform, when I would think
it would be either 4 or 8.
In the ECMA spec, on page 423 for partition III, it says "For a
reference type, the size returned is the size of a reference value to
the corresponding type, not the size of the data stored in objects
referred to by a reference value"
I think that language is a tiny bit ambiguous. Basically, does this
mean mono is being correct in that it's storing a "reference value" as
the entire class(an optimization?), or is Mono doing the wrong thing
in not returning just the size of the pointer? I'm not sure about the
Mono internals or anything, so I suspect that it *might* be conforming
to the spec, but I'd really like if someone could verify for this for
me.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Equivalent of csc /link for mcs (COM interop)?
Have you tried using the newer dynamic stuff to do your COM interop calls?
http://www.codeproject.com/Tips/143694/Get-rid-of-COM-Interop-DLL-by-using-the-new-C-4-dy
http://msdn.microsoft.com/en-us/magazine/ff714583.aspx
On Wed, Nov 14, 2012 at 4:27 AM, Peter Dillinger wrote:
> (This message was not accepted from my work email and or from the
> forum interface. Trying personal email...)
>
> In investigating the ability to drop in mcs as a replacement for csc
> (currently trying out mono 2.11.4), I've run into issues in compiling
> things from some Microsoft C# 4.0 code samples that involve COM
> interop. Here's a simplified example:
>
> public class Program
> {
> public static void Test(Microsoft.Office.Interop.Excel.Application xl)
> {
> xl.Columns[2].AutoFit();
> }
> public static void Test2(Microsoft.Office.Interop.Excel.Range r)
> {
> r.Value = 42;
> }
> }
>
> Compiling this with csc requires -link (aka /link), as seen here:
>
> $ cp /cygdrive/c/Program\ Files\ \(x86\)/Microsoft\ Visual\ Studio\
> 10.0/Visual\ Studio\ Tools\ for\
> Office/PIA/Office12/Microsoft.Office.Interop.Excel.dll .
> $ /cygdrive/c/Windows/Microsoft.NET/Framework/v4.0.30319/csc.exe
> -target:library
> -link:Microsoft.Office.Interop.Excel.dll Program.cs
> Microsoft (R) Visual C# Compiler version 4.0.30319.17929
> for Microsoft (R) .NET Framework 4.5
> Copyright (C) Microsoft Corporation. All rights reserved.
> $ /cygdrive/c/Windows/Microsoft.NET/Framework/v4.0.30319/csc.exe
> -target:library
> -r:Microsoft.Office.Interop.Excel.dll Program.cs
> Microsoft (R) Visual C# Compiler version 4.0.30319.17929
> for Microsoft (R) .NET Framework 4.5
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> Program.cs(5,23): error CS1061: 'object' does not contain a definition
> for 'AutoFit' and no extension method 'AutoFit' accepting a first
> argument of type 'object' could be found (are you missing a using
> directive or an assembly reference?)
> $
>
> So trying to compile this with mcs, it seems the closest we can come
> to -link is to replace with -r, so we would expect it to fail
> similarly to mcs above, which it does for 'Test' but 'Test2' has other
> problems:
>
> $ /cygdrive/c/Program\ Files\ \(x86\)/Mono-2.11.4/bin/mcs.bat
> -target:library
> -r:Microsoft.Office.Interop.Excel.dll Program.cs
> Program.cs(5,23): error CS1061: Type `object' does not contain a
> definition for `AutoFit' and no extension method `AutoFit' of type
> `object' could be found. Are you missing an assembly reference?
> C:\PROGRA~2\MONO-2~1.4\lib\mono\4.5\mscorlib.dll (Location of the
> symbol related to previous error)
> Program.cs(9,11): error CS1546: Property or event
> `Microsoft.Office.Interop.Excel.Range.Value' is not supported by the
> C# language
> D:\scalability-csharp\test-cs4codesamples-orig\samples\This sample
> shows how to use the\C#\Microsoft.Office.Interop.Excel.dll (Location
> of the symbol related to previous error)
> Program.cs(9,11): error CS0200: Property or indexer
> `Microsoft.Office.Interop.Excel.Range.Value' cannot be assigned to (it
> is read-only)
> Compilation failed: 3 error(s), 0 warnings
> $
>
> This leads me to two questions:
>
> (1) Is there any plan to support an equivalent of csc -link (aka
> /link)? Or is there some other work-around I don't know about?
>
> (2) It appears that the "is not supported by the C# language"+"cannot
> be assigned to" issue a bug. Is that correct? (If so, I can file
> it.)
>
> And a bonus question:
>
> (3) For general C# language issues where csc willingly compiles
> something that is arguably not adherent to the language spec, but mcs
> rejects it, does the Mono team consider that a valid bug or
> enhancement request? (Is there a "duplicate Microsoft's bugs" mode
> for mcs?)
>
> Thanks for your help,
>
>
> Peter Dillinger | Senior Engineer
> Coverity | 185 Berry Street | Suite 6500, Lobby 3 | San Francisco, CA 94107
> The Leader in Development Testing
> Read our profile in Forbes, Coverity Gets Code Right 25% Faster
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Equivalent of csc /link for mcs (COM interop)?
On Tue, Nov 13, 2012 at 9:42 AM, Jonathan Chambers wrote:
> You'll probably want to try dmcs (rather than mcs) in order to get C# 4.0
> dynamic binding.
I believe your comment only applies to 2.10.x and earlier. (I moved
to 2.11.x after being annoyed by the distinction.) From
http://www.mono-project.com/CSharp_Compiler:
| Starting with Mono version 2.11 a new unified compiler mcs is
available. It replaces
| all previous runtime specific compilers (gmcs, dmcs, smcs). They
still exist (as
| scripts only) to ease the migration path to mcs but we recommend to use mcs.
And indeed, if I compile and reference this instead of
Microsoft.Office.Interop.Excel.dll, mcs will compile my original
program:
namespace Microsoft.Office.Interop.Excel {
public class Application
{
public dynamic Columns { get; set; }
}
public class Range
{
public dynamic Value { get; set; }
}
}
-peter
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Presentation Framework
> This framework is constantly appearing as an issue when using WINE+mono. > > What would it take, to get the current implementation of the Presentation > Framework from the Olive git repository to be part of the main stream mono > repository? Mono currently has classes that aren't implemented completely > (or at all), couldn't this be treated the same? > > Having it part of main repository would make it easier to create patches > for. > The open source implementation that exists is far from useful. We are not adding large swaths of unfinished code to Mono. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Equivalent of csc /link for mcs (COM interop)?
You'll probably want to try dmcs (rather than mcs) in order to get C# 4.0 dynamic binding. I think that is at least one of the errors. http://www.mono-project.com/CSharp_Compiler - Jonathan On Tue, Nov 13, 2012 at 12:41 PM, Marek Safar wrote: > Hi Peter, > > In investigating the ability to drop in mcs as a replacement for csc >> (currently trying out mono 2.11.4), I've run into issues in compiling >> things from some Microsoft C# 4.0 code samples that involve COM >> interop. Here's a simplified example: >> > > COM has never been high on our priority (quite opposite to be honest), you > can expect few more issues to be discovered. > > This leads me to two questions: >> >> (1) Is there any plan to support an equivalent of csc -link (aka >> /link)? Or is there some other work-around I don't know about? >> > > You are the first one using this feature and reporting it. Please fill a > bug report. > > >> >> (2) It appears that the "is not supported by the C# language"+"cannot >> be assigned to" issue a bug. Is that correct? (If so, I can file >> it.) >> >> Correct, this looks like compiler bug. > > >> And a bonus question: >> >> (3) For general C# language issues where csc willingly compiles >> something that is arguably not adherent to the language spec, but mcs >> rejects it, does the Mono team consider that a valid bug or >> enhancement request? (Is there a "duplicate Microsoft's bugs" mode >> for mcs?) >> > > It really depends on the specific case. We trying to be highly compatible > with csc even in cases where C# standart is ambiguous or unclear. There are > few special cases where we are compatible with C# standard but not with > Microsoft C# compiler but they are all very special corner cases. > > Regards, > Marek > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Equivalent of csc /link for mcs (COM interop)?
Hi Peter, In investigating the ability to drop in mcs as a replacement for csc > (currently trying out mono 2.11.4), I've run into issues in compiling > things from some Microsoft C# 4.0 code samples that involve COM > interop. Here's a simplified example: > COM has never been high on our priority (quite opposite to be honest), you can expect few more issues to be discovered. This leads me to two questions: > > (1) Is there any plan to support an equivalent of csc -link (aka > /link)? Or is there some other work-around I don't know about? > You are the first one using this feature and reporting it. Please fill a bug report. > > (2) It appears that the "is not supported by the C# language"+"cannot > be assigned to" issue a bug. Is that correct? (If so, I can file > it.) > > Correct, this looks like compiler bug. > And a bonus question: > > (3) For general C# language issues where csc willingly compiles > something that is arguably not adherent to the language spec, but mcs > rejects it, does the Mono team consider that a valid bug or > enhancement request? (Is there a "duplicate Microsoft's bugs" mode > for mcs?) > It really depends on the specific case. We trying to be highly compatible with csc even in cases where C# standart is ambiguous or unclear. There are few special cases where we are compatible with C# standard but not with Microsoft C# compiler but they are all very special corner cases. Regards, Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Equivalent of csc /link for mcs (COM interop)?
(This message was not accepted from my work email and or from the
forum interface. Trying personal email...)
In investigating the ability to drop in mcs as a replacement for csc
(currently trying out mono 2.11.4), I've run into issues in compiling
things from some Microsoft C# 4.0 code samples that involve COM
interop. Here's a simplified example:
public class Program
{
public static void Test(Microsoft.Office.Interop.Excel.Application xl)
{
xl.Columns[2].AutoFit();
}
public static void Test2(Microsoft.Office.Interop.Excel.Range r)
{
r.Value = 42;
}
}
Compiling this with csc requires -link (aka /link), as seen here:
$ cp /cygdrive/c/Program\ Files\ \(x86\)/Microsoft\ Visual\ Studio\
10.0/Visual\ Studio\ Tools\ for\
Office/PIA/Office12/Microsoft.Office.Interop.Excel.dll .
$ /cygdrive/c/Windows/Microsoft.NET/Framework/v4.0.30319/csc.exe -target:library
-link:Microsoft.Office.Interop.Excel.dll Program.cs
Microsoft (R) Visual C# Compiler version 4.0.30319.17929
for Microsoft (R) .NET Framework 4.5
Copyright (C) Microsoft Corporation. All rights reserved.
$ /cygdrive/c/Windows/Microsoft.NET/Framework/v4.0.30319/csc.exe -target:library
-r:Microsoft.Office.Interop.Excel.dll Program.cs
Microsoft (R) Visual C# Compiler version 4.0.30319.17929
for Microsoft (R) .NET Framework 4.5
Copyright (C) Microsoft Corporation. All rights reserved.
Program.cs(5,23): error CS1061: 'object' does not contain a definition
for 'AutoFit' and no extension method 'AutoFit' accepting a first
argument of type 'object' could be found (are you missing a using
directive or an assembly reference?)
$
So trying to compile this with mcs, it seems the closest we can come
to -link is to replace with -r, so we would expect it to fail
similarly to mcs above, which it does for 'Test' but 'Test2' has other
problems:
$ /cygdrive/c/Program\ Files\ \(x86\)/Mono-2.11.4/bin/mcs.bat -target:library
-r:Microsoft.Office.Interop.Excel.dll Program.cs
Program.cs(5,23): error CS1061: Type `object' does not contain a
definition for `AutoFit' and no extension method `AutoFit' of type
`object' could be found. Are you missing an assembly reference?
C:\PROGRA~2\MONO-2~1.4\lib\mono\4.5\mscorlib.dll (Location of the
symbol related to previous error)
Program.cs(9,11): error CS1546: Property or event
`Microsoft.Office.Interop.Excel.Range.Value' is not supported by the
C# language
D:\scalability-csharp\test-cs4codesamples-orig\samples\This sample
shows how to use the\C#\Microsoft.Office.Interop.Excel.dll (Location
of the symbol related to previous error)
Program.cs(9,11): error CS0200: Property or indexer
`Microsoft.Office.Interop.Excel.Range.Value' cannot be assigned to (it
is read-only)
Compilation failed: 3 error(s), 0 warnings
$
This leads me to two questions:
(1) Is there any plan to support an equivalent of csc -link (aka
/link)? Or is there some other work-around I don't know about?
(2) It appears that the "is not supported by the C# language"+"cannot
be assigned to" issue a bug. Is that correct? (If so, I can file
it.)
And a bonus question:
(3) For general C# language issues where csc willingly compiles
something that is arguably not adherent to the language spec, but mcs
rejects it, does the Mono team consider that a valid bug or
enhancement request? (Is there a "duplicate Microsoft's bugs" mode
for mcs?)
Thanks for your help,
Peter Dillinger | Senior Engineer
Coverity | 185 Berry Street | Suite 6500, Lobby 3 | San Francisco, CA 94107
The Leader in Development Testing
Read our profile in Forbes, Coverity Gets Code Right 25% Faster
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Presentation Framework
Hi, We wouldn't bring WPF into mono tree unless it becomes usable and solid to some extent. There may be incomplete libraries but that does not justify bringing extraneous components into mcs build. Actually I don't think there is considerable difference between mono and olive to create patches. But if you really have reason, share it, I'm personally all ears :) Atsushi Eno Alistair Leslie-Hughes wrote: Hi, This framework is constantly appearing as an issue when using WINE+mono. What would it take, to get the current implementation of the Presentation Framework from the Olive git repository to be part of the main stream mono repository? Mono currently has classes that aren't implemented completely (or at all), couldn't this be treated the same? Having it part of main repository would make it easier to create patches for. Best Regards, Alistair Leslie-Hughes ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
