Re: [Mono-dev] [PATCH] Warning and errors for InternalsVisibleAttr
Hey guys, Any news? I think this small patch can go in gmcs, since nobody commented on the posibility of having it on mcs. Carlos. El vie, 14-10-2005 a las 09:08 +0100, Marek Safar escribió: Hello, The attached patch checks the validity of InternalsVisibleToAttribute, and reports and warnings depending on the contents. May I commit? - no test for CS1700. - please use syntax `blabla' for error/warning arguments. + if (a.Type == TypeManager.internals_visible_attr_type) + if (!CheckInternalsVisibleAttribute (a)) + return; + ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Extern alias patch (latest modifications)
Hi,
Carlos Alberto Cortez [EMAIL PROTECTED] writes:
Hey, all the remainign issues are fixed now. All my tests are running
fine and that repeated code has been refactored to report the remaining
warnings in the same place.
The patch is attached, and I'm not attaching the tests this time, since
they remain the same.
Looks good to me. Some minor nits:
[snip]
/// summary
/// Computes the namespaces that we import from the assemblies we
reference.
/// /summary
public static void ComputeNamespaces ()
{
- MethodInfo assembly_get_namespaces = typeof
(Assembly).GetMethod (GetNamespaces,
BindingFlags.Instance|BindingFlags.NonPublic);
+ foreach (Assembly assembly in assemblies)
+ GlobalRootNamespace.Global.AddAssemblyReference
(assembly);
For some reason, I feel this is better spelled as RootNamespace.Global :-)
There's needless alliteration here. Very cosmetic, however.
+ public override string GetSignatureForError ()
+ {
+ return ::global;
+ }
I'd rather say 'global::' -- that's how it's used, after all.
public override string ToString ()
{
- if (NS == Namespace.Root)
- return NamespaceEntry (root);
- else
- return String.Format (NamespaceEntry
({0},{1},{2}), ns.Name, IsImplicit, ID);
+ return ns.ToString ();
}
}
This seems to be dropping information. We need to print the details of
the NamespaceEntry too.
- Hari
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Int32.Parse
Hey,
Currently the Int32.TryParse method calls the Int32.Parse method, and
catches the exceptions. That's not the best behaviour, since
Int32.TryParse is designed to avoid the performance problems associated
with exception handling.
The attached patch proposes an approach to keep the result of the
parsing as an enum, and based on it the methods decide whether they
throw an exception or not.
I wanted you to take a look at it, since we need to decide the best
solution for this before changing the TryParse/Parse methods in other
types.
Carlos.
Index: Int32.cs
===
--- Int32.cs (revisión: 51973)
+++ Int32.cs (copia de trabajo)
@@ -92,7 +92,7 @@
}
#endif
- internal static bool Parse (string s, bool tryParse, out int result)
+ internal static ParseResult Parse (string s, out int result)
{
int val = 0;
int len;
@@ -102,10 +102,7 @@
result = 0;
if (s == null)
-if (tryParse)
- return false;
-else
- throw new ArgumentNullException (s);
+return ParseResult.NullArgument;
len = s.Length;
@@ -117,10 +114,7 @@
}
if (i == len)
-if (tryParse)
- return false;
-else
- throw new FormatException ();
+return ParseResult.WrongFormat;
c = s [i];
if (c == '+')
@@ -145,28 +139,18 @@
if (Char.IsWhiteSpace (c)){
for (i++; i len; i++){
if (!Char.IsWhiteSpace (s [i]))
-if (tryParse)
- return false;
-else
- throw new FormatException ();
+return ParseResult.WrongFormat;
}
break;
} else
- if (tryParse)
- return false;
- else
- throw new FormatException ();
+ return ParseResult.WrongFormat;
}
}
if (!digits_seen)
-if (tryParse)
- return false;
-else
- throw new FormatException ();
+return ParseResult.WrongFormat;
result = val;
-
- return true;
+ return ParseResult.Success;
}
public static int Parse (string s, IFormatProvider fp)
@@ -179,7 +163,7 @@
return Parse (s, style, null);
}
- internal static void CheckStyle (NumberStyles style)
+ internal static ParseResult CheckStyle (NumberStyles style)
{
if ((style NumberStyles.AllowHexSpecifier) != 0) {
NumberStyles ne = style ^ NumberStyles.AllowHexSpecifier;
@@ -188,24 +172,37 @@
if ((ne NumberStyles.AllowTrailingWhite) != 0)
ne ^= NumberStyles.AllowTrailingWhite;
if (ne != 0)
- throw new ArgumentException (
- With AllowHexSpecifier only +
- AllowLeadingWhite and AllowTrailingWhite +
- are permitted.);
+ return ParseResult.WrongHexFormat;
}
+
+ return ParseResult.Success;
}
- internal static int JumpOverWhite (int pos, string s, bool excp)
+ internal static bool JumpOverWhite (ref int pos, string s)
{
+ return JumpOverWhite (ref pos, s, true);
+ }
+
+ internal static bool JumpOverWhite (ref int pos, string s, bool report_error)
+ {
while (pos s.Length Char.IsWhiteSpace (s [pos]))
pos++;
- if (excp pos = s.Length)
-throw new FormatException (Input string was not in the correct format.);
+ if (report_error pos = s.Length)
+return false;
- return pos;
+ return true;
}
+ internal static int JumpOverWhite (int pos, string s, bool exc)
+ {
+ int p = pos;
+ if (!JumpOverWhite (ref p, s, exc))
+throw new FormatException ();
+
+ return p;
+ }
+
internal static void FindSign (ref int pos, string s, NumberFormatInfo nfi,
ref bool foundSign, ref bool negative)
{
@@ -275,22 +272,16 @@
return Char.IsDigit (e);
}
- internal static bool Parse (string s, NumberStyles style, IFormatProvider fp, bool tryParse, out int result)
+ internal static ParseResult Parse (string s, NumberStyles style, IFormatProvider fp, out int result)
{
+ ParseResult parse_result;
result = 0;
if (s == null)
-if (tryParse)
- return false;
-else
- throw new ArgumentNullException ();
+return ParseResult.NullArgument;
if (s.Length == 0)
-if (tryParse)
- return false;
-else
- throw new FormatException (Input string was not +
- in the correct format.);
+return ParseResult.WrongFormat;
NumberFormatInfo nfi;
if (fp != null) {
@@ -300,7 +291,9 @@
else
nfi = Thread.CurrentThread.CurrentCulture.NumberFormat;
- CheckStyle (style);
+ parse_result = CheckStyle (style);
+ if (parse_result != ParseResult.Success)
+return parse_result;
bool AllowCurrencySymbol = (style NumberStyles.AllowCurrencySymbol) != 0;
bool AllowHexSpecifier = (style NumberStyles.AllowHexSpecifier) != 0;
@@ -316,7 +309,8 @@
int pos = 0;
if (AllowLeadingWhite)
-pos = JumpOverWhite (pos, s, true);
+if (!JumpOverWhite (ref pos, s))
+ return ParseResult.WrongFormat;
bool foundOpenParentheses = false;
bool negative = false;
@@ -331,20 +325,14 @@
Re: [Mono-dev] Mono
On Wed, 2005-10-19 at 12:05 -0700, Zymmeral wrote: When will there be a C++ compiler for Mono? The Mono team isn't working on a C++ compiler, and likely never will. So the answer to your question depends on what features you want. If you want C++/CLI support for pure-IL assemblies, there will be a C++ compiler for Mono in ~1.5 months, called Visual Studio.NET 2005. In theory, pure-IL C++/CLI apps should run unchanged under Mono, though I haven't heard of too many people actually trying this. If you want C++/CLI support for mixed-mode assemblies (single .dll/.exe files containing both managed and unmanaged code), there are bigger problems -- such as the complete lack of support for mixed-mode assemblies within Mono. I'm not sure if this will ever be corrected, as supporting them would virtually require copying all of /lib/ld.so into Mono. (On Win32, Mixed-mode assemblies work because assemblies are PE files, and normal .DLL files are PE files, so .NET can just LoadLibrary()/GetProcAddress() the assemblies to get the native methods. The normal OS Library Loader helps immensely. Linux is different, as ELF is the shared library format, not PE, so you can't dlopen(3)/dlsym(3) the mixed-mode assembly, meaning that to properly support mixed-mode assemblies in Mono you'd have to replicate most of the work of /lib/ld.so for use on PE files. See also the Wine project. Plus, you won't ever be able to use a Win32-compiled mixed-mode assembly on Linux, ever, because of differences in shared library names, exports, etc.) If you want a Free C++/CLI compiler for Mono, you may be waiting awhile. I've heard of various efforts over the years, but it's been awhile since I've heard anything at all. - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] C# and SWT
You are sure, if your primary target is Mac then you need other solution as Gtk is native only for Linux users. Maybe you can make something like iFolder (www.ifolder.com), it uses 3 diferent toolkits but business layers is same. I use wxWidgets on past and some controls theres a ugly look, as example Win application is not like a native Win apps and if you use some applications writen in Linux with wxWidgets like pgadmin3 you will see that something is bad. Take a look at this page: http://www.mono-project.com/Gui_Toolkits maybe can help you on decision. Everaldo. Em Qua, 2005-10-19 às 20:35 -0700, Elan Feingold escreveu: Why you dont uses Gtk#? Is a nice toolkit and run under Linux and Windows (I am not sure about Mac). I have used GTK+ in the past, and liked it, but I'm really looking to use native widgets this time. In my experience, Mac users demand nothing less, and personally I think it looks better anyway. Thanks for your reply. -elan ___ 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] C# and SWT
On 10/20/05, Elan Feingold [EMAIL PROTECTED] wrote: ... And then there's the IKVM project, which seems to be able to run Eclipse (and thus SWT) under Mono's VM -- but I'm not sure if that means I can write C# code that uses SWT. Yes. It works. bamboo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] remove extra type validation in ObjectDataContainer
Hello all, From the attached test case seems we do too much type validation, the proposed patch fixes that. Please reply if someone has an objection otherwise Ill commit. Regards, Konstantin Triger objectcont.diff Description: objectcont.diff ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
