Re: [Mono-dev] Building Mono on Linux/Alpha

2006-05-04 Thread Sergey Tikhonov

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

2006-05-04 Thread Andrew Skiba
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

2006-05-04 Thread Hubert FONGARNAND




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

2006-05-04 Thread Andrew Skiba
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

2006-05-04 Thread Andrzej Kurzeja
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

2006-05-04 Thread Miguel de Icaza
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

2006-05-04 Thread Chris Toshok
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

2006-05-04 Thread Chris Toshok
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

2006-05-04 Thread Chris Toshok
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