Re: [Mono-dev] Test suite failures (Mono 2.10.2)

2011-06-24 Thread Harry Wilkinson
I don't mean to cast aspersions on the maintenance of the tests (although I
do think it would be unusual if a product was released with failures in its
own automated test suite).  I don't feel entitled to complain too much, but
I'd like to understand the situation.

I just want to find answers to these questions:

   1. Is this expected
  - in general? (It sounds like yes, please somebody correct this if
  they think otherwise)
  - for a released version? (Sounds like yes again)
  - for 2.10.2?
   2. Does it look like I'm doing something wrong?
   3. How is Mono packaged if the test suite fails?

Thanks again.

Harry

On 23 June 2011 20:05, Steve Bjorg ste...@mindtouch.com wrote:

 Here's a thought: only accept code changes that pass all tests?  Just
 saying...

- Steve

 --
 Steve G. Bjorg
 http://mindtouch.com
 http://twitter.com/bjorg

 On Jun 23, 2011, at 11:43 AM, Zoltan Varga wrote:

 Hi,

   Our test suite contains 1000s of tests, written by dozens of people, its
 a bit hard to keep them all passing.

 Zoltan

 On Thu, Jun 23, 2011 at 7:44 PM, Harry Wilkinson hwilkin...@mdsol.comwrote:

 Hi,

 I'm encountering some test failures with the Mono 2.10.2 source tarball
 distributed at http://ftp.novell.com/pub/mono/sources/mono/

 Basically I'm trying to package it for deployment on Ubuntu 10.04.2
 servers in a cloud configuration.  So far I've been building from source and
 encountered no significant problems other than the long build time.  I'd
 like to be able to reduce that by building it once and deploying a compiled
 package.  So I'm using dpkg-buildpackage.

 However, now that I'm packaging rather than just building and installing,
 it seems that the test suite is run and there are some test failures.  The
 first and most obvious one is that it appears that a file is missing from
 the source tarball:


 mcs/class/corlib/Test/System.Runtime.Serialization.Formatters.Binary/VersionTolerantSerialization/VersionTolerantSerializationTestLib/6.0/Address.cs

 The file is there in the Git repo under the 2.10.2 tag, but it's not in
 the tarball.  Unfortunately it's referenced in the associated Makefile
 (mcs/class/corlib/Makefile).  The same applies to 2.10.1, so I'm guessing
 the file is omitted from whatever process builds the tarballs.

 I switched to compiling from the source taken from Git, checkout out the
 2.10.2 tag, and I get a different error (which is also what I get with the
 tarball version if I just hack the makefile):

 make[8]: Entering directory
 `/home/hwilkinson/mono/mcs/class/System.Web.DynamicData'
 MCS [net_2_0] System.Web.DynamicData_test_net_2_0.dll
 Test/../../System.Web/Test/mainsoft/NunitWeb/NunitWeb/MyTemplateControls.cs(43,19):
 error CS0507:
 `MyTemplateControls.TestTemplateControl.CreateChildControls()': cannot
 change access modifiers when overriding `protected' inherited member
 `System.Web.UI.Control.CreateChildControls()'
 /home/hwilkinson/mono/mcs/class/lib/net_2_0/System.Web.dll (Location of
 the symbol related to previous error)
 Compilation failed: 1 error(s), 0 warnings
 make[8]: *** [System.Web.DynamicData_test_net_2_0.dll] Error 1

 It looks like this could well be an incorrect preprocessor definition
 'SYSTEM_WEB_EXTENSIONS' (not sure whether it should be defined or not)
 in 
 mcs/class/System.Web/Test/mainsoft/NunitWeb/NunitWeb/MyTemplateControls.cs.

 Is this expected?  I had sort of assumed that a released version would
 have a passing test suite.  Am I doing something wrong?

 Any advice (well, almost) would be gratefully received.

 Thanks.

 Harry Wilkinson

 ___
 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] Test suite failures (Mono 2.10.2)

