[Mono-dev] Jit and C# Compiler
Hi, I am doing a course on compiler. I am planning to choose a project based on .NET Framework/Mono. I am briefly describing the project below. The project will aim to improve the execution of CIL image on multicore processors. First step is to change the C# compiler to insert custom instructions into the managed binary (just like how the line #s are stored). These instructions will be parsed by JIT to pick valuable information about instruction dependency and will be able to make smart decisions. Yes, the size of binaries will grow. We will work for a optimal solutions - may be by having a percentage size threshold. This is a research/school project to prove a concept. Lots of comments/suggestions are welcomed. Regards, Khaled ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.dll few patches for review
Hello Sebastien. I ran mono-api-check on both 1.1 and 2.0 profile, and it did not see any difference after I removed IEnumerable. So I will commit this patch and check class statuses of 1.1 and 2.0 in a few days. * X509CertificateCollection.patch - remove unnecessary overload If this doesn't cause any error with the class library status pages then remove (don't comment) it. The comment itself can be put in the ChangeLog. According to MSDN X509CertificateCollection does not implement IEnumerable privately. You're right. Anyway CollectionBase already implements IEnumerable. Not sure why it was put there (it's been there since the first commit in 2002). Actually, that means that the patch should look like in the new attachment. What do you mean by class library status pages? The old corcompare which is available online from http://www.mono-project.com/Class_Status You should check both 1.x and 2.0 profiles. I could run make run-test after this patch applied, and it gave same number of errors before and after the patch. Is that enough? No. It will spot functionality regressions but it won't spot errors in API definitions. I don't see how/why this could break but it's safer to always check the pages after an API change (either manually on your own computer or on the public pages a while after the check-in). -- Sebastien Pouliot [EMAIL PROTECTED] Blog: http://pages.infinit.net/ctech/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Where do I start off??
Well I want to work ON Mono and (not *with*) Mono,sorry for all the troubles again.I have around 3 months experience working on C# and ASP.Net.So where do i start developing?? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Where do I start off??
nagendra prasad wrote: Well I want to work ON Mono and (not *with*) Mono,sorry for all the troubles again.I have around 3 months experience working on C# and ASP.Net.So http://ASP.Net.So where do i start developing?? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list You should start here: http://mono-project.com/Contributing The best way to start is by tackling some simple bugs. With your asp.net experience you might want to start by looking at ASP.NET related assemblies. Quick link to bugs: http://mono-project.com/Bugs You should also make sure that you can compile mono/mcs/xsp from svn successfully before trying to tackle a particular bug. - raf ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.dll few patches for review
Hello Andrew, Thanks for spotting/fixing this! On Thu, 2006-10-05 at 00:19 -0700, Andrew Skiba wrote: Hello Sebastien. I ran mono-api-check on both 1.1 and 2.0 profile, and it did not see any difference after I removed IEnumerable. So I will commit this patch and check class statuses of 1.1 and 2.0 in a few days. * X509CertificateCollection.patch - remove unnecessary overload If this doesn't cause any error with the class library status pages then remove (don't comment) it. The comment itself can be put in the ChangeLog. According to MSDN X509CertificateCollection does not implement IEnumerable privately. You're right. Anyway CollectionBase already implements IEnumerable. Not sure why it was put there (it's been there since the first commit in 2002). Actually, that means that the patch should look like in the new attachment. What do you mean by class library status pages? The old corcompare which is available online from http://www.mono-project.com/Class_Status You should check both 1.x and 2.0 profiles. I could run make run-test after this patch applied, and it gave same number of errors before and after the patch. Is that enough? No. It will spot functionality regressions but it won't spot errors in API definitions. I don't see how/why this could break but it's safer to always check the pages after an API change (either manually on your own computer or on the public pages a while after the check-in). -- Sebastien Pouliot [EMAIL PROTECTED] Blog: http://pages.infinit.net/ctech/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] FW: EventHandlerList implementation
Hello, Before we have our weekend, I'd like to resend this patch for approval. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Skiba Sent: Tuesday, October 03, 2006 15:48 To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] EventHandlerList implementation Please review the attached patch for EventHandlerList implementation. Here is the description: Implement event handler list according to MS definition. No hash table, just a simple list with good performance for a small number of events ( 20) and worse performance when number of events is bigger. EventHandlerList.patch Description: EventHandlerList.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mod_mono: vhost clashes again
On Sun, 2006-09-17 at 17:22 -0400, Joshua Tauberer wrote: The attached patch fixes up some clashes when mod_mono is used with vhosts. The XXGLOBAL server socket file must be prefixed with the vhost name because it is created per-vhost. The patch prefixes every alias in a socket file name with the vhost name. (As a matter of code cleanliness, it also now uses a more ugly socket file name that includes the string XXGLOBAL..) Let me know if it's ok. This is now in svn. Thanks a lot. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] FW: EventHandlerList implementation
On Thu, 2006-10-05 at 04:50 -0700, Andrew Skiba wrote: Hello, Before we have our weekend, I'd like to resend this patch for approval. This is ok to commit. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Jit and C# Compiler
Hi!Sounds very interesting!If I am correct you want to detect (thus extract) parallelism from a CIL image right?Do you have any research paper describing the algorithm you plan to use ?Please keep us informed of your advancement :) --cv2006/10/5, Khaled A. K. Mohammed [EMAIL PROTECTED] : Hi,I am doing a course on compiler. I am planning to choose a project basedon .NET Framework/Mono.I am briefly describing the project below.The project will aim to improve the execution of CIL image on multicore processors. First step is to change the C# compiler to insert custominstructions into the managed binary (just like how the line #s arestored). These instructions will be parsed by JIT to pick valuableinformation about instruction dependency and will be able to make smart decisions. Yes, the size of binaries will grow. We will work for aoptimal solutions - may be by having a percentage size threshold.This is a research/school project to prove a concept.Lots of comments/suggestions are welcomed. Regards,Khaled___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] Jit and C# Compiler
Do you plan to automatically detect when parallel usage is possible or will it be something that the C# program's author can specify? Martin On 10/5/06, Cedric Vivier [EMAIL PROTECTED] wrote: Hi! Sounds very interesting! If I am correct you want to detect (thus extract) parallelism from a CIL image right? Do you have any research paper describing the algorithm you plan to use ? Please keep us informed of your advancement :) -- cv 2006/10/5, Khaled A. K. Mohammed [EMAIL PROTECTED] : Hi, I am doing a course on compiler. I am planning to choose a project based on .NET Framework/Mono. I am briefly describing the project below. The project will aim to improve the execution of CIL image on multicore processors. First step is to change the C# compiler to insert custom instructions into the managed binary (just like how the line #s are stored). These instructions will be parsed by JIT to pick valuable information about instruction dependency and will be able to make smart decisions. Yes, the size of binaries will grow. We will work for a optimal solutions - may be by having a percentage size threshold. This is a research/school project to prove a concept. Lots of comments/suggestions are welcomed. Regards, Khaled ___ 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 -- Martin Hinks http://www.m-s-d.net ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Jit and C# Compiler
To simply this task maybe use OpenMP http://www.openmp.org Martin Hinks [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Do you plan to automatically detect when parallel usage is possible or will it be something that the C# program's author can specify? Martin On 10/5/06, Cedric Vivier [EMAIL PROTECTED] wrote: Hi! Sounds very interesting! If I am correct you want to detect (thus extract) parallelism from a CIL image right? Do you have any research paper describing the algorithm you plan to use ? Please keep us informed of your advancement :) -- cv 2006/10/5, Khaled A. K. Mohammed [EMAIL PROTECTED] : Hi, I am doing a course on compiler. I am planning to choose a project based on .NET Framework/Mono. I am briefly describing the project below. The project will aim to improve the execution of CIL image on multicore processors. First step is to change the C# compiler to insert custom instructions into the managed binary (just like how the line #s are stored). These instructions will be parsed by JIT to pick valuable information about instruction dependency and will be able to make smart decisions. Yes, the size of binaries will grow. We will work for a optimal solutions - may be by having a percentage size threshold. This is a research/school project to prove a concept. Lots of comments/suggestions are welcomed. Regards, Khaled ___ 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 -- Martin Hinks http://www.m-s-d.net ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Jit and C# Compiler
Hello, On Thu, 2006-10-05 at 14:18 +0200, Cedric Vivier wrote: Hi! Sounds very interesting! If I am correct you want to detect (thus extract) parallelism from a CIL image right? Yes, the extra information will help JIT to understand the nature of the program. Do you have any research paper describing the algorithm you plan to use ? Well, one of the student of Prof. Tarek (University of Toronto) have modified Jikes (the IBM java compiler) to do something similar. His changes in compiler created two files: a java byte code and a registry for runtime environment. And his changes in JIT will thread any method it finds and will use the registry information to handle dependency issues. http://www.eecg.toronto.edu/zjava/ Prof. Tarek has done a lot of research on inserting extra information in binary image. So I am guessing he has what I would need. The first step is to research on .NET to find out what kind of optimization for multicore processor (parellelism) is currently available? Please keep us informed of your advancement :) Sure, thanks. -- cv 2006/10/5, Khaled A. K. Mohammed [EMAIL PROTECTED]: Hi, I am doing a course on compiler. I am planning to choose a project based on .NET Framework/Mono. I am briefly describing the project below. The project will aim to improve the execution of CIL image on multicore processors. First step is to change the C# compiler to insert custom instructions into the managed binary (just like how the line #s are stored). These instructions will be parsed by JIT to pick valuable information about instruction dependency and will be able to make smart decisions. Yes, the size of binaries will grow. We will work for a optimal solutions - may be by having a percentage size threshold. This is a research/school project to prove a concept. Lots of comments/suggestions are welcomed. Regards, Khaled ___ 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] Jit and C# Compiler
Hi, On Thu, 2006-10-05 at 13:21 +0100, Martin Hinks wrote: Do you plan to automatically detect when parallel usage is possible or will it be something that the C# program's author can specify? Automatic is the plan for now. I might use the compiler to add Attributes [(...)] to methods during compilation, which can probably be added by application developers too. If you have other suggestions, please let me know. Martin On 10/5/06, Cedric Vivier [EMAIL PROTECTED] wrote: Hi! Sounds very interesting! If I am correct you want to detect (thus extract) parallelism from a CIL image right? Do you have any research paper describing the algorithm you plan to use ? Please keep us informed of your advancement :) -- cv 2006/10/5, Khaled A. K. Mohammed [EMAIL PROTECTED] : Hi, I am doing a course on compiler. I am planning to choose a project based on .NET Framework/Mono. I am briefly describing the project below. The project will aim to improve the execution of CIL image on multicore processors. First step is to change the C# compiler to insert custom instructions into the managed binary (just like how the line #s are stored). These instructions will be parsed by JIT to pick valuable information about instruction dependency and will be able to make smart decisions. Yes, the size of binaries will grow. We will work for a optimal solutions - may be by having a percentage size threshold. This is a research/school project to prove a concept. Lots of comments/suggestions are welcomed. Regards, Khaled ___ 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] Parch for Enum support in Custom attributes
Hi Eyal,
Thanks for working on this. I don't want to commit it as it is, but I'll
surely use part of it. I don't want to load the assembly referenced only
for reading a custom attribute body. Instead, I'll create an interface
that CustomAttribute and SecurityDeclaration will share, and will allow
one to load the content of something that needs to load a reference.
Something like:
CustomAttribute ca = ...;
if (!ca.Read) {
ca.ForceRead ();
}
Otherwise, for a lot of assemblies, Cecil will have to load the corelib
while the user don't necessary need to read the content of the custom
attribute.
Jb
Eyal Alaluf wrote:
Hi, JB.
Attached is patch for supporting enums in cutom attributes. Support is
added
for enums as ctor parameters as fields and as properties.
The main problem with Enums is to identify their underlying integral type.
Without this integral type the custom attribute cannot be read. The patch
uses the assembly resolver for this purpose.
I have attached a simple test scenraio with 3 C# files.
* Test1.cs is a DLL defining enums and an attribute that has enums as
field properties and ctor params.
* Test2.cs is another DLL that uses the attribute and enums from Test1.
This exercise the new code that resolves enum types from another DLL.
* ReadTest2.cs is an EXE written using Cecil that parses test2.dll and
prints the custom attributes of its types. It gets as argument the
path
to the dll it parses.
Note that Test1 uses ClassUsageAttaribute from mscorlib. For some reason
the
assembly resolver didn't find mscorlib.dll from the GAC when I ran
ReadTest2
on Test2 until I put mscorlib.dll in the same dir as Test2 ReadTest2.
Eyal.
Index: Mono.Cecil/ReflectionReader.cs
===
--- Mono.Cecil/ReflectionReader.cs(revision 66216)
+++ Mono.Cecil/ReflectionReader.cs(working copy)
@@ -65,7 +65,24 @@
protected CodeReader m_codeReader;
protected ISymbolReader m_symbolReader;
- public ModuleDefinition Module {
+ internal AssemblyNameReference Corlib
+ {
+ get
+ {
+ if (m_corlib == null) {
+ foreach (AssemblyNameReference ar in
m_module.AssemblyReferences) {
+ if (ar.Name ==
Constants.Corlib) {
+ m_corlib = ar;
+ break;
+ }
+ }
+ }
+ return m_corlib;
+ }
+ }
+
+ public ModuleDefinition Module
+ {
get { return m_module; }
}
@@ -295,19 +312,11 @@
TypeReference coreType = m_module.TypeReferences
[fullName];
if (coreType == null) {
- if (m_corlib == null) {
- foreach (AssemblyNameReference ar in
m_module.AssemblyReferences) {
- if (ar.Name ==
Constants.Corlib) {
- m_corlib = ar;
- break;
- }
- }
- }
string [] parts = fullName.Split ('.');
if (parts.Length != 2)
throw new ReflectionException (Unvalid
core type name);
- coreType = new TypeReference (parts [1], parts
[0], m_corlib);
+ coreType = new TypeReference (parts [1], parts
[0], Corlib);
m_module.TypeReferences.Add (coreType);
}
if (!coreType.IsValueType) {
Index: ChangeLog
===
--- ChangeLog (revision 66226)
+++ ChangeLog (working copy)
@@ -1,3 +1,11 @@
+2006-10-05 Eyal Alaluf [EMAIL PROTECTED]
+
+ Mono.Cecil/ReflectionReader.cs:
+ Expose Corlib assembly refereice so SignatureReader can ise it.
+ Mono.Cecil.Signatures/SignatureReader.cs:
+ Added support for enums in custom attributes ctors, properties
and
+ fields.
+
2006-10-04 Eyal Alaluf [EMAIL PROTECTED]
* Mono.Cecil/StructureReader.cs:
@@ -2,3 +10,2 @@
Visit the module we load when a DLL has more then 1
Re: [Mono-dev] Where do I start off??
Joshua Tauberer escribió: According to [1], that's not strictly true. Citing the page: mono-devel-list: A mailing list specifically dedicated to discussions about developing Mono and programming *with* Mono. (snip) [1] http://www.mono-project.com/Mailing_Lists I just fixed the description on the wiki. with wasn't the right word (despite the emphasis around it). Thanks for clearing things Joshua :) 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] System.dll few patches for review
Sorry if this is already handled, just looked over the list and found this bug: Index: System.Net/DigestClient.cs === --- System.Net/DigestClient.cs (revision 66034) +++ System.Net/DigestClient.cs (working copy) @@ -248,9 +248,9 @@ return false; } - // build the hash object (only MD5 is defined in RFC2617) - if ((parser.Algorithm == null) || (parser.Algorithm.ToUpper ().StartsWith (MD5))) - hash = HashAlgorithm.Create (MD5); + // build the hash object (only MD5 is defined in RFC2617) + if ((parser.Algorithm == null) || (parser.Algorithm.ToUpper ().StartsWith (MD5))) + hash = MD5.Create (); return true; } Algorithm.ToUpper ().StartsWith (MD5))) is most likely wrong because the code is doing a culture-sensitive uppercasing. You should use something like ToUpperInvariant or pass the Invariant Culture (or better if possible: one of the case-insensitive compares) I didn't look into the relevant classes, but there may be more similar occurences of that problem. mfg Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.dll few patches for review
You are still wrong :-) InvariantCulture still causes culture sensitive comparison. Use String.CompareOrdinal() or CompareOptions.Ordinal instead. Atsushi Eno Andreas Nahr wrote: Sorry if this is already handled, just looked over the list and found this bug: Index: System.Net/DigestClient.cs === --- System.Net/DigestClient.cs (revision 66034) +++ System.Net/DigestClient.cs (working copy) @@ -248,9 +248,9 @@ return false; } - // build the hash object (only MD5 is defined in RFC2617) - if ((parser.Algorithm == null) || (parser.Algorithm.ToUpper ().StartsWith (MD5))) - hash = HashAlgorithm.Create (MD5); + // build the hash object (only MD5 is defined in RFC2617) + if ((parser.Algorithm == null) || (parser.Algorithm.ToUpper ().StartsWith (MD5))) + hash = MD5.Create (); return true; } Algorithm.ToUpper ().StartsWith (MD5))) is most likely wrong because the code is doing a culture-sensitive uppercasing. You should use something like ToUpperInvariant or pass the Invariant Culture (or better if possible: one of the case-insensitive compares) I didn't look into the relevant classes, but there may be more similar occurences of that problem. mfg Andreas ___ 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] nant console output doubled since corlib update
Well today I tried something clever and paid the price. I needed access to the Decimal.TryParse() method which is only in SVN trunk, but I wanted to leave my Mono-related Debian packages in tact. So I built mono/mcs from scratch, installed to a folder in my home directory, and manually copied both the 1.0 and 2.0 mscorlib.dll assemblies to /usr/lib/mono/version/. Now all of the console output from nant 0.85rc4 is doubled (prints twice). A simple HelloWorld program's output works as expected, so it might be a problem with nant. However, nant worked perfectly with the 1.1.17.1 version of mscorlib.dll. To make matters worse it also messes up my terminal (both PuTTY and gnome-terminal) so that key presses are not echoed locally. Very strange stuff. -- Michael Schurter Synthesys Solutions ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] nant console output doubled since corlib update
On Thu, 2006-10-05 at 15:50 -0500, Michael Schurter wrote: Well today I tried something clever and paid the price. I needed access to the Decimal.TryParse() method which is only in SVN trunk, but I wanted to leave my Mono-related Debian packages in tact. So I built mono/mcs from scratch, installed to a folder in my home directory, and manually copied both the 1.0 and 2.0 mscorlib.dll assemblies to /usr/lib/mono/version/. Now all of the console output from nant 0.85rc4 is doubled (prints twice). A simple HelloWorld program's output works as expected, so it might be a problem with nant. However, nant worked perfectly with the 1.1.17.1 version of mscorlib.dll. To make matters worse it also messes up my terminal (both PuTTY and gnome-terminal) so that key presses are not echoed locally. There's a patch for nant to fix the double output issue. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] WAPI Handle Leaks
I'm curious, is anyone out there doing much work in tracking down the wapi handle leak problems? Our XSP server dies on a daily basis because it's always running out of thread handles. Using 1.1.17.1 or the latest SVN version (r66235), the problem is there. I suspect there are problems with threads created internally (for example, as part of the thread pool) that aren't cleaned up by the garbage collector. I would be happy to help test, but solving the problem seems that it would require fairly in depth knowledge of the io layer, garbage collection, wapi handle usage, and such. Patrick Earl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] System.Transactions key is wrong
The System.Transactions key should be b77a5c561934e089. The following patch changes the key file to the same file that other assemblies with the same name use. I don't really know what that JVM stuff is, but it seemed to be present in the other cases. After applying this patch, my system properly loaded an ADO.NET 2 provider compiled on windows. Patrick Index: class/System.Transactions/Assembly/AssemblyInfo.cs === --- class/System.Transactions/Assembly/AssemblyInfo.cs (revision 66235) +++ class/System.Transactions/Assembly/AssemblyInfo.cs (working copy) @@ -45,7 +45,9 @@ [assembly: NeutralResourcesLanguage (en-US)] [assembly: AssemblyDelaySign (true)] -[assembly: AssemblyKeyFile (../msfinal.pub)] +#if !TARGET_JVM +[assembly: AssemblyKeyFile (../ecma.pub)] +#endif #if NET_2_0 [assembly: AssemblyCompany (MONO development team)] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Transactions key is wrong
On Thu, 2006-10-05 at 16:29 -0600, Patrick Earl wrote: The System.Transactions key should be b77a5c561934e089. The following patch changes the key file to the same file that other assemblies with the same name use. I don't really know what that JVM stuff is, but it seemed to be present in the other cases. After applying this patch, my system properly loaded an ADO.NET 2 provider compiled on windows. Thanks. Your patch is in svn. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] patch to fix OS X/Darwin segfaults.
This patch fixes a GC bug in darwin_stop_world.c where memory would be freed immediately before it was read. I've also submitted this patch to libgc upstream. Could somebody look this over and either give me the OK to commit or apply it themselves? -Allan mono-darwin-stop-world.patch Description: Binary data -- Allan Hsu allan at counterpop dot net 1E64 E20F 34D9 CBA7 1300 1457 AC37 CBBB 0E92 C779 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
