RE: spam: suspected: Re: [Mono-devel-list] Graphics merge-in status
Hi Jonathan. For regression tests I write that rely on external files, I usually have a XXX-update target. For example, if make check runs the regression tests, then check-update would update the external resources. Good idea. I'll separate the platform from the generation of results. So if somebody has no dotnet, he'll be able to create a new test and generate expected result for this new test on Mono. The same will happen if some test fails on dotnet. For tests that I have expected results on dotnet, I'll create initial results on dotnet. I'll commit them to trunk/release/test-ext/ dir (as Atsushi did for xslt expected results), so they don't make mono tarbal bigger. How would you do this for System.Drawing? Probably extract all the .NET Compare() code into Update() methods, place all the Update() methods into a new .cs file, build that into a .exe during `make test`, and then a `test-update` makefile target which executes the new program. Probably, I'll just set an environment variable in the Makefile, so when Compare () sees that variable it will create expected result instead of comparing. For anything that would fail under .NET, mark the test with a [Category(NotDotNet)] attribute declaration. That way we ensure the test keeps working under Mono but it won't be run under .NET (thus avoiding spurious failures). Thank you. Andrew. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Graphics merge-in status
On Thu, 2005-08-04 at 00:06 -0700, Andrew Skiba wrote: I will create a directory under sys.drawing/test for this helper and will commit the helper as is. It needs few changes, however, to be usable for Mono. Today it checks TARGET_JVM to decide whether we are creating reference results on dotnet, or run tests. Of course, it does not suite Mono. I'd like to hear your ideas on how better to fix that. Might I suggest that you instead use an explicit update mechanism to produce the reference results? Requiring that you create the reference results requires that you actually have .NET around to produce them (which may not always be true), and also means that if .NET has a bug we can't provide a correct fix (bug-for-bug compatibility isn't always desirable -- see all the fixes made to System.Reflection.Emit). - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: spam: suspected: Re: [Mono-devel-list] Graphics merge-in status
Hello Jon. Thanks for your answer. I understand that ability to run tests without windows box is an advantage. I thought to commit expected results in similar way we did with XML tests. By explicit update mechanism do you mean any particular technique? Also, how do you suggest to solve the .NET bug problem? Might I suggest that you instead use an explicit update mechanism to produce the reference results? Requiring that you create the reference results requires that you actually have .NET around to produce them (which may not always be true), and also means that if .NET has a bug we can't provide a correct fix (bug-for-bug compatibility isn't always desirable -- see all the fixes made to System.Reflection.Emit). - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] Graphics merge-in status
I commited this helper. It is possible to compile and run it under Mono, but I did not make generate and test phases yet. I'll continue to work on it on Sunday. Anyway, code is available to play with, and there are basic Makefiles to build and run it. The next thing I want to do is to commit the drawing tests helper we started to develop at Mainsoft. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