2011-06-24 Thread Harry Wilkinson
Okay, so I guess this answers 2 of the questions - the test failures are
expected, and I'm not doing anything wrong.  Please correct me if you think
otherwise.

I would still really like to know: how is Mono packaged if the test suite
fails?

This is important to me because I would like to build my own package so I
don't have to compile Mono every time I deploy a Mono app.  Is there a
straightforward way to ignore the tests?

Thanks.

Harry

Date: Fri, 24 Jun 2011 15:12:12 -0300
From: Rodrigo Kumpera kump...@gmail.com
Subject: Re: [Mono-dev] Test suite failures (Mono 2.10.2)
To: Kocsis L?szl? kocsis1...@gmail.com
Cc: mono-devel-list@lists.ximian.com
Message-ID: banlktinxujqsmhyu8jy48jxetzcxzfj...@mail.gmail.com
Content-Type: text/plain; charset=iso-8859-1

I think you misundestood my email. It's the opposite, right now we, at
Xamarin,
can't really afford the time to bring the mono CI infrastructure back so
someone
from the community needs to step up and do it.



On Fri, Jun 24, 2011 at 3:07 PM, Kocsis L?szl? kocsis1...@gmail.com wrote:

 Hi Rodrigo,

 Good news the guys at Xamarin are working hard on getting the build
 infrastructure back. Would you please give us an estimate about when
 will it be up and running again?

 I would like to work on bugs in the Windows version of mono, but I
 could not even compile it. I hope the automatic build and test system
 will solve such problems and mono will compile and pass all tests at
 least on every major platform. Or am I naive and this cannot be
 expected?

 Best,

 Laszlo


 2011/6/24, Rodrigo Kumpera kump...@gmail.com:
  It's hard to do such a thing when you factor in that mono supports many
  dozens of targets and configurations and
  that sometimes those breaks were caused my maintainers - I have my share
 of
  faults.
 
  Thing is, right now the team at Xamarin has tons of stuff on its hand so
  getting the build infrastructure back on
  track, which helps us a lot, won't happen without community help.
 
  A good first step would be to get CI back working at least on linux. S,
 if
  someone wants to rebuild the continuous
  integration farm over linode (or other VPS) please speak up.
 
 
  On Thu, Jun 23, 2011 at 4:05 PM, Steve Bjorg ste...@mindtouch.com
 wrote:
 
  Here's a thought: only accept code changes that pass all tests?  Just
  saying...
 
  - Steve
 
  --
  Steve G. Bjorg
  http://mindtouch.com
  http://twitter.com/bjorg
 
  On Jun 23, 2011, at 11:43 AM, Zoltan Varga wrote:
 
  Hi,
 
Our test suite contains 1000s of tests, written by dozens of people,
 its
  a bit hard to keep them all passing.
 
  Zoltan
 
  On Thu, Jun 23, 2011 at 7:44 PM, Harry Wilkinson
  hwilkin...@mdsol.comwrote:
 
  Hi,
 
  I'm encountering some test failures with the Mono 2.10.2 source
tarball
  distributed at http://ftp.novell.com/pub/mono/sources/mono/
 
  Basically I'm trying to package it for deployment on Ubuntu 10.04.2
  servers in a cloud configuration.  So far I've been building from
 source
  and
  encountered no significant problems other than the long build time.
  I'd
  like to be able to reduce that by building it once and deploying a
  compiled
  package.  So I'm using dpkg-buildpackage.
 
  However, now that I'm packaging rather than just building and
 installing,
  it seems that the test suite is run and there are some test failures.
  The
  first and most obvious one is that it appears that a file is missing
 from
  the source tarball:
 
 
 

mcs/class/corlib/Test/System.Runtime.Serialization.Formatters.Binary/VersionTolerantSerialization/VersionTolerantSerializationTestLib/6.0/Address.cs
 
  The file is there in the Git repo under the 2.10.2 tag, but it's not
