Re: [Mono-dev] Building Mono on Linux/Alpha
Hello Zoltan, Either you should emit code to move from R0 to ins-dreg, or (better), modify your cpu-alpha.md file and the register allocator macros in mini-alpha.h to force the local register allocator to allways allocate the dreg of the call instruction to R0. This way the reg allocator will emit the move instruction if it is neccesary. Here is what a call instruction looks like in cpu-pentium.md: call: dest:a clob:c len:17 And the corresponding macro (only an example): #define MONO_ARCH_INST_FIXED_REG(desc) ((desc == 'a') ? X86_EAX : -1) Using different options triggered some interesting code I had to implement. My question is what is the difference between local and global registers? As I undertood the local registers could be used temporary in basic blocks, the global registers are used during optimizations. Can I define all my local registers as global ones? It seems that they couldn't mixed. Global registers are used during global register allocation. They should be distinct from the set of local registers. mono_arch_get_global_int_regs () returns the list of registers that should be used for global allocation. These registers are usually the 'callee-saved' registers defined by the platform ABI. The global register allocator will set cfg-used_int_regs if needed. I suggest returning an empty list from get_global_int_regs () until all tests are running, so you have a large set of regression tests which you can use to debug the inevitable problems which will arose when some variables are allocated to global registers. After some hacking I was able to run Hello world program. :) It still crashes somewhere at final stage of program rundown, but surely it did a lot before that. :) Now I have to implement hardest part - handling of exceptions. I need some hints here. :) - Of couse I am getting segfaults. For now I return -1 in mono_arch_find_jit_info. It seems to work in most cases - I am getting stack trace. But I guess there is not enough information to do correct unwinding and the VM segfaults again and goes to the loop of segfaults. If you could shed light here - it would be great. - Do I have to implement LMF handling to do correct unwinding? I don't have any LMF frames right now (it seems that I would have to save a lot of information in stack). - I don't have implemented any of throw, finally, call_handler - program exceptions. What are the requirements to implement it in general? Thank you, -- Sergey Tikhonov Solvo Ltd. Saint-Petersburg, Russia [EMAIL PROTECTED] ___ 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] Please Help : Leak of wapi handles
Robert Jordan and me have noticed an important problem in current mono. There's leaks in wapi handles when creating thread and process. This problem is critical, because ASP.NET (which use threads and process) can't run more than a couple of hours... The number of wapi handles is always increasing... We've declared a bug in bugzilla : http://bugzilla.ximian.com/show_bug.cgi?id=78241 but since the bug has been created nobody (from Novell) has written anything on it... I'm working hard to hack the io-layer to see what's the problem, but without any help from mono team, I think i could'nt resolve the bug alone... I'm afraid to say that if this problem is not resolved quickly, my firm will abandon Mono... for something more 'robust'. I've found more than 40 bug in mono since a year, and I hope that this one would'nt prevent my firm to use mono (which is the best OpenSource Project i've been working on) Thanks in advance! Hubert FONGARNAND ___Ce message et les éventuels documents joints peuvent contenir des informations confidentielles.Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite.Les communications sur internet n'étant pas sécurisées, l'intégrité de ce message n'est pas assurée et la société émettrice ne peut être tenue pour responsable de son contenu. ___ 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
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
[Mono-dev] SqlClient and cp1250 patch
Hello When connecting to database via SqlClient with codepage 'windows-1250' there is no encoding initiated. This patch fixes problem. Andy === --- Mono.Data.Tds/Mono.Data.Tds.Protocol/Tds.cs (rev 1.1.15) +++ Mono.Data.Tds/Mono.Data.Tds.Protocol/Tds.cs (my) @@ -1504,7 +1504,7 @@ if (charset == null || charset.Length 30) charset = iso_1; - if (this.charset != null this.charset != charset) + if (this.charset != null this.charset == charset) return; if (charset.StartsWith (cp)) { === ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono: Google Summer of Code
Hello students! The Google Summer of Code has started, we have a list of projects that we are looking to find developers for in: http://www.mono-project.com/StudentProjects Miguel. ___ 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
That patch looks good. Please commit. Chris On Thu, 2006-05-04 at 00:23 -0700, Andrew Skiba wrote: 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 {
RE: [WARNING : A/V UNSCANNABLE] RE: [Mono-dev]System.Web.UI.Pagepatch
I wasn't running the test case on xsp at all. This was with IIS. also, the stack trace is interesting in that they're obviously using generics in asp.net 2.0. Chris On Thu, 2006-05-04 at 00:23 -0700, Andrew Skiba wrote: 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
Re: [Mono-dev] framework for system.web tests
I like this idea, definitely put it in svn. Maybe under the Test/mainsoft directory until we start using it for the individual unit tests? One thing, though, We shouldn't ever write unit tests that use direct string comparisons to validate generated html. The only real exception (that I can think of) to this would be in verifying the behavior of various output modes (xhtml, etc). There are unfortunately examples of the string comparison stuff all over the system.web unit tests, just waiting to be broken by an update to MS's System.Web that adds a space someplace. There's code in the System.Web unit tests to verify the structure of the generated html, and I believe the other mainsoft tests use a similar approach (first converting it to xml or something?) I've fixed bug #78256, so things ought to work with mono now. Nice hack. Chris ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list