Re: [Mono-dev] Gtk# not found
Well Paulo, It does make sense. On Linux GTK# 2.4 is able to run with most installed linuxes, without forcing people to upgrade GTK+. Windows doesn't come with GTK, so normally it is installed with GTK#, and so in that we can use the latest stable version, as that has also better support for/runs better in Windows. Hope it clarifies things a bit, On 4/8/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Attached goes the file erro.txt with the output. But, yes, my program uses Gtk# 2.8. And, The Linux installer comes with gtk# 2.4, while the windows installer comes with gtk# 2.8. Am i very stupid or does this not makes any sense at all? Citando Wade Berrier [EMAIL PROTECTED]: On Sat, 2006-04-08 at 00:06 +0100, [EMAIL PROTECTED] wrote: It was good to know that it was a bug, as a first thing, because i actually ended up suspecting that it might have not been a bug. And it is good to know that you are still paying attention to it. And even better to know that you may be seeing a solution. I ended up compiling the program with mono 1.1.13.4, to be sure my users could run it without having to install another mono. This time in Windows. Yet another funny thing. Tried it in mono 1.1.13.4 (same) in Linux and it complained again about not finding Gtk... I had used the .bin installer (the click and run installer). So you may want to check that one too, if that wasn't in the plans already. Could you post some details about the error using the Linux installer? The Linux installer comes with gtk# 2.4, while the windows installer comes with gtk# 2.8. Maybe that was the issue? Please run you app with with setting this first: export MONO_LOG_LEVEL=debug and post the output so we can debug this. Thanks! Wade Citando Mike Kestner [EMAIL PROTECTED]: On Fri, 2006-03-31 at 16:04 +0100, [EMAIL PROTECTED] wrote: That instalation of mono worked. My program seemed to run fine. In the mean time, i noticed that there is another version of mono, 1.1.13.6, and went to try that one. It still gives the same problem. For watever reason, your experimental installer for Windows runs my Gtk# 2.4 application while the official mono one does not (neither in Windows nor in Linux)... Talked to Wade about this today and we think we figured out why the mono-project installers policy stuff wasn't working. He's working on the issue. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list __ Porque insiste em pagar o dobro? Compare o preço da sua ligação à Internet http://acesso.portugalmail.pt/maisbarato ___ 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 __ Sabe quanto gasta com a sua ligação à Internet? Verifique aqui: http://acesso.portugalmail.pt/contas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Rafael Monoman Teixeira --- As I'm currently working a lot with Java and even fixing Java VMs (JamVM/Kaffe) and GNU Classpath code, I think I may partly borrow the title (Javaman) from my friend Bruno Souza and become the MonoNJavaMan. Yeah, I may currently be crazier than usual... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Add GetString to UnicodeEncoding 2.0 and modify some Encoding wrappers
Hi, UnicodeEncoding overrides GetString in profile 2.0. This makes it possible to use a faster method without copying bytes to a temporary char array. I also noticed that some wrappers of Encoding class are implemented differently on Mono than on MS.NET that can caouse problems when they are overridden. Please review and approve the patch. Do you have any NUnit test patches as well? Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] PATCH: System.Web.UI/Page.cs
Hello, Attached a small refactoring patch, which implements the Page.GetDataItem(). If no one objects Ill commit. Regards, Konstantin Triger ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] RE: PATCH: System.Web.UI/Page.cs
The patch reattached. Regards, Konstantin Triger From: Konstantin Triger Sent: Monday, April 10, 2006 10:23 AM To: mono-devel Subject: PATCH: System.Web.UI/Page.cs Hello, Attached a small refactoring patch, which implements the Page.GetDataItem(). If no one objects Ill commit. Regards, Konstantin Triger GetDataItem.patch Description: GetDataItem.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] SIGSEGV with Windows.Forms programs (Mono 1.1.14)
Hi all,
programs with Windows.Forms work no longer with Mono 1.1.14 on
Linux.
Sample Code, 'makefile' and stack trace are attached.
Regards and thanks for the good work,
Heinz
Copyright notice: the sample code is from Charles Petzold's
Programming Microsoft Windows with C#
--
Heinz Mueller [EMAIL PROTECTED]
Tel: (+49)5251 815137 Fax: ... 816106
Disclaimer: All opinions above are my own (at least I think so ;-))
//---
// TwoForms.cs © 2001 by Charles Petzold
//---
using System.Windows.Forms;
class TwoForms
{
public static void Main()
{
Form form1 = new Form();
Form form2 = new Form();
form1.Text = Form passed to Run();
form2.Text = Second form;
form2.Show();
Application.Run(form1);
MessageBox.Show(Application.Run() has returned +
control back to Main. Bye, bye!,
TwoForms);
}
}
Could not get XIM
=
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=
Stacktrace:
in (wrapper managed-to-native) System.Windows.Forms.X11Keyboard:XCreateIC
(intptr,string,System.Windows.Forms.XIMProperties,string,intptr,string,intptr,intptr)
0x4
in (wrapper managed-to-native) System.Windows.Forms.X11Keyboard:XCreateIC
(intptr,string,System.Windows.Forms.XIMProperties,string,intptr,string,intptr,intptr)
0xffd2
in System.Windows.Forms.X11Keyboard:CreateXic (intptr) 0x32
in System.Windows.Forms.X11Keyboard:.ctor (intptr,intptr) 0x185
in System.Windows.Forms.XplatUIX11:SetDisplay (intptr) 0x3e9
in System.Windows.Forms.XplatUIX11:.ctor () 0x8b
in System.Windows.Forms.XplatUIX11:GetInstance () 0x40
in System.Windows.Forms.XplatUI:.cctor () 0x61
in (wrapper runtime-invoke) System.Object:runtime_invoke_void
(object,intptr,intptr,intptr) 0xc7782857
in System.Windows.Forms.Form:get_CreateParams () 0x
in System.Windows.Forms.Form:get_CreateParams () 0x64
in System.Windows.Forms.Control:.ctor () 0x273
in System.Windows.Forms.ScrollableControl:.ctor () 0x11
in System.Windows.Forms.ContainerControl:.ctor () 0x10
in System.Windows.Forms.Form:.ctor () 0x19
in (wrapper remoting-invoke-with-check) System.Windows.Forms.Form:.ctor ()
0xfefe
in TwoForms:Main () 0x1e
in (wrapper runtime-invoke) System.Object:runtime_invoke_void
(object,intptr,intptr,intptr) 0xc77838d7
Native stacktrace:
mono(mono_handle_native_sigsegv+0xbb) [0x815385b]
mono [0x813e1bf]
[0xe440]
[0x4120afb2]
[0x4120af23]
[0x4120886e]
[0x41205d6a]
[0x41201014]
[0x41200f01]
[0x40da0ff2]
[0x409bb83e]
mono [0x813e070]
mono(mono_runtime_invoke+0x27) [0x80d7847]
mono(mono_runtime_class_init+0x12b) [0x80d5c4b]
mono [0x813d8c4]
mono [0x813dc12]
mono [0x813ddaa]
mono(mono_compile_method+0x3a) [0x80d604a]
mono(mono_magic_trampoline+0x1a) [0x8154cea]
[0x40251032]
[0x40da0324]
[0x40d9fe9a]
[0x40d9fdb9]
[0x40d9fab2]
[0x409bb7ea]
[0x409bb6c7]
[0x409ba7be]
mono [0x813e070]
mono(mono_runtime_invoke+0x27) [0x80d7847]
mono(mono_runtime_exec_main+0x5c) [0x80d897c]
mono(mono_runtime_run_main+0x171) [0x80d85a1]
mono(strftime+0x1bae) [0x805c632]
mono(mono_main+0x841) [0x805d001]
mono(__fxstat64+0x137) [0x805b9eb]
/lib/tls/libc.so.6(__libc_start_main+0xe0) [0x40116250]
mono(sinh+0x4d) [0x805b941]
mcs -r:System.Windows.Forms twoforms.cs
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] PageThemeFileParser.AddDirective
Hello, Chris. I attach skin file, that works perfectly in dotnet, but fails in mono. If I remove PageThemeFileParser.AddDirective, then TemplateControlParser.AddDirective perfectly performs the job. PageThemeFileParser.AddDirective overrides TemplateControlParser.AddDirective to make adding directives impossible. Why did you decide to block normal AddDirective functionality? Thank you in advance. Andrew. SkinFile.skin Description: SkinFile.skin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] PATCH custom WebControls in skin files
When I use a custom web control in a skin file, then the dll holding
this control must be added to references when compiling PageTheme. The
attached patch makes this possible. As such references is already found
by parsers of individual skins, it's only necessary to add new
assemblies to the theme directory parser.
If no one objects, I will commit.
Index: ThemeDirectoryCompiler.cs
===
--- ThemeDirectoryCompiler.cs (revision 59261)
+++ ThemeDirectoryCompiler.cs (working copy)
@@ -62,7 +62,11 @@
if (!(o is ControlBuilder))
continue;
ptp.RootBuilder.AppendSubBuilder
((ControlBuilder)o);
- }
+ }
+
+ foreach (string ass in ptfp.Assemblies)
+ if (!ptp.Assemblies.Contains
(ass))
+
ptp.AddAssemblyByFileName (ass);
}
PageThemeCompiler compiler = new
PageThemeCompiler (ptp);
Index: TemplateParser.cs
===
--- TemplateParser.cs (revision 59261)
+++ TemplateParser.cs (working copy)
@@ -390,6 +390,20 @@
}
}
+ internal virtual Assembly AddAssemblyByFileName (string
filename)
+ {
+ try {
+ Assembly assembly = Assembly.LoadFrom
(filename);
+ AddAssembly (assembly, true);
+ return assembly;
+ }
+ catch (Exception e)
+ {
+ ThrowParseException (Assembly file +
filename + not found, e);
+ return null; //never gets here, only to
satisfy the compiler
+ }
+ }
+
internal virtual Assembly AddAssemblyByName (string
name)
{
if (anames == null)
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Add GetString to UnicodeEncoding 2.0 and modifysome Encoding wrappers
No, but if you have conceptions regarding what kind of new tests we need I can create some. Kornél - Original Message - From: Atsushi Eno [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Sent: Monday, April 10, 2006 8:09 AM Subject: Re: [Mono-dev] [PATCH] Add GetString to UnicodeEncoding 2.0 and modifysome Encoding wrappers Hi, UnicodeEncoding overrides GetString in profile 2.0. This makes it possible to use a faster method without copying bytes to a temporary char array. I also noticed that some wrappers of Encoding class are implemented differently on Mono than on MS.NET that can caouse problems when they are overridden. Please review and approve the patch. Do you have any NUnit test patches as well? Atsushi Eno ___ 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] Re: What would you like to see in Mono? [.wapi-less config]
On Sun, 2006-04-09 at 16:50 +0200, Joachim Ante wrote: So will such a configure variable be added? Or will MONO_DISABLE_SHM be reintroduced? Yes - Dick signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Missing Socket.Send and Socket.Receive methods
Hi,
Included is a patch that implements the missing Socket.Send and
Socket.Receive methods that take SocketError as an out parameter. These
methods do not throw an exception when an error occurs (such as
WouldBlock) and so are quite essential for non-blocking socket IO. I also
changed the SocketError enum to be internal in .Net 1.x version of the
class lib, so that it can be used in socket code instead of those horrible
if (error != 10035) checks.
I've also made a similar Socket.Connect method, but that's not included as
Microsoft's .Net framework does not have such a method. What is the policy
on non-standard methods?
TomiIndex: mcs/class/System/System.Net.Sockets/Socket.cs
===
--- mcs/class/System/System.Net.Sockets/Socket.cs (revision 59285)
+++ mcs/class/System/System.Net.Sockets/Socket.cs (working copy)
@@ -1318,7 +1318,14 @@
if (buf == null)
throw new ArgumentNullException (buf);
- return Receive_nochecks (buf, 0, buf.Length,
SocketFlags.None);
+ SocketError error;
+
+ int ret = Receive_nochecks (buf, 0, buf.Length,
SocketFlags.None, out error);
+
+ if (error != SocketError.Success)
+ throw new SocketException ((int)error);
+
+ return ret;
}
public int Receive (byte [] buf, SocketFlags flags)
@@ -1329,7 +1336,14 @@
if (buf == null)
throw new ArgumentNullException (buf);
- return Receive_nochecks (buf, 0, buf.Length, flags);
+ SocketError error;
+
+ int ret = Receive_nochecks (buf, 0, buf.Length, flags,
out error);
+
+ if (error != SocketError.Success)
+ throw new SocketException ((int)error);
+
+ return ret;
}
public int Receive (byte [] buf, int size, SocketFlags flags)
@@ -1343,17 +1357,16 @@
if (size 0 || size buf.Length)
throw new ArgumentOutOfRangeException (size);
- return Receive_nochecks (buf, 0, size, flags);
+ SocketError error;
+
+ int ret = Receive_nochecks (buf, 0, size, flags, out
error);
+
+ if (error != SocketError.Success)
+ throw new SocketException ((int)error);
+
+ return ret;
}
- [MethodImplAttribute(MethodImplOptions.InternalCall)]
- private extern static int Receive_internal(IntPtr sock,
- byte[] buffer,
- int offset,
- int count,
- SocketFlags flags,
- out int error);
-
public int Receive (byte [] buf, int offset, int size,
SocketFlags flags)
{
if (disposed closed)
@@ -1368,24 +1381,58 @@
if (size 0 || offset + size buf.Length)
throw new ArgumentOutOfRangeException (size);
- return Receive_nochecks (buf, offset, size, flags);
+ SocketError error;
+
+ int ret = Receive_nochecks (buf, offset, size, flags,
out error);
+
+ if(error != SocketError.Success)
+ throw new SocketException ((int)error);
+
+ return ret;
}
- int Receive_nochecks (byte [] buf, int offset, int size,
SocketFlags flags)
+#if NET_2_0
+ public int Receive (byte[] buf, int offset, int size,
SocketFlags flags, out SocketError error)
{
- int ret, error;
+ if (disposed closed)
+ throw new ObjectDisposedException (GetType
().ToString ());
+
+ if (buf == null)
+ throw new ArgumentNullException (buf);
+
+ if (offset 0 || offset buf.Length)
+ throw new ArgumentOutOfRangeException
(offset);
+
+ if (size 0 || offset + size buf.Length)
+ throw new ArgumentOutOfRangeException (size);
- ret = Receive_internal (socket, buf, offset, size,
Re: [Mono-dev] [PATCH] Add GetString to UnicodeEncoding 2.0 and modifysome Encoding wrappers
Kornél Pál wrote: No, but if you have conceptions regarding what kind of new tests we need I can create some. Things that fails without your patch but does not fail with it. (Otherwise why did you create the patch? ;-) For GetBytes() fix I can imagine the difference (though it is very minor: whether it throws NullReferenceException or ArgumentNullException) but not sure for others. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Add GetString to UnicodeEncoding 2.0 and modifysome Encoding wrappers
OK, now I understand what you mean.:) UnicodeEncoding.GetString should have exactly the same result as previously but it should be much faster because data is written directly to the string instead of creating a temporary char[] buffer. All the modified Encoding methods are very high level wrappers that have currently faster implementations than in my patch because some unnecessary checks are avoided. The problem however is that Encoding is an abstract class with a lot of virtual methods so people can implement their own encodings. In this case they may assume that these wrappers call (or wrap) the same methods as in MS.NET. I noticed this when implementing UnicodeEncoding.GetString because GetString (byte[]) calls GetString (byte[] bytes, int, int) on MS.NET while Mono uses new string (GetChars (byte[])). As you can see on MS.NET overriding GetString (byte[] bytes, int, int) will result in modification of GetString (byte[]) as well while on Mono you have to override both of them to have the same effect. The same goes for the two other modified Encoding methods. They are higher level wrappers on MS.NET than on Mono. So the difference can only be experienced when overriding methods in Encoding, you will get different results on MS.NET and Mono. The exact behaviour of these wrappers could be enforced using a test case by creating an inherited class that throws exceptions when methods that should not be called are called and fails when the expected method was not called but I'm not sure whether we need this kind of tests. Note that explicitly throwing ArgumentNullException is required because of accessing .Length that would result in NullReferenceException. These methods throw ArgumentNullException on MS.NET. Previously I thought that ArgumentNullExceptions were already thrown by the wrapped methods in the current implementation but now I reallized that GetBytes (char[]) currently throws NullReferenceException that is a bug. So the goal of this patch is to implement a fast UnicodeEncoding.GetString and to modify some wrapper methods of Encoding to call the same methods as they do on MS.NET (this actually means to make the higher level wrappers than they are currently). Kornél - Original Message - From: Atsushi Eno [EMAIL PROTECTED] To: Kornél Pál [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Sent: Monday, April 10, 2006 12:54 PM Subject: Re: [Mono-dev] [PATCH] Add GetString to UnicodeEncoding 2.0 and modifysome Encoding wrappers Kornél Pál wrote: No, but if you have conceptions regarding what kind of new tests we need I can create some. Things that fails without your patch but does not fail with it. (Otherwise why did you create the patch? ;-) For GetBytes() fix I can imagine the difference (though it is very minor: whether it throws NullReferenceException or ArgumentNullException) but not sure for others. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Add GetString to UnicodeEncoding 2.0 and modifysome Encoding wrappers
Hi, Now I understood why is UnicodeEncodig.GetBytes(string) overridden in MS.NET 1.x but not in MS.NET 2.0. Encoding of MS.NET uses char[] to convert strings in all versions and the call an overload that takes char[] in GetBytes(string) as well. (This is a difference compared to Mono as it uses char* in 2.0.) And I think MS realized that the should make GetBytes(string) a higher level wrapper just like the other ones and call GetBytes(string, int, int, byte[], int) like the overridden method in UnicodeEncoding does. But then they realized that this would break compatibility with MS.NET 1.x so they dropped the modification done to Encodig.GetBytes(string) but forgot to put back the override in UnicodeEncoding so 2.0 UnicodeEncodig.GetBytes(string) is actually less efficient than in 1.0. I updated the patch to call the right method in UnicodeEncodig.GetBytes(string). Also note that Encoding of Mono is using the new unsafe methods for GetBytes that takes string but MS.NET is not doing this optimization and is using char[] instead that is more efficient when the new unsafe methods are not overridden as they convert pointers back to arrays by default. In addition calling the same methods improves compatibility. (Note that all of these information were obtained by overriding Encoding and printing notification to the console when a method is called.) The updated patch is attached. Kornél - Original Message - From: Kornél Pál [EMAIL PROTECTED] To: Atsushi Eno [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Sent: Monday, April 10, 2006 1:12 PM Subject: Re: [Mono-dev] [PATCH] Add GetString to UnicodeEncoding 2.0 and modifysome Encoding wrappers OK, now I understand what you mean.:) UnicodeEncoding.GetString should have exactly the same result as previously but it should be much faster because data is written directly to the string instead of creating a temporary char[] buffer. All the modified Encoding methods are very high level wrappers that have currently faster implementations than in my patch because some unnecessary checks are avoided. The problem however is that Encoding is an abstract class with a lot of virtual methods so people can implement their own encodings. In this case they may assume that these wrappers call (or wrap) the same methods as in MS.NET. I noticed this when implementing UnicodeEncoding.GetString because GetString (byte[]) calls GetString (byte[] bytes, int, int) on MS.NET while Mono uses new string (GetChars (byte[])). As you can see on MS.NET overriding GetString (byte[] bytes, int, int) will result in modification of GetString (byte[]) as well while on Mono you have to override both of them to have the same effect. The same goes for the two other modified Encoding methods. They are higher level wrappers on MS.NET than on Mono. So the difference can only be experienced when overriding methods in Encoding, you will get different results on MS.NET and Mono. The exact behaviour of these wrappers could be enforced using a test case by creating an inherited class that throws exceptions when methods that should not be called are called and fails when the expected method was not called but I'm not sure whether we need this kind of tests. Note that explicitly throwing ArgumentNullException is required because of accessing .Length that would result in NullReferenceException. These methods throw ArgumentNullException on MS.NET. Previously I thought that ArgumentNullExceptions were already thrown by the wrapped methods in the current implementation but now I reallized that GetBytes (char[]) currently throws NullReferenceException that is a bug. So the goal of this patch is to implement a fast UnicodeEncoding.GetString and to modify some wrapper methods of Encoding to call the same methods as they do on MS.NET (this actually means to make the higher level wrappers than they are currently). Kornél - Original Message - From: Atsushi Eno [EMAIL PROTECTED] To: Kornél Pál [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Sent: Monday, April 10, 2006 12:54 PM Subject: Re: [Mono-dev] [PATCH] Add GetString to UnicodeEncoding 2.0 and modifysome Encoding wrappers Kornél Pál wrote: No, but if you have conceptions regarding what kind of new tests we need I can create some. Things that fails without your patch but does not fail with it. (Otherwise why did you create the patch? ;-) For GetBytes() fix I can imagine the difference (though it is very minor: whether it throws NullReferenceException or ArgumentNullException) but not sure for others. Atsushi Eno UnicodeEncoding.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Add GetString to UnicodeEncoding 2.0 and modifysome Encoding wrappers
Hi, Kornél Pál wrote: Hi, Now I understood why is UnicodeEncodig.GetBytes(string) overridden in MS.NET 1.x but not in MS.NET 2.0. Encoding of MS.NET uses char[] to convert strings in all versions and the call an overload that takes char[] in GetBytes(string) as well. (This is a difference compared to Mono as it uses char* in 2.0.) And I think MS realized that the should make GetBytes(string) a higher level wrapper just like the other ones and call GetBytes(string, int, int, byte[], int) like the overridden method in UnicodeEncoding does. But then they realized that this would break compatibility with MS.NET 1.x so they dropped the modification done to Encodig.GetBytes(string) but forgot to put back the override in UnicodeEncoding so 2.0 UnicodeEncodig.GetBytes(string) is actually less efficient than in 1.0. I updated the patch to call the right method in UnicodeEncodig.GetBytes(string). Also note that Encoding of Mono is using the new unsafe methods for GetBytes that takes string but MS.NET is not doing this optimization and is using char[] instead that is more efficient when the new unsafe methods are not overridden as they convert pointers back to arrays by default. In addition calling the same methods improves compatibility. Umm, I don't think that should be our way to go. Creating char[] in GetBytes(string) is *obviously* inefficient. Since I actually added pointer-based overrides in I18N classes, there is no pointers-goes-back-to-arrays problem. This kind of compatibility change rather harms Mono performance. Without exact, practical, clear and present danger of incompatiblity problem, this change makes no sense to me. I'd love to make Mono not suck in the name of compatibility which is anyways broken promise in .NET land. (You should also notice that Encoding implementation in 2.0 is totally different than 1.x. In .NET 2.0 they are managed. In 1.x they are just WIN32API wrappers. They are anyways incompatible, for example having different fallback replacement characters.) (Note that all of these information were obtained by overriding Encoding and printing notification to the console when a method is called.) The updated patch is attached. I wouldn't apply this new patch. If other mono hackers do that I won't stop (but then it is very likely to happen that I stop helping Encoding improvements anymore). Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] PATCH: System.Web.UI.WebControls.BulletedList.cs
Hello, Attached a patch that contains a test file for the class System.Web.UI.WebControls.BulletedList. If no one objects, I will commit. Tal Klahr BulletedListTest.patch Description: BulletedListTest.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] PATCH ThemeDirectoryCompiler.GetCompiledType fix
Hi Chris,
Please review the attached patch for the method in subj. If no one
objects, I will commit.
Index: ThemeDirectoryCompiler.cs
===
--- ThemeDirectoryCompiler.cs (revision 59261)
+++ ThemeDirectoryCompiler.cs (working copy)
@@ -44,7 +44,7 @@
public static Type GetCompiledType (string virtualPath,
HttpContext context)
{
/* XXX map the virtual path to a physical path
*/
- string physicalPath = virtualPath;
+ string physicalPath = context.Request.MapPath
(virtualPath);
string[] skin_files = Directory.GetFiles
(physicalPath, *.skin);
PageThemeParser ptp = new PageThemeParser
(virtualPath, context);
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] XML Parser
Hi, I would like to have a XML Parser that parses network XML stream from server. I would like to be able to feed it with data received from a socket, then be notified of XML nodes encountered in that stream. Say, server sends me stream message/ presence/ iq/ /stream I would like to be notified when message/, presence/, iq/ tags, as well with XML nodes associated with them. Can this be achieved (such push-pull behaviour) with System.Xml? What class(es) should I use? Thanks in advance, Przemysław Sitek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] XML Parser
On 4/10/06, Przemysław Sitek [EMAIL PROTECTED] wrote: Hi, I would like to have a XML Parser that parses network XML stream from server. I would like to be able to feed it with data received from a socket, then be notified of XML nodes encountered in that stream. Say, server sends me stream message/ presence/ iq/ /stream I would like to be notified when message/, presence/, iq/ tags, as well with XML nodes associated with them. Can this be achieved (such push-pull behaviour) with System.Xml? What class(es) should I use? Thanks in advance, Przemysław Sitek ___ Take a look at XmlTextReader class. -- -- Svetoslav Milenov (Sunny) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] PageThemeFileParser.AddDirective
Because most directives are illegal in skin files (Page, Assembly, etc), I assumed that all were. Obviously this isn't the case :) After more investigation, it looks like Register is the only directive allowed. Does this agree with your assessment? By the way, I'm subscribed to this list, so there's no reason to CC me. Chris On Mon, 2006-04-10 at 00:59 -0700, Andrew Skiba wrote: Hello, Chris. I attach skin file, that works perfectly in dotnet, but fails in mono. If I remove PageThemeFileParser.AddDirective, then TemplateControlParser.AddDirective perfectly performs the job. PageThemeFileParser.AddDirective overrides TemplateControlParser.AddDirective to make adding directives impossible. Why did you decide to block normal AddDirective functionality? Thank you in advance. Andrew. ___ 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] PATCH ThemeDirectoryCompiler.GetCompiledType fix
looks good. please remove the XXX comment as well. Chris ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] XML Parser
Hi,
Sunny wrote:
Take a look at XmlTextReader class.
I have looked at that class but I have not found any method to achieve such
push behaviour. I would like to have something like that:
SomeDataAvailableFroRead () {
char [] data = Socket.Read ();
parser.Parse (data);
parser.GetAvailableXmlNodes ();
}
Thanks in advance,
Przemysław Sitek
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] PATCH custom WebControls in skin files
patch looks fine, but I'd prefer an AddAssemblyByFileName that looks
more like AddAssemblyByName, as in:
internal virtual Assembly AddAssemblyByFileName (string filename)
{
Assembly assembly = null;
Exception error = null;
try {
assembly = Assembly.LoadFrom (filename);
} catch (Exception e) { error = e; }
if (assembly == null)
ThrowParseException (Assembly + filename + not
found, error);
AddAssembly (assembly, true);
return assembly;
}
Chris
On Mon, 2006-04-10 at 02:34 -0700, Andrew Skiba wrote:
When I use a custom web control in a skin file, then the dll holding
this control must be added to references when compiling PageTheme. The
attached patch makes this possible. As such references is already found
by parsers of individual skins, it's only necessary to add new
assemblies to the theme directory parser.
If no one objects, I will commit.
Index: ThemeDirectoryCompiler.cs
===
--- ThemeDirectoryCompiler.cs (revision 59261)
+++ ThemeDirectoryCompiler.cs (working copy)
@@ -62,7 +62,11 @@
if (!(o is ControlBuilder))
continue;
ptp.RootBuilder.AppendSubBuilder
((ControlBuilder)o);
- }
+ }
+
+ foreach (string ass in ptfp.Assemblies)
+ if (!ptp.Assemblies.Contains
(ass))
+
ptp.AddAssemblyByFileName (ass);
}
PageThemeCompiler compiler = new
PageThemeCompiler (ptp);
Index: TemplateParser.cs
===
--- TemplateParser.cs (revision 59261)
+++ TemplateParser.cs (working copy)
@@ -390,6 +390,20 @@
}
}
+ internal virtual Assembly AddAssemblyByFileName (string
filename)
+ {
+ try {
+ Assembly assembly = Assembly.LoadFrom
(filename);
+ AddAssembly (assembly, true);
+ return assembly;
+ }
+ catch (Exception e)
+ {
+ ThrowParseException (Assembly file +
filename + not found, e);
+ return null; //never gets here, only to
satisfy the compiler
+ }
+ }
+
internal virtual Assembly AddAssemblyByName (string
name)
{
if (anames == null)
___
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] Re: [PATCH] DocumentableItem.ExtensibleAttributes
Hi, Isn't there a way of doing this without modifying ServiceDescriptionSerializerBase.cs? it is a generated file, so it should not be modified by hand. Lluis. El jue, 06-04-2006 a las 19:23 +0530, Ankit Jain escribió: Hi, The attached patch adds the property System.Web.Services.Description.DocumentableItem.ExtensibleAttributes for the NET_2_0 profile, and adds support for it in ServiceDescriptionSerializerBase . Also attached is a test case for the same. Please review. -Ankit -- Blog : http://ankitj.blogspot.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Where is the JIT compiler?
Hi everyone out there! Is mini.c the heart of the JIT compiler? I'm trying to understand the way the JIT works, but I'm not having an easy time finding my way around the source code tree. Thanks, Alan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around 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] HttpRequest.MapPath and UrlUtils.Combine codeduplication
On Mon, 2006-04-10 at 13:38 -0700, Andrew Skiba wrote: [...] If you say that you want to replace backslashes on non-windows system, too, then I will leave Combine intact. But anyway the code that I removed from MapPath can be removed safely, Combine does all that anyway. As long as backslashes are replaced on non-windows systems, you can commit. Thanks. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] FAMWatcher race condition patch
On Sun, 2006-04-09 at 16:37 +1200, Thong Nguyen wrote: The FAM based FileSystemWatcher has problems monitoring directories recursively because FAM doesn't support this natively. FMAWatcher gets around this by telling FAM to monitor a subdirectory every time a sub directory is created. This will work but there is a race condition that occurs when a sub directory is created and populated with files before FAM is told to monitor the new sub directory. This results in files being created without the FSW raising the appropriate events. For example: If I'm monitoring the current dir and I do this: mkdir a; touch a/pok [...] Your patch is now in svn. Thanks a lot. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Bug in System.WebHttpUtility.UrlDecode
On Mon, 2006-03-27 at 01:56 -0800, Vladimir Krasnov wrote: Hello, There is a bug in UrlDecode method in System.WebHttpUtility, when two precent chars '%%' are present in encoded Url, UrlDecode fails to decode. Also, when the % char follows characters that are not hex numbers, the result of UrlDecode is wrong. Look at attached test cases and the patch that fixes this bug. If no one objects I will commit Hi Vladimir. I just merged in the stuff from your patch that wasn't fixed yet after the changes in the last 2 weeks. Thanks. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Gtk# not found
Ok, i also remembered to try with my older version. That one had been compiled in Linux with mono 1.1.13.2 . I remembered of it complaining, also, of not finding Gtk but it isn't true, it complains of something else. Attached, i send the file erro.txt with the console result. One other dude who tried that older 1.1.13.2 version on Linux in mono 1.1.13.4 said that the program runs well. He didn't installed with the Linux universal installer, like i did. Hope this helps. [EMAIL PROTECTED] escreveu: Attached goes the file erro.txt with the output. But, yes, my program uses Gtk# 2.8. And, The Linux installer comes with gtk# 2.4, while the windows installer comes with gtk# 2.8. Am i very stupid or does this not makes any sense at all? Citando Wade Berrier [EMAIL PROTECTED]: On Sat, 2006-04-08 at 00:06 +0100, [EMAIL PROTECTED] wrote: It was good to know that it was a bug, as a first thing, because i actually ended up suspecting that it might have not been a bug. And it is good to know that you are still paying attention to it. And even better to know that you may be seeing a solution. I ended up compiling the program with mono 1.1.13.4, to be sure my users could run it without having to install another mono. This time in Windows. Yet another funny thing. Tried it in mono 1.1.13.4 (same) in Linux and it complained again about not finding Gtk... I had used the .bin installer (the click and run installer). So you may want to check that one too, if that wasn't in the plans already. Could you post some details about the error using the Linux installer? The Linux installer comes with gtk# 2.4, while the windows installer comes with gtk# 2.8. Maybe that was the issue? Please run you app with with setting this first: export MONO_LOG_LEVEL=debug and post the output so we can debug this. Thanks! Wade Citando Mike Kestner [EMAIL PROTECTED]: On Fri, 2006-03-31 at 16:04 +0100, [EMAIL PROTECTED] wrote: That instalation of mono worked. My program seemed to run fine. In the mean time, i noticed that there is another version of mono, 1.1.13.6, and went to try that one. It still gives the same problem. For watever reason, your experimental installer for Windows runs my Gtk# 2.4 application while the official mono one does not (neither in Windows nor in Linux)... Talked to Wade about this today and we think we figured out why the mono-project installers policy stuff wasn't working. He's working on the issue. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list __ Porque insiste em pagar o dobro? Compare o preço da sua ligação à Internet http://acesso.portugalmail.pt/maisbarato ___ 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 __ Email gratuito com 2 000 MB Espaço para guardar 1 milhão de mensagens http://www.portugalmail.pt/2000mb [EMAIL PROTECTED]:~ export MONO_LOG_DEVEL=debug [EMAIL PROTECTED]:~ cd EdSv0.9/ [EMAIL PROTECTED]:~/EdSv0.9 /opt/mono-1.1.13.4/bin/mono EditorSpringGUI.exe.mono Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for Gtk.Container--- System.DllNotFoundException: gtksharpglue-2 in (wrapper managed-to-native) Gtk.Container:gtksharp_gtk_container_get_focus_child_offset () in 0xa Gtk.Container:.cctor ()--- End of inner exception stack trace --- in 0x0 unknown method in 0xe Gtk.Bin:.ctor (IntPtr raw) in 0x0002f Gtk.Window:.ctor (WindowType type) in 0xc Gtk.Window:.ctor (System.String title) in 0x0002a EditorSpringGUI.LinguaGUI:.ctor () in 0x00042 EditorSpringGUI.Principal:.ctor () in 0x00016 EditorSpringGUI.Principal:Main (System.String[] args) [EMAIL PROTECTED]:~/EdSv0.9 [EMAIL PROTECTED]:~/EdSv0.9 [EMAIL PROTECTED]:~/EdSv0.9 [EMAIL PROTECTED]:~/EdSv0.9 /opt/mono-1.1.14/bin/mono EditorSpringGUI.exe.mono Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for Gtk.Container--- System.DllNotFoundException: gtksharpglue-2 in (wrapper managed-to-native) Gtk.Container:gtksharp_gtk_container_get_focus_child_offset () in 0xa Gtk.Container:.cctor ()--- End of inner exception stack trace --- in 0x0 unknown method in 0xe Gtk.Bin:.ctor (IntPtr raw) in 0x0002f Gtk.Window:.ctor (WindowType type) in 0xc Gtk.Window:.ctor (System.String title) in 0x0002a
Re: [Mono-dev] Gtk# not found
I understood what you say. But in my head it is still hardly acceptable. What is mono and what are those virtual machines? They work like they do, in a great part, so we can have a intermediate language with which to compile programs which will work on all systems because each system will have it's own virtual machine to serve as a intermediate between that special language and the O.S. (me thinks) Working with mono and C# also brings lots of easinesses in many other areas but one of the main features is the theoretical «compile once, run everywhere where there is a virtual machine». Now look at how mono is at the moment. I can't just make an aplication to distribute expecting it to work. Rafael Teixeira escreveu: Well Paulo, It does make sense. On Linux GTK# 2.4 is able to run with most installed linuxes, without forcing people to upgrade GTK+. Windows doesn't come with GTK, so normally it is installed with GTK#, and so in that we can use the latest stable version, as that has also better support for/runs better in Windows. Hope it clarifies things a bit, On 4/8/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Attached goes the file erro.txt with the output. But, yes, my program uses Gtk# 2.8. And, The Linux installer comes with gtk# 2.4, while the windows installer comes with gtk# 2.8. Am i very stupid or does this not makes any sense at all? Citando Wade Berrier [EMAIL PROTECTED]: On Sat, 2006-04-08 at 00:06 +0100, [EMAIL PROTECTED] wrote: It was good to know that it was a bug, as a first thing, because i actually ended up suspecting that it might have not been a bug. And it is good to know that you are still paying attention to it. And even better to know that you may be seeing a solution. I ended up compiling the program with mono 1.1.13.4, to be sure my users could run it without having to install another mono. This time in Windows. Yet another funny thing. Tried it in mono 1.1.13.4 (same) in Linux and it complained again about not finding Gtk... I had used the .bin installer (the click and run installer). So you may want to check that one too, if that wasn't in the plans already. Could you post some details about the error using the Linux installer? The Linux installer comes with gtk# 2.4, while the windows installer comes with gtk# 2.8. Maybe that was the issue? Please run you app with with setting this first: export MONO_LOG_LEVEL=debug and post the output so we can debug this. Thanks! Wade Citando Mike Kestner [EMAIL PROTECTED]: On Fri, 2006-03-31 at 16:04 +0100, [EMAIL PROTECTED] wrote: That instalation of mono worked. My program seemed to run fine. In the mean time, i noticed that there is another version of mono, 1.1.13.6, and went to try that one. It still gives the same problem. For watever reason, your experimental installer for Windows runs my Gtk# 2.4 application while the official mono one does not (neither in Windows nor in Linux)... Talked to Wade about this today and we think we figured out why the mono-project installers policy stuff wasn't working. He's working on the issue. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list __ Porque insiste em pagar o dobro? Compare o preço da sua ligação à Internet http://acesso.portugalmail.pt/maisbarato ___ 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 __ Sabe quanto gasta com a sua ligação à Internet? Verifique aqui: http://acesso.portugalmail.pt/contas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Rafael Monoman Teixeira --- As I'm currently working a lot with Java and even fixing Java VMs (JamVM/Kaffe) and GNU Classpath code, I think I may partly borrow the title (Javaman) from my friend Bruno Souza and become the MonoNJavaMan. Yeah, I may currently be crazier than usual... __ Para grandes mails, grandes contas Portugalmail: 2 000 MB de espaço http://www.portugalmail.pt/2000mb ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Missing Socket.Send and Socket.Receive methods
On Mon, 2006-04-10 at 13:17 +0300, Tomi Valkeinen wrote: Hi, Included is a patch that implements the missing Socket.Send and Socket.Receive methods that take SocketError as an out parameter. These methods do not throw an exception when an error occurs (such as WouldBlock) and so are quite essential for non-blocking socket IO. I also changed the SocketError enum to be internal in .Net 1.x version of the class lib, so that it can be used in socket code instead of those horrible if (error != 10035) checks. Your patch is in svn HEAD now. Thanks. I've also made a similar Socket.Connect method, but that's not included as Microsoft's .Net framework does not have such a method. What is the policy on non-standard methods? We have to keep the System assembly compatible with MS's, so having extra public methods/fields/blah is not an option. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] PATCH: System.Web.UI.WebControls.BulletedList.cs
On Mon, 2006-04-10 at 06:22 -0700, Tal Klar wrote: Hello, Attached a patch that contains a test file for the class System.Web.UI.WebControls.BulletedList. Hi Tal. New test cases are always welcome but, please, follow the coding style guidelines in http://www.mono-project.com/Coding_Guidelines (also mcs/class/README). Thanks. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] VB ASP.NET on a Fedora Core 3
Hi, I'm not sure that this is the correct list. I'm trying to run a VB ASP.NET developed with VS2003 on a Fedora Core 3 x86-64 using XSP: xsp-1.0.9-0.novell MONO: 1.1.8 I've copied all (RELEASE - NO incremental build) files but I get an error, so I searched and dropped CodeBehind incompatibility: Codebehind=_Footer.ascx.vb but now I get this error: Description: Error parsing a resource required to service this request. Review your source file and modify it to fix this error. Error message: Cannot find type xxx.C_footer File name: /var/www/html/yyy/xxx/_Footer.ascxLine: 1 Source Error: %@ Control Language=vb AutoEventWireup=false Inherits=xxx.C_footer % What I'm wrong? Must recompile Mono with a newer version 1.1.14? I tried but I've some problems recompiling libgdiplus-1.1.14: [snip] some warning about missing image libraries (tiff and gif) configure: error: Failed to compile with X11/Xlib.h include. You must fix your compiler paths Mono-1.1.14 is compiled fine (after installing glib2-devel-2.4.7-1.x86_64) Thanks ___ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