in
  the tarball.  Unfortunately it's referenced in the associated Makefile
  (mcs/class/corlib/Makefile).  The same applies to 2.10.1, so I'm
 guessing
  the file is omitted from whatever process builds the tarballs.
 
  I switched to compiling from the source taken from Git, checkout out
 the
  2.10.2 tag, and I get a different error (which is also what I get with
  the
  tarball version if I just hack the makefile):
 
  make[8]: Entering directory
  `/home/hwilkinson/mono/mcs/class/System.Web.DynamicData'
  MCS [net_2_0] System.Web.DynamicData_test_net_2_0.dll
 

Test/../../System.Web/Test/mainsoft/NunitWeb/NunitWeb/MyTemplateControls.cs(43,19):
  error CS0507:
  `MyTemplateControls.TestTemplateControl.CreateChildControls()': cannot
  change access modifiers when overriding `protected' inherited member
  `System.Web.UI.Control.CreateChildControls()'
  /home/hwilkinson/mono/mcs/class/lib/net_2_0/System.Web.dll (Location
of
  the symbol related to previous error)
  Compilation failed: 1 error(s), 0 warnings
  make[8]: *** [System.Web.DynamicData_test_net_2_0.dll] Error 1
 
  It looks like this could well be an incorrect preprocessor definition
  'SYSTEM_WEB_EXTENSIONS' (not sure whether it should be defined or not)
  in
 

mcs/class/System.Web/Test/mainsoft

[Mono-dev] Test suite failures (Mono 2.10.2)

2011-06-23 Thread Harry Wilkinson
Hi,

I'm encountering some test failures with the Mono 2.10.2 source tarball
distributed at http://ftp.novell.com/pub/mono/sources/mono/

Basically I'm trying to package it for deployment on Ubuntu 10.04.2 servers
in a cloud configuration.  So far I've been building from source and
encountered no significant problems other than the long build time.  I'd
like to be able to reduce that by building it once and deploying a compiled
package.  So I'm using dpkg-buildpackage.

However, now that I'm packaging rather than just building and installing, it
seems that the test suite is run and there are some test failures.  The
first and most obvious one is that it appears that a file is missing from
the source tarball:

mcs/class/corlib/Test/System.Runtime.Serialization.Formatters.Binary/VersionTolerantSerialization/VersionTolerantSerializationTestLib/6.0/Address.cs

The file is there in the Git repo under the 2.10.2 tag, but it's not in the
tarball.  Unfortunately it's referenced in the associated Makefile
(mcs/class/corlib/Makefile).  The same applies to 2.10.1, so I'm guessing
the file is omitted from whatever process builds the tarballs.

I switched to compiling from the source taken from Git, checkout out the
2.10.2 tag, and I get a different error (which is also what I get with the
tarball version if I just hack the makefile):

make[8]: Entering directory
`/home/hwilkinson/mono/mcs/class/System.Web.DynamicData'
MCS [net_2_0] System.Web.DynamicData_test_net_2_0.dll
Test/../../System.Web/Test/mainsoft/NunitWeb/NunitWeb/MyTemplateControls.cs(43,19):
error CS0507:
`MyTemplateControls.TestTemplateControl.CreateChildControls()': cannot
change access modifiers when overriding `protected' inherited member
`System.Web.UI.Control.CreateChildControls()'
/home/hwilkinson/mono/mcs/class/lib/net_2_0/System.Web.dll (Location of the
symbol related to previous error)
Compilation failed: 1 error(s), 0 warnings
make[8]: *** [System.Web.DynamicData_test_net_2_0.dll] Error 1

It looks like this could well be an incorrect preprocessor definition
'SYSTEM_WEB_EXTENSIONS' (not sure whether it should be defined or not)
in mcs/class/System.Web/Test/mainsoft/NunitWeb/NunitWeb/MyTemplateControls.cs.

