Re: [Mono-devel-list] Patch idea for previous message
Hi Eno, The CompareOrdinal does not have a case insensitive overload. So you cannot use it instead of string.Compare(s1,s2,true). Regards, Konstantin Triger Atsushi Eno wrote: Hi, This is offtopic (I've replied for the main story yet), but +if (string.Compare(attribute, value, true) == 0) +return; you'd like to be careful to use String.Compare() since it is culture-sensitive comparison by default. In that case, CompareOrdinal() leads you to the right way. We don't use collation now but it will be supported in the near future (I hope ;-) Maybe I need to audit those culture-sensitive things on all the libraries, including sys.xml (I once did in response to Jackson's advisory but I think we need further check). Atsushi Eno ___ 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] [BUG][PATCH] Setting TcpClient.NoDelay to true causes
Bug report and patch against Mono from SVN trunk (revision 45561).
Setting TcpClient.NoDelay to true causes an exception in the 1.0 branch:
Use an integer 1 (true) or 0 (false) instead of a boolean.
Parameter name: opt_value
in 0x000f1 System.Net.Sockets.Socket:SetSocketOption
(SocketOptionLevel level, SocketOptionName name, System.Object opt_value)
in 0x0002a System.Net.Sockets.TcpClient:set_NoDelay (Boolean value)
[...]
Attached patch fixes this problem.
Best regards,
Hans
--
Hans Kratz
Omnicore Software
http://www.omnicore.com
Index: class/System/System.Net.Sockets/TcpClient.cs
===
--- class/System/System.Net.Sockets/TcpClient.cs (revision 45562)
+++ class/System/System.Net.Sockets/TcpClient.cs (working copy)
@@ -181,7 +181,7 @@
set {
client.SetSocketOption(
SocketOptionLevel.Tcp,
- SocketOptionName.NoDelay, value);
+ SocketOptionName.NoDelay, value ? 1 : 0);
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Patch idea for previous message
From: Konstantin Triger The CompareOrdinal does not have a case insensitive overload. So you cannot use it instead of string.Compare(s1,s2,true). From: Atsushi Eno you'd like to be careful to use String.Compare() since it is culture-sensitive comparison by default. In that case, CompareOrdinal() leads you to the right way. Any method that is culture-sensitive can take CultureInfo.InvariantCulture as a formatter, comparer, ..., at this will make it culture-insensitive as InvariantCulture should have the same characterisitcs across all versions and even in different runtimes. Use string.Compare(s1,s2,true,CultureInfo.InvariantCulture) for example. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Patch idea for previous message
Yeah, I knew. However what I meant is String.CompareOrdinal ( s1.ToLower (invariantCulture), s2.ToLower (invariantCulture)) It is not good for performance but safe. Atsushi Eno Konstantin Triger wrote: Hi Eno, The CompareOrdinal does not have a case insensitive overload. So you cannot use it instead of string.Compare(s1,s2,true). Regards, Konstantin Triger Atsushi Eno wrote: Hi, This is offtopic (I've replied for the main story yet), but +if (string.Compare(attribute, value, true) == 0) +return; you'd like to be careful to use String.Compare() since it is culture-sensitive comparison by default. In that case, CompareOrdinal() leads you to the right way. We don't use collation now but it will be supported in the near future (I hope ;-) Maybe I need to audit those culture-sensitive things on all the libraries, including sys.xml (I once did in response to Jackson's advisory but I think we need further check). Atsushi Eno ___ 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-devel-list] Patch idea for previous message
Hi, Any method that is culture-sensitive can take CultureInfo.InvariantCulture as a formatter, comparer, ..., at this will make it culture-insensitive as InvariantCulture should have the same characterisitcs across all versions and even in different runtimes. Use string.Compare(s1,s2,true,CultureInfo.InvariantCulture) for example. No, you aren't aware of the whole problem. String comparison with invariant culture does not mean that it has no other side effect than case insensitivity. With CultureInfo dependent (including InvariantCulture) there are some characters that are ignored in the comparison (and sometimes culture-sensitive comparison is buggy, at least with MS.NET) or regarded equivalent to other character sequences. Try Console.WriteLine (String.Compare (\u00C6, AE, true, CultureInfo.InvariantCulture)); under MS.NET. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Line numbers in stacktraces are off by one
Hi!
I just implemented support for hyperlinking Mono exception stacktraces
in X-develop and noticed that line numbers in stacktraces are off by one.
E.g. for the following program...
---
class Program
{
static void Main(string[] args)
{
string s = null;
int i = s.Length; // line 6
} // line 7
}
---
... I get this stacktrace
$ mono --debug ConsoleApplication45.exe
Unhandled Exception: System.NullReferenceException: Object reference not
set to an instance of an object
in [0x3] (at /home/hans/[...]/Program.cs:7) Program:Main
(System.String[] args)
Is this intentional?
Best regards,
Hans
--
Hans Kratz
Omnicore Software
http://www.omnicore.com
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Line numbers in stacktraces are off by one
Hi,
I was (well, I should say am) working on that matter (aka
precise location patch) but currently it is not done yet.
I created mcs patch 6 months ago and mcs has greatly improved,
it is not impossible to merge directly (and not successful).
I hope I can fix the patch and repost again in the near future.
Atsushi Eno
Hans Kratz wrote:
Hi!
I just implemented support for hyperlinking Mono exception stacktraces
in X-develop and noticed that line numbers in stacktraces are off by one.
E.g. for the following program...
---
class Program
{
static void Main(string[] args)
{
string s = null;
int i = s.Length; // line 6
} // line 7
}
---
... I get this stacktrace
$ mono --debug ConsoleApplication45.exe
Unhandled Exception: System.NullReferenceException: Object reference not
set to an instance of an object
in [0x3] (at /home/hans/[...]/Program.cs:7) Program:Main
(System.String[] args)
Is this intentional?
Best regards,
Hans
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Line numbers in stacktraces are off by one
Hi! Atsushi Eno wrote: I was (well, I should say am) working on that matter (aka precise location patch) but currently it is not done yet. I created mcs patch 6 months ago and mcs has greatly improved, it is not impossible to merge directly (and not successful). I hope I can fix the patch and repost again in the near future. Great! While you are at can you make sure that statements have line and column information in the Dwarf files? This way we can implement fine-grained statement stepping and do not have to rely on line-based stepping. Best regards, Hans -- Hans Kratz Omnicore Software http://www.omnicore.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Line numbers in stacktraces are off by one
Hello, Hans Kratz wrote: Hi! Atsushi Eno wrote: I was (well, I should say am) working on that matter (aka precise location patch) but currently it is not done yet. I created mcs patch 6 months ago and mcs has greatly improved, it is not impossible to merge directly (and not successful). I hope I can fix the patch and repost again in the near future. Great! While you are at can you make sure that statements have line and column information in the Dwarf files? This way we can implement fine-grained statement stepping and do not have to rely on line-based stepping. Well, sadly to say, what I have done was (well, is) just to fix incorrect location information in mcs. I have no further idea on writing debug information in different format like dwarf. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Patch idea for previous message
Atsushi Eno wrote: Hi, String comparison with invariant culture does not mean that it has no other side effect than case insensitivity. With CultureInfo dependent (including InvariantCulture) there are some characters that are ignored in the comparison (and sometimes culture-sensitive comparison is buggy, at least with MS.NET) or regarded equivalent to other character sequences. It's true but I don't treat this as a bug I think it is the expected behaviour. From String.Compare documentation in .NET Framework SDK: Well, I don't think that regarding AE and \u006C as equivalent is a bug. What I have in mind is other cases such as String.Compare (\u00E6\u0304, \u01E3) Oops, I mean String.Compare (A\u0308\u0301, \u1EA6) . Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Trace at will
On Sun, 2005-06-05 at 12:23 +0200, Bill Middleton wrote: There's a mention in libgc/include/private/gc_priv.h about USR2 already being used by linuxthreads when SIG_SUSPEND is redefined as SIGPWR. I have no idea if thats relevant anymore, though. I recall this only because FreeBSD had a problem with USR2 and USR2 that had to be changed there in libgc in the previous release. AFAIK this still happens on systems which only have limited signals (like FreeBSD). Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: Spam: Re: [Mono-devel-list] minor xslttest makefile patch
Hi Andrew, Andrew Skiba wrote: Atsushi Eno wrote: Well, it is not analysis ;) Any progress or difficulty on fixage? The old testsuite reported some regressions when .net throws an exception. I think, we can ignore them for now. Are they really such testcases? I think those tests listed up there are bug in your sed script. The previous catalog.xml which I manually edited was pointing to the correct file names. Just compare old catalog.xml and your catalog-fixed.xml. XSLTFunctions_RoundTripNumber_UsingStringFn ... As for XSLTFunctions_RoundTripNumber_UsingStringFn, there seems different behavior on decimal roundtrip formatting. I remember (and have) your patch for that case, which is sadly still not working. I'll dig into it later. Here we have 3 choices: commit it to mono, make it TARGET_JVM or add the test to knownFailures. Probably I'm not the right person to decide between the last 2, and the first depends on you. If the patched version works fine, then let's just check it in w/ TARGET_JVM with comments. Here is the related part of the spec I think: The html output method should output boolean attributes (that is attributes with only a single allowed value that is equal to the name of the attribute) in minimized form. I notice only a single allowed value - so value of selected=foo is not allowed. What you want to do in such case? Silently ignore the value (as you did), output it when it's different from the usual (as MS does) or throw an exception? I think that I will agree to any solution. I did my investigation before I saw your patch. Well, the type of an attribute does not vary depending on the value string (well, am sure that this is true to XML but not sure when it comes to HTML so correct me if it sounds wrong). So selected attribute is always boolean. Note that it does not say boolean attribute value. And even in case of invalid value in HTML specification, XSLT specification does not require the implementation to raise an error. So, not throwing an error and just minimizing the value is what I thought best conformance. Besides the specification I tend to agree your idea to fix it. It sometimes might happen to keep those not-allowed value for some kind of post-processing on users side, and eliminating such values will slightly make sense (unless there is extremely- strict HTML implementation). Regarding the off-topic discussion on string comparison, we always compare with 2 pre-defined english words - is culture info relevant in such cases? Am not sure what you mean pre-defined english words, but as I wrote to Kornél, String.Compare() is culture dependent (unless you use CompareOptions.Ordinal). We have also some Xalan tests regressed, if you are interested to analyse them, too, I would appretiate. Let's put it on our table :-) Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: Spam: Re: [Mono-devel-list] minor xslttest makefile patch
Atsushi Eno wrote: Are they really such testcases? I think those tests listed up there are bug in your sed script. The previous catalog.xml which I manually edited was pointing to the correct file names. Just compare old catalog.xml and your catalog-fixed.xml. Can you tell me exactly what did you fix by hand? As for the first question, here is the list of tests that throw exception on dotnet and were marked as regressions in the first list. BVTs_bvt083 ConflictResolution__77902 Include__77736 Include_Include_IncludedStylesheetShouldHaveDifferentBaseUri Include_RelUriTest1 And there are few testcases that are not catched by the current testsuite, probably should check them manually (may be they really pass?) Elements__89171 Elements__89177 Output__84011 Text__78309 If the patched version works fine, then let's just check it in w/ TARGET_JVM with comments. Let's decide about that later, OK? Besides the specification I tend to agree your idea to fix it. Good. Am not sure what you mean pre-defined english words, Currently we have only 2: selected checked and may be we should have few others, like disabled readonly multiple ismap that's what I can easily find, surely there are others. We have also some Xalan tests regressed, if you are interested to ... Let's put it on our table :-) copy_copy21 math_math111 message_message01 numberformat_numberformat30 numberformat_numberformat35 string_string132 string_string133 Andrew. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: Spam: Re: [Mono-devel-list] minor xslttest makefile patch
Hello, Andrew Skiba wrote: Atsushi Eno wrote: Are they really such testcases? I think those tests listed up there are bug in your sed script. The previous catalog.xml which I manually edited was pointing to the correct file names. Just compare old catalog.xml and your catalog-fixed.xml. Can you tell me exactly what did you fix by hand? As for the first question, here is the list of tests that throw exception on dotnet and were marked as regressions in the first list. As for your request, with these simple steps below you can find what is missing in your catalog.sed (as well as what I missed): wget http://svn.myrealbox.com/viewcvs/*checkout*/trunk/mcs/class/System.XML/Test/System.Xml.Xsl/standalone_tests/catalog.diff?rev=40689 mv [EMAIL PROTECTED] old-catalog.diff patch catalog.xml old-catalog.diff -o catalog-correct.xml diff catalog-correct.xml catalog-fixed.xml As for regression matter ... I guess originally you might have done the original test run under Windows, and run on Unix environment today. But it will apparently show the difference. I have no further idea why they look like regressions. They must have originally failed under Unixy environment. BVTs_bvt083 Please re-read my first reply. This is not the missing-file case. ConflictResolution__77902 Well, this actually is an error in the stylesheet (includes xslt09009a.xsl while there is only XSLT09009a.xsl). So this testcase is invalid. Since on Windows file names are case insensitice, MS.NET will pass this testcase. Anyways this is not Mono's regression and should be ignored instead. Include__77736 There is no xslt03022.xsl. There is only XSLT03022.xsl. Include_Include_IncludedStylesheetShouldHaveDifferentBaseUri Similar to ConflictResolution__77902 there is no TestInc directory (and even worse the path includes backslash). Should be ignored as well. Include_RelUriTest1 Ditto. No include directory. And there are few testcases that are not catched by the current testsuite, probably should check them manually (may be they really pass?) Elements__89171 Elements__89177 They are the case: no Plants.xml but plants.xml. Output__84011 No OutputText.xml but Outputtext.xml. Text__78309 No XSLT05001.xml but xslt05001.xml. Currently we have only 2: selected checked Ahh, gotcha. Yeah let's add those you listed up as well. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Regarding blocking Read operation
Hi All, I am facing some problem with the read operations being blocking. I am launching a process and and have redirected the output/error streams. Then using the Read method of the StreamReader class, I read from the redirected output/error streams of the process. If there is no data coming in either of these streams, then the Read method blocks and does not return. As I understand from the documentation, ReadBlock is the blocking version of Read method. However, when there is no data in a stream then the Read operation is also blocking. Is there any other way to do a non blocking read opeartion? Thanks in Advance, Taru ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Fwd: Re: Spam: Re: [Mono-devel-list] minor xslttest makefile patch]
Atsushi Eno wrote: insensitice, MS.NET will pass this testcase. Anyways this is not Mono's regression and should be ignored instead. That's what I said ;-) The old testsuite reported some regressions when .net throws an exception. I think, we can ignore them for now. Ahh, gotcha. Yeah let's add those you listed up as well. Just notice that some attributes can appear in different elements, for example disabled, so check all valid elements. I saw HTML SGML DTD in some place, may be you can use it as a reference. Cheers, Andrew. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] [PATCH][RFC] debugger: 32 bit address bug
Hi! Addresses are communicated from the Mono VM as a platform-specific pointer, however Mono.Debugger.TargetBinaryReader.PeekAddress() and ReadAddress() read the pointer as a 32 bit *signed* int on 32 bit architectures and return a sign-extended 64 bit signed int. This causes problems if the communicated address is 2**31 which is frequently the case. When that happens the debugger library is for example unable to find the containing method correctly given a program location. Attached patch fixes this by reading a 32 bit uint from the Mono VM instead. However I think all the APIs should be sanitized to use 64 bit *unsigned* longs (ulongs) for addresses as well, using signed longs does not make much sense. Best regards, Hans -- Hans Kratz Omnicore Software http://www.omnicore.com Index: classes/TargetBinaryReader.cs === --- classes/TargetBinaryReader.cs (revision 45562) +++ classes/TargetBinaryReader.cs (working copy) @@ -147,7 +147,7 @@ if (AddressSize == 8) return PeekInt64 (pos); else -return PeekInt32 (pos); +return PeekUInt32 (pos); } public long PeekAddress () @@ -160,7 +160,7 @@ if (AddressSize == 8) return ReadInt64 (); else -return ReadInt32 (); +return ReadUInt32 (); } public string PeekString (long pos) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Removing depreciated code from svn
On Tue, 2005-06-07 at 12:15 +0200, Martin Baulig wrote: On Mon, 2005-06-06 at 12:22 -0400, Ben Maurer wrote: I'd like to suggest that we move some depreciated and otherwise dead-end code to trunk/old-code Hello, given the fact that SVN is a revision management tool (and as such lets you go back in history), what's the purpose of moving all the crap into a new module ? Let's just SVN remove that stuff. I like the idea of having an old-code module, but let's only keep valuable things in there, not something like nant. It's actually quite hard to retrieve something that was deleted. You have to find the rev in which it was deleted (basically, you need to svn log the whole module [!!!]), and then check that out. Chances are, nobody ever wants to see nant again. However since there is essentially 0 cost (space wise) to keep it, I see no reason not to. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] System.DirectoryServices - implementing default LDAP root functionality
Hello all .NET framework System.DirectoryServices classes provide an ability for user to omit the specification of the LDAP server he wants to connect to and use a default server (actually, default root dsn also) that exists somewhere on the network. It seems that they try to retrieve rootDSE information from the domain server. My proposal for providing the ability for querying rootDSE in our implementation is to enable user to specify his default server name at config level (both machine.config and override in app.config). The section should look like the following : configuration configSections sectionGroup name=System.DirectoryServices section name=Settings type=System.Configuration.NameValueSectionHandler/ /sectionGroup /configSections System.DirectoryServices Settings add key=servername value=server name/ add key=port value=389/ /Settings /System.DirectoryServices /configuration The implementation will retrieve this information if server information was not provided in user code, cache and use it as a default. Boris -- Boris Kirzner Mainsoft Corporation http://www.mainsoft.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] HttpSoap and HttpSoap12 may be removed as well
El dl 06 de 06 del 2005 a les 15:27 +0200, en/na Kornl Pl va escriure: Hi, I think the modified lines can be excluded as well when the cofiguration disallows using these types. If doing this has some side effects please let me know. There shouldn't be any side effect other than generating a wrong wsdl document. So if you have checked that the wsdl is properly generated when HttpSoap is disabled, please commit. Lluis. Kornl ___ 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] MONO_TRACE
Hi there. I just realized that MONO_TRACE environment variable was being used by both the runtime and the System.Diagnostics.DefaultTraceListener. From r45591 on, DefaultTraceListener uses MONO_TRACE_LISTENER and MONO_TRACE is for runtime level call trace. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] HttpSoap and HttpSoap12 may beremoved as well
There shouldn't be any side effect other than generating a wrong wsdl document. So if you have checked that the wsdl is properly generated when HttpSoap is disabled, please commit. There is some difference in Mono and MS.NET implementation when no protocol is enabled (Documentation was enabled). I have tried DefaultWsdlHelpGenerator.aspx in MS.NET and Monos' DefaultWsdlHelpGenerator.aspx in Mono the MS.NET's DefaultWsdlHelpGenerator.aspx in Mono. On MS.NET the service itself can be reflected but it appears as a service without methods. On Mono ServiceDescriptionCollection is empty and thus exception occurs. So I do not commit this patch yet. Some other parts of reflection has to be modified to can provide the same behaviour that MS.NET has when there are no protocols enabled. Kornl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] [Patch] Define Version for AssemblyBuilder
Hi,
Currently when an AssemblyBuilder is created, and then its AssemblyName
is retrieved, the Version is always returned as 0.0.0.0, even when it -
the Version- was defined.
The attached patch defines it, and also minor changes to the tests are
attached.
Carlos.
Index: reflection.c
===
--- reflection.c (revisin: 45600)
+++ reflection.c (copia de trabajo)
@@ -4334,6 +4334,22 @@
else
assembly-assembly.aname.culture = g_strdup ();
+if (assemblyb-version) {
+char **version = g_strsplit (mono_string_to_utf8 (assemblyb-version), ., 4);
+char **parts = version;
+assembly-assembly.aname.major = atoi (*parts++);
+assembly-assembly.aname.minor = atoi (*parts++);
+assembly-assembly.aname.build = *parts != NULL ? atoi (*parts++) : 0;
+assembly-assembly.aname.revision = *parts != NULL ? atoi (*parts) : 0;
+
+g_strfreev (version);
+} else {
+assembly-assembly.aname.major = 0;
+assembly-assembly.aname.minor = 0;
+assembly-assembly.aname.build = 0;
+assembly-assembly.aname.revision = 0;
+}
+
assembly-run = assemblyb-access != 2;
assembly-save = assemblyb-access != 1;
Index: ChangeLog
===
--- ChangeLog (revisin: 45600)
+++ ChangeLog (copia de trabajo)
@@ -1,4 +1,8 @@
+2005-06-07 Carlos Alberto Cortez [EMAIL PROTECTED]
+ * reflection.c (mono_image_basic_init): Define
+ Version in MonoDynamicAssembly.
+
2005-06-06 Michael Meeks [EMAIL PROTECTED]
* object.c (extend_interface_array): fix really silly
Index: AssemblyNameTest.cs
===
--- AssemblyNameTest.cs (revisin: 45568)
+++ AssemblyNameTest.cs (copia de trabajo)
@@ -283,6 +283,15 @@
return Assembly.LoadFrom (Path.Combine (tempDir, name.Name + .dll));
}
+ private AssemblyBuilder GenerateDynamicAssembly (AssemblyName name)
+ {
+ AssemblyBuilder ab = domain.DefineDynamicAssembly (
+name,
+AssemblyBuilderAccess.Run);
+
+ return ab;
+ }
+
[Test]
public void TestCultureInfo ()
{
@@ -302,17 +311,26 @@
Assembly a = GenerateAssembly (name);
Assert.AreEqual (1.2.3.4, a.GetName ().Version.ToString ());
+ AssemblyBuilder ab = GenerateDynamicAssembly (name);
+ Assert.AreEqual (1.2.3.4, ab.GetName ().Version.ToString ());
+
name = GenAssemblyName ();
name.Version = new Version (1, 2, 3);
a = GenerateAssembly (name);
Assert.AreEqual (1.2.3.0, a.GetName ().Version.ToString ());
+ ab = GenerateDynamicAssembly (name);
+ Assert.AreEqual (1.2.3.0, ab.GetName ().Version.ToString ());
+
name = GenAssemblyName ();
name.Version = new Version (1, 2);
a = GenerateAssembly (name);
Assert.AreEqual (1.2.0.0, a.GetName ().Version.ToString ());
+
+ ab = GenerateDynamicAssembly (name);
+ Assert.AreEqual (1.2.0.0, ab.GetName ().Version.ToString ());
}
[Test]
Index: ChangeLog
===
--- ChangeLog (revisin: 45568)
+++ ChangeLog (copia de trabajo)
@@ -1,3 +1,9 @@
+2005-06-07 Carlos Alberto Cortez [EMAIL PROTECTED]
+
+ * AssemblyNameTest.cs: Added tests to Version method,
+ in order to do additional checks with AssemblyBuilder
+ version.
+
2005-06-07 Gonzalo Paniagua Javier [EMAIL PROTECTED]
* AssemblyTest.cs: put back GetEntryAssembly, but this one is working.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Patch idea for previous message
Hi, Kornél Pál wrote: String.Compare (\u00E6\u0304, \u01E3) .NET 1.1 returns -1 BTW \u01E3.Normalize(NormalizationForm.NFD) is \u00E6\u0304 in .NET 2.0 i.e. they are canonically equivalent. Oops, I mean String.Compare (A\u0308\u0301, \u1EA6) . .NET 1.1 returns 0 I have no idea whether these characters exists in real life. Collations should be based on the rules of an existing languge and it's quite undefined how characters not in the language should be sorted. I think this function is intended to sorting human readable text and not to match case insensitive file names, user names, element and attribute names, ... And this is why OrdinalIgnoreCase was introduced in .NET 2.0 Windows XP displays A\u0308\u0301 as a compound charcter and a separated accent but both A\u0308 and A\u0301 display a single compund character so this may not be a bug but I'm not experienced in Unicode enough to tell whether Windows XP should display A\u0308\u0301 as a single compound character or .NET should not treat it as a single character. And of course it is possible that both of these things are allowed by Unicode. Note that culture sensitive comparison never means that it can treat a pair of strings as equal where one (or both) of them is not real string in the culture, unless any characters in the string is ignorable. You will get different result if \u0301 is \u0302. It happens because Windows has no concept of blocking combining marks and which just sums diacritical weights up ignoring overflow. It is design failure of Windows. Am going to introduce that crappy comparison into mono though :-/ You can check that java.text.Collator in JDK never regards them as equal. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
