Re: [Mono-dev] Patch to RotateFlip: reworks existing code and adds 1-and 4-bit support
At 10:44 PM 23/10/2005 -0600, Peter Dennis Bartok wrote: Jonathan, I haven't reviewed the patch yet, but I noticed that you put the tests for it in winforms; it'd be cool you would nunit-ify them and put them straight under System.Drawing/Test? Maybe using GetPixel to verify it rotated correctly. That way it could be automated. The winforms module is mostly meant for visual test applications. I'll respond on the patch tomorrow, after I had a chance to review. Cheers, Peter I poked around in the System.Drawing tests and found that there was already a test in place for rotation of non-indexed bitmaps, so I added a test for just 1- and 4-bit bitmaps (see attached patch). It uses Marshal.ReadByte() in conjunction with Bitmap.LockBits() to read the packed representation of the pixels. I hope this is okay :-) Sorry for adding inappropriate tests to the winforms module. If you'd like, I could hack up the tests there to display their results visually ;-) Jonathan rotate1bit4bit-test.patch.gz Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] corcompare patch for printing generic method type arguments
Hi,
Here is another patch for corcompare for generics support. With
this patch it prints type arguments in generic methods.
Suppose that we have
void FooT,U () where T : IFoo, U : IBar
Then it prints
Foo[T(IFoo), U(IBar)]
Thanks to Martin for fixing bug #76482 (this patch works fine
only after r52118).
Atsushi Eno
Index: mono-api-info.cs
===
--- mono-api-info.cs(revision 52122)
+++ mono-api-info.cs(working copy)
@@ -699,6 +699,28 @@
MethodBase method = (MethodBase) member;
string name = method.Name;
string parms = Parameters.GetSignature
(method.GetParameters ());
+ MethodInfo mi = method as MethodInfo;
+#if NET_2_0
+ Type [] genArgs = mi == null ? Type.EmptyTypes :
+ mi.GetGenericArguments ();
+ if (genArgs.Length 0) {
+ string [] genArgNames = new string
[genArgs.Length];
+ for (int i = 0; i genArgs.Length; i++) {
+ genArgNames [i] = genArgs [i].Name;
+ Type [] gcs = genArgs
[i].GetGenericParameterConstraints ();
+ if (gcs.Length 0) {
+ string [] gcNames = new string
[gcs.Length];
+ for (int g = 0; g gcs.Length;
g++)
+ gcNames [g] = gcs
[g].FullName;
+ genArgNames [i] +=
String.Concat (
+ (,
+ string.Join(, ,
gcNames),
+ ));
+ }
+ }
+ return String.Format ({0}[{2}]({1}), name,
parms, string.Join (,, genArgNames));
+ }
+#endif
return String.Format ({0}({1}), name, parms);
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Use Encoding.Default as the default code page formcs
Hi, I posted this patch two weeks ago but I got no comments. Could you review please? Kornél - Original Message - From: Kornél Pál [EMAIL PROTECTED] To: mono-devel-list@lists.ximian.com Sent: Monday, October 10, 2005 11:47 AM Subject: [Mono-dev] [PATCH] Use Encoding.Default as the default code page formcs Hi, csc.exe uses Encoding.Default as the default code page that is system dependent unlike our current hard coded default code pages. Encoding.Default takes care (or at least should take care:) about everything so we don't have to use try-catch or store it in a variable like default_encoding. This patch simply changes default code page from 28591 to Encoding.Default. In addition to that this is the expected behaviour as csc.exe does the same this is what developers require as they edit source files on their system using their system default code page so they want to compile it using the same code page to get the expected result when compiling code. Note that previously we followed a wrong practicle by defining the code page we use in mcs tree as the default code page of our mcs copiler rather than passig this code page to mcs as command line argument. This is now fixed so we should use Encoding.Default as the default code page of mcs. Please review and approve the patch. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list MCSDefaultCodePage.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] Use Encoding.Default as the default code page formcs
Oops, am sorry I missed it too. I support the fix. Since we already have -codepage in mcs build itself, it should be seamlessly done. Atsushi Eno Kornél Pál wrote: Hi, I posted this patch two weeks ago but I got no comments. Could you review please? Kornél - Original Message - From: Kornél Pál [EMAIL PROTECTED] To: mono-devel-list@lists.ximian.com Sent: Monday, October 10, 2005 11:47 AM Subject: [Mono-dev] [PATCH] Use Encoding.Default as the default code page formcs Hi, csc.exe uses Encoding.Default as the default code page that is system dependent unlike our current hard coded default code pages. Encoding.Default takes care (or at least should take care:) about everything so we don't have to use try-catch or store it in a variable like default_encoding. This patch simply changes default code page from 28591 to Encoding.Default. In addition to that this is the expected behaviour as csc.exe does the same this is what developers require as they edit source files on their system using their system default code page so they want to compile it using the same code page to get the expected result when compiling code. Note that previously we followed a wrong practicle by defining the code page we use in mcs tree as the default code page of our mcs copiler rather than passig this code page to mcs as command line argument. This is now fixed so we should use Encoding.Default as the default code page of mcs. Please review and approve the patch. Kornél ___ 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-dev] Installers and relative paths
The latest Windows installer doesn't set any environment variables in the wrapper scripts and batch files (MONO_PATH, etc...). This works fine in finding the gac binaries. I've looked into doing this for the linux installer as well, and some programs didn't work. gmcs worked, but mcs didn't (couldn't locate a hardcoded dll). Why would this be different on the different oses? Is only windows set up to use relative paths? Wade ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Problem with URIBuilder...
I've opened a new bug in bugzilla :
http://bugzilla.ximian.com/show_bug.cgi?id=76501
If you execute the following code on mono :
UriBuilder ub=new UriBuilder(http://mondomaine/trucmuche/login.aspx);
ub.Query=ub.Query.TrimStart(new char[]{'?'})+ticket=bla;
Console.WriteLine((URIBUILDER)Redirige vers : +ub.ToString());
Console.ReadLine();
you'll obtain :
http://mondomaine:80//trucmuche/login.aspx?ticket=bla
(note the double / after :80)
on MS.NET you'll obtain
http://mondomaine:80/trucmuche/login.aspx?ticket=bla
I've done a little patch to solve this issue...
Could someone apply it...
___Ce message et les éventuels documents joints peuvent contenir des informations confidentielles.Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite.Les communications sur internet n'étant pas sécurisées, l'intégrité de ce message n'est pas assurée et la société émettrice ne peut être tenue pour responsable de son contenu.
Index: System/UriBuilder.cs
===
--- System/UriBuilder.cs (revision 52016)
+++ System/UriBuilder.cs (working copy)
@@ -260,9 +260,15 @@
builder.Append (host);
if (port 0)
builder.Append (: + port);
-
- if (path != String.Empty)
-builder.Append ('/');
+
+ if (path != String.Empty)
+ {
+if (!builder.ToString().EndsWith(/))
+{
+ if (!path.StartsWith(/))
+ builder.Append ('/');
+}
+ }
builder.Append (path);
builder.Append (query);
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] New bug: Problem with null namespaces using XSLT
I have just filed a new bug, if someone is interested: http://bugzilla.ximian.com/show_bug.cgi?id=76530 I hope it is not difficult to fix, and I would appreciate very much if this could be done before 1.2 release. Regards, Andrés [ knocte ] -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Installers and relative paths
Wade, The latest Windows installer doesn't set any environment variables in the wrapper scripts and batch files (MONO_PATH, etc...). This works fine in finding the gac binaries. The path to the mono assemblies is computed from the executable's file name of the process that loads mono.dll. See os/win32/util.cs:mono_set_rootdir. I've looked into doing this for the linux installer as well, and some programs didn't work. gmcs worked, but mcs didn't (couldn't locate a hardcoded dll). Why would this be different on the different oses? Is only windows set up to use relative paths? Only Windows and it's not always perfect: http://bugzilla.ximian.com/show_bug.cgi?id=76529 Relocation based on the executable's file name is not portable under Unix. Glib is still missing this function, AFAIK. That's probably the reason, why under Unix the path is hard coded. Rob ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] runtime specification in nunit-console.exe.config
Actually, as Sebastien mentioned in that thread, we cannot just install the 2.0 nunit assemblies, because they conflict with 1.1 profile ones. But indeed, removing .config file from nunit-console is a good idea, because it is rather meaningless on mono (the corlib should be choosen according to the profile for which nunit-console was compiled and there are no 1.0 compatibility issue). It is a safe operation and IMO can be commited immediately. And about resolving assemblies conflict problem... I have an idea that: - lib/mono/1.0 and lib/mono/2.0 directories would both contain nunit.core.dll, etc. symlinks to the GAC, but there would be two kind of directories in the gac/: - nunit.core, nunit.framework,... and nunit2.core, nunit2.framework, ... - if it is possible, those *2.* directories would just be the disambiguation hack and they would contain standard nunit.core.dll, nunit.framework.dll, ... - there would be additional mono-nunit2.pc, which would point to 2.0 assemblies This is my idea, but I'm not sure what Makefile stuff needs to be done for such configuration and the most important thing, if gacutil allows to create the mentioned hack directories. 2005/10/24, Atsushi Eno [EMAIL PROTECTED]: Oh, thanks Kamil, I overlooked the post... that patch looks cooler :-) I support it. Atsushi Eno Kamil Skalski wrote: Yap, removing this would be nice and it would bring nunit-console on 2.0 profile one step closer to being usable outside the mono build tree (see http://lists.ximian.com/pipermail/mono-devel-list/2005-September/014598.html) This is a deviation from original nunit.org sources though. Still, the most difficult problem with nunit for 2.0 is that we need to store somehow the 2.0 version of nunit assemblies and the current versioning/numbering scheme does not give a clean way for this. Nunit assemblies are currently installed into the GAC under 2.2.0.0 version number (and are compiler for 1.1 profile). -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] corcompare patch for printing generic method type arguments
Hi Marek,
Marek Safar wrote:
Hello Eno,
Here is another patch for corcompare for generics support. With
this patch it prints type arguments in generic methods.
Suppose that we have
void FooT,U () where T : IFoo, U : IBar
Then it prints
Foo[T(IFoo), U(IBar)]
I prefer the syntax where will be more obvious that it is about generic
possibly use same syntax as csc/gmcs use for error reporting.
Something like `FooT(IFoo), U (IBar)'
Oh, true. Well, then we could just make it just to print where, so
void FooT,U () where T : IFoo, U : IBar
becomes
void FooT,U () where T : IFoo, U : IBar
as is ;-) I attached the updated patch.
Atsushi Eno
Index: mono-api-info.cs
===
--- mono-api-info.cs(revision 52138)
+++ mono-api-info.cs(working copy)
@@ -699,6 +699,34 @@
MethodBase method = (MethodBase) member;
string name = method.Name;
string parms = Parameters.GetSignature
(method.GetParameters ());
+ MethodInfo mi = method as MethodInfo;
+#if NET_2_0
+ Type [] genArgs = mi == null ? Type.EmptyTypes :
+ mi.GetGenericArguments ();
+ if (genArgs.Length 0) {
+ string [] genArgNames = new string
[genArgs.Length];
+ string genArgCsts = String.Empty;
+ for (int i = 0; i genArgs.Length; i++) {
+ genArgNames [i] = genArgs [i].Name;
+ Type [] gcs = genArgs
[i].GetGenericParameterConstraints ();
+ if (gcs.Length 0) {
+ string [] gcNames = new string
[gcs.Length];
+ for (int g = 0; g gcs.Length;
g++)
+ gcNames [g] = gcs
[g].FullName;
+ genArgCsts += String.Concat (
+ genArgNames [i],
+: ,
+ string.Join (, ,
gcNames));
+ }
+ }
+ return String.Format ({0}{2}({1}){3},
+ name,
+ parms,
+ string.Join (,, genArgNames),
+ genArgCsts.Length == 0 ? String.Empty :
+where + genArgCsts);
+ }
+#endif
return String.Format ({0}({1}), name, parms);
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Totally baffed! multithread app totally different on two environments with MONO
I have a server process written on Mono that spawns 400 threads, runs great on one server, I just installed in on a different server, and the exact same program spawns ONE PROCESS for each thread (400 linux OS processes!!!) where as on the original server it just is ONE PROCESS. This is very twilight zone'ish, but the app still works (can't have as many threads on the newer). I am sure there is a good answer to this, but I curtainly don't have it! Anyone care to conjecture? one server is SUSE 9.2 (which has only one process for the server app) (mono 1.1.8), the other server is a old redhat 9.X (mono 1.0.2) with 2.4 kernel. mono does threading different depending on whether 2.4.X vs. 2.6.X kernel ?? mono does threading different depending on mono 1.0.2 vs. mono 1.1.8 ?? -tl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Totally baffed! multithread app totally different on two environments with MONO
On Mon, 2005-10-24 at 21:12 -0400, ted leslie wrote: mono does threading different depending on whether 2.4.X vs. 2.6.X kernel ?? The handling of threading changed between Linux 2.4 and 2.6 with the introduction of NPTL -- Native Posix Thread Libraries. 2.6 is far more compliant with the POSIX standards. The issue that you're seeing is that Linux doesn't have the concept of a thread or process, it has the concept of a task. Processes are just how resources are handled. In particular, the Linux sys_clone() system call allows new tasks to specify whether they use the same address space as the caller (thus splitting between the process creation of fork(2) vs. the thread creation of pthread_create()), as well as other resources (file handles, signal handlers, etc.). The deal is that all the 2.4 tools showed each thread as a distinct process, because it _was_ a process (though it did share the process address space with other threads). 2.6 introduced better support for the POSIX standards, allowing the tools to better group by process. In short, you're not seeing a mono issue, you're seeing a Linux issue. mono does threading different depending on mono 1.0.2 vs. mono 1.1.8 ?? No. - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Installers and relative paths
Hello, The latest Windows installer doesn't set any environment variables in the wrapper scripts and batch files (MONO_PATH, etc...). This works fine in finding the gac binaries. I've looked into doing this for the linux installer as well, and some programs didn't work. gmcs worked, but mcs didn't (couldn't locate a hardcoded dll). Why would this be different on the different oses? Is only windows set up to use relative paths? Yes, Windows is set to use relative paths, while the Unix version is not. I think we should fix this. They could be the same, but *typically* on a Unix system, when Mono is integrated with the OS (prefix=/usr), the conventions are something like this: most stuff is relative to $prefix, but configuration is relative to /etc. Which is why we can not guess the start location. Maybe what we could do is have the runtime detect whether its being executed from /usr/bin, and if so, it fallsback to /usr for most things, and /etc for the rest. But if the binary is not in /usr/bin/mono, then it should compute things relative to the executable path. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