Is this expected?  I had sort of assumed that a released version would have
a passing test suite.  Am I doing something wrong?

Any advice (well, almost) would be gratefully received.

Thanks.

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


[Mono-dev] mono X11 rendering

2005-10-14 Thread Harry
Hi guys, 

I am not sure where to post this questions. Hopefuly
you guys are able to answer my questions:

I am developing a simple applications using Thread
class to change the color of the square (Lab
assignment)

everything working correctly, accept I have to drag
the windows in linux to let the Thread working to
change the color of a square. 

I think it has something todo with the X11 rendering
in Linux. Are there any solutions to this problems? 

here is my code: 
using System;
using System.Windows.Forms;
using System.Threading;
using System.Drawing;

public class ColoredBoxes : Form
{
private Color c;
public ColoredBoxes()
{
Thread t = new Thread(new ThreadStart(Run));
t.Start();
}

protected override void OnPaint(PaintEventArgs e)
{
Graphics g = e.Graphics;
Pen blue = new Pen(c, 3);   
g.DrawRectangle(blue, 100,100,30,30);
base.OnPaint(e);
}

public void Run()
{
Random r = new Random();
while(true)
{
c = Color.FromArgb(r.Next(256), r.Next(256),
r.Next(256));
Thread.Sleep(200);
}
}

}

public class Test{
public static void Main()
{
Application.Run(new ColoredBoxes());
}
}

Thank you for all your help guys



--

Harry Tanama
Programmer/Developer
.NET / JAVA
Powerd by GNU/LiNUX  


Let Christ be glorify in our words and actions.

Jesus Christ save the entire human race from sins  GNU/Linux save human from 
high cost software applications.



__ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


[Mono-dev] mono X11 rendering

2005-10-14 Thread Harry
Hi guys,
(sorry for the typo in the previous email)

I am developing a simple applications using Thread
class to change the color of the square (Lab
assignment). Everything is working properly, except I
have to drag or cls /opn the windows in linux to fix
theThread and the only solutions to produce the color
change.  

I think it has something todo with the X11 rendering
in Linux. Are there any solutions to this problems? 

here is my code: (This code should be working in MS
Windows) 

[code]
using System;
using System.Windows.Forms;
using System.Threading;
using System.Drawing;

public class ColoredBoxes : Form
{
private Color c;
public ColoredBoxes()
{
Thread t = new Thread(new ThreadStart(Run));
t.Start();
}

protected override void OnPaint(PaintEventArgs e)
{
Graphics g = e.Graphics;
Pen blue = new Pen(c, 3);   
g.DrawRectangle(blue, 100,100,30,30);
base.OnPaint(e);
}

public void Run()
{
Random r = new Random();
while(true)
{
c = Color.FromArgb(r.Next(256), r.Next(256),
r.Next(256));
Thread.Sleep(200);
}
}

}

public class Test{
public static void Main()
{
Application.Run(new ColoredBoxes());
}
}
[/code]


Thank you for all your help guys



--

Harry Tanama
Programmer/Developer
.NET / JAVA
Powerd by GNU/LiNUX  


Let Christ be glorify in our words and actions.

Jesus Christ save the entire human race from sins  GNU/Linux save human from 
high cost software applications.



__ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


[Mono-dev] libgdiplus-1.1.9.2.tar.gz

2005-10-10 Thread Harry
Hi guys,

I am try to download the latest libgdiplus but I
coudn't find it at Mono-Development-Project website
release code and also on the svc. Please advise. 

Thanks you in advance




__ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


[Mono-dev] Mono structure of development

2005-10-06 Thread Harry
Hi All,

I have a questions regarding Mono structure
development. I have tried all the link at Mono
website, but I couldn't find it. here is my questions.


1. Is Mono only supporting runtime not the library for
all other programming languages? 

