Re: [Mono-dev] Maybe a System.Data.OracleClient.dll bug

2006-09-21 Thread Tony Gu
David,I will argue that if OracleParametr a better solution because I dislike the Parameter personally :) By the way, this is not only bug in the Parameter. The reality is that is not a bad workaround if you don't have the time(like me). The other options are to wait the bug fixed or you go to

Re: [Mono-dev] Maybe a System.Data.OracleClient.dll bug

2006-09-21 Thread David
2006/9/21, Tony Gu [EMAIL PROTECTED]: David,I will argue that if OracleParametr a better solution because I dislike the Parameter personally :) By the way, this is not only bug in the Parameter. The reality is that is not a bad workaround if you don't have the time(like me). The other options are

Re: [Mono-dev] Some bugs in ASP.NET

2006-09-21 Thread Hubert FONGARNAND
Thanks a lot gonzalo! Le mercredi 20 septembre 2006 16:15 -0400, Gonzalo Paniagua Javier a crit : On Wed, 2006-09-20 at 10:14 +0200, Hubert FONGARNAND wrote: Hi, I thought that ASP.NET 1.1 support in mono has a certain maturity... In fact there's still a lot of work!

Re: [Mono-dev] Maybe a System.Data.OracleClient.dll bug

2006-09-21 Thread Leszek Ciesielski
On 9/21/06, David [EMAIL PROTECTED] wrote: 2006/9/19, Leszek Ciesielski [EMAIL PROTECTED]: This has already been reported (check http://bugzilla.ximian.com/show_bug.cgi?id=79004 and http://bugzilla.ximian.com/show_bug.cgi?id=78840 ). Could you please try the OracleClient from the

[Mono-dev] Thread Pool WAPI Ref Problems

2006-09-21 Thread Patrick Earl
Hi. I've been trying to track what might be causing the issue in the following bug: http://bugzilla.ximian.com/show_bug.cgi?id=79060 It seems to be some problem with wapi refs in the threadpool. In any case, though I don't have a good understanding of how everything connects, I did

Re: [Mono-dev] Thread Pool WAPI Ref Problems

2006-09-21 Thread Brian Crowell
Patrick Earl wrote: Hi. I've been trying to track what might be causing the issue in the following bug: http://bugzilla.ximian.com/show_bug.cgi?id=79060 Thought I'd toss in my own related bug: http://bugzilla.ximian.com/show_bug.cgi?id=79286 --Brian

Re: [Mono-dev] SPAM-LOW: Re: Determining the Mono Release

2006-09-21 Thread Rafael Teixeira
Well I would write something like Running under Mono 1.1.17 (with profile 1.1.4322). :) On 9/20/06, Charlie Poole [EMAIL PROTECTED] wrote: Thanks, GetDisplayName was what I needed. Now I need to figure out what to /call/ the two versions I display, e.g.: 1.1.4322 and 1.1.17, so that they

Re: [Mono-dev] Thread Pool WAPI Ref Problems

2006-09-21 Thread Gonzalo Paniagua Javier
On Thu, 2006-09-21 at 10:43 -0600, Patrick Earl wrote: Hi. I've been trying to track what might be causing the issue in the following bug: http://bugzilla.ximian.com/show_bug.cgi?id=79060 It seems to be some problem with wapi refs in the threadpool. In any case, though I don't

Re: [Mono-dev] SPAM-LOW: Re: SPAM-LOW: Re: Determining the Mono Release

2006-09-21 Thread Charlie Poole
Hi, Well I would write something like Running under Mono 1.1.17 (with profile 1.1.4322). FWIW, I did the opposite :-) CLR Version: 1.1.4322 ( Mono 1.1.17 ) Charlie :) On 9/20/06, Charlie Poole [EMAIL PROTECTED] wrote: Thanks, GetDisplayName was what I needed. Now I need to

Re: [Mono-dev] Thread Pool WAPI Ref Problems

2006-09-21 Thread Patrick Earl
Is it correct to assume that wapi handles for threads should stick around until sometime after the thread finishes executing? If so, it seems that the leaking wapi handles (created in the thread pool) are caused by missing code in mono/metadata/threads.c:start_wrapper() function. After

Re: [Mono-dev] Thread Pool WAPI Ref Problems

2006-09-21 Thread Brian Crowell
Patrick Earl wrote: Is it correct to assume that wapi handles for threads should stick around until sometime after the thread finishes executing? Thread has a finalizer that calls Thread_free_internal in metadata/threads.c (554), which then just calls CloseHandle. So that's probably when the

[Mono-dev] NPlot-Gtk 0.9.9.2

2006-09-21 Thread Carlos Ble
Hi! I have commited NPlot-Gtk 0.9.9.2, the update from the previous wrapper that Miguel did. I also uses Gtk#2 instead of 1. Is there any good place to upload a binary package to users? Thanks -- Carlos Ble www.shidix.com/carlosble ___

[Mono-dev] System.Runtime.InteropServices.ExtensibleClassFactory Patch

2006-09-21 Thread Jon Chambers
Attached is an implementation of System.Runtime.InteropServices.ExtensibleClassFactory. I am respecting it in object creation for COM Interop. Please review.For those who care, this is a way to get XPCOM Interop a bit closer to working. You can use this functionality to return an nsISupports

[Mono-dev] [PATCH] System.IO.FileInfo.IsReadOnly

2006-09-21 Thread joel reed
Attached please find an implementation of System.IO.FileInfo.IsReadOnly, a .Net 2.0 method. See http://msdn2.microsoft.com/en-us/library/system.io.fileinfo.isreadonly.aspx Thanks, jr diff --git a/mcs/class/corlib/System.IO/FileInfo.cs b/mcs/class/corlib/System.IO/FileInfo.cs index

Re: [Mono-dev] [PATCH] System.IO.FileInfo.IsReadOnly

2006-09-21 Thread Gonzalo Paniagua Javier
On Thu, 2006-09-21 at 22:30 -0400, joel reed wrote: Attached please find an implementation of System.IO.FileInfo.IsReadOnly, a .Net 2.0 method. See http://msdn2.microsoft.com/en-us/library/system.io.fileinfo.isreadonly.aspx Your patch and test are in svn now. Thanks. -Gonzalo

Re: [Mono-dev] [PATCH] System.IO.FileInfo.IsReadOnly

2006-09-21 Thread Gert Driesen
-Original Message- From: [EMAIL PROTECTED] [mailto:mono-devel-list- [EMAIL PROTECTED] On Behalf Of Gonzalo Paniagua Javier Sent: vrijdag 22 september 2006 4:55 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] [PATCH] System.IO.FileInfo.IsReadOnly On Thu, 2006-09-21

Re: [Mono-dev] Maybe a System.Data.OracleClient.dll bug

2006-09-21 Thread David
Could you please clarify this? If I get you right, you mean that the code in the repository does not work, and mono 1.1.17.1 does not work. Surely the code will work if you do it as a single sql statement (if it does not, things are FUBAR ;-) ), but it is (in regard to performance) better to