[Mono-dev] 3 patches for Mono.CodeGeneration
Hello all,
Thanks for the quick reply on where the latest Mono.CodeGeneration code had
been moved in svn.
Here are 3 patches - pitfully without unit test (as our own library has been
heavily customized and it'd take time to rewrite them).
The bugs fixed are nevetheless quite obvious:
- CoreOrcs and CoreAnd.cs: in the Generate method, the first expression had
it IL generated twice = 1 line removed for each class.
- CodeLiteral.cs: the fact that the value was boxed was not taken into
account and was crashing if the value was not an int (ex: object value =
(byte)1; int i = (int)value = exception thrown)
Regards
Lionel
http://www.aulofee.com
--- CodeOr.cs 2008-09-29 08:57:34.28125 +0200
+++ ..\Mono.CodeGeneration patched/CodeOr.cs2008-09-29 09:23:14.328125000
+0200
@@ -69,7 +69,6 @@
public override void GenerateForBranch(ILGenerator gen, Label
label, bool branchCase)
{
Label endLabel = gen.DefineLabel();
- exp1.Generate(gen);
if (exp1 is CodeConditionExpression)
{
--- CodeAnd.cs 2008-09-29 08:58:01.75000 +0200
+++ ..\Mono.CodeGeneration patched/CodeAnd.cs 2008-09-29 09:22:28.31250
+0200
@@ -70,7 +70,6 @@
public override void GenerateForBranch(ILGenerator gen, Label
label, bool branchCase)
{
Label endLabel = gen.DefineLabel();
- exp1.Generate(gen);
if (exp1 is CodeConditionExpression)
{
--- CodeLiteral.cs 2008-09-29 08:57:40.25000 +0200
+++ ..\Mono.CodeGeneration patched/CodeLiteral.cs 2008-09-29
09:24:22.515625000 +0200
@@ -82,7 +82,7 @@
case TypeCode.UInt16:
case TypeCode.Int32:
case TypeCode.UInt32:
- int i = (int)value;
+ int i = Convert.ToInt(value); // Old
code was (int)value; and was crashing when value was boxed.
switch (i)
{
case 0:
gen.Emit(OpCodes.Ldc_I4_0); break;
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] What is the state of mono interpreter ?
Whatever you might be thinking I can't see why not using mono JIT would be desirable. On some platforms you can't generate _any_ executable code at runtime. So there one needs either the interpreter, or full AOT. Some platform examples: iPhone, Xbox360, (maybe) PS3. Unless you need reflection or fancy runtime support like transparent proxies, full AOT is the supported way for such platforms. And even in that cases, it would be easier and better to extend full AOT than bringing back the interpreter. Yes. I was just pointing out why would anyone want an interpreter. Full AOT would work in that case as well. However, having an interpreter would have some advantages in comparison with AOT (as well as some disadvantages of course). Some that come to my head: * Full AOT to another target architecture, anyone? (e.g. you develop on x86 machine, your target machine is ARM or PPC) * With interpreter, there's a shorter cycle on getting your .NET code to some device (think consoles here). With AOT, it goes this way: compiler - AOT - native assembler - native linker - code signing - device. With interpreter, it's compiler - device. One does not even need to have assembler, linker or code signing tools. For what it's worth, we're going Full AOT route in Unity for iPhone. But we were seriously considering the interpreter route as well. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Support for XmlSerializationReader.CollapseWhitespace ReadTypedNull
On Sat, 2008-09-27 at 12:15 +0900, Atsushi Eno wrote: FileSecurity File.GetAccessControl(string) void FileSystemSecurity.AddAccessRule(FileSystemAccessRule) void FileSystemSecurity.AddAccessRule(FileSystemAccessRule) void File.SetAccessControl(string, FileSecurity) It is Windows-only ACL things. There's no way these could be mapped to POSIX ACLs [0]? From a cursory glance at FileSystemAccessRule and FileSystemRights, it looks like at least a partial mapping could be done between Windows ACLs and POSIX ACLs... - Jon [0] http://www.suse.de/~agruen/acl/linux-acls/online/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Strong-named assembly built with Linux Mono not working with Windows VB Web Application
Hi all, I have a custom web control written in C# that I develop using MonoDevelop (trunk) and release for use under both Mono (trunk) and .NET. Under some circumstances it needs to be installed in the GAC so I sign it. It works fine when referenced from a C# or VB.NET Web Site Project and from a C# Web Application Project, but does not work when referenced from a VB.NET Web Application Project. The error I get when loading the page with my control on it is: *Compiler Error Message: *BC30652: Reference required to assembly 'Brettle.Web.NeatUpload, Version=1.3.2469.19122, Culture=neutral, PublicKeyToken=c95290d92c5893c8' containing the type 'Brettle.Web.NeatUpload.MultiFile'. Add one to your project. The reference is definitely there and if I replace the reference with either a reference to an unsigned assembly or with a signed assembly built from the same source using VS 2008 Express SP1, the error goes away. To sum up, *all * of the following need to be true for the error to occur: 1. VB.NET Web Application project, not c# Web Application project or VB.NETWeb Site Project. 2. Assembly is signed. 3. Assembly is built/signed using Mono, not .NET. Also, if I use .NET's sn.exe (with the -vf option) to verify the signature on the assembly built/signed with Mono, it says it is valid. Has anyone else run into this or doese anyone have any suggestions for ways to diagnose/fix/workaround the problem? Thanks, --Dean ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] What is the state of mono interpreter ?
2008/9/29 Aras Pranckevicius [EMAIL PROTECTED] Whatever you might be thinking I can't see why not using mono JIT would be desirable. On some platforms you can't generate _any_ executable code at runtime. So there one needs either the interpreter, or full AOT. Some platform examples: iPhone, Xbox360, (maybe) PS3. Unless you need reflection or fancy runtime support like transparent proxies, full AOT is the supported way for such platforms. And even in that cases, it would be easier and better to extend full AOT than bringing back the interpreter. Yes. I was just pointing out why would anyone want an interpreter. Full AOT would work in that case as well. However, having an interpreter would have some advantages in comparison with AOT (as well as some disadvantages of course). Some that come to my head: * Full AOT to another target architecture, anyone? (e.g. you develop on x86 machine, your target machine is ARM or PPC) * With interpreter, there's a shorter cycle on getting your .NET code to some device (think consoles here). With AOT, it goes this way: compiler - AOT - native assembler - native linker - code signing - device. With interpreter, it's compiler - device. One does not even need to have assembler, linker or code signing tools. These are shortcomings of the current AOT implementation of mono that are easier to fix than implement a fast interpreter. Add a binary writter is not hard, just take time to do so, it happens that we don't have enough cycles to burn on that. The other issue would be cross AOT'ing code, which is an easier task to accomplish than adding binary witters. For what it's worth, we're going Full AOT route in Unity for iPhone. But we were seriously considering the interpreter route as well. Building an interpreter with decent performance takes quite some time, not counting the time to get things like generics working properly. The CLR bytecode format is not suitable for fast interpretation, so having an AOT pass to convert to a more usable format would be an advantage as well. Something similiar to what the Dalvik VM does. Anyway, building an interpreter isn't a simple task, specially a fast one, which is less portable than a JIT - most of them use hand coded assembly. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Strong-named assembly built with Linux Mono not working with Windows VB Web Application
One first check. Is your assembly CLSCompliant? If not, the VB class binder, which is different from the C# one, may not find things around. :) Hope it helps 2008/9/29 Dean Brettle [EMAIL PROTECTED] Hi all, I have a custom web control written in C# that I develop using MonoDevelop (trunk) and release for use under both Mono (trunk) and .NET. Under some circumstances it needs to be installed in the GAC so I sign it. It works fine when referenced from a C# or VB.NET Web Site Project and from a C# Web Application Project, but does not work when referenced from a VB.NETWeb Application Project. The error I get when loading the page with my control on it is: *Compiler Error Message: *BC30652: Reference required to assembly 'Brettle.Web.NeatUpload, Version=1.3.2469.19122, Culture=neutral, PublicKeyToken=c95290d92c5893c8' containing the type 'Brettle.Web.NeatUpload.MultiFile'. Add one to your project. The reference is definitely there and if I replace the reference with either a reference to an unsigned assembly or with a signed assembly built from the same source using VS 2008 Express SP1, the error goes away. To sum up, *all* of the following need to be true for the error to occur: 1. VB.NET Web Application project, not c# Web Application project or VB.NET Web Site Project. 2. Assembly is signed. 3. Assembly is built/signed using Mono, not .NET. Also, if I use .NET's sn.exe (with the -vf option) to verify the signature on the assembly built/signed with Mono, it says it is valid. Has anyone else run into this or doese anyone have any suggestions for ways to diagnose/fix/workaround the problem? Thanks, --Dean ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Rafael Monoman Teixeira --- I myself am made entirely of flaws, stitched together with good intentions. Augusten Burroughs ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Support for XmlSerializationReader.CollapseWhitespace ReadTypedNull
I don't remember the details but I indeed tried to implement it one year ago, and gave up for not a minor difference between those ACLs. http://lists.ximian.com/pipermail/mono-devel-list/2007-September/025096.html If you take your words and go to implement it, it'd be awesome. Atsushi Eno Jonathan Pryor wrote: On Sat, 2008-09-27 at 12:15 +0900, Atsushi Eno wrote: FileSecurity File.GetAccessControl(string) void FileSystemSecurity.AddAccessRule(FileSystemAccessRule) void FileSystemSecurity.AddAccessRule(FileSystemAccessRule) void File.SetAccessControl(string, FileSecurity) It is Windows-only ACL things. There's no way these could be mapped to POSIX ACLs [0]? From a cursory glance at FileSystemAccessRule and FileSystemRights, it looks like at least a partial mapping could be done between Windows ACLs and POSIX ACLs... - Jon [0] http://www.suse.de/~agruen/acl/linux-acls/online/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Support for XmlSerializationReader.CollapseWhitespace ReadTypedNull
On Mon, 2008-09-29 at 13:28 -0400, Jonathan Pryor wrote: On Sat, 2008-09-27 at 12:15 +0900, Atsushi Eno wrote: FileSecurity File.GetAccessControl(string) void FileSystemSecurity.AddAccessRule(FileSystemAccessRule) void FileSystemSecurity.AddAccessRule(FileSystemAccessRule) void File.SetAccessControl(string, FileSecurity) It is Windows-only ACL things. There's no way these could be mapped to POSIX ACLs [0]? From a cursory glance at FileSystemAccessRule and FileSystemRights, it looks like at least a partial mapping could be done between Windows ACLs and POSIX ACLs... A partial mapping could be done, but at their roots they are pretty different in their details. Anyway I don't think its worth it for two reasons: 1) Applications, under Windows, must deal with file systems (e.g. FAT) that does not support ACL. In their world you either have them or not. Providing a partial solution would cause compatibility issues for some applications. 2) Applications using ACL generally have good reasons for using them. Providing something similar, but not identical, could also prove a bigger problem that not supporting them. Of course I'd love to be prove wrong with a working patch :-) Sebastien - Jon [0] http://www.suse.de/~agruen/acl/linux-acls/online/ ___ 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] What is the state of mono interpreter ?
Rodrigo Kumpera wrote: These are shortcomings of the current AOT implementation of mono that are easier to fix than implement a fast interpreter. Who said anything about fast? I would value an interpreter not as a replacement for JIT in a full mono stack, but as a way to create a very small footprint runner for CLR code, with a really cut-down runtime. This would be competing more with a Lua usecase than anything else. James ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] What is the state of mono interpreter ?
On Mon, Sep 29, 2008 at 2:39 PM, James Mansion [EMAIL PROTECTED] wrote: Rodrigo Kumpera wrote: These are shortcomings of the current AOT implementation of mono that are easier to fix than implement a fast interpreter. Who said anything about fast? I would value an interpreter not as a replacement for JIT in a full mono stack, but as a way to create a very small footprint runner for CLR code, with a really cut-down runtime. This would be competing more with a Lua usecase than anything else. Which is, I think, what the original author of the thread meant by referring to the Micro Framework... http://en.wikipedia.org/wiki/.NET_Micro_Framework -- runs in 300kb, 70 classes, 420 methods, doesn't need an OS or a MMU... -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] libgdiplus tutorials
Hi, Are there any simple to follow libgdiplus tutorials folks can recommend me to read? I'm after doing some things with it... TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] libgdiplus tutorials
On Mon, 2008-09-29 at 22:16 +0100, Paul wrote: Hi, Are there any simple to follow libgdiplus tutorials folks can recommend me to read? I'm after doing some things with it... From ? C# (or any .NET language) or C/C++ ? In the first case then google for System.Drawing. Much of what you'll ind will apply to both Linux, Mac and Windows. In the later cases then it's unlikely you'll find much (beside the rendering) about it that applies outside the Windows world. If your main environment is Linux and you want compatibility with Windows I suggest you to learn Cairo directly. Sebastien ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono 2.0 RC3 is out!!
Hey Everyone, We've just released Mono 2.0 RC3 today! Please help us out by giving it a try with your applications. Unfortunately this version doesn't include an update for the OS X installer. We're looking to update it with the next release candidate. As always, you can get the preview/RC releases here: http://mono.ximian.com/monobuild/preview/download-preview/ Please report any bugs that you may find using our Bugs page, AND reply to this thread with the bug numbers so we can track them! http://www.mono-project.com/Bugs You can see the bugs we're tracking for Mono 2.0 here: https://bugzilla.novell.com/buglist.cgi?bug_file_loc_type=allwordssubstrbug_file_loc=http%3A%2F%2Fwww.go-mono.com%2Farchive%2F2.0%2Forder=bugs.bug_status%20 The earlier you file the bugs and reply to this message, the more likely your bugs will get fixed. Special attention is given to regressions, so if you can tell us a version of Mono where the bug worked and you tag the summary of the bug with [Regression], then it is much more likely your bug will get fixed. Please help the Mono team to make 2.0 the best ever. Thanks again! Mono QA ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] What is the state of mono interpreter ?
Which is, I think, what the original author of the thread meant by referring to the Micro Framework... http://en.wikipedia.org/wiki/.NET_Micro_Framework -- runs in 300kb, 70 classes, 420 methods, doesn't need an OS or a MMU... Yes, thats exactly my idea... the microframework is avaible as always from microsoft in a braindead way, its very dificult to get acess to the porting kit I think this maybe a very nice project =), at least for the embedded fans :D ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