2. Why all the library such as System, System.Drawing,
etc... class is in the mcs library not in Mono library
i.g Mono[verions]/Class/System.Windows.Forms ?

3. Are you guys have different compiler for every
languages and always includes the library such as
System, System.Drawing, etc... i.g [../class/System] ?

4. Is Mono only support runtime for C# programming
languages? 

Thank you in advance for your answers



--

Harry Tanama
Programmer/Developer
.NET / JAVA
Powerd by GNU/LiNUX  


Let Christ be glorify in our words and actions.

Jesus Christ save the entire human race from sins  GNU/Linux save human from 
high cost software applications.



__ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] Time zone problems with DateTime.Parse (patch and bug)

2005-09-07 Thread Harry Holt
Hmmm... Will the changes in daylight saving time for 2007+
(http://aa.usno.navy.mil/faq/docs/daylight_time.html) have any affect
on this?

... HHOn 9/7/05, Atsushi Eno [EMAIL PROTECTED] wrote:
Hi, Test case: http://bugzilla.ximian.com/show_bug.cgi?id=75985 I think the problem here is that the internal DateTime(bool,long)
 constructor calls tz.GetUtcOffset(this) with the UTC time to get the timezone offset before applying it to get local time, but that function expects a local time to determine if DST is active. A bit of a
 chicken-and-egg problem, perhaps... ;) Agreed. But it seems possible to avoid that problem. Can you please try attached patch? I don't have sane Unix environment and I'm
 not in such region that has summer time ;-) It would be even nicer if you try the entire corlib Nunit tests as well. Cool, that's definitely closer! Unfortunately it's still a bit off;
 during the doubled hour in the DST transition it's an hour off in the wrong direction. Using output from my test proggy on that bug: Okk, based on your help, I found some things. The most important one
 is that there are different basis of TimeZone: UTC and local time (there might be other patterns). now I think we need our own TimeZone data store, that would store timezone names as well.
 At least DateTime.ToLocalTime() will be rewritten just to invoke TimeZone.CurrentTimeZone.ToLocalTime(this). So, I'll revisit here later. Thanks for all your help, Brion :-)After some attempt (I think) I could fix 
