[Mono-dev] reviewing x86-codegen.h
Hi all, Reviewing mono/arch/x86/x86-codegen.h I found that sometimes it uses the assert macro while in two cases it is g_assert(). I would guess that there is no problem at all but as I am kind of perfectionist I could not resist to report this. Regards, Aleksey ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Upload (File Field) Control doesn't not add the enctype attribute to the form
I've seen a behaviour difference between Mono and MS.NET with the File Field Control! please see http://bugzilla.ximian.com/show_bug.cgi?id=76837 There's an attached test case! thanks ___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
Re: [Mono-dev] Fix for failing TreeNode tests
Hello, these look good. I have only one comment (inline). Do you have
write access to svn?
Cheers,
Jackson
On Sat, 2005-11-26 at 20:55 +0100, Dieter Bremes wrote:
> Hi,
>
> below are 2 fixes + an additional test for the TreeNode's FullPath and
> Index properties.
>
> I also added the namespace for TreeNodeTest but didn't update the
> indentation because it would obscure the diff.
>
> Dieter
>
>
>
> * TreeNode.cs : Fixed bugs that caused FullPathTest + Traverse to fail.
>
> * TreeNodeTest.cs : Added namespace + SingleNodeIndexTest.
> Fixed warning CS0219.
>
>
> Index: System.Windows.Forms/TreeNode.cs
> ===
> --- System.Windows.Forms/TreeNode.cs (Revision 53205)
> +++ System.Windows.Forms/TreeNode.cs (Arbeitskopie)
> @@ -199,7 +199,7 @@
>
> public string FullPath {
> get {
> - if (tree_view == null)
> + if (TreeView == null)
> throw new Exception ("No TreeView
> associated");
>
> StringBuilder builder = new StringBuilder ();
> @@ -498,9 +498,10 @@
>
> public int Index {
> get {
> - if (parent == null)
> - return -1;
> - return parent.Nodes.IndexOf (this);
> + if (parent != null)
> + return parent.Nodes.IndexOf (this);
> + else
> + return 0;
> }
> }
I would prefer dropping the else here:
> + if (parent != null)
> + return parent.Nodes.IndexOf (this);
> + return 0;
> Index: Test/System.Windows.Forms/TreeNodeTest.cs
> ===
> --- Test/System.Windows.Forms/TreeNodeTest.cs (Revision 53205)
> +++ Test/System.Windows.Forms/TreeNodeTest.cs (Arbeitskopie)
> @@ -1,7 +1,11 @@
> using System;
> using NUnit.Framework;
> using System.Windows.Forms;
> +using SystemDrawingNamespace = System.Drawing; // Prevent CS0234
>
> +namespace MonoTests.System.Windows.Forms
> +{
> +
> [TestFixture]
> public class TreeNodeTest {
>
> @@ -100,6 +104,9 @@
> public void FullPathException ()
> {
> string s = new TreeNode ("").FullPath;
> + // Prevent CS0219, will never write anything
> + // due to previous statement throwing Exception
> + Console.WriteLine(s);
> }
>
> [Test]
> @@ -126,8 +133,8 @@
> TreeNode orig = new TreeNode ("text", 2, 3, new TreeNode [] {
> new
> TreeNode ("child", 22, 33) });
> orig.Tag = FlatStyle.Flat;
> orig.Checked = true;
> - orig.BackColor = System.Drawing.Color.AliceBlue;
> - orig.ForeColor = System.Drawing.Color.Beige;
> + orig.BackColor = SystemDrawingNamespace.Color.AliceBlue;
> + orig.ForeColor = SystemDrawingNamespace.Color.Beige;
>
> TreeNode clone = (TreeNode)orig.Clone ();
> Assert.AreEqual ("text", clone.Text, "#1");
> @@ -138,8 +145,20 @@
> Assert.IsTrue (clone.Checked, "#6");
> Assert.AreEqual ("child", clone.Nodes [0].Text, "#10");
> Assert.AreEqual (22, clone.Nodes [0].ImageIndex, "#11");
> - Assert.AreEqual (System.Drawing.Color.AliceBlue,
> clone.BackColor, "#12");
> - Assert.AreEqual (System.Drawing.Color.Beige, clone.ForeColor,
> "#13");
> + Assert.AreEqual (SystemDrawingNamespace.Color.AliceBlue,
> clone.BackColor, "#12");
> + Assert.AreEqual (SystemDrawingNamespace.Color.Beige,
> clone.ForeColor,
> "#13");
> }
>
> + [Test]
> + public void SingleNodeIndexTest ()
> + {
> + TreeNode tn_1 = new TreeNode ("A");
> + Assert.AreEqual (0, tn_1.Index, "#1");
> + TreeView tv = new TreeView ();
> + tv.Nodes.Add (tn_1);
> + Assert.AreEqual (0, tn_1.Index, "#2");
> + }
> +
> +}
> +
> }
> \ No newline at end of file
> ___
> 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-dev] sharing violation on log4net
I am getting a sharing violation exception a lot since upgrading to mono 1.1.10, the code used to work a lot more often without that exception on mono 1.1.9.2 What its really bothering me now is that the sharing violation not only ocurrs after mono is completely closed and restarted but I am even getting it after system reboots, it makes no sense why that would happen. Below is the exception I get: log4net:ERROR [RollingFileAppender] OpenFile(/home/user/program.log,True) call failed. System.IO.IOException: Sharing violation on path /home/user/program.log in <0x00401> System.IO.FileStream:.ctor (System.String name, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean isAsync, Boolean anonymous) in <0x00046> System.IO.FileStream:.ctor (System.String name, FileMode mode, FileAccess access, FileShare share) in (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare) in <0x00142> System.IO.StreamWriter:.ctor (System.String path, Boolean append, System.Text.Encoding encoding, Int32 bufferSize) in <0x00035> System.IO.StreamWriter:.ctor (System.String path, Boolean append, System.Text.Encoding encoding) in (wrapper remoting-invoke-with-check) System.IO.StreamWriter:.ctor (string,bool,System.Text.Encoding) in <0x00142> log4net.Appender.FileAppender:OpenFile (System.String fileName, Boolean append) in <0x001af> log4net.Appender.RollingFileAppender:OpenFile (System.String fileName, Boolean append) in <0x0008a> log4net.Appender.FileAppender:ActivateOptions () ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] sharing violation on log4net
On Mon, 2005-11-28 at 17:22 -0600, Carlos Solorzano wrote: > I am getting a sharing violation exception a lot since upgrading to mono > 1.1.10, the code used to work a lot more often without that exception on > mono 1.1.9.2 The file handling code should be the same between those two releases, as far as I can remember. > What its really bothering me now is that the sharing violation not only > ocurrs after mono is completely closed and restarted but I am even > getting it after system reboots, it makes no sense why that would happen. The share data is stored in a file in ~/.wapi. If it finds a record for the file you are trying to open, it tries to check /proc for mono processes that have that file open. Look in mono/io-layer/handles.c:_wapi_handle_check_share to see what it's doing, and you might be able to watch it in gdb to see why it's failing. - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] patch for Mono.Cairo to rename Graphics to Context
Hello,
Here is a patch that renames the Graphics class to Context, like all the
other cairo bindings use. It would be a breaking change, but I think it
will be less confusing for developers. Please speak up if you disagree.
There is one other API change I think would be nice, but I dont think
I'll have time to do it this week. That is to change PointD, Color, etc
to structs and rename PointD to Point. Everything else should be able
to be handled in an API compatible way.
Index: Mono.Cairo.dll.sources
===
--- Mono.Cairo.dll.sources (revision 53582)
+++ Mono.Cairo.dll.sources (working copy)
@@ -2,9 +2,9 @@
../../build/common/Consts.cs
../../build/common/Locale.cs
./Mono.Cairo/Cairo.cs
+./Mono.Cairo/Context.cs
./Mono.Cairo/FontOptions.cs
./Mono.Cairo/Matrix.cs
-./Mono.Cairo/Graphics.cs
./Mono.Cairo/Surface.cs
./Mono.Cairo/Pattern.cs
Index: Mono.Cairo/Graphics.cs
===
--- Mono.Cairo/Graphics.cs (revision 53582)
+++ Mono.Cairo/Graphics.cs (working copy)
@@ -1,647 +0,0 @@
-//
-// Mono.Cairo.Graphics.cs
-//
-// Author:
-// Duncan Mak ([EMAIL PROTECTED])
-// Miguel de Icaza ([EMAIL PROTECTED])
-// Hisham Mardam Bey ([EMAIL PROTECTED])
-//
-// (C) Ximian Inc, 2003.
-// (C) Novell Inc, 2003.
-//
-// This is an OO wrapper API for the Cairo API.
-//
-// Copyright (C) 2004 Novell, Inc (http://www.novell.com)
-//
-// Permission is hereby granted, free of charge, to any person obtaining
-// a copy of this software and associated documentation files (the
-// "Software"), to deal in the Software without restriction, including
-// without limitation the rights to use, copy, modify, merge, publish,
-// distribute, sublicense, and/or sell copies of the Software, and to
-// permit persons to whom the Software is furnished to do so, subject to
-// the following conditions:
-//
-// The above copyright notice and this permission notice shall be
-// included in all copies or substantial portions of the Software.
-//
-// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
-// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
-// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
-// NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
-// LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
-// OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
-// WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
-//
-
-using System;
-using System.Runtime.InteropServices;
-using Cairo;
-
-namespace Cairo {
-
-public class Point
-{
- public int X;
- public int Y;
-
- public Point (int x, int y)
- {
- X = x;
- Y = y;
- }
- }
-
-public class PointD
-{
- public double X;
- public double Y;
-
- public PointD (double x, double y)
- {
- X = x;
- Y = y;
- }
- }
-
-
-public class Distance
-{
- public double Dx;
- public double Dy;
-
- public Distance (double x, double y)
- {
- Dx = x;
- Dy = y;
- }
- }
-
-public class Color
-{
- public double R;
- public double G;
- public double B;
- public double A;
-
- public Color(double r, double g, double b) : this (r, g, b, 1.0)
- {
- }
-
- public Color(double r, double g, double b, double a)
- {
- R = r;
- G = g;
- B = b;
- A = a;
- }
- }
-
-public class Graphics : IDisposable
-{
-internal IntPtr state = IntPtr.Zero;
-
-public Graphics (Surface surface)
-{
- state = CairoAPI.cairo_create (surface.Pointer);
-}
-
- public Graphics (IntPtr state)
- {
- this.state = state;
- }
-
- ~Graphics ()
- {
- Dispose (false);
- }
-
- void IDisposable.Dispose ()
- {
- Dispose (true);
- GC.SuppressFinalize (this);
- }
-
-protected virtual void Dispose (bool disposing)
-{
- if (!disposing){
-//Console.WriteLine ("Cairo.Graphics: called from thread");
-return;
- }
-
- if (state == IntPtr.Zero)
-return;
-
- //Console.WriteLine ("Destroying");
-CairoAPI.cairo_destroy (state);
- state = IntPtr.Zero;
-}
-
-public void Save ()
-{
-CairoAPI.cairo_save (state);
-}
-
-public void Restore ()
-{
-CairoAPI.cairo_restore (state);
-}
-
- public Antialias Antialias {
- get { return CairoAPI.cairo_get_antialias (state); }
- set { CairoAPI.cairo_set_antialias (state, value); }
- }
-
-public Cairo.Status Status {
-get {
-return CairoAPI.cairo_status (state);
-}
-}
-
-public Int
Re: [Mono-dev] sharing violation on log4net
Something else that is weird is that XSP doesn't work at all if the log setup fails, I will quit using file base logs on XSP to get around it though. --Carlos On Nov 28, 2005, at 6:22 PM, Dick Porter wrote: On Mon, 2005-11-28 at 17:22 -0600, Carlos Solorzano wrote: I am getting a sharing violation exception a lot since upgrading to mono 1.1.10, the code used to work a lot more often without that exception on mono 1.1.9.2 The file handling code should be the same between those two releases, as far as I can remember. What its really bothering me now is that the sharing violation not only ocurrs after mono is completely closed and restarted but I am even getting it after system reboots, it makes no sense why that would happen. The share data is stored in a file in ~/.wapi. If it finds a record for the file you are trying to open, it tries to check /proc for mono processes that have that file open. Look in mono/io-layer/handles.c:_wapi_handle_check_share to see what it's doing, and you might be able to watch it in gdb to see why it's failing. - Dick ___ 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-dev] System.Drawing.SystemIcons.cs
Hello all, I reimplemented the System.Drawing.SystemIcons.jvm.cs class in a platform independent way, so it’s suitable for mono too. In addition, I put predefined system icons under System.Drawing/Assembly folder. Please review and approve merge of this feature into the mono shared sources. BTW, does someone know why Icon.cs has its codec inside and does not use a pluggable mechanism, like other codecs do? Regards, Konstantin Triger ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Drawing.SystemIcons.cs
> BTW, does someone know why Icon.cs has its codec inside and does not use > a pluggable mechanism, like other codecs do? Not sure what that would achieve. What codecs do you want to plug in? The Icon format is defined by MS. Cheers, Peter ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] System.Drawing.SystemIcons.cs
1. I may want to plug some 3rd party or an encoder. 2. This will give a unified architecture. 3. This will make the ToBitmap method to return the internal object instead of serializing / deserializing to BMP. But actually I wondered whether this was made deliberately or is an historic issue. Regards, Konstantin Triger -Original Message- From: Peter Dennis Bartok [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 9:20 AM To: Konstantin Triger; mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] System.Drawing.SystemIcons.cs > BTW, does someone know why Icon.cs has its codec inside and does not use > a pluggable mechanism, like other codecs do? Not sure what that would achieve. What codecs do you want to plug in? The Icon format is defined by MS. Cheers, Peter ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
