[Mono-dev] Tests failures when running on MS.NET
Hi, I have noticed that the following CharCategory related tests fails when running on MS: CharCategoryTest.IsDigit CharCategoryTest.IsLower CharCategoryTest.IsNumber CharCategoryTest.IsPunctuation CharCategoryTest.IsSeperator CharCategoryTest.IsSymbol CharCategoryTest.IsUpper CharCategoryTest.IsWhiteSpace Is there a specific reason for this or can I fix the tests? Regards, Roei Erez ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Can we change the name of the MonoTests.System namespace?
Hi all, This has happened several times now. I'm adding some code to a unit test class and want to use the fully qualified name (e.g. System.Web.UI.Adapters.PageAdapter) for some type, either because (a) I'm only using the type in a couple spots and I'd rather not pollute the namespace with a 'using' declaration, or (b) the unqualified name (e.g. PageAdapter) is already being used in the current namespace for something else. But when I try to use the fully qualified name I get a compile time error like this: error CS0234: The type or namespace name `PageAdapter' does not exist in the namespace `MonoTests.System.Web.UI.Adapters'. Are you missing an assembly reference? Basically, the compiler uses (correctly I think) the System namespace under MonoTests instead of the top-level System namespace. I could do: using Sys = System; but that is going to make my code less readable. The next developer to come along will have to check the using declarations to figure out exactly what Sys.Web.UI.Adapters.PageAdapter refers to. As I mentioned above, I could do: using System.Web.UI.Adapters; but that will unnecessarily pollute the namespace when I'm only using the type in a couple spots. It also doesn't help when the name is already in use in the current namespace. This wouldn't be a problem if we didn't have a namespace named System under MonoTests. Thus the question in the subject of this message: Can we change the name of the MonoTests.System namespace? We could use MonoTests_System, MonoTestsSystem, or perhaps just System. Using just System has the advantage that we wouldn't need as many using declarations to access the classes being tested, but there might be some major disadvantage that I'm missing. Thoughts? --Dean ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] The big as cast cleanup
Thanks for the feedback!
I've reduced the patch to those spots where I'm adding real value to the
code.
Please review.
The patch is a lot shorter now...
- Juraj
On Tue, 2008-01-08 at 22:34 -0500, Miguel de Icaza wrote:
I don't like to change working code unnecessarily just for your
preference. I'd wait for another patch that removes any extra changes.
I agree with Atsushi's statement, and also:
Personally I like as operator which sometimes makes the sources
more readable and kind enough for code completion depending on
the editor/IDE.
miguel.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Index: System.Collections/ChangeLog
===
--- System.Collections/ChangeLog (revision 92431)
+++ System.Collections/ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2008-01-08 Juraj Skripsky [EMAIL PROTECTED]
+
+ * SortedList.cs (Clone): Remove unnecessary cast with as.
+
+ * Comparer.cs (Compare): Eliminate is check.
+
2007-11-06 Jb Evain [EMAIL PROTECTED]
* Hashtable.cs: Don't compare user keys against the special removed
Index: System.Collections/SortedList.cs
===
--- System.Collections/SortedList.cs (revision 92431)
+++ System.Collections/SortedList.cs (working copy)
@@ -1140,7 +1140,7 @@
public override object Clone ()
{
lock (host.SyncRoot) {
- return (host.Clone () as SortedList);
+ return host.Clone ();
}
}
Index: System.Collections/Comparer.cs
===
--- System.Collections/Comparer.cs (revision 92431)
+++ System.Collections/Comparer.cs (working copy)
@@ -87,10 +87,12 @@
return m_compareInfo.Compare (sa, sb);
}
- if (a is IComparable)
-return (a as IComparable).CompareTo (b);
- else if (b is IComparable)
-return -(b as IComparable).CompareTo (a);
+ IComparable ca = a as IComparable;
+ if (ca != null)
+return ca.CompareTo (b);
+ IComparable cb = b as IComparable;
+ if (cb != null)
+return -cb.CompareTo (a);
throw new ArgumentException (Locale.GetText (Neither 'a' nor 'b' implements IComparable.));
}
Index: System.Collections.ObjectModel/Collection.cs
===
--- System.Collections.ObjectModel/Collection.cs (revision 92431)
+++ System.Collections.ObjectModel/Collection.cs (working copy)
@@ -51,10 +51,8 @@
public Collection ()
{
- List T l = new List T ();
- IList l2 = l as IList;
- syncRoot = l2.SyncRoot;
- list = l;
+ list = new List T ();
+ syncRoot = ((IList)list).SyncRoot;
}
public Collection (IList T list)
Index: System.Collections.ObjectModel/ChangeLog
===
--- System.Collections.ObjectModel/ChangeLog (revision 92431)
+++ System.Collections.ObjectModel/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2008-01-08 Juraj Skripsky [EMAIL PROTECTED]
+
+ * Collection.cs (.ctor): Replace as with explicit cast, as List T
+ always implements IList.
+
2006-08-08 Atsushi Enomoto [EMAIL PROTECTED]
* ReadOnlyCollection.cs : added get_IListT.this(int).
Index: System.Text/EncoderExceptionFallback.cs
===
--- System.Text/EncoderExceptionFallback.cs (revision 92431)
+++ System.Text/EncoderExceptionFallback.cs (working copy)
@@ -49,7 +49,7 @@
public override bool Equals (object value)
{
- return value as EncoderExceptionFallback != null;
+ return (value is EncoderExceptionFallback);
}
public override int GetHashCode ()
Index: System.Text/ChangeLog
===
--- System.Text/ChangeLog (revision 92431)
+++ System.Text/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2008-01-08 Juraj Skripsky [EMAIL PROTECTED]
+
+ * EncoderExceptionFallback.cs (Equals),
+ DecoderExceptionFallback.cs (Equals): Reduce .. as .. != null to is.
+
2007-12-27 Atsushi Enomoto [EMAIL PROTECTED]
* DecoderFallback.cs, EncoderFallback.cs, Encoding.cs :
Index: System.Text/DecoderExceptionFallback.cs
===
--- System.Text/DecoderExceptionFallback.cs (revision 92431)
+++ System.Text/DecoderExceptionFallback.cs (working copy)
@@ -49,7 +49,7 @@
public override bool Equals (object value)
{
- return value as DecoderExceptionFallback != null;
+ return (value is DecoderExceptionFallback);
}
public override int GetHashCode ()
Index: System.Runtime.Remoting.Proxies/ChangeLog
===
--- System.Runtime.Remoting.Proxies/ChangeLog (revision 92431)
+++ System.Runtime.Remoting.Proxies/ChangeLog (working copy)
@@ -1,3 +1,7 @@
Re: [Mono-dev] Tests failures when running on MS.NET
Those values are different between .NET 2.0 and 1.x. In mono land they are embedded in our runtime, which does not differentiate 2.0 and 1.x. If we have both tables it increases the size of the runtime almost unnecessarily. You can't fix the tests. You don't pay any attention to the Mono test results, but if you fix them, they will fail on mono. Atsushi Eno Roei Erez wrote: Hi, I have noticed that the following CharCategory related tests fails when running on MS: CharCategoryTest.IsDigit CharCategoryTest.IsLower CharCategoryTest.IsNumber CharCategoryTest.IsPunctuation CharCategoryTest.IsSeperator CharCategoryTest.IsSymbol CharCategoryTest.IsUpper CharCategoryTest.IsWhiteSpace Is there a specific reason for this or can I fix the tests? Regards, Roei Erez ___ 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] Patch for HttpRequest and HttpCookieCollection
Hi Marek,
Attached is a patch that
- fixes a issue in HttpRequest.UrlReferrer
(it is not supposed to throw when the headers contain an invalid url)
- adds a unit test for that issue
- simplifies the code in HttpCookieCollection.AllKeys
All unit tests pass.
May I commit?
- Juraj
Index: Test/System.Web/ChangeLog
===
--- Test/System.Web/ChangeLog (revision 92488)
+++ Test/System.Web/ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2008-01-09 Juraj Skripsky [EMAIL PROTECTED]
+
+ * HttpRequestTest.cs (TestReferer): added test for invalid referer url.
+
2007-12-19 Gert Driesen [EMAIL PROTECTED]
* HttpCookieCollectionTest.cs: Added test for string indexer and
Index: Test/System.Web/HttpRequestTest.cs
===
--- Test/System.Web/HttpRequestTest.cs (revision 92488)
+++ Test/System.Web/HttpRequestTest.cs (working copy)
@@ -417,6 +417,7 @@
case 1: return null;
case 2: return http://www.mono-project.com/test.aspx;;
case 15: return http://www.mono-project.com;;
+ case 33: return x;
}
break;
case HttpWorkerRequest.HeaderUserAgent:
@@ -751,7 +752,10 @@
Assert.AreEqual (null, c.Request.UrlReferrer, REF1);
c = Cook (2);
- Assert.AreEqual (http://www.mono-project.com/test.aspx;, c.Request.UrlReferrer.ToString (), REF1);
+ Assert.AreEqual (http://www.mono-project.com/test.aspx;, c.Request.UrlReferrer.ToString (), REF1);
+
+ c = Cook (33);
+ Assert.AreEqual (null, c.Request.UrlReferrer, REF1);
}
Index: System.Web/ChangeLog
===
--- System.Web/ChangeLog (revision 92488)
+++ System.Web/ChangeLog (working copy)
@@ -1,3 +1,12 @@
+2008-01-09 Juraj Skripsky [EMAIL PROTECTED]
+
+ * HttpRequest.cs (get_UrlReferrer): Handle case when headers contain
+ invalid Url for referer.
+
+2008-01-09 Juraj Skripsky [EMAIL PROTECTED]
+
+ * HttpCookieCollection.cs (AllKeys): Use Keys.CopyTo().
+
2008-01-02 Vladimir Krasnov [EMAIL PROTECTED]
* HttpContext.cs: added resource manager caching in GetResourceObject
Index: System.Web/HttpCookieCollection.cs
===
--- System.Web/HttpCookieCollection.cs (revision 92488)
+++ System.Web/HttpCookieCollection.cs (working copy)
@@ -28,6 +28,7 @@
// WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
//
+using System.Collections;
using System.Collections.Specialized;
using System.Security.Permissions;
@@ -161,13 +162,8 @@
public string[] AllKeys {
get {
-/* XXX another inefficient copy due to
- * lack of exposure from the base
- * class */
string[] keys = new string [Keys.Count];
-for (int i = 0; i Keys.Count; i ++)
- keys[i] = Keys[i];
-
+((ICollection)Keys).CopyTo (keys, 0);
return keys;
}
}
Index: System.Web/HttpRequest.cs
===
--- System.Web/HttpRequest.cs (revision 92488)
+++ System.Web/HttpRequest.cs (working copy)
@@ -1069,7 +1069,11 @@
if (hr == null)
return null;
-return new Uri (hr);
+Uri uri = null;
+try {
+ uri = new Uri (hr);
+} catch (UriFormatException) {}
+return uri;
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Tests failures when running on MS.NET
Hello, Agreed. If there's no objection I'd welcome such a change (or will do if no one does but not sure when). Atsushi Eno Hi, Atsushi. So right now Mono 2.0 behaves like .Net 1.1. What about making Mono compatible with .Net 2.0? This will make Mono 1.1 behave like .Net 2.0 but since most of the changes are bug fixes and improvements this should not be a bigger problem then the one we currently have. Thanks, Eyal. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Atsushi Eno Sent: 09 January 2008 13:50 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Tests failures when running on MS.NET Those values are different between .NET 2.0 and 1.x. In mono land they are embedded in our runtime, which does not differentiate 2.0 and 1.x. If we have both tables it increases the size of the runtime almost unnecessarily. You can't fix the tests. You don't pay any attention to the Mono test results, but if you fix them, they will fail on mono. Atsushi Eno Roei Erez wrote: Hi, I have noticed that the following CharCategory related tests fails when running on MS: CharCategoryTest.IsDigit CharCategoryTest.IsLower CharCategoryTest.IsNumber CharCategoryTest.IsPunctuation CharCategoryTest.IsSeperator CharCategoryTest.IsSymbol CharCategoryTest.IsUpper CharCategoryTest.IsWhiteSpace Is there a specific reason for this or can I fix the tests? Regards, Roei Erez ___ 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] Tests failures when running on MS.NET
Hi, Atsushi. So right now Mono 2.0 behaves like .Net 1.1. What about making Mono compatible with .Net 2.0? This will make Mono 1.1 behave like .Net 2.0 but since most of the changes are bug fixes and improvements this should not be a bigger problem then the one we currently have. Thanks, Eyal. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Atsushi Eno Sent: 09 January 2008 13:50 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Tests failures when running on MS.NET Those values are different between .NET 2.0 and 1.x. In mono land they are embedded in our runtime, which does not differentiate 2.0 and 1.x. If we have both tables it increases the size of the runtime almost unnecessarily. You can't fix the tests. You don't pay any attention to the Mono test results, but if you fix them, they will fail on mono. Atsushi Eno Roei Erez wrote: Hi, I have noticed that the following CharCategory related tests fails when running on MS: CharCategoryTest.IsDigit CharCategoryTest.IsLower CharCategoryTest.IsNumber CharCategoryTest.IsPunctuation CharCategoryTest.IsSeperator CharCategoryTest.IsSymbol CharCategoryTest.IsUpper CharCategoryTest.IsWhiteSpace Is there a specific reason for this or can I fix the tests? Regards, Roei Erez ___ 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] Wine Integration
Have you tried installing the Win32 build of Mono on WINE? then calling the program with mono program.exe? On Wed, 2008-01-09 at 12:14 -0200, rod marola wrote: I am in need to run a program on GNU/Linux that is a .NET application but make calls of Win32 native API. I would like to know if there is any work made towards integrating MONO with WINE, in order to make such calls possible. I am interested in developing such integration, as described in WINE's wiki ( http://wiki.winehq.org/Mono-Wine_bridge ), what advice can you give me? Thanks, -- Rodrigo Q Saramago ___ 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] Can we change the name of the MonoTests.System namespace?
On Wed, 2008-01-09 at 01:53 -0800, Dean Brettle wrote: This has happened several times now. I'm adding some code to a unit test class and want to use the fully qualified name (e.g. System.Web.UI.Adapters.PageAdapter) for some type, either because (a) I'm only using the type in a couple spots and I'd rather not pollute the namespace with a 'using' declaration, or (b) the unqualified name (e.g. PageAdapter) is already being used in the current namespace for something else. But when I try to use the fully qualified name I get a compile time error like this: error CS0234: The type or namespace name `PageAdapter' does not exist in the namespace `MonoTests.System.Web.UI.Adapters'. Are you missing an assembly reference? Use global::System.Web.UI.Adapters.PageAdapter. Your alternate solution of renaming MonoTests.System to MonoTests_System or some other variant would also work, but we have LOTS of unit tests already using MonoTests.System, and they won't all be changed at once. So we'd have a lengthy migration period, increasing confusion. So the simpler solutions are to: - Just pollute the global namespace with using declarations. (It's a unit test, why worry about namespace pollution?) - Use a using alias just for the conflicting types - Use global:: when the above two don't work. - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Wine Integration
rod marola wrote: I am in need to run a program on GNU/Linux that is a .NET application but make calls of Win32 native API. I would like to know if there is any work made towards integrating MONO with WINE, in order to make such calls possible. I am interested in developing such integration, as described in WINE's wiki ( http://wiki.winehq.org/Mono-Wine_bridge ), what advice can you give me? Replace the Win32 p/invoke calls with something portable. *SCNR* Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Tests failures when running on MS.NET
- Original Message - From: Atsushi Eno [EMAIL PROTECTED] To: Eyal Alaluf [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Sent: Wednesday, January 09, 2008 2:38 PM Subject: Re: [Mono-dev] Tests failures when running on MS.NET Hello, Agreed. If there's no objection I'd welcome such a change (or will do if no one does but not sure when). Having it in managed code (where it's easier to have different tables for each profile) is not an option I assume? Gert Hi, Atsushi. So right now Mono 2.0 behaves like .Net 1.1. What about making Mono compatible with .Net 2.0? This will make Mono 1.1 behave like .Net 2.0 but since most of the changes are bug fixes and improvements this should not be a bigger problem then the one we currently have. Thanks, Eyal. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Atsushi Eno Sent: 09 January 2008 13:50 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Tests failures when running on MS.NET Those values are different between .NET 2.0 and 1.x. In mono land they are embedded in our runtime, which does not differentiate 2.0 and 1.x. If we have both tables it increases the size of the runtime almost unnecessarily. You can't fix the tests. You don't pay any attention to the Mono test results, but if you fix them, they will fail on mono. Atsushi Eno Roei Erez wrote: Hi, I have noticed that the following CharCategory related tests fails when running on MS: CharCategoryTest.IsDigit CharCategoryTest.IsLower CharCategoryTest.IsNumber CharCategoryTest.IsPunctuation CharCategoryTest.IsSeperator CharCategoryTest.IsSymbol CharCategoryTest.IsUpper CharCategoryTest.IsWhiteSpace Is there a specific reason for this or can I fix the tests? Regards, Roei Erez ___ 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Control-C handler
On Tue, 2008-01-08 at 22:02 -0500, Jonathan Pryor wrote:
Thank you for the background on why signal handlers can't be made to
work with the current Stdlib.signal implementation.
However...
I don't see why we need a new API to support this. It seems that we
could retrofit the existing Stdlib.signal() API to use the
implementation you described, with one difference: a runtime internal
thread could be used to block on the internal pipe, and when the pipe is
readable it could dispatch the appropriate signal via delegate
registered with Stdlib.signal(). No polling, and no new public API
would be required.
The one thing I'm not sure about is which thread should wait on the
pipe. Would a dedicated Mono.Posix-internal thread be more appropriate,
or would one of the existing threads be beter (e.g. a ThreadPool thread,
or a Timer-related thread, or...).
Attached are patches to mcs/class/Mono.Posix/Mono.Unix.Native and
mono/support as an initial implementation of this idea. It currently
uses a dedicated Mono.Posix-internal thread to do managed signal
dispatching (as the ThreadPool is intended for short-lived tasks, and
I'm not familiar enough with the Timer-related infrastructure to see if
it would be a good fit).
Thoughts?
- Jon
Index: Stdlib.cs
===
--- Stdlib.cs (revision 92060)
+++ Stdlib.cs (working copy)
@@ -31,6 +31,9 @@
using System.IO;
using System.Runtime.InteropServices;
using System.Text;
+using System.Threading;
+
+using Mono.Unix;
using Mono.Unix.Native;
namespace Mono.Unix.Native {
@@ -359,7 +362,7 @@
//This is the case for using NativeConvert, which will throw an
//exception if an invalid/unsupported value is used.
//
- public class Stdlib
+ public unsafe class Stdlib
{
internal const string LIBC = msvcrt;
internal const string MPH = MonoPosixHelper;
@@ -445,24 +448,21 @@
registered_signals = new SignalHandler [(int) signals.GetValue (signals.Length-1)];
}
- [DllImport (LIBC, CallingConvention=CallingConvention.Cdecl,
-SetLastError=true, EntryPoint=signal)]
+ [DllImport (MPH, CallingConvention=CallingConvention.Cdecl,
+SetLastError=true, EntryPoint=Mono_Posix_Stdlib_signal)]
private static extern IntPtr sys_signal (int signum, SignalHandler handler);
- [DllImport (LIBC, CallingConvention=CallingConvention.Cdecl,
-SetLastError=true, EntryPoint=signal)]
+ [DllImport (MPH, CallingConvention=CallingConvention.Cdecl,
+SetLastError=true, EntryPoint=Mono_Posix_Stdlib_signal)]
private static extern IntPtr sys_signal (int signum, IntPtr handler);
[CLSCompliant (false)]
public static SignalHandler signal (Signum signum, SignalHandler handler)
{
+ InitSignalSupport ();
+
int _sig = NativeConvert.FromSignum (signum);
- Delegate[] handlers = handler.GetInvocationList ();
- for (int i = 0; i handlers.Length; ++i) {
-Marshal.Prelink (handlers [i].Method);
- }
-
lock (registered_signals) {
registered_signals [(int) signum] = handler;
}
@@ -494,6 +494,45 @@
#endif
}
+ [DllImport (MPH, CallingConvention=CallingConvention.Cdecl,
+SetLastError=true, EntryPoint=_mph_set_signal_write_fd)]
+ private static extern void set_signal_write_fd (int signum);
+
+ static object signal_dispatcher;
+ static intsignal_read_fd;
+
+ private static void InitSignalSupport ()
+ {
+ if (Path.DirectorySeparatorChar == '\\')
+return;
+
+ if (signal_dispatcher == null) {
+object c = new Thread (SignalDispatcher);
+Thread.MemoryBarrier ();
+while (Interlocked.CompareExchange (ref signal_dispatcher, c, null) == null) {
+ int writing;
+ if (Syscall.pipe (out signal_read_fd, out writing) 0)
+ throw UnixMarshal.CreateExceptionForLastError ();
+ set_signal_write_fd (writing);
+ Thread _c = (Thread) c;
+ _c.IsBackground = true;
+ _c.Name = Mono.Unix.Native Signal Dispatcher;
+ _c.Start ();
+}
+Thread.MemoryBarrier ();
+ }
+ }
+
+ private static unsafe void SignalDispatcher ()
+ {
+ byte c;
+ while (Syscall.read (signal_read_fd, c, 1) = 1) {
+SignalHandler h = registered_signals [c];
+if (h != null)
+ h (c);
+ }
+ }
+
[DllImport (LIBC, CallingConvention=CallingConvention.Cdecl, EntryPoint=raise)]
private static extern int sys_raise (int sig);
Index: ChangeLog
===
--- ChangeLog (revision 92274)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2008-01-09 Jonathan Pryor [EMAIL PROTECTED]
+
+ * Stdlib.cs: Update Stdlib.signal() so that it's safe; see also:
+ http://lists.ximian.com/pipermail/mono-devel-list/2008-January/026501.html
+ http://lists.ximian.com/pipermail/mono-devel-list/2008-January/026503.html
+
2008-01-05 Jonathan Pryor [EMAIL PROTECTED]
* Syscall.cs: Add ST_NOEXEC, ST_REMOUNT, ST_BIND to MountFlags. Patch from
Index: ChangeLog
Re: [Mono-dev] Control-C handler
On Wed, 2008-01-09 at 11:52 -0500, Avery Pennarun wrote:
On 08/01/2008, Jonathan Pryor [EMAIL PROTECTED] wrote:
I don't see why we need a new API to support this. It seems that we
could retrofit the existing Stdlib.signal() API to use the
implementation you described, with one difference: a runtime internal
thread could be used to block on the internal pipe, and when the pipe is
readable it could dispatch the appropriate signal via delegate
registered with Stdlib.signal(). No polling, and no new public API
would be required.
It seems to me that lupus's suggestion is more general than this. In
other words, you could implement your desired API above on top of his
without any extra overhead (ie. the overhead is inherent to the
interface), while you couldn't implement his on top of yours without
doing a lot of unnecessary work (ie. bouncing into a thread and then
back again).
Fair point.
Since mono's signal API is already (presumably) non-standard, it
should be harmless to correct it by introducing a new nonstandard one
that works properly.
Now what do you mean by non-standard, i.e. what's the standard
here? .NET? Windows has no signals, so .NET won't expose such a
concept.
On the other hand, the Mono.Unix.Native types have existed for quite
some time and intend to follow the Standard C and POSIX interfaces as
closely as possible. signal(2) is part of the C standard, and is thus
exposed via Stdlib.signal(). It's as standard as you're going to get.
Note that polling a variable is a fine way to handle signals in many C
programs. I often write mainloops of the form while (!want_to_die),
where want_to_die is set by my SIGTERM/SIGINT/etc handler. Involving
a thread for this purpose would be overkill. While this method does
count as polling, it is syscall-free polling and only happens at the
places where you would want to shut down cleanly anyway.
This reminds me, though: what happens to things like socket
read/write/connect system calls in mono when a signal comes in? In C,
they get interrupted and return EINTR/EAGAIN, which is why you pop
back to the mainloop and get a chance to poll your signal variable.
The same thing would happen if you use the low-level Syscall methods --
-1 would be returned and Stdlib.GetLastError() would return Errno.EINTR
or Errno.EAGAIN. The higher-level Mono.Unix types like UnixStream
ignore EINTR.
However, this does raise an interesting problem with a thread-based
approach: since signal dispatching would happen on another thread, there
is no guarantee (and no way to guarantee) that the signal will be
dispatched before the system call returns:
1. Thread 1: Syscall.write()
2. kernel dispatches signal to process
3. Thread 1: Syscall.write() returns -1/EINTR
# some future point in time...
4. Thread 2: Dispatches signal originally raised in (2).
Thread 1 can't safely check e.g. a variable after the EINTR return (in
the normal C fashion) because it might not have been set by the signal
handler yet. It would instead need to wait on a semaphore/condition
variable, which the signal handler could set, to ensure that the threads
are properly synchronized.
On the plus side, the signal handler thread can actually use
semaphores/etc. as it's not running within signal handler context.
So perhaps it would make more sense to expose lupus' approach and layer
Stdlib.signal() atop of it. Though to do that we'd need a better name:
there is already a Mono.Unix.Native.SignalHandler type, and trying to
describe the difference between SignalHandler and UnixSignalHandler is
something I don't look forward to. Perhaps instead:
public class Signal : System.Threading.WaitHandle {
public Signal (Signum signal);
~Signal ();
public Signum Signum { get; }
public bool IsSignaled { get; set; }
}
though the WaitHandle base type might be pure crack (not sure);
regardless, IDisposable should certainly be implemented.
- Jon
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [SPAM] Re: [PATCH] ToString() performace in Mono revisited
I like the patch a lot and am looking forward to see some final speed results. On the other hand when taking into account the importance and size of the patch several people should look over it ;) Greetings Andreas -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Eyal Alaluf Gesendet: Mittwoch, 9. Januar 2008 10:03 An: Miguel de Icaza Cc: mono-devel-list@lists.ximian.com Betreff: [SPAM] Re: [Mono-dev] [PATCH] ToString() performace in Mono revisited Hi, Miguel. Can I go ahead and commit this important patch? Thanks, Eyal. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eyal Alaluf Sent: 06 January 2008 16:34 To: Andreas Nahr; Prakash Punnoor; mono-devel-list@lists.ximian.com Cc: Atsushi Eno; Miguel de Icaza; Juraj Skripsky Subject: Re: [Mono-dev] [SPAM] Re: [SPAM] Re: ToString() performace inMono revisited Hi, all. I have attached a patch following Andreas suggestions below. Please review, especially the metadata part. I saw once that Mono checks compatibility of Mscorlib with the runtime, is this happenening automatically whenever an internal call is added? BTW, since now the numberFormatter tables become arrays of magic numbers in mono/metadata, is there a place where I should put the program that generates these numbers? Thanks, Eyal. -Original Message- From: Andreas Nahr [mailto:[EMAIL PROTECTED] Sent: 04 January 2008 00:26 To: Eyal Alaluf; 'Andreas Nahr'; 'Prakash Punnoor'; mono-devel-list@lists.ximian.com Cc: 'Atsushi Eno'; 'Miguel de Icaza'; 'Juraj Skripsky' Subject: AW: [SPAM] Re: [Mono-dev] [SPAM] Re: ToString() performace in Mono revisited It does make sense to make the 'DblExpTab' common to all appdomains. How do you implement such a scheme in Mono? Is it possible to achieve this without going out to unsafe code and internal methods? Afaik to gain all the advantages you need one internal method to return the pointers and unsafe code for accepting the pointer. The scheme is pretty straightforward (compare Char or CultureInfo): Runtime: * Pregenerate the table data * convert to a C constant array * embed that into the runtime (e.g. http://anonsvn.mono-project.com/viewcvs/trunk/mono/mono/metada ta/culture -inf o-tables.h?rev=88796view=auto) * Create one runtime method to return a pointer to the array Classlib: * Define internalcall to the runtime method * Store the retrieved pointer in a static variable * Use the pointer as you would use the array (syntax is compatible, so no need to change the code) * Get Array-Bounds-Check-Removal for free :) If the above is complicated, do you think that it makes sense to consider the above as a separate task since the array size is now 24K and a scenario with 1000 domains is a rare scenario? Well I personally am much more concerned about the additional startup cost of the current suggestion (Managed already has a high startup cost and this is measurably increasing it) than the additional memory cost. But not everybody will think that way... So imho it would be worth implementing in the runtime. Greetings Andreas P.S. WAY back then I tried to do the same without runtime support by acquiring a pointer to an embedded resource file. I don't know if this works now, but back then it didn't (as far as I can remember). A starting point MIGHT be Assembly.GetManifestResourceInternal ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Program Option Parsing Library
I've been doing a lot of work on monodocer, and (for some unknown
reason) decided that the warning about the deprecation of
Mono.GetOptions was annoying so I thought I'd come up with a
replacement.
This replacement is NOT currently intended to be stable, nor to be
bundled with Mono itself for public use.
It is also extremely crack-addled, which is why I'm liking it so much,
and why I thought I'd share it with you.
Crack-addled? How else would you describe this cunning combination of
collection initializers and lambda delegates?
bool help = false;
int verbose = 0;
string source = null;
var p = new Options () {
{ h|?|help, v = help = v != null },
{ v|verbose, v = { ++verbose; } },
{ source=, v = source = v },
};
p.Parse (new string[]{--help, -v, -v, -source=foo})
.ToArray ();
After p.Parse().ToArray(), help=true, verbose=2, and source=foo.
It is inspired by Perl's Getopt::Long library, except that all option
processing is done via delegates (i.e. Perl `sub's) and not via by-ref
variables (as Perl also supports).
No reflection is used unless you use TypeConverter to implicitly convert
strings to random managed types:
int n = 0;
var p = new Options () {
{ n=, (int v) = n = v }
};
Options currently supports:
* Parameters of the form: -flag, --flag, /flag, -flag=value,
--flag=value, /flag=value, -flag:value,
--flag:value, /flag:value, -flag value, --flag value, /flag
value.
* boolean parameters of the form: -flag, --flag, and /flag.
Boolean parameters can have a `+' or `-' appended to explicitly
enable or disable the flag (in the same fashion as mcs -debug+).
For boolean callbacks, the provided value is non-null for
enabled, and null for disabled.
* value parameters with a required value (append `=' to the
option name) or an optional value (append `:' to the option
name). The option value can either be in the current option
(--opt=value) or in the following parameter (--opt value). The
actual value is provided as the parameter to the callback
delegate, unless it's (1) optional and (2) missing, in which
case null is passed.
* bundled parameters which must start with a single `-' and
consists of only single characters. In this manner, -abc would
be a shorthand for -a -b -c.
* Option processing is disabled when -- is encountered.
Furthermore, it does not treat '-' options differently from '--' or '/'
options, aside from the aforementioned bundling support.
Regardless, at ~270 LOC for the associated classes (not including
comments or tests), I think it's a reasonably concise and useful library
for command-line option processing.
See also:
http://www.jprl.com/Blog/archive/development/mono/2008/Jan-07.html
Thoughts?
- Jon
//
// Options.cs
//
// Authors:
// Jonathan Pryor [EMAIL PROTECTED]
//
// Copyright (C) 2008 Novell (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.
//
// Compile With:
// gmcs -debug+ -d:TEST -langversion:linq -r:System.Core Options.cs
//
// A Getopt::Long-inspired option parsing library for C#.
//
// Mono.Documentation.Options is built upon a key/value table, where the
// key is a option format string and the value is an Actionstring
// delegate that is invoked when the format string is matched.
//
// Option format strings:
// BNF Grammar: ( name [=:]? ) ( '|' name [=:]? )+
//
// Each '|'-delimited name is an alias for the associated action. If the
// format string ends in a '=', it has a required value. If the format
// string ends in a ':', it has an optional value. If neither '=' or ':'
// is present, no value is supported.
//
// Options are extracted either from the current option by looking for
// the option name
Re: [Mono-dev] [SPAM] Re: Tests failures when running on MS.NET
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Gert Driesen Gesendet: Mittwoch, 9. Januar 2008 18:06 An: Atsushi Eno; Eyal Alaluf Cc: mono-devel-list@lists.ximian.com Betreff: [SPAM] Re: [Mono-dev] Tests failures when running on MS.NET - Original Message - From: Atsushi Eno [EMAIL PROTECTED] To: Eyal Alaluf [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Sent: Wednesday, January 09, 2008 2:38 PM Subject: Re: [Mono-dev] Tests failures when running on MS.NET Hello, Agreed. If there's no objection I'd welcome such a change (or will do if no one does but not sure when). Having it in managed code (where it's easier to have different tables for each profile) is not an option I assume? Imho the problem is that this option would need a lot of research from somebody very familiar with the core OS level. We had that discussion quite a few year back and this were some results (as far as I can remember): Embedding will give you: * Automatic memmapping through the OS without any additional work to do (So we don't (have to) care about which part of tables to load into memory and which not) OSs are usually good at doing that. * No hassle with endianess. The Runtime is Arch dependent anyways, so you get the correct endianess with embedded tables. * Source code visibility. You can change/inspect (by hand) individual values. * Does not add any additional complexity to the build process. * Already existing and implemented Disadvantages are potentially: * No easy way for different versions. * You may include things in the runtime which are not needed for a specific application that would better be included in a specific assembly. * Bloats the runtime size. * To add a new/change a table you always have to touch both runtime and classlibrary. One of the solutions I found back then that MAY be possible (did not have the time to completely research it): Embed the data tables into the specific assembly (Into the manifest) as a binary data blob. This removes the disadvantages above however will come with a host of new problems: * The data would have to be binary. Which means you need toolapps to create it (this is already true for some/most of the tables anyways) * You would need a way to get a pointer to the data fast without a lot of overhead (Current overhead is just one internalcall and a single line of C code) * Unclear if you still get free memmapping (showstopper if you need to preload all table data manually) * The class library (potentially) becomes arch-dependent because the embedded binary data is arch-dependent (No good way to solve: Either include both doubling size or live with the fact and ship arch-dependent libraries) * More complicated build process that needs additional steps to create/embed the binary data. * Somebody has to do it Greetings Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Hello - monodevelopers -- goodbye problems!
Whats up guys, Ok so I needed to use a hyperlink in a gridview and so I decided that I needed to compile form src, have had a problem getting mod mono working from src for about a week now. No one responds to my forum messages so I'm giving this a try. So after reading and reading and reading and reading let me get this straight: 1. compile install gdiplus 2. compile install mono in that order? Im on ubuntu 7.10 so I am getting from svn the problem I have is that: 1. I can't compile gdiplus: configure: error: Cairo requires at least one font backend. Please install freetype and fontconfig, then try again: http://freetype.org/ http://fontconfig.org/ even though I have cairo2-dev installed, i have installed both of those packages as well with no luck, I was reading a tutorial on how to compile from src that said i needed cairo1-dev but I can't install it because apparently a lot of the programs on ubuntu depend on cairo2 for some reason or another and it is listed that cairo is conflicting with cairo2-dev and some other things 2. I get an error from mod mono, saying that my corlib.dll is version 65 when it wanted 64, note that I am installing everything from src, mono, xsp, mod mono all versions 1.2.6. Thanks I hope you guys can help me out Btw this has been my only real problem with mono so far, everything else has been able to convert my entire web application over to mono with minimal troubles so I am eager to get this working. Also I am going to try to use this for production use so maybe there would be a way that I could get the newer libraries and use the stable build since all I really need is for the hyperlink in a gridview to work, any comments would be appreciated as well. -Nate ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Hello - monodevelopers -- goodbye problems!
Hi, About the corlib.dll version problem: version 64 means you are using mono SVN, not 1.2.6. The probable fix is to recompile and reinstall mono. You probably has incompatible monoversions lying around on your system. Zoltan On Jan 9, 2008 9:21 PM, Nate Barger [EMAIL PROTECTED] wrote: Whats up guys, Ok so I needed to use a hyperlink in a gridview and so I decided that I needed to compile form src, have had a problem getting mod mono working from src for about a week now. No one responds to my forum messages so I'm giving this a try. So after reading and reading and reading and reading let me get this straight: 1. compile install gdiplus 2. compile install mono in that order? Im on ubuntu 7.10 so I am getting from svn the problem I have is that: 1. I can't compile gdiplus: configure: error: Cairo requires at least one font backend. Please install freetype and fontconfig, then try again: http://freetype.org/ http://fontconfig.org/ even though I have cairo2-dev installed, i have installed both of those packages as well with no luck, I was reading a tutorial on how to compile from src that said i needed cairo1-dev but I can't install it because apparently a lot of the programs on ubuntu depend on cairo2 for some reason or another and it is listed that cairo is conflicting with cairo2-dev and some other things 2. I get an error from mod mono, saying that my corlib.dll is version 65 when it wanted 64, note that I am installing everything from src, mono, xsp, mod mono all versions 1.2.6. Thanks I hope you guys can help me out Btw this has been my only real problem with mono so far, everything else has been able to convert my entire web application over to mono with minimal troubles so I am eager to get this working. Also I am going to try to use this for production use so maybe there would be a way that I could get the newer libraries and use the stable build since all I really need is for the hyperlink in a gridview to work, any comments would be appreciated as well. -Nate ___ 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] [PATCH] CodeGenerator/CodeDom classes
Hello,
Attached you'll find patches for CodeGenerator.cs and quite a few
System.CodeDom classes. Also included is a new file ICodeDomVisitor.cs
which belongs into System/System.CodeDom. ChangeLog entries are
included.
These patches replace those (ugly ones) I posted on Jan 6th. They
implement the Visitor pattern for the CodeGenerator (traverser) and the
classes in System.CodeDom (nodes to be visited)*. The result is much
nicer and faster code.
*) Thanks again Robert Jordan, for sketching out how to apply the
Visitor pattern to the CodeGenerator/CodeDom classes!
All unit tests pass.
Please review.
- Juraj
Index: System.dll.sources
===
--- System.dll.sources (revision 92488)
+++ System.dll.sources (working copy)
@@ -112,6 +112,7 @@
System.CodeDom/CodeTypeReferenceOptions.cs
System.CodeDom/CodeVariableDeclarationStatement.cs
System.CodeDom/CodeVariableReferenceExpression.cs
+System.CodeDom/ICodeDomVisitor.cs
System.CodeDom.Compiler/CodeCompiler.cs
System.CodeDom.Compiler/CodeDomConfigurationHandler.cs
System.CodeDom.Compiler/CodeDomProvider.cs
Index: ChangeLog
===
--- ChangeLog (revision 92488)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2008-01-09 Juraj Skripsky [EMAIL PROTECTED]
+
+ * System.dll.sources: Added ICodeDomVisitor.cs.
+
2007-12-24 Gert Driesen [EMAIL PROTECTED]
* System_test.dll.sources: Added CheckoutExceptionTest.cs.
Index: System.CodeDom/CodeEventReferenceExpression.cs
===
--- System.CodeDom/CodeEventReferenceExpression.cs (revision 92488)
+++ System.CodeDom/CodeEventReferenceExpression.cs (working copy)
@@ -76,5 +76,13 @@
targetObject = value;
}
}
+
+ //
+ // ICodeDomVisitor method
+ //
+ internal override void Accept (ICodeDomVisitor visitor)
+ {
+ visitor.Visit (this);
+ }
}
}
Index: System.CodeDom/CodeArgumentReferenceExpression.cs
===
--- System.CodeDom/CodeArgumentReferenceExpression.cs (revision 92488)
+++ System.CodeDom/CodeArgumentReferenceExpression.cs (working copy)
@@ -65,5 +65,13 @@
parameterName = value;
}
}
+
+ //
+ // ICodeDomVisitor method
+ //
+ internal override void Accept (ICodeDomVisitor visitor)
+ {
+ visitor.Visit (this);
+ }
}
}
Index: System.CodeDom/CodeAttachEventStatement.cs
===
--- System.CodeDom/CodeAttachEventStatement.cs (revision 92488)
+++ System.CodeDom/CodeAttachEventStatement.cs (working copy)
@@ -87,5 +87,13 @@
listener = value;
}
}
+
+ //
+ // ICodeDomVisitor method
+ //
+ internal override void Accept (ICodeDomVisitor visitor)
+ {
+ visitor.Visit (this);
+ }
}
}
Index: System.CodeDom/CodePropertySetValueReferenceExpression.cs
===
--- System.CodeDom/CodePropertySetValueReferenceExpression.cs (revision 92488)
+++ System.CodeDom/CodePropertySetValueReferenceExpression.cs (working copy)
@@ -38,5 +38,12 @@
public class CodePropertySetValueReferenceExpression
: CodeExpression
{
+ //
+ // ICodeDomVisitor method
+ //
+ internal override void Accept (ICodeDomVisitor visitor)
+ {
+ visitor.Visit (this);
+ }
}
}
Index: System.CodeDom/CodeDirectionExpression.cs
===
--- System.CodeDom/CodeDirectionExpression.cs (revision 92488)
+++ System.CodeDom/CodeDirectionExpression.cs (working copy)
@@ -76,5 +76,13 @@
expression = value;
}
}
+
+ //
+ // ICodeDomVisitor method
+ //
+ internal override void Accept (ICodeDomVisitor visitor)
+ {
+ visitor.Visit (this);
+ }
}
}
Index: System.CodeDom/CodeThisReferenceExpression.cs
===
--- System.CodeDom/CodeThisReferenceExpression.cs (revision 92488)
+++ System.CodeDom/CodeThisReferenceExpression.cs (working copy)
@@ -45,5 +45,13 @@
public CodeThisReferenceExpression()
{
}
+
+ //
+ // ICodeDomVisitor method
+ //
+ internal override void Accept (ICodeDomVisitor visitor)
+ {
+ visitor.Visit (this);
+ }
}
}
Index: System.CodeDom/CodeMemberMethod.cs
===
--- System.CodeDom/CodeMemberMethod.cs (revision 92488)
+++ System.CodeDom/CodeMemberMethod.cs (working copy)
@@ -140,5 +140,13 @@
public event EventHandler PopulateParameters;
public event EventHandler PopulateStatements;
+
+ //
+ // ICodeDomVisitor method
+ //
+ internal override void Accept (ICodeDomVisitor visitor)
+ {
+ visitor.Visit (this);
+ }
}
}
Index: System.CodeDom/CodeMemberProperty.cs
===
--- System.CodeDom/CodeMemberProperty.cs (revision 92488)
+++
Re: [Mono-dev] [SPAM] Re: [PATCH] ToString() performace in Mono revisited
Hi, I like the original version which contained managed arrays better. The new version might use less memory, but it contains lots of unsafe code using pointers, and this will become a problem when we want to do a security audit for moonlight. Zoltan On Jan 9, 2008 7:45 PM, Andreas Nahr [EMAIL PROTECTED] wrote: I like the patch a lot and am looking forward to see some final speed results. On the other hand when taking into account the importance and size of the patch several people should look over it ;) Greetings Andreas -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Eyal Alaluf Gesendet: Mittwoch, 9. Januar 2008 10:03 An: Miguel de Icaza Cc: mono-devel-list@lists.ximian.com Betreff: [SPAM] Re: [Mono-dev] [PATCH] ToString() performace in Mono revisited Hi, Miguel. Can I go ahead and commit this important patch? Thanks, Eyal. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eyal Alaluf Sent: 06 January 2008 16:34 To: Andreas Nahr; Prakash Punnoor; mono-devel-list@lists.ximian.com Cc: Atsushi Eno; Miguel de Icaza; Juraj Skripsky Subject: Re: [Mono-dev] [SPAM] Re: [SPAM] Re: ToString() performace inMono revisited Hi, all. I have attached a patch following Andreas suggestions below. Please review, especially the metadata part. I saw once that Mono checks compatibility of Mscorlib with the runtime, is this happenening automatically whenever an internal call is added? BTW, since now the numberFormatter tables become arrays of magic numbers in mono/metadata, is there a place where I should put the program that generates these numbers? Thanks, Eyal. -Original Message- From: Andreas Nahr [mailto:[EMAIL PROTECTED] Sent: 04 January 2008 00:26 To: Eyal Alaluf; 'Andreas Nahr'; 'Prakash Punnoor'; mono-devel-list@lists.ximian.com Cc: 'Atsushi Eno'; 'Miguel de Icaza'; 'Juraj Skripsky' Subject: AW: [SPAM] Re: [Mono-dev] [SPAM] Re: ToString() performace in Mono revisited It does make sense to make the 'DblExpTab' common to all appdomains. How do you implement such a scheme in Mono? Is it possible to achieve this without going out to unsafe code and internal methods? Afaik to gain all the advantages you need one internal method to return the pointers and unsafe code for accepting the pointer. The scheme is pretty straightforward (compare Char or CultureInfo): Runtime: * Pregenerate the table data * convert to a C constant array * embed that into the runtime (e.g. http://anonsvn.mono-project.com/viewcvs/trunk/mono/mono/metada ta/culture -inf o-tables.h?rev=88796view=auto) * Create one runtime method to return a pointer to the array Classlib: * Define internalcall to the runtime method * Store the retrieved pointer in a static variable * Use the pointer as you would use the array (syntax is compatible, so no need to change the code) * Get Array-Bounds-Check-Removal for free :) If the above is complicated, do you think that it makes sense to consider the above as a separate task since the array size is now 24K and a scenario with 1000 domains is a rare scenario? Well I personally am much more concerned about the additional startup cost of the current suggestion (Managed already has a high startup cost and this is measurably increasing it) than the additional memory cost. But not everybody will think that way... So imho it would be worth implementing in the runtime. Greetings Andreas P.S. WAY back then I tried to do the same without runtime support by acquiring a pointer to an embedded resource file. I don't know if this works now, but back then it didn't (as far as I can remember). A starting point MIGHT be Assembly.GetManifestResourceInternal ___ 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] [SPAM] Re: [PATCH] ToString() performace in Mono revisited
Are you sure? Besides the potential KB/MBs of memory wasted for that we pay a startup performance penalty so that it is probably at least 500% slower than now (Yes that is 5 Mio). Imho for ANYTHING but running on the server this would be completely useless. In that situation I'd actually prefer the original code any time. Greetings Andreas -Ursprüngliche Nachricht- Von: Zoltan Varga [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 9. Januar 2008 23:09 An: Andreas Nahr Cc: Eyal Alaluf; Miguel de Icaza; mono-devel-list@lists.ximian.com Betreff: Re: [Mono-dev] [SPAM] Re: [PATCH] ToString() performace in Mono revisited Hi, I like the original version which contained managed arrays better. The new version might use less memory, but it contains lots of unsafe code using pointers, and this will become a problem when we want to do a security audit for moonlight. Zoltan On Jan 9, 2008 7:45 PM, Andreas Nahr [EMAIL PROTECTED] wrote: I like the patch a lot and am looking forward to see some final speed results. On the other hand when taking into account the importance and size of the patch several people should look over it ;) Greetings Andreas -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Eyal Alaluf Gesendet: Mittwoch, 9. Januar 2008 10:03 An: Miguel de Icaza Cc: mono-devel-list@lists.ximian.com Betreff: [SPAM] Re: [Mono-dev] [PATCH] ToString() performace in Mono revisited Hi, Miguel. Can I go ahead and commit this important patch? Thanks, Eyal. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eyal Alaluf Sent: 06 January 2008 16:34 To: Andreas Nahr; Prakash Punnoor; mono-devel-list@lists.ximian.com Cc: Atsushi Eno; Miguel de Icaza; Juraj Skripsky Subject: Re: [Mono-dev] [SPAM] Re: [SPAM] Re: ToString() performace inMono revisited Hi, all. I have attached a patch following Andreas suggestions below. Please review, especially the metadata part. I saw once that Mono checks compatibility of Mscorlib with the runtime, is this happenening automatically whenever an internal call is added? BTW, since now the numberFormatter tables become arrays of magic numbers in mono/metadata, is there a place where I should put the program that generates these numbers? Thanks, Eyal. -Original Message- From: Andreas Nahr [mailto:[EMAIL PROTECTED] Sent: 04 January 2008 00:26 To: Eyal Alaluf; 'Andreas Nahr'; 'Prakash Punnoor'; mono-devel-list@lists.ximian.com Cc: 'Atsushi Eno'; 'Miguel de Icaza'; 'Juraj Skripsky' Subject: AW: [SPAM] Re: [Mono-dev] [SPAM] Re: ToString() performace in Mono revisited It does make sense to make the 'DblExpTab' common to all appdomains. How do you implement such a scheme in Mono? Is it possible to achieve this without going out to unsafe code and internal methods? Afaik to gain all the advantages you need one internal method to return the pointers and unsafe code for accepting the pointer. The scheme is pretty straightforward (compare Char or CultureInfo): Runtime: * Pregenerate the table data * convert to a C constant array * embed that into the runtime (e.g. http://anonsvn.mono-project.com/viewcvs/trunk/mono/mono/metada ta/culture -inf o-tables.h?rev=88796view=auto) * Create one runtime method to return a pointer to the array Classlib: * Define internalcall to the runtime method * Store the retrieved pointer in a static variable * Use the pointer as you would use the array (syntax is compatible, so no need to change the code) * Get Array-Bounds-Check-Removal for free :) If the above is complicated, do you think that it makes sense to consider the above as a separate task since the array size is now 24K and a scenario with 1000 domains is a rare scenario? Well I personally am much more concerned about the additional startup cost of the current suggestion (Managed already has a high startup cost and this is measurably increasing it) than the additional memory cost. But not everybody will think that way... So imho it would be worth implementing in the runtime. Greetings Andreas P.S. WAY back then I tried to do the same without runtime support by acquiring a pointer to an embedded resource file. I don't know if this works now, but back then it didn't (as far as I can remember). A starting point MIGHT be Assembly.GetManifestResourceInternal ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___
