[Mono-dev] [PATCH] Small Winx64 change.
Hello All, The attached patch fixes the vararg.exe runtime test on Winx64. The MonoTypedRef is not always passed on the stack on Windows. Calling add_valuetype will select the correct operation. -bill MONO_TYPE_TYPEDBYREF.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] [Ximian-mono-list] Generics Sharing in the Debugger: Request for breaking the code freeze
Is attaching to a non --debug Mono process a widely used feature? I do not think this is a good question to ask, because in general debugging of a Mono program is not even a widely used feature. A better question to ask is whether developers routinely attach to running processes to debug with other debuggers, and I think the answer to that is yes, and we should expect that in the long term this should be a supported configuration. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Windows build
A sidenote (and an argument for msys): folks behind Windows git port are currently finishing their migration from cygwin to msys because of performance reasons. 2008/7/17 Jonathan Chambers [EMAIL PROTECTED]: I started looking at using msys to build mono a few months ago. I got distracted by some other things (mainly the beginning of the Win64 port), but I would be willing to pick it up again if there is interest. It would probably be a good thing, IMO. Thanks, Jonathan On Thu, Jul 17, 2008 at 3:08 AM, Kornél Pál [EMAIL PROTECTED] wrote: Hi, msys could be a better choice because cygwin uses it's own runtime that has to be avoided by using -mno-cygwin and I believe that msys is easier to install but I'm not sure that it's currently properly supported by Mono. In the previous version of the buildbot page there was a button to force a build immediately. In the current version I didn't find a similar functionality. Is it possible to make a build when I want to? Kornél Andrew Jorgensen wrote: On Wed, 2008-07-16 at 08:47 -0400, Jonathan Chambers wrote: I reverted your changes related to __ImageBase yesterday in hopes of getting something working. The build machine has historically had a (very) old version of cygwin, as upgrading cygwin in the past has cause problems. However, it would be nice to upgrade the cygwin on the build machine at some point; I am not sure who is responsible for that in Novell. I'm the responsible person there but as you say we've been bit in the past. I am willing to upgrade cygwin but I think it would be best to wait until after the 2.0 release. Also there was some discussion about using msys instead? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- MS-DOS user since 5.0 Windows user since 3.11 Linux user since kernel 2.4 Novell Netware user since 2.2 WARCRAFT user since 1.0 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Windows build
Is there a compelling reason (other than the fact that the managed code does not yet build off the msvc build system) to support msys or cygwin at all? Mike On Jul 18, 2008, at 11:34 AM, Leszek Ciesielski wrote: A sidenote (and an argument for msys): folks behind Windows git port are currently finishing their migration from cygwin to msys because of performance reasons. 2008/7/17 Jonathan Chambers [EMAIL PROTECTED]: I started looking at using msys to build mono a few months ago. I got distracted by some other things (mainly the beginning of the Win64 port), but I would be willing to pick it up again if there is interest. It would probably be a good thing, IMO. Thanks, Jonathan On Thu, Jul 17, 2008 at 3:08 AM, Kornél Pál [EMAIL PROTECTED] wrote: Hi, msys could be a better choice because cygwin uses it's own runtime that has to be avoided by using -mno-cygwin and I believe that msys is easier to install but I'm not sure that it's currently properly supported by Mono. In the previous version of the buildbot page there was a button to force a build immediately. In the current version I didn't find a similar functionality. Is it possible to make a build when I want to? Kornél Andrew Jorgensen wrote: On Wed, 2008-07-16 at 08:47 -0400, Jonathan Chambers wrote: I reverted your changes related to __ImageBase yesterday in hopes of getting something working. The build machine has historically had a (very) old version of cygwin, as upgrading cygwin in the past has cause problems. However, it would be nice to upgrade the cygwin on the build machine at some point; I am not sure who is responsible for that in Novell. I'm the responsible person there but as you say we've been bit in the past. I am willing to upgrade cygwin but I think it would be best to wait until after the 2.0 release. Also there was some discussion about using msys instead? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- MS-DOS user since 5.0 Windows user since 3.11 Linux user since kernel 2.4 Novell Netware user since 2.2 WARCRAFT user since 1.0 ___ 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] Windows build
Hi, Michael Jerris wrote: Is there a compelling reason (other than the fact that the managed code does not yet build off the msvc build system) to support msys or cygwin at all? Both of them are using the same open source compilers and tools (cygwin is a kind of Linux API implementation while msys is Windows API based) that is currently supported and these tools are used on non-Windows operating systems as well. So I think it's good to support them. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Ximian-mono-list] Generics Sharing in the Debugger: Request for breaking the code freeze
On Fri, Jul 18, 2008 at 5:27 PM, Miguel de Icaza [EMAIL PROTECTED] wrote: Is attaching to a non --debug Mono process a widely used feature? A better question to ask is whether developers routinely attach to running processes to debug with other debuggers, and I think the answer to that is yes, and we should expect that in the long term this should be a supported configuration. The question here is not about long term but only about 2.0. We want to support full generic sharing debugging with 2.1, but for 2.0 this is not an option anymore. So, to recap, from my point of view we have two sane options for 2.0: 1. Leave generic sharing turned on by default, but turn it off if running with --debug. Debugging will work, but attaching to a process that runs without --debug will fail and the debugger should tell the user that the process should be run with --debug. 2. Turn off generic sharing by default. The debugger should still be able to tell if a process runs with generic sharing enabled, though, and report that. I'd prefer 1. Mark ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Patch for mwf-designer
Hello,
Please find attached a suggested patch for mwf-designer, which corrects
improper exception handling when empty fields are provided in the
NewFileDialog dialog box (upon pressing Done).
Guillaume Simard
Index: src/UI/NewFileDialog.cs
===
--- src/UI/NewFileDialog.cs (revision 108217)
+++ src/UI/NewFileDialog.cs (working copy)
@@ -92,7 +92,8 @@
_namespace = namespaceTextbox.Text;
_class = classTextbox.Text;
_fileName = filenameTextbox.Text;
- if (_templateName == null || _namespace == null || _class == null || _fileName == null) {
+ if (isNotValidEntry (_templateName) || isNotValidEntry (_namespace) ||
+ isNotValidEntry (_class) || isNotValidEntry (_fileName)) {
MessageBox.Show (Please select a template from the list, specify the class and namespace names and +
then choose file name and location.);
} else {
@@ -100,5 +101,12 @@
this.Close();
}
}
+
+ private bool isNotValidEntry(string s)
+ {
+ if (s == null || s == string.Empty)
+return true;
+ return false;
+ }
}
}
\ No newline at end of file
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Assenza
Saro' assente fino alla prima settimana d'Agosto. Umberto ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Fast Virtual Generic Method Calls
Hi everybody,
I've improved the implementation of virtual generic method calls, at
least in terms of speed. Now I'd like to ask if anybody knows of
reasonably easy to install applications which use virtual generic
methods extensively, so that I can test and improve the code with
real-world examples.
Previously doing a virtual generic call involved calling an unmanaged
function which did the look-up, so it was rather slow. My
implementation uses the runtime generic context infrastructure I
developed for generic code sharing. Note that it does not require
generic code sharing to be turned on to work (actually it's faster
without it). Note also that the optimization doesn't apply to
interface calls. Unfortunately, the memory usage of my implementation
is (still) unreasonably high (see below). I'm working on that.
Still, I've included the patch and a simple benchmark program.
What the benchmark does is run three different but very similar loops
100 million times each. The loops differ in that one does no calls,
one does a non-generic virtual call each iteration and one does a
generic virtual call each iteration. It prints out the time in
nanoseconds for one iteration for each loop and then the difference of
the last two loops to the first, i.e. the costs of the method calls.
Here's what I get on my machine (x86) before my patch:
no calls: 32.34614
non-generic calls: 36.13996
generic calls: 691.26125
non-generic call cost: 3.79382
generic call cost: 658.91511
This is what I get with my patch and generic sharing turned on for all classes:
no calls: 32.59865
non-generic calls: 36.07583
generic calls: 42.34147
non-generic call cost: 3.47718
generic call cost: 9.74282
This is what I get on the same machine with Microsoft's CLR:
no calls: 18.90625
non-generic calls: 31.40625
generic calls: 52.96875
non-generic call cost: 12.5
generic call cost: 34.0625
The huge difference in the relations is probably a sign of the
crudeness of the benchmark, but I think we're competitive now, to say
the least.
The speed gained comes at the cost of memory used by the (M)RGCTXes.
I have two applications which make use of virtual generic methods,
namely IronPython2 and F#2. Here's what's going on there, with full
generic code sharing enabled:
IronPython2 (running pystone):
generic virtual calls w/o patch: 138
slow generic virtual calls with patch: 47
(M)RGCTX memory usage w/o patch: 43.5k
(M)RGCTX memory usage with patch: 45.5k
F#2 (compiling a simple program):
generic virtual calls w/o patch: 2421
slow generic virtual calls with patch: 0
(M)RGCTX memory usage w/o patch: 242k
(M)RGCTX memory usage with patch: 288k
If I run the F# benchmark without generic sharing the memory used by
(M)RGCTXes is about 17k, all of which is completely due to the virtual
generic method call optimization. It seems that there are 64
different instantiations of virtual generic methods called in that
benchmark.
Mark
Index: metadata/class.c
===
--- metadata/class.c (revision 108246)
+++ metadata/class.c (working copy)
@@ -7440,42 +7440,8 @@
gboolean
mono_class_generic_sharing_enabled (MonoClass *class)
{
-#if defined(__i386__) || defined(__x86_64__)
- static gboolean supported = TRUE;
-#else
- /* Not supported by the JIT backends */
- static gboolean supported = FALSE;
-#endif
- static int generic_sharing = MONO_GENERIC_SHARING_NONE;
- static gboolean inited = FALSE;
+ int generic_sharing = mono_generic_sharing_get_mode ();
- if (!inited) {
- const char *option;
-
- if (supported)
- generic_sharing = MONO_GENERIC_SHARING_COLLECTIONS;
- else
- generic_sharing = MONO_GENERIC_SHARING_NONE;
-
- if ((option = g_getenv (MONO_GENERIC_SHARING))) {
- if (strcmp (option, corlib) == 0)
-generic_sharing = MONO_GENERIC_SHARING_CORLIB;
- else if (strcmp (option, collections) == 0)
-generic_sharing = MONO_GENERIC_SHARING_COLLECTIONS;
- else if (strcmp (option, all) == 0)
-generic_sharing = MONO_GENERIC_SHARING_ALL;
- else if (strcmp (option, none) == 0)
-generic_sharing = MONO_GENERIC_SHARING_NONE;
- else
-g_warning (Unknown generic sharing option `%s'., option);
- }
-
- if (!supported)
- generic_sharing = MONO_GENERIC_SHARING_NONE;
-
- inited = TRUE;
- }
-
switch (generic_sharing) {
case MONO_GENERIC_SHARING_NONE:
return FALSE;
Index: metadata/generic-sharing.c
===
--- metadata/generic-sharing.c (revision 108246)
+++ metadata/generic-sharing.c (working copy)
@@ -21,7 +21,10 @@
#include class-internals.h
#include marshal.h
#include debug-helpers.h
+#include tabledefs.h
+static MonoCreateRGCTXFetchTrampoline create_rgctx_fetch_trampoline;
+
static int
type_check_context_used (MonoType *type, gboolean recursive)
{
@@ -515,7 +518,7 @@
}
static gpointer
-inflate_other_data (gpointer data, int info_type, MonoGenericContext *context)
[Mono-dev] Feedback wanted: Mono 1.9 to Mono 2.0 changes.
Hello folks, As usual, I am looking for feedback on all the new features that were implemented since Mono 1.9 was branched in January for the Mono 2.0 release notes. A draft of the Mono release notes can be found here: http://www.go-mono.com/archive/2.0 Thanks in advance! Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] string hash code collisions
Dear Mono Devs,
I tested string hash code collisions in mono and .NET and saw that mono's
hash code algorithm for strings lead to almost the same collisions with java
whereas .NET seems to perform better with 0 collisions in both tests.
You can read about it here:
http://corsis.blogspot.com/2008/07/mono-string-hash-code-collisions.html
Just wanted to ask about the implications of these results and whether you
might plan to improve on the current state.
Best Regards,
Cetin Sert
P/s: below is the quick and probably poor quality test code used to get the
results for the blog post
http://corsis.de/mono/string-hashcode-collision-test.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace HashCollisions
{
class Program
{
static void Main(string[] args)
{
var arr = get3(3);
var l = arr.Length;
var x = 0; // total collisions
var y = 0; // colls
var q = false;
for (int i = 0; i l; i++)
{
var c = arr[i];
var h = c.GetHashCode();
for (int j = 0; j l; j++)
{
if (i != j)
{
var t = arr[j];
if (h == t.GetHashCode())
{
Console.Write(c);
Console.Write(, );
Console.WriteLine(t);
y++;
break;
//
if (!q)
{
Console.Write(c);
Console.Write(, );
y++;
}
x++;
Console.Write(t);
Console.Write(, );
q = true;
}
}
}
if (q) Console.WriteLine();
q = false;
}
Console.WriteLine(l);
Console.WriteLine(l * l);
Console.WriteLine(y);
Console.WriteLine(x);
}
unsafe static string[] get(int size)
{
var s = set.Length;
var l = set.Length;
for (int i = 0; i size-1; i++)
{
l *= l;
}
var all = new string[l];
char* itm = stackalloc char[size + 1];
int x = 0;
for (int i = 0; i s; i++)
{
itm[0] = set[i];
for (int j = 0; j s; j++)
{
itm[1] = set[j];
all[x++] = new string(itm);
}
}
return all;
}
unsafe static string[] get3(int size)
{
var s = set.Length;
var l = (int)Math.Pow(s, size);
var all = new string[l];
char* itm = stackalloc char[size + 1];
int x = 0;
for (int i = 0; i s; i++)
{
itm[0] = set[i];
for (int j = 0; j s; j++)
{
itm[1] = set[j];
for (int k = 0; k s; k++)
{
itm[2] = set[k];
all[x++] = new string(itm);
}
}
}
return all;
}
static char[] set = init();
static char[] init()
{
var b1 = block('a', 'z');
var b2 = block('A', 'Z');
var b3 = block('0', '9');
var set = new char[b1.Length + b2.Length + b3.Length];
Array.Copy(b1, 0, set, 0, b1.Length);
Array.Copy(b2, 0, set, b1.Length, b2.Length);
Array.Copy(b3, 0, set, b1.Length + b2.Length, b3.Length);
return set;
}
static char[] block(char start, char end)
{
return block((int)start, (int)end + 1);
}
unsafe static char[] block(int start, int end)
{
var length = end - start;
var block = new char[length];
fixed (char *p = block)
{
char* x = p;
for (int i = start; i end; i++, x++)
{
*x = (char)i;
Console.WriteLine(*x);
}
}
return block;
}
}
}___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] DataGridView Virtual Mode
Dear Mono Devs, Is the virtual mode of winforms DataGridView already usable in the latest mono releases or at least in the SVN repository? Best Regards, Cetin Sert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] DataGridView Virtual Mode
No, datagridview's virtual mode is not currently implemented in a release or SVN. Jonathan Cetin Sert wrote: Dear Mono Devs, Is the virtual mode of winforms DataGridView already usable in the latest mono releases or at least in the SVN repository? Best Regards, Cetin Sert ___ 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] System.Console problem
I try to reset the width and height of the console: This functionality is not supported on Unix consoles. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