TimeZone.ToLocalTime() forPST/PDT (the attached patch is for bug #75985). However, I have nobetter idea than that it just fixes offsets in that timezone, asI mentioned my concern about the basis difference (UTC or localtime).
So I will have to dig into POSIX timezone design in depth.And apart from the matter above, I will still have to extend ourlocale-builder to support TimeZone name.Atsushi EnoIndex: System/TimeZone.cs
===--- System/TimeZone.cs(revision 49638)+++ System/TimeZone.cs(working copy)@@ -108,27 +108,33 @@public
virtual DateTime ToLocalTime (DateTime time){-//
return time + GetUtcOffset (time);-
TimeSpan offset = GetUtcOffset (time);--
if (offset.Ticks  0) {-
if (DateTime.MaxValue - offset  time)+
DaylightTime dlt = GetDaylightChanges (time.Year);+
TimeSpan utcOffset = GetUtcOffset (time);+
if (utcOffset.Ticks  0) {+
if (DateTime.MaxValue - utcOffset  time)return
DateTime.MaxValue;-
} else if (offset.Ticks  0) {-
// MS.NET fails to check validity here-
// - it may throw ArgumentOutOfRangeException-
/*-
if (DateTime.MinValue - offset  this)-
return DateTime.MinValue;-
*/+
//} else if (utcOffset.Ticks  0) {+
//LAMESPEC: MS.NET fails to check
validity here+
//it may throw
ArgumentOutOfRangeException.}--
DateTime lt = new DateTime (time.Ticks + offset.Ticks);-
TimeSpan ltoffset = GetUtcOffset (lt);-
if (ltoffset != offset)-
lt = lt.Add (ltoffset.Subtract (offset));-
return lt;+
DateTime local = time.Add (utcOffset);+
if (dlt.Delta.Ticks == 0)+
return local;++
// FIXME: check all of the combination of+
//- basis: local-based or UTC-based+
//- hemisphere: Northern or Southern+
//- offset: positive or negative++
// PST should work fine here.+
if (local  dlt.End  dlt.End.Subtract (dlt.Delta) =
local)+
return local;+
if (local = dlt.Start  dlt.Start.Add (dlt.Delta) 
local)+
return local.Subtract (dlt.Delta);++
TimeSpan localOffset = GetUtcOffset (local);+
return time.Add (localOffset);}public
virtual DateTime ToUniversalTime (DateTime time)___Mono-devel-list mailing listMono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list-- 
Robbie the Nanobot says:Only YOU can prevent gray goo(NEVER release nanobot assemblers without replication limiting code)http://lizardslounge.org
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] Re: [PATCH] Fully Asynchronous and Re-Factored Ssl Streams in Mono.Security

2005-08-31 Thread Harry Holt
This seems to work fine on W2k. Running under IIS5.1 on WXP,
though, it always throws an ObjectDisposedException in
SSLStreamBase.cs when a bind over SSL is attempted.

Won't this:
   if (workthreads = (maxworkthreads - 4))
   {
async = false;
   }
cause the SSL Stream to use synchronous handshake until threads start getting used?

I would also recommend changing this:
  protected void checkDisposed()
  {
   if (this.disposed)
   {
  
 throw new ObjectDisposedException(The Stream is
closed.);
   }
  }

to this:
  protected void checkDisposed()
  {
   if (this.disposed)
   {
  
 throw new
ObjectDisposedException(this.GetType().Name, The Stream is closed.);
   }
  }
which produces a more readable error message.

Thx... HHOn 8/25/05, Sebastien Pouliot [EMAIL PROTECTED] wrote:
Hello JD,On Wed, 2005-24-08 at 21:12 -0700, JD Conley wrote: I took the plunge and fully implemented async Ssl streams for both client and server.This fixes 
http://bugzilla.ximian.com/show_bug.cgi?id=75687 as well as other bugs I've been talking with Sebastien and Carlos about off list. This patch passes the SocketHell tests that I contributed to them last week
 (multi threaded concurrent async streaming through TCP sockets).Wow! That's the kind of surprise I like when I wake up :-) It's also a bit of a re-factor, though I only touched two classes and
 added one.I pulled most of the code out of the individual SslClientStream and SslServerStream and moved it down into a new abstract SslStreamBase.Client and server are now practically the same implementation.I left all existing interfaces present, but
 obviously had to add some new ones.We always sticked to the Fx 1.2 preview specs for the Ssl[Client|Server]Stream API and didn't planned to change this before implementingthe new SslStream (in 
System.dll) for 2.0 - BUT this isn't a majorproblem if it doesn't break binary compatibility (for currentapplications linked with Mono.Security.dll). The only gotcha is if you start running low on threadpool threads.
 Then the Ssl Stream will fall back to a synchronous handshake. The other option here is to spawn a thread ourselves for the handshake instead of using Delegate.BeginInvoke(), use the IO ThreadPool (is
 that available to Mono.Security?), or just live with a synchronous handshake. Of course, 99.999% of the time this issue won't occur and won't be a problem unless you have both client and server sharing the
 same Threadpool causing a deadlock.That's not worse than the original (where the handshake was alwayssynchronous). I hope this helps and gets integrated.It's definitely necessary for
 our implementation.1. I'll review the patch and, in doing so, check for possible binarycompatibility problems. I'm sure Carlos will do likewise;2. I'll make public a new Mono.Security.dll assembly so that people that
