[Mono-dev] misc: C# request info
well, I was looking into C# some, and admittedly I have much less fammiliarity with the language than with others... (I have started looking at ECMA-334 some, but it is long and a little awkward to answer specific questions from absent some digging...). so, firstly, it is my guess that in order to compile C# properly, it is required to load a whole group of files at once (I am uncertain whether the term 'assembly' also applies to the collection of input source files, or only to a produced DLL or EXE). my guess is that it works like this: the group of files is loaded; each file is preprocessed and parsed (it is looking like C# uses a context-independent syntax?...); all of the namespaces and declarations are lifted out of the parse trees; each file's parse tree can then be compiled. from what I can tell, types are like this: type = qualifiers* type-name so, I can type: static Foo bar; and the parser will know that 'Foo' is the type, even if the type for Foo is not visible at the time of parsing (in C, this can't be done since there is no clear distinction or ordering between types and qualifiers, and so one would not know if 'Foo' is the type, or an intended variable name with the type being assumed to be 'int'). so, in C we can have: unsigned int i; int unsigned i; int volatile i; _Complex float f; double _Complex g; unsigned i; short int j; int long k; .. so, my guess then is that C# code is just parsed, with no need to lookup, for example, is Foo a struct or class or other typedef'ed type? ... as far as the parser is concerned 'int' or 'byte' is syntactically not different from 'Foo' or 'Bar'?... .. any comments?... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] More .NET and mono floating point inconsistencies
David, I've evaluated your test cases and found that the behavior exposed by your tests cases is not a bug. For the first sight this seems to be a bug is MS.NET, but it isn't a bug of MS.NET either. ECMA specs (part3, 1.1.1 Numeric data types) explicitly state the following: When a floating-point value ... is put in a storage location, it is automatically coerced to the type of the storage location. ... However, the value might be retained in the internal representation for future use, if it is reloaded from the storage location without having been modified. ... This freedom to carry extra precision is not permitted, however, following the execution of an explicit conversion (conv.r4 or conv.r8) ... This means that unlike integer variables, floating point store/load pairs are not (necessarily) cause conversion. On the other hand if you need deterministic behavior, you should issue an explicit conv.r4 (x = (float)y; in C#) because this is an implementation detail of the current MS JIT compiler that may change in the future even in that compiler. Although ECMA specs permit the native float type to have additional precision, you will most likely never notice the same behavior with double (float64), because both Mono and MS.NET configure the FPU to round each arithmetic operations to 64-bits. Also note that there is no performance gain from using float (float32), because the FPU still operates in 64-bit mode that has to be converted to 32-bits. As a result if you want performance you shouldn't use float32 at all. A simplified test case: float f1=200; float f2=162.980057f; float f3 = (1 - (f2 / f1)); float f4 = f3*f3; Console.WriteLine(f4.ToString(R, CultureInfo.InvariantCulture)); Adding an extra conversion you will get the behavior of Mono on MS.NET as well: float f1=200; float f2=162.980057f; float f3 = (float)(1 - (f2 / f1)); float f4 = f3*f3; Console.WriteLine(f4.ToString(R, CultureInfo.InvariantCulture)); Kornél Rodrigo Kumpera wrote: I have commited the fixed from Kornél for all bugs that have tests. On Fri, Feb 20, 2009 at 12:14 AM, ddambro ddam...@gmail.com mailto:ddam...@gmail.com wrote: Hi, Thanks for looking into my issues. I hope my post didn't come across as rude or anything, I was really just looking to ask if it was better to post issues here or directly to Bugzilla. I'm sure there are far more important issues than my weird floating point inconsistencies. For the curious, I am an AI researcher working on Evolutionary Computation. I tend to use Windows and .NET to run my code, but my research group has several large computing clusters that could massively speed up my experiments, but they only run Linux. Also academia tends to shy away from Windows Only software, so if I can say Runs in Linux when I release my code to the public, it's a pretty big boon for me as well as the people who want to run it. However, because of the floating point issues described, experiments run on mono are not compatible with experiments run on .NET, as over the course of a simulation, the small errors propagate over thousands of time steps into large differences in the final AI behavior. Thus, if I used both mono and .NET, not only would I have to be mindful of which experiment was run on which platform when I do analysis and demonstrations, but when I release my results to the public I would also have to mark arbitrary sets of experiments as mono only or .NET only. Kornél Pál wrote: Hi, Thanks for the test cases, I'll invetigate these as well and try to fix them. The best way to get bugs fixed is to produce test cases and report them in buzilla. You can help more if you are able to provide a patch to fix the bugs. Note that for some reasons Novell guys seem to ignore this bug mostly because they have other things to do and their approval is required for these changes. Could you please describe your scenario (application name, purpose, etc. if they are public) where you need these floating point roundings and describe why these bugs are critical for you. Providing some description may raise component owners' attention. Kornél ddambro wrote: I previously posted about some differences I noticed between the floating point math in .NET and mono http://www.nabble.com/Mono-and-.Net-Floating-Point-Inconsistencies-to21428695ef1367.html here . The bug report can be found https://bugzilla.novell.com/show_bug.cgi?id=467201 here . The patch provided (Thank you!) fixes several issues I was encountering, but unfortunately it led me to discover a couple more. The following two
[Mono-list] Cairo
Hi I'm trying to create dynamic images with Mono.Cairo in a webservice. I just used some sample code from the Mono site, and the image is being created (written to disc). But, I would like to use the png output directly to a stream. I noticed that in the file Mono.Cairo.NativeMethods.cs, the write to stream interop methods are not available. So, my question is, how can I write a PNG to the Context.Request, without first writing the png to a file? Secondly, can anyone hint me howto create a jpeg (or a different filetype) from the surface? Thanx in advance Peter Hagen ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Code optimizations
Robert Jordan wrote:
Yoav HaCohen wrote:
Here is my first idea:
Suppose we have the following code:
[DllImport(NATIVE_LIBRARY, CallingConvention = CallingConvention.Cdecl)]
private static extern void NativeFoo(int temp, out int cx, out
int
cy);
public System.Drawing.Point Foo()
{
int cx, cy;
NativeFoo(int a, out cx, out cy);
return new System.Drawing.Point(cx, cy);
|
I'm aware that you did not intend to start a discussion
about p/invoke, but I could not resist (1):
You don't want to p/invoke just to get one point out of
the unmanaged world. The managed/unmanaged transition
is too costly for this. Any optimization done by the JIT
after this call would be pointless.
When dealing with (arrays of) Point/Rectangle/Size (and other similar
well known structs), there is a (rather dirty) way to gain speed:
Define Point/Rectangle/Size as structs in the unmanaged
world and pass them by reference back and forth.
Robert
(1) that's why designers are using lorem ipsum paragraphs for
prototyping ;)
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
I know that it's costly to call unmanaged from managed code but there are a
good reason in this case for doing that.
Anyway, this is just an example, such cases can be also found in the managed
code.
My philosophy is that there is no pointless optimization if nothing is
required from the developer.
Yoav
--
View this message in context:
http://www.nabble.com/Code-optimizations-tp22119164p22138683.html
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] MySql error Stream is not a valid .resources file, magic=0x6d783f3c
I'm getting this when connecting to mysql server from my ubuntu 8.10: Stream is not a valid .resources file, magic=0x6d783f3c There is nothing much on google about this except https://lists.ubuntu.com/archives/universe-bugs/2008-December/028127.html where it sais it's fixed, but it does not work for me. Any ideas? mysql: Server version: 5.0.67-0ubuntu6 I use MySql.Data.dll for mono. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MySql error Stream is not a valid .resources file, magic=0x6d783f3c
2009/2/21 gabriel balint gabriel.bal...@gmail.com: I'm getting this when connecting to mysql server from my ubuntu 8.10: Stream is not a valid .resources file, magic=0x6d783f3c There is nothing much on google about this except https://lists.ubuntu.com/archives/universe-bugs/2008-December/028127.html where it sais it's fixed, but it does not work for me. Any ideas? mysql: Server version: 5.0.67-0ubuntu6 I use MySql.Data.dll for mono. what is your mono -V can you try with the last MySQL.data dll from mysql, also yesterday after other problem, i used the old ByteFx who solve my update/write problems :-) ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- Cordially. Small Eric Quotations of the days: --- If one day one reproaches you that your work is not a work of professional, say you that: Amateurs built the arch of Noah, and professionals the Titanic. --- Few people are done for independence, it is the privilege of the powerful ones. --- No key was wounded during the drafting of this message. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Mixing Mono and .NET dlls?
Miguel's blog on Mono.Options, got me wondering (again) about hybrid projects. http://tirania.org/blog/archive/2009/Feb-21.html On the technical side, what are the advantages and pitfalls of mixing dlls from both stacks. I develop mainly in Visual Studio. Can I include Mono.Options.dll in my .NET project? Another Mono widget I'm contemplating is the Webbrowser form. I use the .NET webbrowser form, but I'm not happy with its performance. Also, it doesn't work on linux. I would like to try the mono/gluezilla widget. Can I simply include Mono.System.Windows.Forms in Visual Studio? And then there's the legal question. Is there anything wrong with swapping out bits of .NET with Mono? -- View this message in context: http://www.nabble.com/Mixing-Mono-and-.NET-dlls--tp22141289p22141289.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing Mono and .NET dlls?
2009/2/21 fevans fev...@harris.com: Miguel's blog on Mono.Options, got me wondering (again) about hybrid projects. http://tirania.org/blog/archive/2009/Feb-21.html On the technical side, what are the advantages and pitfalls of mixing dlls from both stacks. I develop mainly in Visual Studio. Can I include Mono.Options.dll in my .NET project? As long as it's a purely managed assembly, it should work the same way everywhere. Mono.Options is, so there is no problem at all. Another Mono widget I'm contemplating is the Webbrowser form. I use the .NET webbrowser form, but I'm not happy with its performance. Also, it doesn't work on linux. I would like to try the mono/gluezilla widget. Can I simply include Mono.System.Windows.Forms in Visual Studio? I guess you must not reference the MS winforms assembly, but I never tried anything Mono-related on Windows. Perhaps it won't work at all. I'm not sure how the Mono implementation works. And then there's the legal question. Is there anything wrong with swapping out bits of .NET with Mono? I'm not a lawyer (and especially not an EULA reader), but I think that is like asking is there something wrong with using my own library?. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] More .NET and mono floating point inconsistencies
Kornél, Thank you for looking into this issue for me. After adding a few more explicit float conversions and removing some temporary variables, I was able to create a version of my program that runs the same on both mono (svn127604) and .NET. However, I am interested in what you said about doubles. If I'm understanding correctly, if I use doubles instead of floats I shouldn't have to worry about these rounding inconsistencies? I think we started with doubles, but moved to floats because they were supposedly faster, but if what you say is true, I might try and change everything over when I have time. Checking Google only reveals that there is some conflict as to if floats are faster than doubles in C#. Plus if I ever decide to use the SIMD instructions, I can only do half as much work at a time. But even if there is a performance loss it might be worth it to avoid constantly having to test new versions for .NET/mono compatibility. David Kornél Pál wrote: David, I've evaluated your test cases and found that the behavior exposed by your tests cases is not a bug. For the first sight this seems to be a bug is MS.NET, but it isn't a bug of MS.NET either. ECMA specs (part3, 1.1.1 Numeric data types) explicitly state the following: When a floating-point value ... is put in a storage location, it is automatically coerced to the type of the storage location. ... However, the value might be retained in the internal representation for future use, if it is reloaded from the storage location without having been modified. ... This freedom to carry extra precision is not permitted, however, following the execution of an explicit conversion (conv.r4 or conv.r8) ... This means that unlike integer variables, floating point store/load pairs are not (necessarily) cause conversion. On the other hand if you need deterministic behavior, you should issue an explicit conv.r4 (x = (float)y; in C#) because this is an implementation detail of the current MS JIT compiler that may change in the future even in that compiler. Although ECMA specs permit the native float type to have additional precision, you will most likely never notice the same behavior with double (float64), because both Mono and MS.NET configure the FPU to round each arithmetic operations to 64-bits. Also note that there is no performance gain from using float (float32), because the FPU still operates in 64-bit mode that has to be converted to 32-bits. As a result if you want performance you shouldn't use float32 at all. A simplified test case: float f1=200; float f2=162.980057f; float f3 = (1 - (f2 / f1)); float f4 = f3*f3; Console.WriteLine(f4.ToString(R, CultureInfo.InvariantCulture)); Adding an extra conversion you will get the behavior of Mono on MS.NET as well: float f1=200; float f2=162.980057f; float f3 = (float)(1 - (f2 / f1)); float f4 = f3*f3; Console.WriteLine(f4.ToString(R, CultureInfo.InvariantCulture)); Kornél Rodrigo Kumpera wrote: I have commited the fixed from Kornél for all bugs that have tests. On Fri, Feb 20, 2009 at 12:14 AM, ddambro ddam...@gmail.com mailto:ddam...@gmail.com wrote: Hi, Thanks for looking into my issues. I hope my post didn't come across as rude or anything, I was really just looking to ask if it was better to post issues here or directly to Bugzilla. I'm sure there are far more important issues than my weird floating point inconsistencies. For the curious, I am an AI researcher working on Evolutionary Computation. I tend to use Windows and .NET to run my code, but my research group has several large computing clusters that could massively speed up my experiments, but they only run Linux. Also academia tends to shy away from Windows Only software, so if I can say Runs in Linux when I release my code to the public, it's a pretty big boon for me as well as the people who want to run it. However, because of the floating point issues described, experiments run on mono are not compatible with experiments run on .NET, as over the course of a simulation, the small errors propagate over thousands of time steps into large differences in the final AI behavior. Thus, if I used both mono and .NET, not only would I have to be mindful of which experiment was run on which platform when I do analysis and demonstrations, but when I release my results to the public I would also have to mark arbitrary sets of experiments as mono only or .NET only. Kornél Pál wrote: Hi, Thanks for the test cases, I'll invetigate these as well and try to fix them. The best way to get bugs fixed is to produce test cases and report them in buzilla. You can help more if you are able to provide a patch to fix the bugs.
