Re: [Mono-dev] [PATCH] Dir.Services - small refactoring

2006-01-29 Thread Eyal Alaluf

Hi, Kosta.

I have two remarks regarding the change in ObjectArray:
  * You should use the 'Clear' method instead of setting 'this[i] = null'.
  * The original code documents that it is clearing up the original array. It 
even tries
to do this using 'ToSrray()[i] = null'. However, this is a serious bug 
becuase
'ToArray()' always creates a new array each time  and so doing 
'ToArray()[i] = null'
has absolutely no side effects (except on performance :-). I believe that 
you should
verify that fixing this bug has no side effects in System.DirectoryServices 
code.

Eyal.

On Thu, 26 Jan 2006, Konstantin Triger wrote:


Date: Thu, 26 Jan 2006 04:36:52 -0800
From: Konstantin Triger [EMAIL PROTECTED]
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev] [PATCH] Dir.Services - small refactoring

Hello all,



I made some refactoring reducing number of objects created.

Please review the attached patch before I commit.



Regards,

Konstantin Triger





perf.patch
Description: perf.patch
___
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] XslTransform tool

2006-01-29 Thread Boris Kirzner
Hi Eno,

Actually your tool does everything I need (and much more :), so I'll be
fully satisfied with it
(the only thing I need to change is adding some #ifdefs since
Grasshopper does not support relaxng yet).

   - We are not likely to add further functionality before Mono 1.2
 (thus am even refrained from adding forgotten dtd2rng in 
 mono/scripts...)

What do you think is the earliest opportunity this tool can be submitted
to repository?

--
Boris Kirzner
Mono RD team, Mainsoft Corporation.
Blogging at http://boriskirzner.blogspot.com/  

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


[Mono-dev] help with mysql connection

2006-01-29 Thread danilo
Hi,

I am trying to connect to Mysql from an example running under xsp2

here is my code:

%@ Page Language=C# %
%@ Import Namespace=System %

%@ Import Namespace=System.Data %

%@ Import Namespace=System.Data.Odbc %

html
head runat=server
  titleGridView Bound to SqlDataSource/title
/head
body
  form id=form1 runat=server
asp:GridView ID=GridView1 DataSourceID=SqlDataSource1
runat=server /
asp:SqlDataSource ID=SqlDataSource1 runat=server   
 ConnectionString=DRIVER={MySQL ODBC
3.51Driver};SERVER=localhost;DATABASE=X;USER=root;PASSWORD=X;OPTION=3;

  ProviderName=System.Data.Odbc SelectCommand=XX
 
/asp:SqlDataSource

  /form
/body
/html

I am having this error:

System.ArgumentException: Keyword not supported :DRIVER

I have been looking for a solution in google for some  days  and  I
couldn't  find anything.

Can someone help me ?

Thanks in advance !
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


[Mono-dev] Refactoring in System.Data.Common

2006-01-29 Thread Konstantin Triger








Hello,



I made some methods/fields in System.Data.Common/ExceptionHelper.cs,
DbTypes.cs to enable reuse in other assemblies like System.Data.OracleClient.



Please review before I commit.



Regards,

Konstantin Triger










public.patch
Description: public.patch
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


RE: SPAM-LOW: Re: [Mono-dev] NUnit 2.2.6 Portability Bug

2006-01-29 Thread Jonathan Pryor
On Sat, 2006-01-28 at 18:15 -0800, Charlie Poole wrote:
 Hi Jonathan, 
 I'll write a test. :-)
  
  PathRelativePathTo: this variation on your 
  PathUtils.RelativePath works for me (minimally tested):
 
 This looks too simple to work, but I'll try it. ;-)