depends on Ssl*Stream may tests it and report any problem/difference;3. I'll run the regressions tests, the tools under /mcs/class/Mono.Security/Test/tools/*, to see if it works in previously reportedconditions.
4. Commit (both the patch and your SocketHell tests). Hopefully we cando all this before the next release.Many thanks!--Sebastien___Mono-devel-list mailing list
Mono-devel-list@lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/mono-devel-list
-- Robbie the Nanobot says:Only YOU can prevent gray goo(NEVER release nanobot assemblers without replication limiting code)
http://lizardslounge.org
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] Unhandled Exceptions in Novell.Directory.Ldap and other Synchronization Issues

2005-08-22 Thread Harry Holt
I don't know ??

On 8/22/05, JD Conley [EMAIL PROTECTED] wrote:
  Please submit any bug reports for the LdapCsharp library to Novell
 Forge
  at:
  http://forge.novell.com/modules/xfmod/tracker/?group_id=1318atid=1362
 
 No problem.  Does this library regularly get replicated into the Mono
 SVN repository?  I'd obviously like to see any fixes put in the Mono
 tree.
 
 -JD
 


-- 

Robbie the Nanobot says:
Only YOU can prevent gray goo
(NEVER release nanobot assemblers without replication limiting code)
http://lizardslounge.org
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: SPAM: RE: [Mono-devel-list] DateTime Parameters in MSSQL Server

2005-07-13 Thread Harry Holt
SQL Server will accept a variety of formats for datetime, but .NET
will often hand it dates it can't deal with due to culture settings. 
DateTime.Now may return '7/13/2005' or '13/7/2005', and SQL is
generally going to reject one or the other.  It will also not accept
dates earlier than January 1, 1753.

Yes, it WILL accept ISO formatted datetime, but not UTC.  It will
generally only accept datetime strings with some type of delimiters
for each part.

A word of caution:
If you are using the SQLHelper methods from
Microsoft.ApplicationBlocks.Data, be careful to never use the
ExecuteDataReader methods that accept connection strings.  Instead,
use the ones that accept a Connection object and manage the connection
in your own code.  The methods that accept a connection string will
open new connections and leave them open indefinately.  You will
eventually run out of connections in the pool and your app will die. 
This was a pretty nasty bug that took me a while to track down,
because it didn't show up until my application went into UAT, and I
was looking for problems with MY code instead of the MS stuff (this
behavior is completely the opposite of their own best practices).

If you're having concurrency issues, don't assume it's mono or your
own code - make sure that the application block is handling things
correctly.

... HH


