[Mono-dev] I finished my employement at Mainsoft
Hello. I finished my duties at Mainsoft, and started to work for Liveperson. So probably I will be less visible in the nearest future, and I want to thank all of you who worked with me. I enjoyed participating in Mono very much, and I had luck to work with outstanding people. Special thanks to Gonzalo, Chris, Luis, and of course to Atsushi. I will be very glad to work with you in the future. I keep my private key for svn and I hope to use it in my spare time when I will have some. Once in Mono - always in Mono :-). However, I probably will miss messages sent to mono-devel list so if you want to reach me for sure, CC to this gmail account. Good luck guys, Andrew. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.dll few patches for review
Hello Sebastien. I ran mono-api-check on both 1.1 and 2.0 profile, and it did not see any difference after I removed IEnumerable. So I will commit this patch and check class statuses of 1.1 and 2.0 in a few days. * X509CertificateCollection.patch - remove unnecessary overload If this doesn't cause any error with the class library status pages then remove (don't comment) it. The comment itself can be put in the ChangeLog. According to MSDN X509CertificateCollection does not implement IEnumerable privately. You're right. Anyway CollectionBase already implements IEnumerable. Not sure why it was put there (it's been there since the first commit in 2002). Actually, that means that the patch should look like in the new attachment. What do you mean by class library status pages? The old corcompare which is available online from http://www.mono-project.com/Class_Status You should check both 1.x and 2.0 profiles. I could run make run-test after this patch applied, and it gave same number of errors before and after the patch. Is that enough? No. It will spot functionality regressions but it won't spot errors in API definitions. I don't see how/why this could break but it's safer to always check the pages after an API change (either manually on your own computer or on the public pages a while after the check-in). -- Sebastien Pouliot [EMAIL PROTECTED] Blog: http://pages.infinit.net/ctech/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] FW: EventHandlerList implementation
Hello, Before we have our weekend, I'd like to resend this patch for approval. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Skiba Sent: Tuesday, October 03, 2006 15:48 To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] EventHandlerList implementation Please review the attached patch for EventHandlerList implementation. Here is the description: Implement event handler list according to MS definition. No hash table, just a simple list with good performance for a small number of events ( 20) and worse performance when number of events is bigger. EventHandlerList.patch Description: EventHandlerList.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] System.dll few patches for review
Hello. Please review these patches for System.dll. Part of them is needed to omit TARGET_JVM, so code will be common. * DigestClient.patch - use MD5.Create instead of HashAlgorithm.Create (MD5) * X509CertificateCollection.patch - remove unnecessary overload Thank you. Andrew. DigestClient.patch Description: DigestClient.patch X509CertificateCollection.patch Description: X509CertificateCollection.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] EventHandlerList implementation
Please review the attached patch for EventHandlerList implementation. Here is the description: Implement event handler list according to MS definition. No hash table, just a simple list with good performance for a small number of events ( 20) and worse performance when number of events is bigger. EventHandlerList.patch Description: EventHandlerList.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] System.dll bootstrap
Hello Raja. I'm working an GH System.dll project files to build them from Visual studio and I'm trying to understand how is it bootstrapped in 2.0. How many times is it compiled? It looks that the process must be like this: 1. System.dll w/o xml and configuration 2. System.Xml 3. System.dll w/ xml only (to make possible to declare IConfigurationSectionHandler.Create (..., XmlNode) 4. System.Configuration 5. System.dll - w/ xml and configuration But in System.dll makefile I don't see the step for i.3. So can you explain, how is the problem of IConfigurationSectionHandler solved then? Thanks in advance for your help. Andrew. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.dll few patches for review
Hello Sebastien, Part of them is needed to omit TARGET_JVM, so code will be common. There are no TARGET_JVM in the two files. As I said, these changes are needed to omit TARGET_JVM. * DigestClient.patch - use MD5.Create instead of HashAlgorithm.Create (MD5) This is ok in the sense that it will result in the exact same thing. So the question is: Is that change required ? if so, can you say why (and include the rational in the ChangeLog). After futher investigation, I see that this old limitation in Grasshopper is gone, so this patch is not necessary anymore. * X509CertificateCollection.patch - remove unnecessary overload If this doesn't cause any error with the class library status pages then remove (don't comment) it. The comment itself can be put in the ChangeLog. According to MSDN X509CertificateCollection does not implement IEnumerable privately. Actually, that means that the patch should look like in the new attachment. What do you mean by class library status pages? I could run make run-test after this patch applied, and it gave same number of errors before and after the patch. Is that enough? Thank you. Andrew. X509CertificateCollection.patch Description: X509CertificateCollection.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] several patches for System.dll
Hello. Please review these patches for System.dll. Part of them is needed to omit TARGET_JVM, so code will be common. * AcceptList.patch - stop using of non-standard methods from mscorlib * DigestClient.patch - use MD5.Create instead of HashAlgorithm.Create (MD5) * IOrderedDictionary.patch - fix the base intefaces list to match .Net * ListDictionary.patch - remove unused output parameter (expensive in Java) * X509CertificateCollection.patch - remove unnecessary overload Thank you. Andrew. AccessControl.patch Description: AccessControl.patch DigestClient.patch Description: DigestClient.patch IOrderedDictionary.patch Description: IOrderedDictionary.patch ListDictionary.patch Description: ListDictionary.patch X509CertificateCollection.patch Description: X509CertificateCollection.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] ConfigurationSettings patch
Hello. The attachment has a patch for ConfigurationSettings to add support for requirePermission attribute. Thank you. Andrew. ConfigSet.patch Description: ConfigSet.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] I need help with AppDomain or runtime bug
Hello, Gonzalo. Tried with r65944 and it happened on the second run. It's a Debian machine with 2.6.16-2-686-smp kernel. Thank you. Andrew. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gonzalo Paniagua Javier Sent: Tuesday, September 26, 2006 19:50 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] I need help with AppDomain or runtime bug On Mon, 2006-09-25 at 07:43 -0700, Andrew Skiba wrote: Hello. As I wrote a few mothes ago, when I made NunitWeb test framework, there a strange bug when I run tests on mono. Sometimes mono hangs, and oftentimes there are exceptions with the following stacktrace: Tick caught an exception that has not been propagated: System.NullReferenceException: Object reference not set to an instance of an object at System.Web.HttpApplication.ProcessError (System.Exception e) [0x0] at System.Web.HttpApplication+Pipeline__5.MoveNext () [0x0] at System.Web.HttpApplication.Tick () [0x0] Can you try if you still get that with current svn? I'm not getting them any more. -Gonzalo ___ 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
[Mono-dev] I need help with AppDomain or runtime bug
Hello. As I wrote a few mothes ago, when I made NunitWeb test framework, there a strange bug when I run tests on mono. Sometimes mono hangs, and oftentimes there are exceptions with the following stacktrace: Tick caught an exception that has not been propagated: System.NullReferenceException: Object reference not set to an instance of an object at System.Web.HttpApplication.ProcessError (System.Exception e) [0x0] at System.Web.HttpApplication+Pipeline__5.MoveNext () [0x0] at System.Web.HttpApplication.Tick () [0x0] It can happen at different tests, or not happen at all. I could not understand what causes it, but I could make the situation somewhat better by adding Sleep(100) before unloading AppDomain. Now, when we have hundreds of web tests, this hardly helps. Our QA-Dev guys have to run the tests few times until they don't stuck. To reproduce the problem, one should launch 'make run-test PROFILE=net_2_0' in System.Web directory. 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-dev] patch for System.Net/WebException.cs
Hello.
The previous testcase used a null for WebResponse. This may produce an
impression, that not-null response would produce a different
serialization result. So please consider an improved test in the
attachment. I attach the fix for WebException again, for your
convenience.
Thank you.
Andrew.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Andrew Skiba
Sent: Monday, September 18, 2006 15:31
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev] patch for System.Net/WebException.cs
Hello.
The following code reveils 2 problems in subj: wrong initial
value for Status, and incompatibility with .Net
serialization. To check the latter, run test on .net, rename
out.xml into in.xml and run test on mono. After applying the
patch the test passes and initial value for Status is the same.
using System;
using System.Runtime.Serialization.Formatters.Soap;
using System.Net;
using System.IO;
namespace dumb_GH20
{
class Program
{
static void Main (string[] args)
{
WebException def = new WebException ();
Console.Out.Write (def.Status);
WebException e = new WebException
(message, new Exception (inner),
WebExceptionStatus.PipelineFailure,
null);
SoapFormatter f = new SoapFormatter ();
FileStream fs = new FileStream
(out.xml, FileMode.CreateNew);
f.Serialize (fs, e);
WebException e1 = (WebException)
f.Deserialize (new FileStream (in.xml, FileMode.Open));
}
}
}
Thank you.
Andrew.
Program.cs
Description: Program.cs
WebException.patch
Description: WebException.patch
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] patch for System.Net/WebException.cs
Hello.
The following code reveils 2 problems in subj: wrong initial value for
Status, and incompatibility with .Net serialization. To check the
latter, run test on .net, rename out.xml into in.xml and run test on
mono. After applying the patch the test passes and initial value for
Status is the same.
using System;
using System.Runtime.Serialization.Formatters.Soap;
using System.Net;
using System.IO;
namespace dumb_GH20
{
class Program
{
static void Main (string[] args)
{
WebException def = new WebException ();
Console.Out.Write (def.Status);
WebException e = new WebException (message,
new Exception (inner), WebExceptionStatus.PipelineFailure,
null);
SoapFormatter f = new SoapFormatter ();
FileStream fs = new FileStream (out.xml,
FileMode.CreateNew);
f.Serialize (fs, e);
WebException e1 = (WebException) f.Deserialize
(new FileStream (in.xml, FileMode.Open));
}
}
}
Thank you.
Andrew.
WebException.patch
Description: WebException.patch
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [patch] System.Web.UI.WebControls/SqlDataSourceView.cs
Hello, Please review the attached patch for SqlDataSourceView.ExecuteSelect. A standalone test aspx is attached as well. It proves that in .Net ExecuteSelect returns DataView and not DataTableReader. This is important for implementing paging abilities for GridView. The test also demonstrates that only the first table is used when there are few tables in result. I did not run the test on mono, it was written to check what happens on .Net. In my fix, I changed the behavior for DataSourceMode == DataSet. According to MSDN, this mode is used when paging capabilities are necessary. .Net returns only the first table when the select returns more than one table, so did I. I did not check what happens when there are no tables (is that possible?), so I left the behavior untouched. Thank you. Andrew. SqlDataSourceView.patch Description: SqlDataSourceView.patch Default.aspx Description: Default.aspx ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] System.Web.UI.Control.ResolveClientUrl
Hello. Robert, I see that Gonzalo approved your patch for bug #77539. Are you going to commit it soon? I want to commit the attached patch, and it depends on yours. Gonzalo, can I commit the attached patch after patch for bug #77539 is in SVN? Thank you. Andrew. TableStyle.patch Description: TableStyle.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] (no subject)
Hi Robert, According to the code of the current ResolveUrl, it always returns an absolute path. However on dotnet, Page.ResolveUrl(aaa.jpg) returns aaa.jpg. So why we need ResolveClientUrl on 1.1, if ResolveUrl should return relative paths as well? I still don't understand, why .Net has 2 different functions? Andrew. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Jordan Sent: Thursday, July 27, 2006 13:48 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] (no subject) Hi Andrew, ResolveClientUrl is implemented here, together with a bugfix for ResolveUrl: http://bugzilla.ximian.com/show_bug.cgi?id=77539 Robert Andrew Skiba wrote: Hi, Gonzalo. Following our IRC conversation, I made some investigation. On 2.0 when I tried to render asp:table with BackImageUrl=~/c:\aaa.jpg I've got the following exception stacktrace: [HttpException (0x80004005): '~/c:\aaa.jpg' is not a valid virtual path.] System.Web.Util.UrlPath.CheckValidVirtualPath(String path) +210 System.Web.Util.UrlPath.Combine(String appPath, String basepath, String relative) +154 System.Web.UI.Control.ResolveClientUrl(String relativeUrl) +377 System.Web.UI.WebControls.TableStyle.FillStyleAttributes(CssStyleColle ct ion attributes, IUrlResolutionService urlResolver) +51 System.Web.UI.WebControls.Style.AddAttributesToRender(HtmlTextWriter writer, WebControl owner) +204 System.Web.UI.WebControls.TableStyle.AddAttributesToRender(HtmlTextWri te r writer, WebControl owner) +27 System.Web.UI.WebControls.WebControl.AddAttributesToRender(HtmlTextWri te r writer) +378 System.Web.UI.WebControls.Table.AddAttributesToRender(HtmlTextWriter writer) +38 System.Web.UI.WebControls.WebControl.RenderBeginTag(HtmlTextWriter writer) +17 System.Web.UI.WebControls.Table.RenderBeginTag(HtmlTextWriter writer) +16 System.Web.UI.WebControls.WebControl.Render(HtmlTextWriter writer) +17 On dotnet 1.1 I could not cause such exception no matter what URL I gave to BackImageUrl. Except that, I saw, that on dotnet ResolveUrl(aaa.jpg) returns aaa.jpg. So our Control.ResolveUrl should be fixed, because now it always returns an absolute path, including the application name. After that fix, on 1.1 ResolveUrl should be sufficient for TableStyle.AddAttributesToRender. On 2.0 I decided to make a minimal patch to fix my test, because I don't want to make big changes right now. If I had more time, I would do some refactoring, to make our call stack look similar to dotnet. There is lots of code duplication in our code in Style.WriteStyleAttributes, Style.FillStyleAttributes, TableStyle.FillStyleAttributes and TableStyle.AddAttributesToRender. Also, I decided not to try and find what ResolveClientUrl does. Its difference from ResolveUrl is undocumented, and can change. So I see no value in copying .Net behaviour, until clients will come with real testcases. I implemented the bare minimum to make my test pass. I attach the minimal patch for your review. Thank you. Andrew. -- -- ___ 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] How to include an assembly in mono documentation?
Hi. I want to add the documentation for the new test framework to the online Mono documentation. When I browse the documentation for Novel.Directory.Ldap, it looks that it was generated from XML comments. Code in mcs\class\System.Web.dotnet\Test\mainsoft\NunitWeb already has XML comments, what should I do to make the documentation to appear in http://www.go-mono.com/docs/ ? Thank you. Andrew. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] System.Web.UI.WebControls.AutoGeneratedField patch
Hi, please review the attached patch for AutoGeneratedField internal constructor. This fixes DetailsView_CreateAutoGenerateRow test. Andrew. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Web.UI.Page fix
Hi Gonzalo, Sorry for late answer. Lost track of this patch somehow. There is no mixing of virtual and physical pathes here. In string returned by Path.GetFileName there are no path separators, so the result is a virtual path. It's resolved with ResolveUrl when HtmlLink is created. Regards, Andrew. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gonzalo Paniagua Javier Sent: Friday, July 14, 2006 01:22 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] [PATCH] System.Web.UI.Page fix On Sun, 2006-07-09 at 08:41 -0700, Andrew Skiba wrote: [...] for (int i = 0; i css_files.Length; i++) - css_urls [i] = UrlUtils.Combine (physicalPath, Path.GetFileName (css_files [i])); + css_urls [i] = virtualPath + Path.GetFileName (css_files [i]); ptp.LinkedStyleSheets = css_urls; [...] Notice how physical and virtual paths are mixed here. That will fail on windows. -Gonzalo ___ 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] System.Web.UI.WebControls.AutoGeneratedField patch
Heh :-) Here you go. Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gonzalo Paniagua Javier Sent: Wednesday, July 26, 2006 21:25 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] System.Web.UI.WebControls.AutoGeneratedField patch On Wed, 2006-07-26 at 07:05 -0700, Andrew Skiba wrote: Hi, please review the attached patch for AutoGeneratedField internal constructor. This fixes DetailsView_CreateAutoGenerateRow test. Forgot the attachment? -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list AutoGeneratedField.patch Description: AutoGeneratedField.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Web.UI.Page fix
Please review the new patch instead of the previous one. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Skiba Sent: Thursday, July 06, 2006 16:29 To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] [PATCH] System.Web.UI.Page fix Hello, Please review the attached patch. This patch fixes the URL in head/link elements. PageTheme.GetStyleSheets () returns absolute pathes like C:/cygwin/monobuild/xsp/PWS1/App_Themes/White//Default.css. I checked the dotnet and it does the same. But the rendered link must look like App_Themes/White//Default.css. So I think it must be fixed where HtmlLink controls are created. The testcase for this bug is standalone/ThemeTest4/indexWithInit.aspx. Look at head-link-href before and after the fix. Thank you. Andrew. CssPath.patch Description: CssPath.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] UrlPropertyAttribute support for PageThemeCompiler
Hello, The attached test reveils the missing functionality in PageThemeCompiler and the attached patch provides it. In addition to the test here is some documentation on the issue (see Theme Graphics and Other Resources) : http://msdn2.microsoft.com/en-us/library/ykzx33wh.aspx if no one objects, I will commit. Andrew. UrlProperty.patch Description: UrlProperty.patch UrlProperty.test.patch Description: UrlProperty.test.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] [patch] System.Web.HttpApplication.InitOnce
Don't commit. It's a hack that fixes the problem for you, but we don't know why that happens. That happens because HttpContext.Current is set in HttpRuntime.RealProcessRequest, and when HttpApplication.Start runs in a different thread, HttpContext.Current is null. I explained it in more details here: http://bugzilla.ximian.com/show_bug.cgi?id=78583 To reproduce the bug cd to System.Web/Test/standalone/hosting/test1 and make run-test. Andrew. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [patch] System.Web.HttpApplication.InitOnce
Hello, While running in custom web hosting of NunitWeb I got a NullReferenceException from TemplateParser.cs:118. The problem is that HttpContext.Current is null. It's hard to reproduce in a small standalone test, though. So I attach the stacktrace of my exception together with the patch that fixes it. The fix changes the flow only when HttpContext.Current is null, but probably it should set it always, what do you guys think? Also I found an interesting blog entry on the of HttpContext.Current handling on dotnet: http://piers7.blogspot.com/2005/11/threadstatic-callcontext-and_02.html Any idea about how to create a testcase for the flow like in my stacktrace will be appretiated. If no one objects, I will commit. Andrew. System.NullReferenceException: Object reference not set to an instance of an object in [0x1] (at /home/andrews/monobuild/mcs/class/System.Web/System.Web.UI/TemplateParser.cs:118) System.Web.UI.TemplateParser:AddApplicationAssembly () in [0x0003d] (at /home/andrews/monobuild/mcs/class/System.Web/System.Web.UI/UserControlParser.cs:64) System.Web.UI.UserControlParser:.ctor (System.String virtualPath, System.String inputFile, System.Web.HttpContext context, System.String type) in [0x9] (at /home/andrews/monobuild/mcs/class/System.Web/System.Web.UI/MasterPageParser.cs:47) System.Web.UI.MasterPageParser:.ctor (System.String virtualPath, System.String inputFile, System.Web.HttpContext context) in [0x3] (at /home/andrews/monobuild/mcs/class/System.Web/System.Web.UI/MasterPageParser.cs:58) System.Web.UI.MasterPageParser:GetCompiledMasterType (System.String virtualPath, System.String inputFile, System.Web.HttpContext context) in [0x00507] (at /home/andrews/monobuild/mcs/class/System.Web/System.Web.UI/PageParser.cs:285) System.Web.UI.PageParser:ProcessMainAttributes (System.Collections.Hashtable atts) in [0x00047] (at /home/andrews/monobuild/mcs/class/System.Web/System.Web.UI/TemplateParser.cs:145) System.Web.UI.TemplateParser:AddDirective (System.String directive, System.Collections.Hashtable atts) in [0x002fe] (at /home/andrews/monobuild/mcs/class/System.Web/System.Web.UI/TemplateControlParser.cs:175) System.Web.UI.TemplateControlParser:AddDirective (System.String directive, System.Collections.Hashtable atts) in [0x000ad] (at /home/andrews/monobuild/mcs/class/System.Web/System.Web.UI/PageParser.cs:317) System.Web.UI.PageParser:AddDirective (System.String directive, System.Collections.Hashtable atts) in [0x00131] (at /home/andrews/monobuild/mcs/class/System.Web/System.Web.Compilation/AspGenerator.cs:353) System.Web.Compilation.AspGenerator:TagParsed (ILocation location, TagType tagtype, System.String tagid, System.Web.Compilation.TagAttributes attributes) in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_ILocation_TagType_string_TagAttributes (System.Web.Compilation.ILocation,System.Web.Compilation.TagType,string,System.Web.Compilation.TagAttributes) in [0x00015] (at /home/andrews/monobuild/mcs/class/System.Web/System.Web.Compilation/AspParser.cs:467) System.Web.Compilation.AspParser:OnTagParsed (TagType tagtype, System.String id, System.Web.Compilation.TagAttributes attributes) in [0x00100] (at /home/andrews/monobuild/mcs/class/System.Web/System.Web.Compilation/AspParser.cs:163) System.Web.Compilation.AspParser:Parse () in [0x00012] (at /home/andrews/monobuild/mcs/class/System.Web/System.Web.Compilation/AspGenerator.cs:248) System.Web.Compilation.AspGenerator:Parse (System.String file) in [0x00011] (at /home/andrews/monobuild/mcs/class/System.Web/System.Web.Compilation/AspGenerator.cs:265) System.Web.Compilation.AspGenerator:Parse () in [0x0004a] (at /home/andrews/monobuild/mcs/class/System.Web/System.Web.Compilation/AspGenerator.cs:278) System.Web.Compilation.AspGenerator:GetCompiledType () in [0x8] (at /home/andrews/monobuild/mcs/class/System.Web/System.Web.UI/PageParser.cs:334) System.Web.UI.PageParser:CompileIntoType () in [0x1] (at /home/andrews/monobuild/mcs/class/System.Web/System.Web.UI/TemplateControlParser.cs:73) System.Web.UI.TemplateControlParser:GetCompiledInstance () in [0xa] (at /home/andrews/monobuild/mcs/class/System.Web/System.Web.UI/PageParser.cs:101) System.Web.UI.PageParser:GetCompiledPageInstance (System.String virtualPath, System.String inputFile, System.Web.HttpContext context) in [0x4] (at /home/andrews/monobuild/mcs/class/System.Web/System.Web.UI/PageHandlerFactory.cs:41) System.Web.UI.PageHandlerFactory:GetHandler (System.Web.HttpContext context, System.String requestType, System.String url, System.String path) in [0x00068] (at /home/andrews/monobuild/mcs/class/System.Web/System.Web/HttpApplication.cs:1069) System.Web.HttpApplication:GetHandler (System.Web.HttpContext context) in lt;0x00b3bgt; System.Web.HttpApplication+lt;Pipelinegt;__2:MoveNext () HttpApplication.patch Description: HttpApplication.patch ___ Mono-devel-list
[Mono-dev] configure.in patch
Hello, This patch create a symlink at mono/runtime/etc/mono/2.0/web.config similar to mono/runtime/etc/mono/2.0/machine.config This is necessary to have web.config in user created host when running via mono-wrapper from make run-test If no one objects, I will commit. web.config.patch Description: web.config.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] RE: improved patch for ApplyTheme
Sorry, I sent the old patch in the last message. This is the correct one. -Original Message- From: Andrew Skiba Sent: Sunday, May 21, 2006 17:12 To: 'Chris Toshok' Cc: mono-devel-list@lists.ximian.com Subject: improved patch for ApplyTheme Hello, Chris. Sorry for the late answer. Please look at the test in sys.web/Tests/standalone/themes/PageLinks. On dotnet it outputs child.set_ImageUrl child.OnInit parent.set_ImageUrl parent.OnInit page.OnInit The property setters set_ImageUrl are called when the theme is applied. This is the output of unpatched sys.web: page.OnInit child.OnInit parent.OnInit In addition to the incorrect flow, this test shows the invalid behaviour (missing image). After applying the patch, both the flow and the image are fixed. Here is how the flow changed. Was: 1. InitializeTheme + ApplyThemeRecursive (incorrect recursion, should be in the same depth-first search as OnInit) 2. Init Recursive 3. ApplyMasterPage As result, 'ApplyThemeRecursive' did not affect any controls related to the master page feature. After the fix the flow became: 1. Initialize Theme 2. ApplyMasterPage 3. InitRecursive + ApplyTheme As a result, when the theme is applied, all the controls are already created. When I started to trace the order of set_ImageUrl, I found a mistake in my previous patch: first child.OnInit should be called, and only then ApplyTheme. Anyway, it's easy to see that on dotnet ApplyTheme (however it's named) is called during the same tree travel as OnInit. If no one objects I will commit. Andrew. ApplyTheme.patch Description: ApplyTheme.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
FW: [Mono-dev] new test framework works on dotnet
Title: Re: [Mono-dev] new test framework works on dotnet Hello Miguel, Thank youfor your response. I forgot to mention that I used cygwin to run mono, if that matters. When I sent QUIT to the Mono process, it terminated, with message about core dump, but core dump was not created. I did not manage to try it on Linux today, I'll try to do that on Sunday. Also I was not clear enough about the Sleep work around. With sleep, there is no hang problem, when I said that 'some tests still fail', I meant that they did not pass some assert. So right nowhang problemdoes not blockmy work. Andrew. From: Miguel de Icaza [mailto:[EMAIL PROTECTED]Sent: Wed 5/17/2006 4:14 PMTo: Andrew SkibaCc: mono-devel-list@lists.ximian.comSubject: Re: [Mono-dev] new test framework works on dotnet Hello, Some tests pass on Mono, but some of them need more effort. Sometimes mono vm stucks, I worked around that by adding Sleep at the beginning of each test. Some tests still fail.Mhm, very strange.Could you send a QUIT signal to the Mono process when it hangs? Thiswill help pinpoint. I added a custom target run-nunitweb-ondotnet and run-nunitweb-onmono to the makefile to run only the tests which use the new framework. So I'm looking for the help to make them all pass on mono, so we can run them as a part of a build. Andrew. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list--Miguel de Icaza [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] new test framework works on dotnet
Hello, The attached patch adds new tests to the system.web testsuite, using the new test framework. The tests can be built on mono and run on mono or on dotnet by using the standard target make run-test-ondotnet. Some tests pass on Mono, but some of them need more effort. Sometimes mono vm stucks, I worked around that by adding Sleep at the beginning of each test. Some tests still fail. I added a custom target run-nunitweb-ondotnet and run-nunitweb-onmono to the makefile to run only the tests which use the new framework. So I'm looking for the help to make them all pass on mono, so we can run them as a part of a build. Andrew. NunitWeb.patch Description: NunitWeb.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] framework for system.web tests
Hello, Chris. Are you sure you compiled the sources from the attached zip? Because in those sources I see code Console.WriteLine (res); Assert.AreEqual (@spana href=#_SkipLinkimg alt=Skip Navigation Links height=0 width=0 src=/NunitWeb/WebResource.axd?d=HkJ8fQo6w7kxQaySxHq4Lg2amp;t=63279744 5633148088 style=border-width:0px; //aa id=_SkipLink/a/span, res); And it's strange that such code simultaneously outputs !DOCTYPE ... and does not fail on Assert.AreEqual (span..., res). Anyway, I don't think this version of framework is relevant. In last 2 days I added functionality of aspx, and now most tests will be written using aspx, and not using custom handler. So I'm going to narrow the problem I reported yesterday, and hopefully to provide a testcase. Thank you. Andrew. Hm, If I compile Program.cs to Program.exe and run it with mono, here's what I see: $ mono Program.exe !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; head id=Head1title Untitled Page /title/head body form name=form1 method=post action=MyPage.aspx id=form1 input type=hidden name=__VIEWSTATE value= / div /div /form /body /html --- Looks like it's working? Chris ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] System.Web.UI/TemplateParser.cs patch
Hello, I tried to compile aspx from directory with spaces in the name, and got the following error. This patch fixes that bug. If no one objects, I will commit. bDescription: /bError compiling a resource required to service this request. Review your source file and modify it to fix this error. p bError message: /berror CS2001: Source file 'C:/Documents' could not be found error CS2001: Source file 'and' could not be found error CS2001: Source file 'Settings/andrews/Local' could not be found error CS2001: Source file 'Settings/Temp/tmpB9A.tmp\MyPage.aspx.cs' could not be found TemplateQuotes.patch Description: TemplateQuotes.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] HttpHandlerAction cosmetic patch
This keeps the inner exception. If noone objects, I will commit. HttpHandlerAction.patch Description: HttpHandlerAction.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] framework for system.web tests committed
Hi Chris. I committed it to sys.web/Tests/mainsoft/NunitWeb. There you will see new functionality like aspx and master page support. There is a primitive Makefile to build and run some sample tests with nunit-console2. However, I have some problem with aspx compilation on mono. I attach the exception stack trace to this message in case you will not be able to run tests. Can you give me a hint what can be a possible reason for this problem? Thank you. Andrew. System.Web.HttpException: --- System.NullReferenceException: Object reference not set to an instance of an object in 0x00018 System.Web.UI.TemplateParser:AddApplicationAssembly () in 0x00075 System.Web.UI.UserControlParser:.ctor (System.String virtualPath, System.String inputFile, System.Web.HttpContext context, System.String type) in 0x00018 System.Web.UI.MasterPageParser:.ctor (System.String virtualPath, System.String inputFile, System.Web.HttpContext context) in 0x00022 System.Web.UI.MasterPageParser:GetCompiledMasterType (System.String virtualPath, System.String inputFile, System.Web.HttpContext context) in 0x00c2d System.Web.UI.PageParser:ProcessMainAttributes (System.Collections.Hashtable atts) in 0x000cf System.Web.UI.TemplateParser:AddDirective (System.String directive, System.Collections.Hashtable atts) in 0x005c0 System.Web.UI.TemplateControlParser:AddDirective (System.String directive, System.Collections.Hashtable atts) in 0x00122 System.Web.UI.PageParser:AddDirective (System.String directive, System.Collections.Hashtable atts) in 0x001e2 System.Web.Compilation.AspGenerator:TagParsed (ILocation location, TagType tagtype, System.String tagid, System.Web.Compilation.TagAttributes attributes) in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_ILocation_TagType_string_TagAttributes (System.Web.Compilation.ILocation,System.Web.Compilation.TagType,string,System.Web.Compilation.TagAttributes) in 0x00023 System.Web.Compilation.AspParser:OnTagParsed (TagType tagtype, System.String id, System.Web.Compilation.TagAttributes attributes) in 0x00172 System.Web.Compilation.AspParser:Parse () in 0x0002e System.Web.Compilation.AspGenerator:Parse (System.String file) in 0x0002c System.Web.Compilation.AspGenerator:Parse () in 0x000aa System.Web.Compilation.AspGenerator:GetCompiledType () in 0x00029 System.Web.UI.PageParser:CompileIntoType () in 0x00011 System.Web.UI.TemplateControlParser:GetCompiledInstance () in 0x00035 System.Web.UI.PageParser:GetCompiledPageInstance (System.String virtualPath, System.String inputFile, System.Web.HttpContext context) in 0x00010 System.Web.UI.PageHandlerFactory:GetHandler (System.Web.HttpContext context, System.String requestType, System.String url, System.String path) in 0x001da System.Web.HttpApplication:GetHandler (System.Web.HttpContext context) in 0x00b5b System.Web.HttpApplication+Pipeline__5:MoveNext () --- End of inner exception stack trace --- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] framework for system.web tests
Why not adopt this to be part of the unit tests directly? That's definitely the idea - the patch just didn't provide any changes to the existing unit tests. My colleges Tal and Yoni are going to commit few tests as soon as this framework is ready. And if this is not possible, we should add it as another check so we can use make run-test-local as a way of ensuring that we have not broken anything. Putting the tests in Test/mainsoft just means that we will not likely run those until someone does the work and we will just ignore them and not get the benefit of having them. Right but there's no code here to actually run any new unit tests (or alter existing unit tests to make use of it). it's just framework code. I just figured getting it into svn someplace now (and later mv'ing it once we had patches to tests to started using it, or once we wrote new tests that depend on it) would be better than waiting until tests used it to get it in svn at all. Chris ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [WARNING : A/V UNSCANNABLE] RE: [Mono-dev]System.Web.UI.Pagepatch
I see. Sorry you did not write if the patch causes the problems, or
unpatched XSP also fails. Can you at least test Page.Web.Config.patch?
This patch waits almost 2 weeks. It allows to assign the default theme
or stylesheet theme for all pages in web.config. In the mean time I will
see what's the problem with the testcase.
Thank you.
Andrew.
-Original Message-
From: Chris Toshok [mailto:[EMAIL PROTECTED]
Sent: Monday, May 01, 2006 20:45
To: Andrew Skiba
Cc: mono-devel-list@lists.ximian.com
Subject: RE: [WARNING : A/V UNSCANNABLE] RE:
[Mono-dev]System.Web.UI.Pagepatch
I have yet to successfully test your patch. Hacking it
together on windows gets me this (this is without using your
custom controls. just the vanilla Default/master page):
[HttpException (0x80004005): Login1: LayoutTemplate does not
contain an IEditableTextControl with ID UserName for the username.]
System.Web.UI.WebControls.GenericContainer`1.FindControl(Strin
g id, Boolean required, String errorResourceKey) +1716147
System.Web.UI.WebControls.Login.get_UserNameInternal() +91
System.Web.UI.WebControls.Login.SetEditableChildProperties() +26
System.Web.UI.WebControls.Login.CreateChildControls() +179
System.Web.UI.Control.EnsureChildControls() +87
System.Web.UI.Control.PreRenderRecursiveInternal() +41
System.Web.UI.Control.PreRenderRecursiveInternal() +161
System.Web.UI.Control.PreRenderRecursiveInternal() +161
System.Web.UI.Control.PreRenderRecursiveInternal() +161
System.Web.UI.Control.PreRenderRecursiveInternal() +161
System.Web.UI.Control.PreRenderRecursiveInternal() +161
System.Web.UI.Control.PreRenderRecursiveInternal() +161
System.Web.UI.Page.ProcessRequestMain(Boolean
includeStagesBeforeAsyncPoint, Boolean
includeStagesAfterAsyncPoint) +1360
Chris
On Sat, 2006-04-29 at 23:16 -0700, Andrew Skiba wrote:
Hello, Chris.
So can I commit these patches yet?
Thank you.
Andrew.
-Original Message-
From: Chris Toshok [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 25, 2006 20:51
To: Andrew Skiba
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [WARNING : A/V UNSCANNABLE] RE: [Mono-dev]
System.Web.UI.Pagepatch
On Tue, 2006-04-25 at 02:16 -0700, Andrew Skiba wrote:
I'd like to see the test used for this as well.
Did you see the standalone test that I sent yesterday? For
convenience, I attach it to this message, too. It covers
the following patches:
ApplyTheme.patch
Page.Web.Config.patch
PageTheme.patch
At first blush the theme change looks ok, but I really don't
like the idea of adding the ApplyTheme behavior to OnInit.
Unless, of course, this is what actually happens in MS's
implementation.
It's not OnInit, it's in CreateChildControls flow. To
figure that out
in MS implementation I made this:
ah, sorry - I wasn't looking at the line numbers, I just searched
for the surrounding patch context.
public class MyLogin:Login
{
protected override void OnInit (EventArgs e)
{
Trace.WriteLine (before Login.OnInit);
base.OnInit (e);
Trace.WriteLine (after Login.OnInit);
}
protected override void AddedControl
(System.Web.UI.Control control,
int index)
{
Trace.WriteLine (before
Login.AddedControl);
base.AddedControl (control, index);
Trace.WriteLine (after
Login.AddedControl);
}
protected override void CreateChildControls()
{
Trace.WriteLine (before
Login.CreateChildControls);
base.CreateChildControls ();
Trace.WriteLine (after
Login.CreateChildControls);
}
}
public class MyImageButton:ImageButton
{
protected override void OnInit (EventArgs e)
{
Trace.WriteLine (ImageButton.OnInit);
base.OnInit (e);
}
public override void ApplyStyleSheetSkin
(System.Web.UI.Page page)
{
Trace.WriteLine
(ImageButton.ApplyStyleSheetSkin);
base.ApplyStyleSheetSkin (page);
}
public override string ImageUrl
{
get
{
return base.ImageUrl;
}
set
[Mono-dev] framework for system.web tests
Hello.
I created a simple framework that might help in creating unit tests for
system.web, and want to contribute it. When we tryed to write test for
SiteMapPath.Render, we saw that it needs many things from HttpContext.
Now it's possible to create a method that will run in a web context,
looking like:
public static void TestMapSitePath (HttpContext context, object
param)
{
Control c = new System.Web.UI.WebControls.MapSitePath
();
c.Page = new Page ();
using (HtmlTextWriter htw = new HtmlTextWriter
(context.Response.Output)) {
c.RenderControl (htw);
}
}
and to call it like this:
string res = NunitWeb.Helper.Run (TestMapSitePath, null));
the result can be used in a regular nunit assert:
Assert.AreEqual (@spana href=#_SkipLinkimg alt=Skip
Navigation Links height=0 width=0
src=/NunitWeb/WebResource.axd?d=HkJ8fQo6w7kxQaySxHq4Lg2amp;t=63279744
5633148088 style=border-width:0px; //aa
id=_SkipLink/a/span, res);
This framework works good on dotnet, but unfortunately, on mono there is
bug with web.config. I reproduced it, and reported here:
http://bugzilla.ximian.com/show_bug.cgi?id=78256. When it's fixed I hope
we will be able to use this framework on mono, too.
Is it OK to commmit this framework to sys.web/Tests ?
Regards,
Andrew.
NunitWeb.csproj
Description: NunitWeb.csproj
Web.config
Description: Web.config
Helper.cs
Description: Helper.cs
MyHandler.cs
Description: MyHandler.cs
MyHost.cs
Description: MyHost.cs
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [WARNING : A/V UNSCANNABLE] RE: [Mono-dev] System.Web.UI.Pagepatch
Hello, Chris.
So can I commit these patches yet?
Thank you.
Andrew.
-Original Message-
From: Chris Toshok [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 25, 2006 20:51
To: Andrew Skiba
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [WARNING : A/V UNSCANNABLE] RE: [Mono-dev]
System.Web.UI.Pagepatch
On Tue, 2006-04-25 at 02:16 -0700, Andrew Skiba wrote:
I'd like to see the test used for this as well.
Did you see the standalone test that I sent yesterday? For
convenience, I attach it to this message, too. It covers
the following patches:
ApplyTheme.patch
Page.Web.Config.patch
PageTheme.patch
At first blush the theme change looks ok, but I really don't like
the idea of adding the ApplyTheme behavior to OnInit.
Unless, of course, this is what actually happens in MS's
implementation.
It's not OnInit, it's in CreateChildControls flow. To
figure that out
in MS implementation I made this:
ah, sorry - I wasn't looking at the line numbers, I just
searched for the surrounding patch context.
public class MyLogin:Login
{
protected override void OnInit (EventArgs e)
{
Trace.WriteLine (before Login.OnInit);
base.OnInit (e);
Trace.WriteLine (after Login.OnInit);
}
protected override void AddedControl
(System.Web.UI.Control control,
int index)
{
Trace.WriteLine (before Login.AddedControl);
base.AddedControl (control, index);
Trace.WriteLine (after Login.AddedControl);
}
protected override void CreateChildControls()
{
Trace.WriteLine (before
Login.CreateChildControls);
base.CreateChildControls ();
Trace.WriteLine (after
Login.CreateChildControls);
}
}
public class MyImageButton:ImageButton
{
protected override void OnInit (EventArgs e)
{
Trace.WriteLine (ImageButton.OnInit);
base.OnInit (e);
}
public override void ApplyStyleSheetSkin
(System.Web.UI.Page page)
{
Trace.WriteLine
(ImageButton.ApplyStyleSheetSkin);
base.ApplyStyleSheetSkin (page);
}
public override string ImageUrl
{
get
{
return base.ImageUrl;
}
set
{
Trace.WriteLine (Set
ImageButton.ImageURL);
base.ImageUrl = value;
}
}
}
and changed in aspx asp:login and asp:imagebutton to
my:MyLogin
and my:MyImageButton
the output looked like:
before Login.OnInit
after Login.OnInit
before Login.CreateChildControls
ImageButton.ApplyStyleSheetSkin
Set ImageButton.ImageURL
before Login.AddedControl
ImageButton.OnInit
after Login.AddedControl
after Login.CreateChildControls
Also, the master page change doesn't seem necessary to me, in the
scope of the greater change. The controls will have their OnInit
methods's called properly when they're added to the
already Init'ed
controls.
If you do ApplyMasterPage after InitRecursive, then
elements defined
on master page do not get their themes. Just try the
standalone test I
sent, the difference is clear.
My comment was made under the assumption that the ApplyTheme
call was in OnInit (as above.)
I'll take a look at this further tonight probably.
Chris
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] aspx testcase
Hello, Chris. Yesterday you asked for testcases for my patches. The attached tar.gz includes a small website, which reveals the effect of the following patches: ApplyTheme.patch Page.Web.Config.patch PageTheme.patch If no one objects, I'll add the test to System.Web/Tests/standalone/theme directory in SVN, and will commit the patches listed above. Thank you. Andrew. PageLinks.tar.gz Description: PageLinks.tar.gz ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] LinkedStyleSheets in PageThemeCompiler
Hi Gonzalo, First I forgot to use VirtualPathUtility.Combine and committed my patch with simple concatenation. Immediately after that, I noticed my mistake and tried to fix it. But when I used VirtualPathUtility.Combine, I've got ArgumentException (basePath is not an absolute path, basePath); The basePath comes from Page.InitializeStyleSheet, and it's hard coded to be relative path. I see that many pathes are combined with simple concatenation. See 2 lines later: PageThemeFileParser ptfp = new PageThemeFileParser (virtualPath + Path.GetFileName (skin_files[i]), So I just leave things as they are. Andrew. Use VirtualPathUtility.Combine instead of plain string concatenation. -Gonzalo ___ 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
[Mono-dev] System.Web.UI.PageTheme patch
The attached patch uses LinkedStyleSheets from the PageTheme to insert links in page header. If no one objects, I will commit. Thank you. Andrew. PageTheme.patch Description: PageTheme.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] System.Web.UI.Page patch
The attached patch fixes the flow for themes combined with master pages. If no one objects, I will commit. Page.patch Description: Page.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] System.Web.UI.PageTheme patch
Hi Chris, Thanks for the response. Please review the fixed patch. The previous patch did not handle correctly the StyleSheetTheme and Theme combination. I'll look for the easiest way to test this in a mean time. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Toshok Sent: Sunday, April 23, 2006 18:28 To: Andrew Skiba Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] System.Web.UI.PageTheme patch could use a test case for this.. Chris On Sun, 2006-04-23 at 01:42 -0700, Andrew Skiba wrote: The attached patch uses LinkedStyleSheets from the PageTheme to insert links in page header. If no one objects, I will commit. Thank you. Andrew. ___ 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 PageTheme.patch Description: PageTheme.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] System.Web.UI.Control null reference exception test and fix
Please review the attached patch for test and fix. If no one objects, I will commit. Andrew. ControlNull.patch Description: ControlNull.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] System.Web.UI.Page patch
The attached patch provides an ability to set the default theme and stylesheet theme in Web.Config, as documented in http://msdn2.microsoft.com/en-US/library/950xf363.aspx If no one objects, I will commit. Page.Web.Config.patch Description: Page.Web.Config.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] System.Web.UI.Page patch
Please ignore the previous patch, review the new patch instead. Sorry for the inconvenience. The previous patch did not handle the situation when StyleSheetTheme should affect a control created by template (as ImageButton inside LoginView). To find out the correct flow, I subclassed an ImageButton in dotnet, and watched the order in which the following methods were called: EnsureChildControls, OnPreRender, OnLoad, OnInit, ApplyStyleSheetSkin, set_ImageUrl In current mono implementation theme is applied for all the control hierarchy before applying the master page. But at this stage many controls still don't exist. My previous patch solved problem with master page, but not with contols created during PreRerderRecursiveInternal. This patch solves the problem and removes code duplication for recursion. If no one objects, I will commit. Thank you. Andrew. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Skiba Sent: Sunday, April 23, 2006 11:46 To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] System.Web.UI.Page patch The attached patch fixes the flow for themes combined with master pages. If no one objects, I will commit. ApplyTheme.patch Description: ApplyTheme.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] LinkedStyleSheets in PageThemeCompiler
Hello. Please review the attached patch. Current implementation always returns null, this patch makes it return values similar to dotnet. Please ignore CR-LF problems in the patch, I will fix them before committing. If no one objects, I will commit. Thank you. Andrew. PageThemeCompiler.patch Description: PageThemeCompiler.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] LinkedStyleSheets in PageThemeCompiler
Title: RE: [Mono-dev] LinkedStyleSheets in PageThemeCompiler Hi, Gonzalo and Chris. Thanks for your comments. I will commit on Sunday, when I'm back in the office. Andrew. -Original Message- From: [EMAIL PROTECTED] on behalf of Gonzalo Paniagua Javier Sent: Thu 4/20/2006 10:05 AM To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] LinkedStyleSheets in PageThemeCompiler On Thu, 2006-04-20 at 09:01 -0700, Andrew Skiba wrote: Hello. Please review the attached patch. Current implementation always returns null, this patch makes it return values similar to dotnet. Please ignore CR-LF problems in the patch, I will fix them before committing. If no one objects, I will commit. Use VirtualPathUtility.Combine instead of plain string concatenation. -Gonzalo ___ 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
[Mono-dev] SiteMapNode.cs unit tests and fix
please review the attached patch for reproducing and fixing several null reference exceptions in SiteMapNode. Please, ignore the previous patch, that fixed the problem with 'attributes' field but did not fix 'roles' field. If no one objects, I will commit. SiteMapNode.patch Description: SiteMapNode.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] PageThemeFileParser.AddDirective
Hi Chris,
Please review the new patch.
BTW, what do you think on refactoring ThrowParseException into throw
ParseException? I mean to create the exception in the helper function,
but to throw it explicitely?
Thank you,
Andrew.
Index: PageThemeFileParser.cs
===
--- PageThemeFileParser.cs (revision 59261)
+++ PageThemeFileParser.cs (working copy)
@@ -51,8 +51,11 @@
}
internal override void AddDirective (string directive,
Hashtable atts)
- {
- ThrowParseException (Unknown directive: +
directive);
+ {
+ if (string.CompareOrdinal (directive,
Register) == 0)
+ base.AddDirective (directive, atts);
+ else
+ ThrowParseException (Unknown directive:
+ directive);
}
internal override Type DefaultBaseType {
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] PATCH custom WebControls in skin files
I don't want to commit code like this. This
Exception error = null;
try {
assembly = Assembly.LoadFrom (filename);
} catch (Exception e) { error = e; }
if (assembly == null)
ThrowParseException (Assembly + filename + not
found, error);
looks more cryptic than this:
try {
assembly = Assembly.LoadFrom (filename);
} catch (Exception e) {
throw CreateParseException (Assebly + filename +
not found, e);
}
So I'll wait for your opinion on refactoring ThrowParseException.
Thank you in advance.
Andrew.
patch looks fine, but I'd prefer an AddAssemblyByFileName
that looks more like AddAssemblyByName, as in:
internal virtual Assembly AddAssemblyByFileName (string
filename)
{
Assembly assembly = null;
Exception error = null;
try {
assembly = Assembly.LoadFrom (filename);
} catch (Exception e) { error = e; }
if (assembly == null)
ThrowParseException (Assembly +
filename + not found, error);
AddAssembly (assembly, true);
return assembly;
}
Chris
On Mon, 2006-04-10 at 02:34 -0700, Andrew Skiba wrote:
When I use a custom web control in a skin file, then the
dll holding
this control must be added to references when compiling
PageTheme. The
attached patch makes this possible. As such references is already
found by parsers of individual skins, it's only necessary
to add new
assemblies to the theme directory parser.
If no one objects, I will commit.
Index: ThemeDirectoryCompiler.cs
===
--- ThemeDirectoryCompiler.cs (revision 59261)
+++ ThemeDirectoryCompiler.cs (working copy)
@@ -62,7 +62,11 @@
if (!(o is ControlBuilder))
continue;
ptp.RootBuilder.AppendSubBuilder ((ControlBuilder)o);
- }
+ }
+
+ foreach (string ass in ptfp.Assemblies)
+ if (!ptp.Assemblies.Contains
(ass))
+
ptp.AddAssemblyByFileName (ass);
}
PageThemeCompiler compiler = new
PageThemeCompiler (ptp);
Index: TemplateParser.cs
===
--- TemplateParser.cs (revision 59261)
+++ TemplateParser.cs (working copy)
@@ -390,6 +390,20 @@
}
}
+ internal virtual Assembly AddAssemblyByFileName (string
filename)
+ {
+ try {
+ Assembly assembly = Assembly.LoadFrom
(filename);
+ AddAssembly (assembly, true);
+ return assembly;
+ }
+ catch (Exception e)
+ {
+ ThrowParseException (Assembly file +
filename + not found, e);
+ return null; //never gets here, only to
satisfy the compiler
+ }
+ }
+
internal virtual Assembly AddAssemblyByName (string
name)
{
if (anames == null)
___
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
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] TemplateControlCompiler.cs
As no one replied, I will commit the patch.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Andrew Skiba
Sent: Sunday, April 09, 2006 16:41
To: [EMAIL PROTECTED]
Cc: Mono-devel-list@lists.ximian.com
Subject: [Mono-dev] TemplateControlCompiler.cs
Hi, Chris.
At revision 56619 you introduced the following code at
TemplateControlCompiler.cs:176
if (builder is RootBuilder) {
typeString = parser.ClassName;
}
In my flow, parser.ClassName == Default_aspx, which is
unresolved, but parser.PartialClassName has the correct value
of _Default.
At BaseCompiler.Init there is a similar code:
if (parser.IsPartial) {
...
mainClass = new CodeTypeDeclaration (parser.PartialClassName);
...
} else {
...
mainClass = new CodeTypeDeclaration (parser.ClassName); }
So, what do you think of the following patch?
Thank you.
Andrew.
Index: TemplateControlCompiler.cs
===
--- TemplateControlCompiler.cs(revision 59261)
+++ TemplateControlCompiler.cs(working copy)
@@ -174,7 +174,10 @@
if (childrenAsProperties ||
builder.ControlType == null) {
string typeString;
if (builder is RootBuilder) {
- typeString = parser.ClassName;
+ if (parser.IsPartial)
+ typeString =
parser.PartialClassName;
+ else
+ typeString =
parser.ClassName;
}
else {
if (builder.ControlType != null
builder.isProperty
___
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
[Mono-dev] PATCH SiteMapNode
Use properties instead of fields to protect from null values. If no one
objects, I will commit.
Index: SiteMapNode.cs
===
--- SiteMapNode.cs (revision 59261)
+++ SiteMapNode.cs (working copy)
@@ -249,10 +249,10 @@
SiteMapNode node = ob as SiteMapNode;
if (node == null) return false;
- if (node.key != key ||
- node.url != url ||
- node.title != title ||
- node.description != description)
{
+ if (node.Key != Key ||
+ node.Url != Url ||
+ node.Title != Title ||
+ node.Description != Description)
{
return false;
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] PATCH: System.Web/SiteMapNode.cs - fix NullRef exceptions
This patch still does not handle situation when attributes==null and node.attributes!=null. Please review the corrected patch. If no one objects, I will commit. Index: SiteMapNode.cs === --- SiteMapNode.cs (revision 59261) +++ SiteMapNode.cs (working copy) @@ -238,7 +238,8 @@ node.title = title; node.description = description; node.roles = new ArrayList (roles); - node.attributes = new NameValueCollection (attributes); + if (attributes != null) + node.attributes = new NameValueCollection (attributes); if (cloneParentNodes ParentNode != null) node.parent = (SiteMapNode) ParentNode.Clone (true); return node; @@ -262,7 +263,9 @@ foreach (object role in roles) if (!node.roles.Contains (role)) return false; - if ((attributes == null || node.attributes == null) (attributes != node.attributes)) return false; + if (attributes == null || node.attributes == null) + return (attributes == null node.attributes == null); + if (attributes.Count != node.attributes.Count) return false; foreach (string k in attributes) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Konstantin Triger Sent: Tuesday, April 11, 2006 11:30 To: mono-devel Subject: [Mono-dev] PATCH: System.Web/SiteMapNode.cs - fix NullRef exceptions Hello, Attached a patch fixing NullRefs exceptions. If no one objects I'll commit. Regards, Konstantin Triger ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] PageThemeFileParser.AddDirective
I think CompareOrdinal is more appropriate here, so if you don't mind I will commit my patch. I actually already committed a patch that works more or less like the one you've written here. Chris ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] PATCH SiteMapNode
You are right. Sorry for the inconvenience. This patch isn't necessary. comparison works just fine in the face of null values. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] PageThemeFileParser.AddDirective
I disagree that it is more appropriate - it's case sensitive. I checked, and found that you are right and directives are case insensitive. FYI TemplateControlParser uses case-sensitive comparison everywhere. But anyway OrdinalComparison is more appropriate in this patch (with ignore case), you can look here for an example of unexpected results: ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.NETDEVFX.v20.en/cpref2/html/M_Syste m_String_Compare_2_16e9e883.htm So please review the fixed patch. Regards, Andrew. PageThemeFileParser.patch Description: PageThemeFileParser.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] PATCH: System.Web/SiteMapNode.cs - fix NullRefexceptions
Please review the patch including the testcase. Thank you. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Toshok Sent: Tuesday, April 11, 2006 15:09 To: Andrew Skiba Cc: mono-devel Subject: RE: [Mono-dev] PATCH: System.Web/SiteMapNode.cs - fix NullRefexceptions also please add a testcase for this. Chris On Tue, 2006-04-11 at 03:23 -0700, Andrew Skiba wrote: This patch still does not handle situation when attributes==null and node.attributes!=null. Please review the corrected patch. If no one objects, I will commit. Index: SiteMapNode.cs === --- SiteMapNode.cs (revision 59261) +++ SiteMapNode.cs (working copy) @@ -238,7 +238,8 @@ node.title = title; node.description = description; node.roles = new ArrayList (roles); - node.attributes = new NameValueCollection (attributes); + if (attributes != null) + node.attributes = new NameValueCollection (attributes); if (cloneParentNodes ParentNode != null) node.parent = (SiteMapNode) ParentNode.Clone (true); return node; @@ -262,7 +263,9 @@ foreach (object role in roles) if (!node.roles.Contains (role)) return false; - if ((attributes == null || node.attributes == null) (attributes != node.attributes)) return false; + if (attributes == null || node.attributes == null) + return (attributes == null node.attributes == null); + if (attributes.Count != node.attributes.Count) return false; foreach (string k in attributes) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Konstantin Triger Sent: Tuesday, April 11, 2006 11:30 To: mono-devel Subject: [Mono-dev] PATCH: System.Web/SiteMapNode.cs - fix NullRef exceptions Hello, Attached a patch fixing NullRefs exceptions. If no one objects I'll commit. Regards, Konstantin Triger ___ 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 SiteMapNode.patch Description: SiteMapNode.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] PageThemeFileParser.AddDirective
Sorry, my bad. Did not notice that TagAttributes.GetDictionary creates Hashtable with InvariantCultureIgnoreCase parameter. The url without ms-help is http://msdn2.microsoft.com/en-us/library/zkcaxw5y.aspx -Original Message- From: Chris Toshok [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 11, 2006 19:36 To: Andrew Skiba Cc: Mono-devel-list@lists.ximian.com Subject: RE: [Mono-dev] PageThemeFileParser.AddDirective On Tue, 2006-04-11 at 08:31 -0700, Andrew Skiba wrote: FYI TemplateControlParser uses case-sensitive comparison everywhere. where? these should be fixed. Chris ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] PageThemeFileParser.AddDirective
Hello, Chris. I attach skin file, that works perfectly in dotnet, but fails in mono. If I remove PageThemeFileParser.AddDirective, then TemplateControlParser.AddDirective perfectly performs the job. PageThemeFileParser.AddDirective overrides TemplateControlParser.AddDirective to make adding directives impossible. Why did you decide to block normal AddDirective functionality? Thank you in advance. Andrew. SkinFile.skin Description: SkinFile.skin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] PATCH custom WebControls in skin files
When I use a custom web control in a skin file, then the dll holding
this control must be added to references when compiling PageTheme. The
attached patch makes this possible. As such references is already found
by parsers of individual skins, it's only necessary to add new
assemblies to the theme directory parser.
If no one objects, I will commit.
Index: ThemeDirectoryCompiler.cs
===
--- ThemeDirectoryCompiler.cs (revision 59261)
+++ ThemeDirectoryCompiler.cs (working copy)
@@ -62,7 +62,11 @@
if (!(o is ControlBuilder))
continue;
ptp.RootBuilder.AppendSubBuilder
((ControlBuilder)o);
- }
+ }
+
+ foreach (string ass in ptfp.Assemblies)
+ if (!ptp.Assemblies.Contains
(ass))
+
ptp.AddAssemblyByFileName (ass);
}
PageThemeCompiler compiler = new
PageThemeCompiler (ptp);
Index: TemplateParser.cs
===
--- TemplateParser.cs (revision 59261)
+++ TemplateParser.cs (working copy)
@@ -390,6 +390,20 @@
}
}
+ internal virtual Assembly AddAssemblyByFileName (string
filename)
+ {
+ try {
+ Assembly assembly = Assembly.LoadFrom
(filename);
+ AddAssembly (assembly, true);
+ return assembly;
+ }
+ catch (Exception e)
+ {
+ ThrowParseException (Assembly file +
filename + not found, e);
+ return null; //never gets here, only to
satisfy the compiler
+ }
+ }
+
internal virtual Assembly AddAssemblyByName (string
name)
{
if (anames == null)
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] PATCH ThemeDirectoryCompiler.GetCompiledType fix
Hi Chris,
Please review the attached patch for the method in subj. If no one
objects, I will commit.
Index: ThemeDirectoryCompiler.cs
===
--- ThemeDirectoryCompiler.cs (revision 59261)
+++ ThemeDirectoryCompiler.cs (working copy)
@@ -44,7 +44,7 @@
public static Type GetCompiledType (string virtualPath,
HttpContext context)
{
/* XXX map the virtual path to a physical path
*/
- string physicalPath = virtualPath;
+ string physicalPath = context.Request.MapPath
(virtualPath);
string[] skin_files = Directory.GetFiles
(physicalPath, *.skin);
PageThemeParser ptp = new PageThemeParser
(virtualPath, context);
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] TemplateControlCompiler.cs
Hi, Chris.
At revision 56619 you introduced the following code at
TemplateControlCompiler.cs:176
if (builder is RootBuilder) {
typeString = parser.ClassName;
}
In my flow, parser.ClassName == Default_aspx, which is unresolved, but
parser.PartialClassName has the correct value of _Default.
At BaseCompiler.Init there is a similar code:
if (parser.IsPartial) {
...
mainClass = new CodeTypeDeclaration (parser.PartialClassName);
...
} else {
...
mainClass = new CodeTypeDeclaration (parser.ClassName);
}
So, what do you think of the following patch?
Thank you.
Andrew.
Index: TemplateControlCompiler.cs
===
--- TemplateControlCompiler.cs (revision 59261)
+++ TemplateControlCompiler.cs (working copy)
@@ -174,7 +174,10 @@
if (childrenAsProperties || builder.ControlType
== null) {
string typeString;
if (builder is RootBuilder) {
- typeString = parser.ClassName;
+ if (parser.IsPartial)
+ typeString =
parser.PartialClassName;
+ else
+ typeString =
parser.ClassName;
}
else {
if (builder.ControlType != null
builder.isProperty
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] HttpRequest.MapPath and UrlUtils.Combine code duplication
Hello.
I found code duplication, please review the patch to remove it.
If no one objects, I will commit.
Index: UrlUtils.cs
===
--- UrlUtils.cs (revision 59261)
+++ UrlUtils.cs (working copy)
@@ -101,7 +101,9 @@
if (rlength == 0)
return ;
- relPath = relPath.Replace (\\, /);
+ if (System.IO.Path.DirectorySeparatorChar !=
'/')
+ relPath = relPath.Replace
(System.IO.Path.DirectorySeparatorChar, '/');
+
if (IsRooted (relPath))
return Canonic (relPath);
Index: HttpRequest.cs
===
--- HttpRequest.cs (revision 59261)
+++ HttpRequest.cs (working copy)
@@ -1163,17 +1163,10 @@
if
(virtualPath.StartsWith(vmw.common.IAppDomainConfig.WAR_ROOT_SYMBOL))
return virtualPath;
#endif
- if (System.IO.Path.DirectorySeparatorChar !=
'/')
- virtualPath = virtualPath.Replace
(System.IO.Path.DirectorySeparatorChar, '/');
-
- if (UrlUtils.IsRooted (virtualPath))
- virtualPath = UrlUtils.Canonic
(virtualPath);
- else {
- if (baseVirtualDir == null)
- baseVirtualDir = RootVirtualDir;
- virtualPath = UrlUtils.Combine
(baseVirtualDir, virtualPath);
- }
+ if (baseVirtualDir == null)
+ baseVirtualDir = RootVirtualDir;
+ virtualPath = UrlUtils.Combine (baseVirtualDir,
virtualPath);
if (!allowCrossAppMapping){
if (!StrUtils.StartsWith (virtualPath,
RootVirtualDir, true))
throw new HttpException
(MapPath: Mapping across applications not allowed);
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] UrlEncode patch
Hi guys, The patch contains new unittest, passing on dotnet and failing on mono, and fix for that unittest. This is an old issue, probably you remember as Ben suggested an improvement for the testcase. I did that improvement, please tell me what you think now. The new unittest passes on dotnet and after the fix it passes on mono, too. Thank you. Andrew. HttpUtility.patch Description: HttpUtility.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] UrlEncode patch
Hello again. After posting the previous patch I noticed that UrlEncodeUnicode has all the problems that UrlEncode had, plus it did not handle right all characters after 0x100. So I made some refactoring, united the common code into private method UrlEncodeChar, and made additions to the unit test so it checks the both. Please review the new patch. If nobody objects, I will commit. Thank you. Andrew. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Skiba Sent: Sunday, April 02, 2006 14:09 To: Ben Maurer; [EMAIL PROTECTED] Cc: Mono-devel-list@lists.ximian.com Subject: [Mono-dev] UrlEncode patch Hi guys, The patch contains new unittest, passing on dotnet and failing on mono, and fix for that unittest. This is an old issue, probably you remember as Ben suggested an improvement for the testcase. I did that improvement, please tell me what you think now. The new unittest passes on dotnet and after the fix it passes on mono, too. Thank you. Andrew. HttpUtility.patch Description: HttpUtility.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] performance patch for TypeDescriptor
Hello,
I found a big performance trouble relative to dotnet with the following
code:
static void Main(string[] args)
{
while (true) {
DateTime start = DateTime.Now;
for (int i=0; i1000; i++) {
TextBox tb = new TextBox ();
TypeDescriptor.GetProperties (tb);
tb.Dispose ();
}
TimeSpan ts = DateTime.Now - start;
Console.WriteLine (ts.ToString());
}
}
on dotnet it takes 12 seconds to perform 10,000,000 of such loops, while
on mono it takes 20 second for 10,000. So the performance is worse in
more than 1000 times.
'TypeDescriptor.GetProperties(Object component)' treats component
differently if it
implements IComponent. This is done in order to allow the component
'Site' to filter
the attributes (see TypeDescriptor lines 760-764).
However, if the Site of the component is null all of this is unnecessary
and one can
use the component type to retrieve the components properties. We have
seen that
System.Web.UI.Control implements IComponent but its Site property is
always null (unless
modified by the programmer explicitly) making this case frequent and
important.
We therefore propose the attached patch that uses the component's type
to retrieve its
properties, events and attributes if the component Site property is
null, and uses the
component only if Site is not null.
I attach also a simple WebForm that reveals the performance gain in a
real web environment.
To test it, make a GET request, set the value of TextBox1 to a string
starting with 'a' to pass
validation, and make POST. Before this patch I had 1800 rps, and after -
2600 rps.
Regards, Andrew.
TypeDescriptor.cs.patch
Description: TypeDescriptor.cs.patch
WebForm1.aspx
Description: WebForm1.aspx
WebForm1.aspx.cs
Description: WebForm1.aspx.cs
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] UrlEncode difference in dotnet and mono
Hi Ben. You wrote A much better test would be to copy to proposed impl into the test suite (you'd first have to make sure manually that it gives the exact same result for any given char as msft). Then make the test check that the result is the same as the copied impl. This would be a great start if we want to make perf improvements. I did not understand what you mean. Do you want me to make expected results for 64K chars, like I did for the first 127? First 127 I checked with dotnet, and yes, it gives the same results after the fix I proposed. Andrew. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] UrlEncode difference in dotnet and mono
Hi Ben. You wrote: + for (char c=Char.MinValue; c128; c++) chars are from 0 to 2^16-1 I do check those chars. Look at the second loop that iterates from 128 to Char.MaxValue (did you notice it?) Let me clarify my idea: I could not create expected results for 64K characters, so I did so only for ASCII (in the first loop) and for the rest I check that a character does not stay the same (gets some encoding). Surely this can be improved by the interested hacker. Regards, Andrew. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] UrlEncode difference in dotnet and mono
Hi Ben,
Sorry for late answer.
I have problems with Mono System.Web at my cygwin, so if there is anyone
still interested in solving the problem, I attach the unittest and the
fix here, please check they are correct. The unittest is based on the
test I made successfully on dotnet and Grasshopper after applying the
patch.
Regards, Andrew.
Index: System.Web/HttpUtility.cs
===
--- System.Web/HttpUtility.cs (revision 55002)
+++ System.Web/HttpUtility.cs (working copy)
@@ -650,7 +650,7 @@
int end = offset + count;
for (int i = offset; i end; i++) {
char c = (char) bytes [i];
- if ((c == ' ') || (c '0' c != '-'
c != '.') ||
+ if ((c == ' ') || (c '0' c != '-'
c != '.' c != '*') ||
(c 'A' c '9') ||
(c 'Z' c 'a' c != '_') ||
(c 'z')) {
Index: Test/System.Web/HttpUtilityTest.cs
===
--- Test/System.Web/HttpUtilityTest.cs (revision 55002)
+++ Test/System.Web/HttpUtilityTest.cs (working copy)
@@ -131,6 +131,21 @@
Assert.AreEqual (%7f,
HttpUtility.UrlEncodeUnicode ( + (char) 127), #4);
Assert.AreEqual (%u0080,
HttpUtility.UrlEncodeUnicode ( + (char) 128), #5);
}
+
+ [Test]
+ public void UrlEncode ()
+ {
+ string expected =
%00%01%02%03%04%05%06%07%08%09%0a%0b%0c%0d%0e%0f%10%11%12%13%14%15%16%1
7%18%19%1a%1b%1c%1d%1e%1f+!%22%23%24%25%26'()*%2b%2c-.%2f0123456789%3a%3
b%3c%3d%3e%3f%40ABCDEFGHIJKLMNOPQRSTUVWXYZ%5b%5c%5d%5e_%60abcdefghijklmn
opqrstuvwxyz%7b%7c%7d%7e%7f;
+ StringBuilder sb = new StringBuilder ();
+ for (char c=Char.MinValue; c128; c++)
+ sb.Append
(System.Web.HttpUtility.UrlEncode(c.ToString()));
+ Assert.AreEqual (expected, sb.ToString ());
+ for (char c=(char)128; c Char.MaxValue; c++) {
+ string s = c.ToString();
+ Assert.IsTrue (s !=
System.Web.HttpUtility.UrlEncode(s),
+ UrlEncode must escape character
'+s+');
+ }
+ }
}
}
-Original Message-
From: Ben Maurer [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 22, 2005 01:14
To: Andrew Skiba
Cc: [EMAIL PROTECTED]; Mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] UrlEncode difference in dotnet and mono
Hi Gonzalo,
I found that UrlEncode behaves differently in dotnet and
Mono, namely
Mono encodes the asterisk (*) symbol into %2a.
The following code prints different values, for example:
public static void Main ()
{
Console.Out.WriteLine
(System.Web.HttpUtility.UrlEncode(aaa*bbb));
}
A naive fix might be like this, but may be there are
similar problems
with other characters. What do you think?
This should really come with a unit test. In fact, what
really should be done is to generaate a table of UrlEncode
(c) for c in [0...char.MaxValue] on msft and check that we
give the same results. This would make sure we have no other issues.
-- Ben
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] UrlEncode difference in dotnet and mono
Hi Gonzalo,
I found that UrlEncode behaves differently in dotnet and Mono, namely
Mono encodes the asterisk (*) symbol into %2a.
The following code prints different values, for example:
public static void Main ()
{
Console.Out.WriteLine
(System.Web.HttpUtility.UrlEncode(aaa*bbb));
}
A naive fix might be like this, but may be there are similar problems
with other characters. What do you think?
Index: HttpUtility.cs
===
--- HttpUtility.cs (revision 54691)
+++ HttpUtility.cs (working copy)
@@ -650,7 +650,7 @@
int end = offset + count;
for (int i = offset; i end; i++) {
char c = (char) bytes [i];
- if ((c == ' ') || (c '0' c != '-'
c != '.') ||
+ if ((c == ' ') || (c '0' c != '-'
c != '.' c != '*') ||
(c 'A' c '9') ||
(c 'Z' c 'a' c != '_') ||
(c 'z')) {
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Cosmetic fix for XslTranslate
Hi Eno,
I saw in one of the overloads there is a check that stylesheet was
loaded, and in the other there is no such check, so instead of
XsltException there will be NullPointerException. Please review the
patch to fix it.
Regards,
Andrew.
Index: XslTransform.cs
===
--- XslTransform.cs (revision 52469)
+++ XslTransform.cs (working copy)
@@ -192,6 +192,9 @@
void Transform (XPathNavigator input, XsltArgumentList
args, TextWriter output, XmlResolver resolver)
#endif
{
+ if (s == null)
+ throw new XsltException (No stylesheet
was loaded., null);
+
Outputter outputter = new
GenericOutputter(output, s.Outputs, output.Encoding);
new XslTransformProcessor (s).Process (input,
outputter, args, resolver);
outputter.Done ();
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] RE: porting tool
Title: RE: porting tool Sure. In the most simple scenario you run $ find -type fINDEX And then use this index as both source and target list. Typically one will filter executables out of this list, as well as svn directories, etc. Then you can run $ mono CaseRePorter.exe INDEX INDEX out.lst and see what is in the out.lst. If you see too much noise in it, you can review your INDEX and remove the noising files. Hopefully you get output like file1.ext ./path/path/file2.cs:100: s = new StreamWriter (file1.EXT); then you go to file2.cs and fix the name. As I said, I ran it on a big project tree (after FEW iterations tuning INDEX) and I had no noise, and ~1000 lines of useful output. Lots of files were referenced with wrong case from everywhere - aspx pages, xmls, csharp sources, you name it. Unfortunately, I am not familiar with AspNetForums, so I don't know if this tool will help there. I'm not sure exactly how one would use this tool. Can you walk me through how I would take a typical web application (say, AspNetForums) and fix up the path references? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] RE: porting tool
Title: RE: [Mono-dev] RE: porting tool Thank you for comments, especially for idea of bin files. So what's in your opinion is the right place in mono tree for such tool? This is a clever idea. Just a few suggestions: 1) try testing for binary files when you open something to see if it has any path references in it. For our purposes, binary file can be defined as any file which contains a \0 in it's first 8 kb of data. The chance of a randomly generated file failing this test is (255/256)^(8*1024), or 1.2 × 10^-14. This should prevent any need for tuning. wow, that's really good idea. 2) would need a manpage, etc to show how to use it. I will start with a simple README 3) Why not have a mode where it does the find -type f for you, and then looks at all the files. This will be practical once you do 1 to remove binary files from consideration. I started with the find phase included, but then I saw that I want a manual intervention. As I said, plain find produces some noise. And in such projects I usually run few finds and create indeces to search for files faster. As these indeces include many files from the actual tree, they slow down the process alot. Especially with the naive search algorithm I used. But now I have a better algorithm in mind, stay tuned ;-) 4) IMHO, we shouldn't only look at files, directories might be referenced too. Again, I started with directories included, but then many directories like ./Something/Xml produced noise on every string like ?xml version=3.0?. Files are better, because they usually have extensions. And if you control the find phase, nobody prevents you from running find without -type f. 5) Any ideas on how to catch not using path.combine? not yet :-( -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] RE: patch for xmlconf.cs
Hi Eno, Good idea, I like it. Please commit this patch. Thank you, Andrew. -Original Message- From: Atsushi Eno [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 22:23 To: Andrew Skiba Cc: mono-devel Subject: patch for xmlconf.cs Hi Andrew, I think xmlconf.exe should also include the actual error message in addition to the stack trace string. Does the attached patch look OK for you? Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] RE: [Mono-patches] r48417 -trunk/mcs/class/System.Drawing/System.Drawing
Just for curiosity: can svn:eol-style of parent dir take care of all the files? * Color.cs: Fixed line endings. Set eol-style to native. * ColorConverter.cs: Fixed line endings. Set eol-style to native. * Size.cs: Set eol-style to native. * SizeF.cs: Use current culture in ToString(), set eol-style to native. * SizeConverter.cs: Take culture into account when converting to/from string. Set eol-style to native. * Point.cs: Fixed line endings. Set eol-style to native. * PointF.cs: Use current culture in ToString(), set eol-style to native. * PointConverter.cs: Take culture into account when converting to/from string. Set eol-style to native. * ImageFormatConverter.cs: Fixed line endings. Set eol-style to native. * RectangleConverter.cs: Fixed line endings. Set eol-style to native. Property changes on: trunk/mcs/class/System.Drawing/System.Drawing/Color.cs ___ Name: svn:eol-style + native ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] RE: [Mono-patches] r48374 - in trunk/mcs/class/System.Drawing: .System.Drawing Test/System.Drawing
I wrote some test cases, and searched for a culture-specific character that matches the results I got. You wrote tests that demonstrate the difference in behavior of dotnet and mono before your fixes? Can you add these tests to the testsuite, or at least send these tests to the devlist? Thank you. Andrew. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] RE: [Mono-patches] r48374 - in trunk/mcs/class/System.Drawing: .System.Drawing Test/System.Drawing
Hi Gert. Can you please tell me, how do you know that dotnet uses the CultureInfo.InvariantCulture.TextInfo.ListSeparator and not hardcoded comma? And BTW you did not change CT#3 testcase, so it fails now: Failures: 1) MonoTests.System.Drawing.ColorConverterFixture.ConvertTo : CT#3 String lengths are both 14. Strings differ at index 2. expected:10, 20, 30, 40 but was:10. 20. 30. 40 -^ Thank you. Andrew Skiba. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] RE: [Mono-patches] r48374 - in trunk/mcs/class/System.Drawing: .System.Drawing Test/System.Drawing
Hi Gert. You wrote: I'm still working on additional fixes and tests, I should get things stable today (meaning tests should pass on both mono and MS.NET). Gert Can you make things stable before committing, please? We are actively working on System.Drawing these days, and it is very disturbing when tests fail on mono and dotnet (before we speak about java). Also it takes time to review commits if they are lengthy, have reformatting changes like - -using NUnit.Framework; using System; -using System.Drawing; using System.Collections; using System.ComponentModel; +using System.Drawing; using System.Globalization; +using System.Threading; +using NUnit.Framework; + and svn:eol-style changes for tens of files. Can you at least during our active development in the same namespace try to minimize diffs? It's fine to remove unused TearDown functions and Assertion inheritance sometime, but why to do it now, when we work on the very same files, so it can produce more conflicts? 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-dev] not implemented destructor in FontNameConverter
As a temporary solution I committed TARGET_JVM so that this destructor will not be present in our build, but probably it's worth to do same for Mono, too. I wonder, what was the need to throw NotImplementedException in FontNameConverter destructor? What will do GC when destructor fails in such way? The code is in FontConverter.cs:283 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] PointConverter patch
Added GetStandardValuesSupported to the previous patches. Includes previous changes, too. PointAndRectangle.patch Description: PointAndRectangle.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] PointConverter patch
Add same tests for SizeConvertor. If no one objects, I will commit. PointRectangleSize.patch Description: PointRectangleSize.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] ColorConverter tests and fixes
Hi. Please review the attached patches. The tests are written from scratch, so I made as Ben and Jordi suggested regarding ExpectedExceptions. In 2 places it revealed a difference in the exception thrown in dotnet and mono. Also the new tests uncovered a few bugs in ColorConverter class. One of them was not taking care of FormatException in GetNumber function. The other is not really a bug, but incompatibility with undocumented dotnet feature. It appears, that ConvertTo does not insert into the result string the alpha when the alpha is 255. If no one objects, I will commit. Thank you. Andrew. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] ColorTranslator tests and fixes
Please review the attached ColorTranslator tests and fixes. The fixes patch includes the previously sent fixes for ColorConverter tests, as well. If no one objects, I will commit. Thank you. Andrew. ColorConverterAndTranslator.patch Description: ColorConverterAndTranslator.patch ColorTranslatorTest.patch Description: ColorTranslatorTest.patch ___ 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
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
[Mono-devel-list] Delete old xml standalone test dir
Hello, Eno. Today I saw someone trying to run old sys.xml/Test/System.Xml/standalone_tests testsuite. It's outdated and it fails on svn latest. As it is completely replaced by Test/System.Xml/W3C suite, may be it's better just to remove the old one (or move it to deleted dirs), so it does not confuse people anymore? Thank you. Andrew. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Graphics merge-in status
Hello.
Yesterday I finished merging out our changes to System.Drawing. Vast
majority of changes were java-specific.
The next thing I want to do is to commit the drawing tests helper we
started to develop at Mainsoft.
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.
Few words on the idea of this tool.
It is supposed to aid in writing tests that result in drawing. So there
is a class that provides 3 main features:
* Graphics property which can be used for any drawing operations
* Show method that opens a window with the result of the drawing to see
results manually
* Compare methods family - I will explain that in more details below.
So a typical test case will look like:
[Test]
public void DrawRectTest ()
{
DrawingTest t = DrawingTest.Create (200, 200); //create helper
class instance with drawing area of this size
t.Graphics.DrawRectangle (Pens.Blue, 10, 10, 150, 180);
t.Show (); // optional
Assert.IsTrue (t.Compare ());
t.Graphics.DrawRectangle (Pens.Red, 50, 20, 190, 30);
Assert.IsTrue (t.Compare ());
}
Now I will explain what Compare is all about.
When it's run on dotnet, Compare always returns true and as a side
effect it creates expected result named DrawRectTest:X where X is the
sequential number of the call inside DrawRectTest function. The name of
the function is extracted from the call stack.
When it later is run on java, Compare will find the expected result that
dotnet created and compare the FFT of the resulting bitmaps. If the
bitmaps were similar enough, it will return true. There is an overload
with tolerance parameter, for fine-tuning weird tests.
The comparing itself is done very approximately at this stage, actually
it's very easy to confuse the algorithm. It only calculates the sum of
the squares of all FFT values for every picture and compares the sums
for java and dotnet. This was done because it's very easy to keep one
number per expected result.
Any questions and suggestions are welcome.
Andrew.
___
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
RE: [Mono-devel-list] Merging our System.Drawing
Hello Jordi, Tuesday, August 2, 2005, 6:49:37 PM, you wrote: I think that we should add a test unit for this class also. Can you write it ? I would like to see the patch and the unit test applied to the tree at the same time. I know that we have not been very good writing test units for System.Drawing, but this is really the way that should be done. Sorry, the patch included the whole file because of whitespace difference. Please review the fixed patch to make sure it is really innocent. In any case, this patch is not mine, it's only a part of the merge. There are good chances we will write a test fixture for this class. As you can see, I write tests for all classes I deal with - starting with basic Point and Rectangle structs, then will follow Pen and Brush and so on. What is blocking us now is that our team is partly using our old ClearCase repository and partly new files from SVN, so I want to do merge ASAP so everybody can use SVN exclusively. If you can accept those merge changes without tests, I promise you will be flooded with unit tests in nearest days :-) 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] Merging our System.Drawing
Sorry, the patch included the whole file because of whitespace difference. Please review the fixed patch to make sure it is really innocent. Sorry, forgotten to attach the patch. ColorTranslator.patch Description: ColorTranslator.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] Merging our System.Drawing
Thank you. What about patches sent on Sunday, can I commit them yet? Please, commit the patch. Thanks for your work. Jordi, ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Merging our System.Drawing
Hello. I am starting to merge out our fixes to System.Drawing, together with TARGET_JVM ifdefs. The goal is to use Mono SVN as our primary source repository for System.Drawing. Patches that do not change flow with TARGET_JVM undefined I will commit without sending to devlist, and those that affect flow of Mono I will post here for review. The attached file is the first patch, adding to ColorTranslator ability to produce HTML color names for system colors. Thank you. Andrew. P.S. Can I commit all patches I sent yesterday? ColorTranslator.patch Description: ColorTranslator.patch ___ 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.Pens test patch
Hi Ben. Thanks for your comments. What you suggest is really the cleanest solution. Unfortunately, to use it, it's necessary to separate positive parts of tests from those that are expected to throw exceptions. In part of places, it's relatively easy to do, in other it requires refactoring of the whole class (see TestSystemPens.CheckMethods() for example). So it's not worth the effort to do big changes in the tests right now. If you guys consider my patch as improvement of current situation, I'll commit it. Thank you. Andrew. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Mainsoft branch for System.Drawing
Hello. We are going to implement a big part of System.Drawing for JVM. While majority of the code will be java-specific, I expect some changes to shared code, too. So the question is - can I create a branch to perform this development in svn? After we get to some stable point I will create patches for shared code and mail them to the devlist, so those changes can be merged into trunk. Thank you. Andrew. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] More tests and fixes for them
Please review the attached tests and fixes for them. I know the fixes look weird, but that's what dot net appear to do in their sys.drawing. PointF.ToString returns string with space, while Point.ToString returns without space. And the hash code for PointF seem to ignore the y value. MoreTests.patch Description: MoreTests.patch Point.patch Description: Point.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] More tests and fixes for them
I'm wondering the same thing. There will be many places with weird dotnet behavior in sys.drawing, we need to decide how to deal with them. And how to write tests for places where we decide to have different behavior? Andrew. From: Hugo Ferreira [mailto:[EMAIL PROTECTED] Sent: Monday, August 01, 2005 13:32 To: Andrew Skiba Subject: Re: [Mono-devel-list] More tests and fixes for them Heya there, I'm wondering... Should we stick so close to MSFT idiosyncrasies? I mean, for example, if the GetHashCode() for PointF ignores the Y value, shouldn't we make it more correct (and possibly increase performance when using Data Structures that take advantage of hashes)? Same goes with coherence. If the ToString() of two similar structures is different, why not make it the right way? Unless it breakes code, of course, though I don't see those two functions as code-breaking (correct me if I'm wrong). ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] new rectangle tests and patch for fixing them
Forgotten testcase added and more elegant fix. Please use these patches instead of previous. TestRectangle.patch Description: TestRectangle.patch Rectangle.patch Description: Rectangle.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] new rectangle tests and patch for fixing them
Sorry, I missed a couple of methods to test in both Rectangle and RectangleF. I attach all patches here for convenience. RectangleF.patch Description: RectangleF.patch Rectangle.patch Description: Rectangle.patch TestRectangle.patch Description: TestRectangle.patch TestRectangleF.patch Description: TestRectangleF.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] More tests and fixes for them
At the beginning I hoped to simulate MS functionality as much as possible, but as I don't know how to reproduce Rectangle hash code, I don't care if Point will have different code, too. So I will change the test so it does not requires fixed hash values, as I did with Rectangle. Thank you. Andrew. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Color tests and fix for them
Added tests to cover 100% of Color API. Needed to fix Color.GetHashCode to take Name into account, in addition to ARGB. TestColor.patch Description: TestColor.patch Color.patch Description: Color.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Size and SizeF tests - no fixes needed!
Added tests to cover 100% of Size and SizeF API. No bugs revealed. TestSize.patch Description: TestSize.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
