[Mono-devel-list] System.Drawing Tests - image recognition similarities
Hi Jordi, (and mono devs) Mainsoft wish to invest some effort in testing System.Drawing. We wish to enhance the test suite with an image compare component which will compare the difference between the expected .NET image and the mono image. The comparer (which we just started prototyping it) will be customized and produce a result according to several algorithms: * Prior to compare: format, size, colors, resolution * Color - strip boarders; compare histograms to get top colors and areas. * Edge Detect - edge detection, and line generation, compare line lists. * Histogram to detect shapes * FFT (or cosine transform) of sub-regions or the whole image. * Tangent space Vectors * I appreciate your inputs? * Do you recommend on a curtain GPL library? * Does anyone have such task in his TODO list? - Mizrahi Rafael Dev/QA Team Leader Mainsoft ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Determine the name and/or kind of CLI runtime environment
Hi, Is there any official or unofficial but working way to determine what kind of CLI runtime environment is executing the assembly? There are at least three of them: -Microsoft .NET Framework -Mono -DotGNU Portable.NET They have different interfaces to low level runtime functionality and it is good if an error report contains the name of the CLI runtime as well. What do you recommend on detecting Mono from managed code? Kornl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Test policy proposition
Hi, We will never add those massive standalone tests into NUnit test (note that they are going to be separate module). But it still sounds nice to develop such integration as long as it is *optional* run. Note that the discussion also applies to the whole standalone test things BTW. Atsushi Eno RafaelMizrahi wrote: Hi Andrew and Atsushi, I suggest that all stand_alone test suites will output NUnit report. This way they can be included in build, regression reports etc' . ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] System.Drawing Tests - image recognition similarities
On Mon, 2005-05-30 at 11:05 +0300, RafaelMizrahi wrote: Hi Jordi, (and mono devs) Mainsoft wish to invest some effort in testing System.Drawing. We wish to enhance the test suite with an image compare component which will compare the difference between the expected .NET image and the mono image. The comparer (which we just started prototyping it) will be customized and produce a result according to several algorithms: * Prior to compare: format, size, colors, resolution * Color - strip boarders; compare histograms to get top colors and areas. * Edge Detect - edge detection, and line generation, compare line lists. * Histogram to detect shapes * FFT (or cosine transform) of sub-regions or the whole image. * Tangent space Vectors What if, rather than comparing the mono and .net image -- which could be different due to, eg, differences in the anti-alias methods used -- you did the following: * Run the test suites on both mono and msft * Compare the images. If the images are similar enough to consider the test as passing, mark the test as pass. Obviously this is a manual process. * Check in the binary images that are generated by *mono* for all sucessful runs * Test that the images stay the same pixel by pixel (ie, that the binary data of the image is the same). This makes the assumption that in general, Cairo is deterministic in how it renders an image. This is probably a reasonable assumption. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Re: Test policy proposition
Oh, forgot to mention the patch. It is fine, especially it is nice to have the description on the test output in README :-) Atsushi Eno Better yet, have the whole patch, I hope, it's self-explaining. If not, we'll talk. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] Test policy proposition
Atsushi, I did not suggest to convert or to run them as NUnit, I just suggest that it is better to have their output as NUnit report. - Mizrahi Rafael -Original Message- From: Atsushi Eno [mailto:[EMAIL PROTECTED] Sent: Monday, May 30, 2005 5:12 PM To: RafaelMizrahi Cc: 'Andrew Skiba'; 'mono-devel mailing list' Subject: Re: [Mono-devel-list] Test policy proposition Hi, We will never add those massive standalone tests into NUnit test (note that they are going to be separate module). But it still sounds nice to develop such integration as long as it is *optional* run. Note that the discussion also applies to the whole standalone test things BTW. Atsushi Eno RafaelMizrahi wrote: Hi Andrew and Atsushi, I suggest that all stand_alone test suites will output NUnit report. This way they can be included in build, regression reports etc' . ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Test policy proposition
Hi Rafi, RafaelMizrahi wrote: Atsushi, I did not suggest to convert or to run them as NUnit, I just suggest that it is better to have their output as NUnit report. Well, then how better is it? We don't have time data. asserts are always 1. There are known failures rather than success which only has True or False. It would be mapped to [Category (NotWorking)] which is not reported in our NUnit tests. Or alternatively it could be mapped to [Ignore], but there are another set of ignore.lst file which holds tests to be ignored. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Mainsoft switching to SVN : System.Data
Hello all As a part of an effort to share a common code base between Mono and Mainsoft, we've moved our System.Data development entirely to SVN. Also we aim to have as more common code as possible, its completely clear that because of our willing to base a connected mode implementation on JDBC, the most of its code will remain separate between Mono and Mainsoft. Thus, for the connected mode namespaces the Mainsoft-specific code resides in directories complementary to existing ones (for example, while Mono implementation of OleDb namespace located in System.Data.OleDb directory, Mainsoft implementation resides in System.Data.OleDb.jvm directory). In addition, the Mainsoft project file, named System.Data.vmwcsproj, was added to SVN System.Data root directory. Boris -- Boris Kirzner Mainsoft Corporation http://www.mainsoft.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] debugger module does not build
../frontend/Interpreter.cs(101) error CS0117: `Mono.Debugger.ThreadManager' does not contain a definition for `TargetOutputEvent' After a fresh checkout. Everything (mono/mcs/debugger) are uptodate (rev. 45194). Rodrigo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Test policy proposition
Hi Rafi, Ohh, ok, I should first say that I was talking about the results on comparing NUnit's resulting xml (TestResult-*.xml) structures. We don't have time data. If I understand you, time can be Now(). Well, when it is about test-results element, you are right. time attribute on each test-suite element is duration. asserts are always 1. Why is that ? the stand_alone test suite report will have one test with an assert for each xml test, that can pass or fail. So here I meant asserts attribute in tests. There are known failures rather than success In this case, Maybe Andrew proposal should remove the known failures Oh, no it is useful (actually I dare say it is required). We should not *remove* important bits just to make output to be equivalent to NUnit stuff. And analyzing the status of the test suite should be done through the NUnit reports system. My major goal is to have a unified report system, and not to have a special report for each stand_alone test suite. I choose NUnit report because we (mainsoft and mono) already created a report system for NUnit reports. Why not just write a stylesheet or another simple result aggregator that assembles test results (known failures, ignore-lists etc.) into NUnit-like output? It would be simpler than modifying existing output and (more importantly) keep things more human-readable. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] System.Drawing Tests - image recognitionsimilarities
At 11:05 AM 30/05/2005 +0300, Mizrahi Rafael wrote: Hi Jordi, (and mono devs) Mainsoft wish to invest some effort in testing System.Drawing. We wish to enhance the test suite with an image compare component which will compare the difference between the expected .NET image and the mono image. The comparer (which we just started prototyping it) will be customized and produce a result according to several algorithms: * Prior to compare: format, size, colors, resolution [snip] If you can wait for a short while, there's a decent chance that a patch enabling indexed pixel formats will make it into SVN. At the moment, libgdiplus only does 24- and 32-bit pixel formats (and its 24-bit support is a hack; the data is stored at 32 bpp anyway, and is converted to/from 24bpp when/if the user calls Bitmap::LockBits/UnlockBits :-). My patch adds support for 1-, 4- and 8-bpp images, but does not address the 24-bit issue. The 24-bit issue is imposed by Cairo, which works only with ARGB 32-bpp pixels internally; actually storing the data at 24 bpp would mean that it would have to be upsampled for pretty much every operation other than LockBits. It is a trade-off, but I think sacrificing speed in only one area is better than favouring that area over all others. Just thought I'd let you know :-) Jonathan Gilbert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] emitting a MethodInfo instance
I have a MethodInfo instance that I would like to emit into IL code.
Basically I need to emit a method call which takes a MethodInfo as an
argument, and the MethodInfo will be static when the IL code is
created. Is there an easy way to emit a MethodInfo instance?
The method I need to provide looks like this:
void Emit_MethodInfo( ILGenerator ig, MethodInfo method )
It looks like it could be done by emitting code which looks something
like typeof([type]).GetMethod([name], [args]), but that is
non-trivial and is not efficient:
{
// typeof([type]).GetMethod([name], [args])
ig.Emit( OpCodes.Ldtoken, method.DeclaringType );
ig.EmitCall( OpCodes.Call, Type_GetTypeFromHandle, null );
ig.Emit( OpCodes.Ldstr, method.Name );
ParameterInfo[] parms = method.GetParameters();
Type[] parTypes = new Type[parms.Length];
for( int parN = 0; parN parms.Length; ++parN)
parTypes[parN] = parms[parN].ParameterType;
// create an array to hold the types..
Emit_LoadInt( ig, parTypes.Length );
ig.Emit(OpCodes.Newarr, typeof(System.Type));
for(int i=0; iparTypes.Length; ++i)
{
ig.Emit(OpCodes.Dup);
Emit_LoadInt( ig, i );
Emit_GetTypeFromHandle( ig, parTypes[i] );
ig.Emit(OpCodes.Stelem_Ref);
}
ig.Emit( OpCodes.Call,
typeof(System.Type).GetMethod(GetMethod,
new Type[] { typeof(string), typeof(Type[]) }));
}
There must be a better way?
tia,
Valient
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Running Programs on Mono 1.1.7 on Windows and Cygwin
With the Mono 1.1.7 Windows Installer, I can run programs okay from the command-line, but I can not get it to work under Cygwin. Does anyone know why? Even if I try to set it via mono --config, it still does not work. [EMAIL PROTECTED] ~/monosvn/sqlsharpgtk/sqlsharpgtk $ mono --config E:\Mono-1.1.7\etc\mono\1.1\machine.config sqlsharpgtk.exe (unknown:1088): GLib-CRITICAL **: g_convert: assertion `str != NULL' failed Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for Mono.Data.ProviderFactory --- System.Configuration .ConfigurationException: Cannot find E:\Mono-1.1.7\etc:\mono\1.0\machine.config () in 0x000a6 System.Configuration.DefaultConfig:Init () in 0xd System.Configuration.DefaultConfig:GetConfig (System.String section Name) in 0x00069 System.Configuration.ConfigurationSettings:GetConfig (System.String sectionName) in 0xd Mono.Data.ProviderFactory:.cctor ()--- End of inner exception stack trace --- in 0x0 unknown method in 0x0001f Mono.Data.SqlSharp.GtkSharp.LoginDialog:PopulateProviders () in 0x0005b Mono.Data.SqlSharp.GtkSharp.LoginDialog:.ctor (Mono.Data.SqlSharp.G tkSharp.SqlSharpGtk sqlSharpGtk) in 0x0001c Mono.Data.SqlSharp.GtkSharp.SqlSharpGtk:Login () in 0x0003b Mono.Data.SqlSharp.GtkSharp.SqlSharpGtk:Main (System.String[] args) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Re: Determine the name and/or kind of CLI runtime environment
From: Rodrigo B. de Oliveira My only problem is Mono.Runtime is seems not to been always there. Could anyone suggest a better class name in mscorlib.dll? I use Mono.Type but I'm not sure about its availability on earlier releases. I was looking for Mono.Type but the I realized it is System.MonoType. It seems to been there from the beginning, it is Mono specific (in the name as well), internal, is inside mscorlib.dll, so it is good. Thanks for the class.:) Proposal to make this Mono detection method official: What about documenting that using the boolean expression (typeof(object).Assembly.GetType(System.MonoType) != null) is the recommented way to detect Mono? In this case it should be documented that this sould be used only to display the name of the runtime, if necessary runtime specific codes should be based on the existance of classes or not thrown exceptions. And it should be documented in MonoType.cs as well that this class should not be removed as it is used to detect Mono. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Re: emitting a MethodInfo instance
On 5/30/05, Valient Gough [EMAIL PROTECTED] wrote: void Emit_MethodInfo( ILGenerator ig, MethodInfo method ) It looks like it could be done by emitting code which looks something like typeof([type]).GetMethod([name], [args]), but that is non-trivial and is not efficient: Forgot to add, my first guess was actually to use OpCode.Ldtoken to directly load MethodInfo, because I found the following snippet in msdn online docs for OpCodes.LdToken: The following Emit constructor overloads can use the ldtoken opcode: * ILGenerator.Emit(OpCode, MethodInfo) * ILGenerator.Emit(OpCode, FieldInfo) * ILGenerator.Emit(OpCode, Type) However, when I try and emit (OpCode.Ldtoken, MethodInfo), that causes the ILGenerator to halt in mid-opcode, and monodis shows that last opcode as ldtoken with no args.. Perhaps ILGenerator.Emit(OpCode, MethodInfo) only works in mono 1.1.7 where OpCode == OpCode.Call* ? Valient ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Determine the name and/or kind of CLI runtime environment
On Mon, 2005-05-30 at 10:31 +0200, Kornl Pl wrote: Hi, Is there any official or unofficial but working way to determine what kind of CLI runtime environment is executing the assembly? There are at least three of them: -Microsoft .NET Framework -Mono -DotGNU Portable.NET They have different interfaces to low level runtime functionality and it is good if an error report contains the name of the CLI runtime as well. What do you recommend on detecting Mono from managed code? The name of the runtime alone isn't that useful. You'd probably want the version of Mono as well. Probably the best way to do this is to test if `basedir typeof (object).Assembly.Location`/mcs.exe is there (using c# + bash :-), and if it is to execute that with --version. (I guess you need to test for gmcs.exe too, since that is what will be there for 2.0...) If you want a simpler test, being able to load Mono.Posix via reflection would be a pretty good one. Much better than depending on an internal type like MonoType... -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] no regression policy for System.XML
Hello, I think this should apply to the rest of the code base: the only real solution is to run everything with each build. The Mythical Man Month comes to mind. It is not only about automated builds but also about hackers' builds. Have you ever tried bugfixing and accumulative test run? Am pretty sure that you will get stuck with your idea. Also, some of the buildbot machines runs slowly which is inevitable, e.g. cygwin build. Similarly, on my previous slower machine I needed a couple of minutes to just run OASIS XSLT tests (no MSFT tests). The builds frequently run whenever we want to verify the build sanity. So it is enough that the entire tests runs just *often*, say, once in a day (daily test). Excluding the slowest test will be risky. They are slow because they hit critical/complex paths more often than not. A bug caught here is worth more than anywhere else. Actually differentiating slower test and not working tests makes little sense (we don't differentiate now). What Andrew had in mind was (AFAIK, only) two testcases from MSFT xslt tests whose output is megabytes of outputs. The problem to solve is to increase the test/unit of time ratio so the slow and critical tests can be included. I have no idea what you have in mind, but I don't think there are such concrete thresholds. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