On 7/13/05, Michael J. Ryan [EMAIL PROTECTED] wrote:
 AFAIK, sql server should accept an ISO formatted datetime..
 iirc: -MM-ddTHH:mm:ss.fff
 not sure about appending a zzz for the offset?
 
 maybe entering as UTC with a Z after the .fff ?
 
 Chris van Wyk wrote:
  Hi,
 
  Datetime has also been giving me huge amounts of problems.
 
  The work around for me was to convert the item using ToString(s). If you
  are going to use stored procs, you will need to modify your stored proc
  parameters in the sql statement to string in stead of datetime.
 
  I have also been able to get the Microsoft.ApplicationBlocks.Data going with
  modification to specific DateTime parameter formatting.
 
  There seems to be problems with the data adapter using the sqlhelper from
  the above. I am getting concurrency errors on updates for instance. If
  someone else has had concurrency errors please let me know as I have been
  able to work round this, but I'm not sure if it is a bug in Mono.
 
  I am using 1.1.7 and have not tested the above on 1.1.8
 
  Regards
  Chris
 
 
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:mono-devel-list-
 [EMAIL PROTECTED] On Behalf Of Hubert FONGARNAND
 Sent: 12 July 2005 03:28 PM
 To: mono-devel-list@lists.ximian.com
 Subject: [Mono-devel-list] DateTime Parameters in MSSQL Server
 
 I've an issue with datetime parameters with MSSQL Server in Mono...
 It seem's that the parameters is badly sent to the SQL Server...
 Please test that :
 
 using System;
 using System.Data;
 using System.Data.SqlClient;
 
 class MainClass
 {
   static string cnx=user id=sa;password=sa;data
 source=10.69.100.93;initial
 catalog=Fiche_Produit;
 
 
   public static void Main(string[] args)
   {
   Console.WriteLine(Hello World!);
   SqlCommand cmd=new SqlCommand();
   cmd.Connection=new SqlConnection(cnx);
   cmd.CommandText=INSERT INTO essais (date) VALUES (@date);
   cmd.Parameters.Clear();
 
   cmd.Parameters.Add(@date,SqlDbType.DateTime).Value=DateTime.Now;
   cmd.Connection.Open();
   cmd.ExecuteNonQuery();
   cmd.Connection.Close();
   }
 }
 
 it returns :
 Unhandled Exception: System.Data.SqlClient.SqlException: Erreur de
 conversion
 du type de données varchar en datetime.
 Erreur de conversion du type de données varchar en datetime.
 in [0x00034]
 (at
 /home/hubert/mono/mcs/class/System.Data/System.Data.SqlClient/SqlConnectio
 n.cs:266)
 System.Data.SqlClient.SqlConnection:ErrorHandler (System.Object sender,
 Mono.Data.Tds.Protocol.TdsInternalErrorMessageEventArgs e)
 in (wrapper delegate-invoke)
 System.MulticastDelegate:invoke_void_object_TdsInternalErrorMessageEventAr
 gs
 (object,Mono.Data.Tds.Protocol.TdsInternalErrorMessageEventArgs)
 
 
 In english : error when converting a varchar datatype into a datetime
 
 thanks
 
 --
 Michael J. Ryan - tracker1(at)theroughnecks(dot)com - www.theroughnecks.net
 icq: 4935386  -  AIM/AOL: azTracker1  -  Y!: azTracker1  -  MSN/Win: (email)
 
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list
 


-- 

Robbie the Nanobot says:
Only YOU can prevent gray goo
(NEVER release nanobot assemblers without replication limiting code)
http://lizardslounge.org
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


RE: [Mono-devel-list] Warning with Gnome.About

2005-07-03 Thread Harry Chesley
 On Fri, 2005-07-01 at 09:15 -0700, Harry Chesley wrote:
  I use Gnome.About to display my about box. If I just open and close the
  about box, I get four of the following warnings (with sequential
 increasing
  ids):
 
  (Argeebee:5931): GLib-GObject-WARNING **: gsignal.c:1781: instance
  `0x9f08310' has no handler with id `183'
 
  If I open and close the credits sub-window before closing the about box,
 I
  don't get any warnings.
 
  Is there a way to avoid these warnings?
 
  (I can easily write my own about box, but it seems a shame not to use
 the
  standard one.)
 
  Thanks!
 
 
 
 This has to do with you calling Destroy with attached signal handlers,
 You should either let the gc handle it for you, or detach the signal
 handlers before you call Destroy.

All I do in my program is this (with appropriate declarations of progname,
progversion, prismIcon, authors, and documenters):

   new Gnome.About(progname, progversion, (C) 2005 Harry Chesley,
  Optics game, authors, documenters, null, prismIcon).Run();

So I suspect the offending behavior is inside the Gnome.About class. Short
of fixing it there (which I'd rather not get into as a first Mono project
:-), is there any way to work around it?

Thanks.



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


[Mono-devel-list] Warning with Gnome.About

2005-07-01 Thread Harry Chesley
I use Gnome.About to display my about box. If I just open and close the
about box, I get four of the following warnings (with sequential increasing
ids):

(Argeebee:5931): GLib-GObject-WARNING **: gsignal.c:1781: instance
`0x9f08310' has no handler with id `183'

If I open and close the credits sub-window before closing the about box, I
don't get any warnings.

Is there a way to avoid these warnings?

(I can easily write my own about box, but it seems a shame not to use the
standard one.)

Thanks!



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