Re: [Mono-dev] Re: [Mono-devel-list] Initial ARM JIT port in svn
Hi, I have no interest or plans to do a PocketPC port myself (if I had a pda I'd run a useful operating system on it, like Linux). Sure... Linux runs on every PDA out there That's not quite true - there are some that it refuses to run on due to problems with the interface and pointing devices. Mr. Paolo, it seems that you've managed to pass your anger against microsoft in a single textual sentence. No problem... I'm also not very fond of it either. But, as it seems, when the market DO buy those PDAs, and when people ONLY use them, if you want to sell a product, you have to develop for that OS... There's no point in so much anger, is there? This isn't ideological discussion. It's a fact! You're totally correct. However, on the other side of the coin, if you never offer them a choice, you get nowhere. We can go into the whys and wherefores from now until sometime approaching the year dot on how the computing industry has managed to get into such a poor state, but it is a waste of time and resources. I'm with both of you on this one. Hmmm... After all... Mono do exist after a product from Microsoft... Correct. Why not just use cygwin and bung it onto the PDA after all? If people want to change this scenario, it's not only in the hands of the tool developers, it's also in the hands of the application developers. Yep. As we all know, anything written in C# and compiled using Mono will work correctly on a Windows box. All you need is a blatant advert on all Mono packages saying so - not that the end user will give a toss. Now guess what the end-user will choose... No. The end user uses the end product. They're not that interested in where it comes from. Case in point. Those who have used OpenOffice 2 often prefer it to MS Office 2003, yet those who buy the software for companies (etc) don't see the word MS and so avoid the far better alternative. Discuss. But you should feel free to contribute such port or to hire someone to do it. The same goes for a Symbian or RISC OS port. Well... I feel honored that you give me permission to contribute or *hire* someone to do it. Come on. There are a number of companies out there using and contributing to Mono. What is to say one (or more than one) don't turn around and say Hey you - here's a wad of money, now port Mono for platform_x? I'm personally more interested in hearing from people with access to devices like the nokia 770, ipaqs running linux etc. Good luck with that. Let me make one thing clear and straight: I didn't like your answer. I think we can tell! You deserve everyone's respect for your efforts in the open-source community, and that's it. I asked you a simple question, without offending anyone. If you can't control your idealisms and respect the others, well... Email me privately that I will answer you adequately. It's the old usenet idiom - you post here, you get a reply here. That is unless the reply is very specific (such as I've had in the past) As for this mailing-list, all I have to ask is sorry for this post. No further messages will be necessary in this thread. Oopsie. TTFN Paul -- Some people will do anything for a woman in uniform - The Doctor - Unregenerate (Big Finish audio) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] DateTime.Parse difference with .NET
Hello, El Tue, 09 Aug 2005 13:30:19 +0900 Atsushi Eno [EMAIL PROTECTED] escribió: Hello, [...] In fact using DateTime.Parse() is somewhat stupid ;-) Read here: http://msdn.microsoft.com/msdnmag/issues/05/03/CultureInfo/default .aspx?side=true#a The DateTime.Parse method in the Microsoft .NET Framework has goals much like its predecessors, but unfortunately it suffers from some of the same problems. The code is slower since the extra checking takes time, and there will always be some new format that is not properly detected. In those older products, you may remember, the behavior was sometimes disparagingly referred to as evil date parsing. At least DateTime.Parse() is COM dependent where the behavior is totally unpredictable and not countable from DateTimeFormatInfo. But in [1] we find that format string we need to specify as a valid format (see Globalization.DateTimeFormatInfo) it is unfinished :-S May be I lost something... what do you suggest to use instead of DateTime.Parse() or DateTime.ParseExact()? Alfredo. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] DateTime.Parse difference with .NET
Hi, Now that it turned out that the bug is not reproducible with the latest svn HEAD (i.e. the bug report is invalid)... Alfredo Jose Muela Romero wrote: Hello, El Tue, 09 Aug 2005 13:30:19 +0900 Atsushi Eno [EMAIL PROTECTED] escribió: Hello, [...] In fact using DateTime.Parse() is somewhat stupid ;-) Read here: http://msdn.microsoft.com/msdnmag/issues/05/03/CultureInfo/default .aspx?side=true#a The DateTime.Parse method in the Microsoft .NET Framework has goals much like its predecessors, but unfortunately it suffers from some of the same problems. The code is slower since the extra checking takes time, and there will always be some new format that is not properly detected. In those older products, you may remember, the behavior was sometimes disparagingly referred to as evil date parsing. At least DateTime.Parse() is COM dependent where the behavior is totally unpredictable and not countable from DateTimeFormatInfo. But in [1] we find that format string we need to specify as a valid format (see Globalization.DateTimeFormatInfo) it is unfinished :-S If we have corresponding format string, it is likely to work like this case. May be I lost something... what do you suggest to use instead of DateTime.Parse() or DateTime.ParseExact()? I don't understand why we need to find something instead of DateTime.ParseExact(). Just use it. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] DateTime.Parse difference with .NET
Hi, Alfredo Jose Muela Romero wrote: El Tue, 09 Aug 2005 19:01:32 +0900 Atsushi Eno [EMAIL PROTECTED] escribió: Hi, Now that it turned out that the bug is not reproducible with the latest svn HEAD (i.e. the bug report is invalid)... Which bug? Did I talk to any bug? :-S If I did so I didn't mean it, I just wanted to ask a doubt... I am talking along with the original topic i.e. bug #75749. Since you replied to this thread, it should be no wonder that I guess you are talking about it. Alfredo Jose Muela Romero wrote: Hello, El Tue, 09 Aug 2005 13:30:19 +0900 Atsushi Eno [EMAIL PROTECTED] escribió: Hello, [...] In fact using DateTime.Parse() is somewhat stupid ;-) Read here: http://msdn.microsoft.com/msdnmag/issues/05/03/CultureInfo/d efault .aspx?side=true#a The DateTime.Parse method in the Microsoft .NET Framework has goals much like its predecessors, but unfortunately it suffers from some of the same problems. The code is slower since the extra checking takes time, and there will always be some new format that is not properly detected. In those older products, you may remember, the behavior was sometimes disparagingly referred to as evil date parsing. At least DateTime.Parse() is COM dependent where the behavior is totally unpredictable and not countable from DateTimeFormatInfo. But in [1] we find that format string we need to specify as a valid format (see Globalization.DateTimeFormatInfo) it is unfinished :-S If we have corresponding format string, it is likely to work like this case. I guess I didn't understand the unfinished concept or your answer... In other words... even if there are unfinished members on a class, and consecuently the class is marked as unfinished, is still the class usable? (I thought I couldn't...) Originally there is no one who mentioned unfinished concept so I just ignored it (and [1] as well). What are they? What are you talking about? What are you asking about? May be I lost something... what do you suggest to use instead of DateTime.Parse() or DateTime.ParseExact()? I don't understand why we need to find something instead of DateTime.ParseExact(). Just use it. So, should I use a string specify for myself (such as dd/MM/ H:mm*:ss*) for the format? Yes, or alternatively use CultureInfo.DateTimeFormat.GetAllDateTimePatterns() or whatever. The fact that there is no decent alternative of DateTime.Parse() (that would consider only explicitly-defined date time format strings) is a problem in Microsoft.NET, not ours. (oh, yes we could provide alternative decent library if there is need though ;-) Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] DateTime.Parse difference with .NET
El Tue, 09 Aug 2005 20:13:09 +0900 Atsushi Eno [EMAIL PROTECTED] escribió: Hi, Alfredo Jose Muela Romero wrote: El Tue, 09 Aug 2005 19:01:32 +0900 Atsushi Eno [EMAIL PROTECTED] escribió: Hi, Now that it turned out that the bug is not reproducible with the latest svn HEAD (i.e. the bug report is invalid)... Which bug? Did I talk to any bug? :-S If I did so I didn't mean it, I just wanted to ask a doubt... I am talking along with the original topic i.e. bug #75749. Since you replied to this thread, it should be no wonder that I guess you are talking about it. Ok, correct. It was just that I hesitated about being understood. Alfredo Jose Muela Romero wrote: Hello, El Tue, 09 Aug 2005 13:30:19 +0900 Atsushi Eno [EMAIL PROTECTED] escribió: Hello, [...] In fact using DateTime.Parse() is somewhat stupid ;-) Read here: http://msdn.microsoft.com/msdnmag/issues/05/03/CultureInfo /d efault .aspx?side=true#a The DateTime.Parse method in the Microsoft .NET Framework has goals much like its predecessors, but unfortunately it suffers from some of the same problems. The code is slower since the extra checking takes time, and there will always be some new format that is not properly detected. In those older products, you may remember, the behavior was sometimes disparagingly referred to as evil date parsing. At least DateTime.Parse() is COM dependent where the behavior is totally unpredictable and not countable from DateTimeFormatInfo. But in [1] we find that format string we need to specify as a valid format (see Globalization.DateTimeFormatInfo) it is unfinished :-S If we have corresponding format string, it is likely to work like this case. I guess I didn't understand the unfinished concept or your answer... In other words... even if there are unfinished members on a class, and consecuently the class is marked as unfinished, is still the class usable? (I thought I couldn't...) Originally there is no one who mentioned unfinished concept so I just ignored it (and [1] as well). What are they? What are you talking about? What are you asking about? Sorry, I forgot to paste the link (Ooops 0_o), actually [1] meant to be: [1]http://www.go-mono.com/docs/index.aspx?link=T%3aSystem.Global ization.DateTimeFormatInfo I hope it would answer that questions... May be I lost something... what do you suggest to use instead of DateTime.Parse() or DateTime.ParseExact()? I don't understand why we need to find something instead of DateTime.ParseExact(). Just use it. So, should I use a string specify for myself (such as dd/MM/ H:mm*:ss*) for the format? Yes, or alternatively use CultureInfo.DateTimeFormat.GetAllDateTimePatterns() or whatever. Ok, got it. The fact that there is no decent alternative of DateTime.Parse() (that would consider only explicitly-defined date time format strings) is a problem in Microsoft.NET, not ours. (oh, yes we could provide alternative decent library if there is need though ;-) I see ^_^ Alfredo. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Re: [Mono-devel-list] USE_MMAP speed/time tradeoff
On Sun, 2005-08-07 at 00:14 +0200, Michal Moskal wrote: Also, Gonzalo was trying to work on the large file upload setup, which has better solutions (buffering to files, like is done in Whidbey). large file upload? I don't get it. When POSTing anything big to a ASP.NET page or web service, it has to be buffered. Someone filed a bug report saying that it used too much memory and the mmap patch made it behave *much* better. However, ASP.NET 2.0 has some feature to use a file on disk instead of keeping the whole buffer in memory and we might do this for 1.1 too. In this case, it would help if you provide a test that we can use to measure the slowdown. Based on that, the mmap option could be removed once the write-buffer-to-disk code is ready. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] not implemented destructor in FontNameConverter
As a temporary solution I committed TARGET_JVM so that this destructor will not be present in our build, but probably it's worth to do same for Mono, too. I wonder, what was the need to throw NotImplementedException in FontNameConverter destructor? What will do GC when destructor fails in such way? The code is in FontConverter.cs:283 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Re: [Mono-devel-list] Initial ARM JIT port in svn
Mr Paolo, I've demanded anything here?? Your message just showed the kind of person I'm dealing with. No need for comments. We'll continue in private and save the list from this things... Hugo Ferreira On 08/09/05 Paolo Molaro wrote: On 08/09/05 Hugo Ferreira wrote: Sure... Linux runs on every PDA out there I didn't say that, of course. Mr. Paolo, it seems that you've managed to pass your anger against microsoft in a single textual sentence. No problem... I'm also not Maybe you're projecting? Are you frustrated because you bought a PocketPC brick? If you can't deal with the technical meaning of usefulness in the context of mono, this list is not for you. I'm not angry at microsoft, if you are, I suggest you keep your complaints somewhere lese. very fond of it either. But, as it seems, when the market DO buy those PDAs, and when people ONLY use them, if you want to sell a product, you have to develop for that OS... There's no point in so much anger, is there? This isn't ideological discussion. It's a fact! If you want to sell a product, you're free to develop it and sell it. What you're not free to do without looking like a *censored*, is to demand that we develop the product for you. I'm not sure why you're so upset about this, there is no ideology involved, just the plain fact that I'm not interested in PocketPC: I have no use for such a device if it doesn't run Linux. If it's useful for you, do something about it instead of whining on the list. If people want to change this scenario, it's not only in the hands of the tool developers, it's also in the hands of the application developers. If they don't have an option, they choose for what they got... If when they get interested in alternatives, they got an answer like yours.. Well... I'm glad this isn't always the case... You got it backwards: PocketPC is not the alternative, it is just a different ring used to bound your nose. We are interested in the alternative, and that is Linux on PDAs. If you're interested in mono on PocketPC, write the code. Well... I feel honored that you give me permission to contribute or *hire* someone to do it. You don't need my permission, of course, I only mentioned it because someone may not get it. And it looks like this is news for you, so my suggestions was at least useful. Let me make one thing clear and straight: I didn't like your answer. Excellent, now why didn't you send a private email so that it can be easily discarded instead of annoying all the people on the list? community, and that's it. I asked you a simple question, without offending anyone. If you can't control your idealisms and respect the others, well... Dude, you're really frustrated, get a life. I'm sorry if you thought that by subscribing to this list you're entitled to a PocketPC port, a free dinner cooked directly at your home or anything else you might have imagined. I'll see if we can change the welcome message of the list to make it clearer. No further messages will be necessary in this thread. We're all relieved. Thanks. lupus ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Re: [Mono-devel-list] Initial ARM JIT port in svn
On 08/08/05 Paul F. Johnson wrote: The same goes for a Symbian or RISC OS port. Problem is that for RISC OS, they don't have dynamic linking support as yet (though the RISC OS gcc is getting there). There would also have to be a different layer between SWF and the desktop as it's not running X. Dynamic linking is not strictly required, mono uses it only for the optional external profilers and p/invoke. And if the platform doesn't have shared libraries p/invoke is not useful, so you have no excuses:-) Anyway, I really know nothing about risc os, I just know it still exists since it's installed in my arm box, so I though someone out there was still using it. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] not implemented destructor in FontNameConverter
Hello, I wonder, what was the need to throw NotImplementedException in FontNameConverter destructor? What will do GC when destructor fails in such way? The code is in FontConverter.cs:283 It seems like code that was originally just stubbed out and not completed. Thanks for pointing this out, I have removed the offending code. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Please revert your changes.
System.Runtime.InteropServices._CustomAttributeBuilder is missing form .NET
Framework 1.1 RTM but is in SP1 and is included with NET_1_1.
This is true for System.Web.HttpResponse.TransmitFile as well and it is
included in NET_1_1.
I think including serivce pack extensions in Mono is the best solution to
preserve .NET Framework compatibility.
But the _CustomAttributeBuilder stuff should be used only with NET_1_1.
Note that none of the interfaces starting with _ in
System.Runtime.InteropServices are present in the RTM version of 1.1 but are
in SP1. There may be other differences. So metadata comparsion should be
done on SP1 assemblies rather than on RTM.
Kornél
- Original Message -
From: Gert Driesen [EMAIL PROTECTED]
To: 'Miguel de Icaza' [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, August 09, 2005 11:21 PM
Subject: RE: [Mono-dev] Please revert your changes.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Miguel de Icaza
Sent: dinsdag 9 augustus 2005 19:33
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [Mono-dev] Please revert your changes.
Hello Gert,
The changes that you committed to Mono to add .NET 2.x signature
compatibility break the .NET 1.x signature compatibility.
I have not reviewed the entire patch in detail but I know that at
least things like this are wrong:
namespace System.Reflection.Emit {
#if NET_2_0
[ComVisible (true)]
[ComDefaultInterface (typeof (_CustomAttributeBuilder))]
#endif
[ClassInterface (ClassInterfaceType.None)]
public class CustomAttributeBuilder : _CustomAttributeBuilder {
ConstructorInfo ctor;
byte[] data;
The problem is that now on the 1.x profile you are
inheriting from
_CustomAttributeBuilder which did not exist in 1.x, and which
should not be exposed in the 1.x profile.
I don't recall if it existed in .NET 1.1, but it does exist in .NET 1.1
SP1.
Also the class status pages do not show that there's something wrong :
http://mono.ximian.com/class-status/mono-HEAD-vs-fx-1-1/class-status-mscorli
b.html
The interface should not exist, and it should not implement the
interface.
Until today I had assumed that you knew about this, but
given this
new tidbit of information, I think we must review every one of your
older patches and ensure that you have not broken the 1.x profile like
this.
Please fix this, or revert all of these changes.
Let me know what you want me to do.
Gert
___
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] Please revert your changes.
Hello Gert,
I don't recall if it existed in .NET 1.1, but it does exist in .NET 1.1 SP1.
I just installed .NET 1.1 SP1 (after much pain) and wrote a simple
program:
using System;
using System.Reflection.Emit;
class X {
static void Main ()
{
Type t = typeof (CustomAttributeBuilder);
Console.WriteLine (t.BaseType);
}
}
And it does not display anything. When compiled with csc 8, it does
display _CustomAttributeBuilder.
I have not been able to find a .NET 1.1 SP1 SDK, so I do not know if
there are any docs in there.
I am curious where you got the information that .NET 1.1 SP1 has these
changes, I do not seem to find them anywhere.
Also the class status pages do not show that there's something wrong :
http://mono.ximian.com/class-status/mono-HEAD-vs-fx-1-1/class-status-mscorli
b.html
That might be:
* A limitation on CorCompare
* The fact that the build that updates that page has not been
triggered (I forget which machine takes care of that, but
it is manually triggered during the day)
Miguel.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Please revert your changes.
Hi! Note that none of the interfaces starting with _ in System.Runtime.InteropServices are present in the RTM version of 1.1 but are in SP1. There may be other differences. So metadata comparsion should be done on SP1 assemblies rather than on RTM. I am very confused. What does `RTM' mean, and when I write a program that peeks at the interfaces (posted on the last message) why does it not show them up? RTM means 'Release To Manufacturing'. I think Kornél means the initial 'Gold' release, though technically a service pack will also RTM when it's finished... How would a developer link/develop against SP1 and have those run in RTM? You couldn't. I managed to find a document confirming that these interfaces were indeed introduced in .NET 1.1 SP1 : http://www.usysware.com/blog/?p=21 Microsoft's own documentation on MSDN2 says that these first appear in .NET 2.0, but I think they're just hiding that there isn't backwards API compatibility between .NET 1.1 SP1 and .NET SP1 Gold. In fact, trying to compile a program on a machine with SP1 installed that references System.Runtime.InteropServices._CustomAttributeBuilder results in an error. This is odd. Maybe the compiler is hiding the API changes somehow? Regards, Michael ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Please revert your changes.
Hello, You couldn't. I managed to find a document confirming that these interfaces were indeed introduced in .NET 1.1 SP1 : http://www.usysware.com/blog/?p=21 Microsoft's own documentation on MSDN2 says that these first appear in NET 2.0, but I think they're just hiding that there isn't backwards API compatibility between .NET 1.1 SP1 and .NET SP1 Gold. The guy is describing what he found on his GAC, but the compiler does not link against the GAC. The compiler links against the code in the directory where csc lives. The mscorlib in the csc directory is dated 2003, while the mscorlib directory in the GAC had today's date. So the exposed API to developer is one which guarantee that it will work on old (pre-SP1) systems. The difference in API is probably a trick used so that the masses keep targeting 1.1 by default, but some special customers or people who need extra features get the new API calls and fixes at their own risk. So at this point, am not sure what to do. We should do a CorCompare run between 1.1 and 1.1 SP1 and examine the extent of the damage and based on that make a decision about what we are going to do. I do not particularly feel excited about building 1.1 and 1.1SP1 assemblies. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [Patch] AssemblyName ctor
hey,
Currently the AssemblyName (string) ctor is not implemented to receive
the long format assembly name (such MyAssembly, Version=1.2,...). The
attached patch adds support for it.
Some tests are also attached.
Carlos.
Index: icall.c
===
--- icall.c (revisión: 48211)
+++ icall.c (copia de trabajo)
@@ -3730,6 +3730,44 @@
return result;
}
+static void
+ves_icall_System_Reflection_AssemblyName_InternalParseKeyToken (MonoReflectionAssemblyName *aname, MonoString *key_token)
+{
+ char *p, *token;
+ int i, j;
+
+ token = mono_string_to_utf8 (key_token);
+ aname-keyToken = mono_array_new (mono_domain_get (), mono_defaults.byte_class, 8);
+ p = mono_array_addr (aname-keyToken, char, 0);
+ for (i = 0, j = 0; i 8; i++) {
+ *p = g_ascii_xdigit_value (token [j++]) 4;
+ *p |= g_ascii_xdigit_value (token [j++]);
+ p++;
+ }
+
+ g_free (token);
+}
+
+static void
+ves_icall_System_Reflection_AssemblyName_InternalParseKey (MonoReflectionAssemblyName *aname, MonoString *public_key)
+{
+ char *p, *key;
+ int pkey_len, i, j;
+
+ key = mono_string_to_utf8 (public_key);
+ pkey_len = mono_string_length (public_key) / 2; // Format used in .Net
+
+ aname-publicKey = mono_array_new (mono_domain_get (), mono_defaults.byte_class, pkey_len);
+ p = mono_array_addr (aname-publicKey, char, 0);
+ for (i = 0, j = 0; i pkey_len; i++) {
+ *p = g_ascii_xdigit_value (key [j++]) 4;
+ *p |= g_ascii_xdigit_value (key [j++]);
+ p++;
+ }
+
+ g_free (key);
+}
+
typedef struct {
MonoArray *res;
int idx;
@@ -6510,6 +6548,11 @@
{load_with_partial_name, ves_icall_System_Reflection_Assembly_load_with_partial_name}
};
+static const IcallEntry assembly_name_icalls [] = {
+ {InternalParseKey, ves_icall_System_Reflection_AssemblyName_InternalParseKey},
+ {InternalParseKeyToken, ves_icall_System_Reflection_AssemblyName_InternalParseKeyToken}
+};
+
static const IcallEntry methodbase_icalls [] = {
{GetCurrentMethod, ves_icall_GetCurrentMethod},
{GetMethodBodyInternal, ves_icall_System_Reflection_MethodBase_GetMethodBodyInternal},
@@ -7046,6 +7089,7 @@
{System.Net.Sockets.SocketException, socketex_icalls, G_N_ELEMENTS (socketex_icalls)},
{System.Object, object_icalls, G_N_ELEMENTS (object_icalls)},
{System.Reflection.Assembly, assembly_icalls, G_N_ELEMENTS (assembly_icalls)},
+ {System.Reflection.AssemblyName, assembly_name_icalls, G_N_ELEMENTS (assembly_name_icalls)},
{System.Reflection.Emit.AssemblyBuilder, assemblybuilder_icalls, G_N_ELEMENTS (assemblybuilder_icalls)},
{System.Reflection.Emit.CustomAttributeBuilder, customattrbuilder_icalls, G_N_ELEMENTS (customattrbuilder_icalls)},
{System.Reflection.Emit.DynamicMethod, dynamicmethod_icalls, G_N_ELEMENTS (dynamicmethod_icalls)},
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [Patch] AssemblyName ctor (correction)
In the last message some attachments were missing.
All of them are now correctly attached.
Index: AssemblyName.cs
===
--- AssemblyName.cs (revisión: 48211)
+++ AssemblyName.cs (copia de trabajo)
@@ -37,6 +37,7 @@
using System.Text;
using System.Runtime.InteropServices;
using System.Runtime.CompilerServices;
+using System.IO;
using Mono.Security;
@@ -73,6 +74,7 @@
int processor_architecture;
#endif
#endregion
+ static readonly char [] delimiter = {','};
public AssemblyName ()
{
@@ -83,9 +85,64 @@
#if NET_2_0
public AssemblyName (string assemblyName)
{
- name = assemblyName;
+ string [] parts;
+
+ if (assemblyName == null)
+throw new ArgumentNullException (assemblyName);
+ if (assemblyName == )
+throw new ArgumentException (assemblyName cannot have zero length, assemblyName);
+
+ // Remove white spaces, to mimic .Net behavior
+ assemblyName = assemblyName.Replace ( , );
+ parts = assemblyName.Split (delimiter);
+ if (parts [0] == )
+throw new FileLoadException (The assembly name is invalid.);
+
+ name = parts [0];
+ for (int i = 0; i parts.Length; i++) {
+try {
+ if (String.Compare (parts [i], 0, Version=, 0, 8, true, CultureInfo.InvariantCulture) == 0)
+ version = new Version (parts [i].Substring (8, parts [i].Length - 8));
+ else if (String.Compare (parts [i], 0, Culture=, 0, 8, true, CultureInfo.InvariantCulture) == 0) {
+ string culture = parts [i].Substring (8, parts [i].Length - 8);
+ if (String.Compare (culture, neutral, true, CultureInfo.InvariantCulture) == 0)
+ culture = ;
+ cultureinfo = new CultureInfo (culture);
+ }
+ else if (String.Compare (parts [i], 0, PublicKeyToken=, 0, 15, true, CultureInfo.InvariantCulture) == 0)
+ ParseKeyToken (parts [i].Substring (15, parts [i].Length - 15));
+ else if (String.Compare (parts [i], 0, PublicKey=, 0, 10, true, CultureInfo.InvariantCulture) == 0)
+ ParseKey (parts [i].Substring (10, parts [i].Length - 10));
+} catch {
+ throw new FileLoadException (The assembly name is invalid.);
+}
+ }
+
}
+ [MethodImpl (MethodImplOptions.InternalCall)]
+ extern void InternalParseKeyToken (string keyToken);
+
+ void ParseKeyToken (string kToken)
+ {
+ if (kToken.Length != 16)
+throw new Exception ();
+
+ InternalParseKeyToken (kToken);
+ }
+
+ [MethodImpl (MethodImplOptions.InternalCall)]
+ extern void InternalParseKey (string key);
+
+ void ParseKey (string key)
+ {
+ if (key.Length != 320)
+throw new Exception ();
+
+ flags = AssemblyNameFlags.PublicKey;
+ InternalParseKey (key);
+ }
+
[MonoTODO]
public ProcessorArchitecture ProcessorArchitecture {
get {
Index: AssemblyNameTest.cs
===
--- AssemblyNameTest.cs (revisión: 48211)
+++ AssemblyNameTest.cs (copia de trabajo)
@@ -19,6 +19,7 @@
using System.Globalization;
using System.Runtime.Serialization.Formatters.Binary;
using System.Security;
+using System.Text;
namespace MonoTests.System.Reflection {
@@ -531,6 +532,73 @@
}
return tokenString;
}
+
+#if NET_2_0
+ [Test]
+ public void Ctor1 ()
+ {
+ const string assemblyName = TestAssembly;
+ AssemblyName an = new AssemblyName (assemblyName);
+ Assert.IsNotNull (an.Name, Ctor1#1);
+ Assert.AreEqual (an.Name, assemblyName, Ctor1#2);
+ }
+
+ [Test]
+ public void Ctor2 ()
+ {
+ const string assemblyName = TestAssembly;
+ const string assemblyVersion = 1.2;
+ AssemblyName an = new AssemblyName (assemblyName + , Version= + assemblyVersion);
+ Assert.IsNotNull (an.Name, Ctor2#1);
+ Assert.AreEqual (an.Name, assemblyName, Ctor2#2);
+ Assert.IsNotNull (an.Version, Ctor2#3);
+ Assert.AreEqual (an.Version, new Version (assemblyVersion), Ctor2#4);
+ }
+
+ [Test]
+ public void Ctor3 ()
+ {
+ const string assemblyName = TestAssembly;
+ const string assemblyCulture = en-US;
+ AssemblyName an = new AssemblyName (assemblyName + , Culture= + assemblyCulture);
+ Assert.IsNotNull (an.Name, Ctor3#1);
+ Assert.AreEqual (an.Name, assemblyName, Ctor3#2);
+ Assert.IsNotNull (an.CultureInfo, Ctor3#3);
+ Assert.AreEqual (an.CultureInfo, new CultureInfo (assemblyCulture), Ctor3#4);
+ }
+
+ [Test]
+ public void Ctor4 ()
+ {
+ const string assemblyName = TestAssembly;
+ byte [] assemblyKeyToken;
+ AssemblyName an = new AssemblyName (assemblyName + , PublicKeyToken= + GetTokenString (token));
+ Assert.IsNotNull (an.Name, Ctor4#1);
+ Assert.AreEqual (an.Name, assemblyName, Ctor4#2);
+ Assert.IsNotNull (assemblyKeyToken = an.GetPublicKeyToken (), Ctor4#3);
+ Assert.AreEqual (assemblyKeyToken, token, Ctor4#4);
+ }
+
+ [Test]
+ public void Ctor5 ()
+ {
+ const string assemblyName = TestAssembly;
+ const string assemblyCulture = neutral;
+ const string assemblyVersion = 1.2.3.4;
+ byte [] assemblyKeyToken;
+
+ AssemblyName an = new
RE: [Mono-dev] Please revert your changes.
Miguel de Icaza wrote: Type t = typeof (CustomAttributeBuilder); Console.WriteLine (t.BaseType); And it does not display anything. When compiled with csc 8, it does display _CustomAttributeBuilder. Huh? _CustomAttributeBuilder is an interface, so it obviously won't show up with the above code (not on csc 8 either) and it definitely exists in .NET 1.1 SP1. Regards, Jeroen ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] Please revert your changes.
Hello,
Type t = typeof (CustomAttributeBuilder);
Console.WriteLine (t.BaseType);
And it does not display anything. When compiled with csc 8, it does
display _CustomAttributeBuilder.
Huh? _CustomAttributeBuilder is an interface, so it obviously won't show
up with the above code (not on csc 8 either) and it definitely exists in
NET 1.1 SP1.
Sorry, I posted the wrong code snipped.
My other piece of code (now at work) calls:
foreach (Type t in typeof (CustomAttributeBuilder).GetInterfaces()){
}
And that code does not display _CustomAttributeBuilder.
And typeof(_CustomAttributeBuilder) fails to build.
Miguel.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