Attached is a better version, complete with test cases.  The previous
function was Unix-native -- it didn't care about drives or other such
things that I found in PathUtilTests.cs.  The attached version is a
little smarter, though it means we can't use the same input strings on
both Unix and Windows for testing -- we need platform-specific
tests. :-(

 - Jon


// PathRelativePathTo:

using System;
using System.IO;
using System.Text;

/* 
The relative path is relative from: c:\a\b\path
The relative path is relative to: c:\a\x\y\file
The relative path is: ..\..\x\y\file
 */

class Test {
	static string RelativePath (string from, string to)
	{
		if (from == null)
			throw new ArgumentNullException (from);
		if (to == null)
			throw new ArgumentNullException (to);
		if (!Path.IsPathRooted (to))
			return to;
		if (Path.GetPathRoot (from) != Path.GetPathRoot (to))
			return null;

		string[] _from = from.Split (Path.DirectorySeparatorChar, 
Path.AltDirectorySeparatorChar);
		string[] _to   =   to.Split (Path.DirectorySeparatorChar, 
Path.AltDirectorySeparatorChar);

		StringBuilder sb = new StringBuilder (Math.Max (from.Length, to.Length));

		int last_common, min = Math.Min (_from.Length, _to.Length);
		for (last_common = 0; last_common  min;  ++last_common) {
			if (!_from [last_common].Equals (_to [last_common]))
break;
		}

		if (last_common  _from.Length)
			sb.Append (..);
		for (int i = last_common + 1; i  _from.Length; ++i) {
			sb.Append (Path.DirectorySeparatorChar).Append (..);
		}

		if (sb.Length  0)
			sb.Append (Path.DirectorySeparatorChar);
		if (last_common  _to.Length)
			sb.Append (_to [last_common]);
		for (int i = last_common + 1; i  _to.Length; ++i) {
			sb.Append (Path.DirectorySeparatorChar).Append (_to [i]);
		}

		return sb.ToString ();
	}

	static void Check (string a, string b)
	{
		Console.WriteLine (\t{0,5}: \{1}\ == \{2}\, a == b, a, b);
	}

	public static void Main (string[] args)
	{
		Console.WriteLine (Unix);
		Check (folder2/folder3, RelativePath (/folder1, /folder1/folder2/folder3));
		Check (../folder2/folder3, RelativePath (/folder1, /folder2/folder3));
		Check (bin/debug, RelativePath (/folder1, bin/debug));
		Check (../../d, RelativePath (/a/b/c, /a/d));
		Console.WriteLine (Windows);
		Check (@folder2\folder3, 
RelativePath (@C:\folder1, @C:\folder1\folder2\folder3));
		Check (@..\folder2\folder3, RelativePath (@C:\folder1, @C:\folder2\folder3));
		Check (@bin\debug, RelativePath (@C:\folder1, @bin\debug));
		Check (null, RelativePath (@C:\folder, @D:\folder));
		Check (@folder2\folder3, 
RelativePath (@C:/folder1, @C:/folder1/folder2/folder3));
		Check (@..\folder2\folder3, RelativePath (@C:/folder1, @C:/folder2/folder3));
		Check (@bin/debug, RelativePath (@C:/folder1, @bin/debug));
		Check (null, RelativePath (@C:/folder, @D:/folder));
		if (args.Length = 2) {
			Console.WriteLine (from:  + args[0]);
			Console.WriteLine (  to:  + args[1]);
			Console.WriteLine ( rel:  + RelativePath (args [0], args [1]));
		}
	}
}

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


RE: [Mono-dev] Ldap and Threading

2006-01-29 Thread Konstantin Triger
Hello Mike,

As I wrote in my analysis of your patches, I ran the application you
provided and, unfortunately, did not repro the issue. (see
http://lists.ximian.com/pipermail/mono-devel-list/2006-January/016771.ht
ml).

The only suspicious exception was the first one:
1. Unhandled Exception: System.ArgumentException: length in 0x005cc
System.Array:Copy (System.Array sourceArray, Int32 sourceIndex,
System.Array destinationArray, Int32 destinationIndex, Int32 length) in
0x0004b System.Array:Copy (System.Array sourceArray, System.Array
destinationArray, Int32 length) in 0x00016
System.Collections.ArrayList:CopyTo (System.Array array) in 0x0002a
System.Collections.ArrayList:ToArray () in 0x00048
Novell.Directory.Ldap.MessageVector:findMessageById (Int32
msgId)

But in order to validate the fix, I need to understand what was done by
some other thread that caused this race. Then we will be able to see how
the proposed patch fixes that.

Regards,
Konstantin Triger


-Original Message-
From: Mike Glenn [mailto:[EMAIL PROTECTED] 
Sent: Sunday, January 29, 2006 5:59 PM
To: Konstantin Triger; 'JD Conley'
Cc: mono-devel-list@lists.ximian.com
Subject: RE: [Mono-dev] Ldap and Threading

 Can you point exactly on the race condition you face? For 
 example by providing a stack trace or explaining thread A is 
 doing this and thread B is doing that etc.
 I need this to ensure we eliminate this race and to create a 
 granular patch for this specific issue.

If you reference back to the start of this thread I posted a console app
that
was able to relably reproduce the issues I was having with a description
of the
exceptions and stacktrace's I received. If you need a copy I can dig it
up and
send it to you. 

Mike Glenn

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


RE: [Mono-dev] Ldap and Threading

2006-01-29 Thread JD Conley
 As I wrote in my analysis of your patches, I ran the application you
 provided and, unfortunately, did not repro the issue. (see

http://lists.ximian.com/pipermail/mono-devel-list/2006-January/016771.ht
 ml).

It didn't work reliably. Now it does. Our intentions are good. Search
for me on this list. I did some similar (very large) patches to
Mono.Security that are working quite well. Run your test suite if you're
worried about introducing bugs into the library. Please, just take the
patch! I don't want to maintain my own copy of this library.

Threading bugs are notoriously difficult to reproduce. If I remember
correctly (Again, I submitted this way back in August -- with only the
necessities patched), the issue was more easily reproduced on a slower
network connection where search results trickled in a bit more. The
background thread that parses the network data was adding results into
the collection while I was pulling them out from my thread. I was
testing over a VPN with about 30ms ping latency with the 2.0 build.

-JD
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] Refactoring in System.Data.Common

2006-01-29 Thread Ben Maurer
On Sun, 2006-01-29 at 05:13 -0800, Konstantin Triger wrote:
 I made some methods/fields in System.Data.Common/ExceptionHelper.cs,
 DbTypes.cs to enable reuse in other assemblies like
 System.Data.OracleClient.

Isn't this creating new public types? We can't do that. It would prevent
the other db providers from running on the Microsoft runtime (handy for
testing).

If you need to reuse stuff like this, we need to figure out a way to let
the build system do that.

-- Ben

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] Refactoring in System.Data.Common

2006-01-29 Thread Miguel de Icaza
Hello,

 I made some methods/fields in System.Data.Common/ExceptionHelper.cs,
 DbTypes.cs to enable reuse in other assemblies like
 System.Data.OracleClient.

Like Ben pointed out this patch has the unintended side effect of
exposing types that are not part of the public API, so it can not be
applied.

What you could consider doing to share this information is to list the
necessary files that you need to share data with in the .sources file
for the other module.

If you need to re-namespace the constants, you could use an ifdef around
it.

Miguel.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list