Re: [Mono-devel-list] Plan for XSP Changes
Hi, Looks like a good plan to me, fwiw. I'd like to add Just a small feature request though, if you have time. I'd really like to have xsp provide a configurable output for errors. Right now it pretty much just does console.write() for everything, making it difficult to catch errors, especially in the mod-mono server. Thanks, Bill On Apr 8, 2005 6:22 AM, Brian Ritchie <[EMAIL PROTECTED]> wrote:Based on comments from Gonzalo, Sebastien, and Miguel and I'm planningon making the following changes to the XSP code base. Hopefully I'mnot putting words in your mouth :)Please review...1) Create 2 modules: xsp.exe & Mono.ASPNET.dll (Let me know what namesyou prefer for the modules)2) Configure library to be compiled with both mcs and gmcs (for 1.xand 2.x profiles and controls)3) Add a .pc file so third parties can link against it. I'm notfamiliar with the pkg-config stuff, so I'll need a hand on this one.4) Divide existing code between the modules:- xsp.exe would contain all configuration options, functinality suchas AddApplicationsFromConfigDirectory, AddApplicationsFromConfigFile,AddApplicationFromElement, AddApplicationsFromCommandLine. It wouldhandle console output, help messages, etc.- Mono.ASPNET.dll would contain the core HTTP Server. In the futurethis would be further split into the new HttpListener class (.net 2.0)and ASP.NET integration code.5) Make class & method accessibility changes to limit the public"surface" of the assembly.6) Add HTTPS support. The core assembly will utilize theSslServerStream from Mono.Security. Besides IP & Port, it will alsorequire a SecurityProtocolType, X509 Certificate, and aPrivateKeySelectionCallback which returns an AsymmetricAlgorithm tothe private key. xsp.exe will be enhanced to allow the protocoltypes, certificate filename, private key filename & password to bespecified. This can be enhanced in the future to support other kindsof certificate stores. Also, client-side certs will be looked at in afuture round of changes.7) Add OnCreateHost delegate to allow trapping of loading (orreloading) of application hosts. This is useful for responding to anAppDomain reload after a config file or other change.Well, that's the basic plan. Let me know what you think,Brian___Mono-devel-list mailing listMono-devel-list@lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Comparing against null
Hi, Miguel de Icaza <[EMAIL PROTECTED]> writes: > Hello, > >> This usage lies somewhere in the gray, murkey watters between ugly and >> wrong. I'd advise you find some other way to do what you want. > > Is our compiler buggy, yes or no? I believe it's buggy. AFAI can make out of the standard, comparison against null is not special, and undergoes the same rules for choosing user-defined operator==. - Hari ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Comparing against null
Hello, > This usage lies somewhere in the gray, murkey watters between ugly and > wrong. I'd advise you find some other way to do what you want. Is our compiler buggy, yes or no? Independently of how ugly and wrong something is, if we have introduced a bug, it must be fixed. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Plan for XSP Changes
Based on comments from Gonzalo, Sebastien, and Miguel and I'm planning on making the following changes to the XSP code base. Hopefully I'm not putting words in your mouth :) Please review... 1) Create 2 modules: xsp.exe & Mono.ASPNET.dll (Let me know what names you prefer for the modules) 2) Configure library to be compiled with both mcs and gmcs (for 1.x and 2.x profiles and controls) 3) Add a .pc file so third parties can link against it. I'm not familiar with the pkg-config stuff, so I'll need a hand on this one. 4) Divide existing code between the modules: - xsp.exe would contain all configuration options, functinality such as AddApplicationsFromConfigDirectory, AddApplicationsFromConfigFile, AddApplicationFromElement, AddApplicationsFromCommandLine. It would handle console output, help messages, etc. - Mono.ASPNET.dll would contain the core HTTP Server. In the future this would be further split into the new HttpListener class (.net 2.0) and ASP.NET integration code. 5) Make class & method accessibility changes to limit the public "surface" of the assembly. 6) Add HTTPS support. The core assembly will utilize the SslServerStream from Mono.Security. Besides IP & Port, it will also require a SecurityProtocolType, X509 Certificate, and a PrivateKeySelectionCallback which returns an AsymmetricAlgorithm to the private key. xsp.exe will be enhanced to allow the protocol types, certificate filename, private key filename & password to be specified. This can be enhanced in the future to support other kinds of certificate stores. Also, client-side certs will be looked at in a future round of changes. 7) Add OnCreateHost delegate to allow trapping of loading (or reloading) of application hosts. This is useful for responding to an AppDomain reload after a config file or other change. Well, that's the basic plan. Let me know what you think, Brian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Comparing against null
Just to check, I had someone compile your test under MS csc version, and the code compiled by csc does call operator==. So this would really seem like an mcs bug. On Thursday 07 April 2005 4:12 am, Joe Ante wrote: > Hi, > > Is there a way to compare an object against null with a user defined > operator? > > In mono 1.0.4 i did get operator == called even if comparing against null. > In mono 1.1.6 that doesn't happen anymore. > Is this according to the standard? If it is how do i overload comparison > against null? ___ 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] Reflection Only Test
Hey, This is ok to check in. Zoltan On Apr 8, 2005 1:10 AM, Carlos Alberto Cortez <[EMAIL PROTECTED]> wrote: > Hi, > > I've attached changes to add Reflection only tests in those existing > ones. > > All of them run ok with .NET. > > May I commit? > > Carlos. > > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] [Patch] Reflection Only Test
Hi,
I've attached changes to add Reflection only tests in those existing
ones.
All of them run ok with .NET.
May I commit?
Carlos.
Index: AssemblyTest.cs
===
--- AssemblyTest.cs (revisiÃn: 42636)
+++ AssemblyTest.cs (copia de trabajo)
@@ -188,6 +188,36 @@
Assembly corlib2 = Assembly.LoadWithPartialName ("corlib_plattest");
Assert.IsTrue (corlib != null || corlib2 != null);
}
+
+#if NET_2_0
+ [Test]
+ public void ReflectionOnlyLoad ()
+ {
+ Assembly assembly = Assembly.ReflectionOnlyLoad (typeof (AssemblyTest).Assembly.FullName);
+
+ Assert.IsNotNull (assembly);
+ Assert.IsTrue (assembly.ReflectionOnly);
+ }
+
+ [Test]
+ public void ReflectionOnlyLoadFrom ()
+ {
+ string loc = typeof (AssemblyTest).Assembly.Location;
+ string filename = Path.GetFileName (loc);
+ Assembly assembly = Assembly.ReflectionOnlyLoadFrom (filename);
+
+ Assert.IsNotNull (assembly);
+ Assert.IsTrue (assembly.ReflectionOnly);
+ }
+
+ [Test]
+ [ExpectedException (typeof (ArgumentException))]
+ public void CreateInstanceOnRefOnly ()
+ {
+ Assembly assembly = Assembly.ReflectionOnlyLoad (typeof (AssemblyTest).Assembly.FullName);
+ assembly.CreateInstance ("MonoTests.System.Reflection.AssemblyTest");
+ }
+#endif
}
}
Index: MethodInfoTest.cs
===
--- MethodInfoTest.cs (revisiÃn: 42636)
+++ MethodInfoTest.cs (copia de trabajo)
@@ -153,7 +153,30 @@
else
AssertEquals (false, locals [1].IsPinned);
}
+
+ [Test]
+ [ExpectedException (typeof (InvalidOperationException))]
+ public void InvokeOnRefOnlyAssembly ()
+ {
+ Assembly a = Assembly.ReflectionOnlyLoad (typeof (MethodInfoTest).Assembly.FullName);
+ Type t = a.GetType (typeof (RefOnlyClass).FullName);
+ MethodInfo m = t.GetMethod ("RefOnlyMethod", BindingFlags.Static | BindingFlags.NonPublic);
+
+ m.Invoke (null, new object [0]);
+ }
+
#endif
}
+
+#if NET_2_0
+ // Helper class
+ class RefOnlyClass
+ {
+ // Helper static method
+ static void RefOnlyMethod ()
+ {
+ }
+ }
+#endif
}
Index: FieldInfoTest.cs
===
--- FieldInfoTest.cs (revisiÃn: 42636)
+++ FieldInfoTest.cs (copia de trabajo)
@@ -95,6 +95,37 @@
AssertEquals (typeof (Marshal1), Type.GetType (attr.MarshalType));
*/
}
+
+ [Test]
+ [ExpectedException (typeof (InvalidOperationException))]
+ public void GetValueOnRefOnlyAssembly ()
+ {
+ Assembly assembly = Assembly.ReflectionOnlyLoad (typeof (FieldInfoTest).Assembly.FullName);
+ Type t = assembly.GetType (typeof (RefOnlyClass).FullName);
+ FieldInfo f = t.GetField ("RefOnlyField", BindingFlags.Static | BindingFlags.NonPublic);
+
+ f.GetValue (null);
+ }
+
+ [Test]
+ [ExpectedException (typeof (InvalidOperationException))]
+ public void SetValueOnRefOnlyAssembly ()
+ {
+ Assembly assembly = Assembly.ReflectionOnlyLoad (typeof (FieldInfoTest).Assembly.FullName);
+ Type t = assembly.GetType (typeof (RefOnlyClass).FullName);
+ FieldInfo f = t.GetField ("RefOnlyField", BindingFlags.Static | BindingFlags.NonPublic);
+
+ f.SetValue (null, 8);
+ }
+
#endif
}
+#if NET_2_0
+// Helper class
+class RefOnlyClass
+{
+ // Helper property
+ static int RefOnlyField;
}
+#endif
+}
Index: PropertyInfoTest.cs
===
--- PropertyInfoTest.cs (revisiÃn: 42636)
+++ PropertyInfoTest.cs (copia de trabajo)
@@ -29,7 +29,6 @@
}
-
private class TestClass
{
public string ReadOnlyProperty
Re: [Mono-devel-list] Comparing against null
> A couple of suggestions: > > By the way, why do you need a customized version of operator==? What kind of > operations are you needing to do in there? I am checking if the C++ representation has not already been destroyed. Which for all practical purposes means that the C# object is null. > You might try this workaround: change the comparison ``t == null'' to > ``t == (Type) null''. That is not possible, we are creating a release quality product. I can't reasonably require our customers to write such code. Is there a way to make the compiler give compile errors when the user is about to use the comparison operator? Disabling it completely is at least better than wrong behaviour. Joachim Ante www.otee.dk > > > On Thursday 07 April 2005 11:56 am, you wrote: > >> In our game engine we wrap C++ objects with small mono objects. >> The C++ representation might be destroyed. We use a lot of weak referencing >> and I want it to be straightforward to use. >> Comparing against null is the obvious way to do that. > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] libgdiplus 1.1.5 - conflicting types
This has been fixed a while back in SVN.
Peter
-Original Message-
From: "Jonathan J. Vargas R." <[EMAIL PROTECTED]>
To:
Date: 07 April, 2005 13:42
Subject: [Mono-devel-list] libgdiplus 1.1.5 - conflicting types
>hi
>
>libgdiplus 1.1.5 is not compiling because of a type conflict.
>
>src/gifcodec.c defines two versions of a function differing by an
>unsigned parameter.. in the header src/gifcodec.h there is only one
>version of the function.
>
>[gifcodec.h]
>GpStatus gdip_save_gif_image_to_file (char *filename, GpImage *image);
>
>[gifcodec.c]
>
>GpStatus gdip_save_gif_image_to_file (unsigned char *filename, GpImage
>*image)
>{
> return UnknownImageFormat;
>}
>
>GpStatus gdip_save_gif_image_to_file (char *filename, GpImage *image)
>{
> return gdip_save_gif_image ( (void *)filename, image, TRUE);
>}
>
>
>--
>Jonathan J. Vargas Rodriguez
>[EMAIL PROTECTED]
>"Conservar el silencio interior cuando vuelo en la tormenta me es
>mejor, porque asi ya no soy otra gota de la tempestad"
>___
>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] libgdiplus 1.1.5 - conflicting types
hi
libgdiplus 1.1.5 is not compiling because of a type conflict.
src/gifcodec.c defines two versions of a function differing by an
unsigned parameter.. in the header src/gifcodec.h there is only one
version of the function.
[gifcodec.h]
GpStatus gdip_save_gif_image_to_file (char *filename, GpImage *image);
[gifcodec.c]
GpStatus gdip_save_gif_image_to_file (unsigned char *filename, GpImage *image)
{
return UnknownImageFormat;
}
GpStatus gdip_save_gif_image_to_file (char *filename, GpImage *image)
{
return gdip_save_gif_image ( (void *)filename, image, TRUE);
}
--
Jonathan J. Vargas Rodriguez
[EMAIL PROTECTED]
"Conservar el silencio interior cuando vuelo en la tormenta me es
mejor, porque asi ya no soy otra gota de la tempestad"
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Comparing against null
On Thu, 2005-04-07 at 19:08 +0200, Joe Ante wrote: > Ben, > >> In the general case i agree but i think for what we are doing it makes > >> obvious sense to compare against nulll and return true if the C++ > >> representation is not around anymore, since it will generate exceptions if > >> you use it anyway. > > This usage lies somewhere in the gray, murkey watters between ugly and > > wrong. I'd advise you find some other way to do what you want. > I disagree but do you have a better suggestion? Not specifically. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Comparing against null
Ben, >> In the general case i agree but i think for what we are doing it makes >> obvious sense to compare against nulll and return true if the C++ >> representation is not around anymore, since it will generate exceptions if >> you use it anyway. > This usage lies somewhere in the gray, murkey watters between ugly and > wrong. I'd advise you find some other way to do what you want. I disagree but do you have a better suggestion? Joachim Ante ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Comparing against null
On Thu, 2005-04-07 at 18:56 +0200, Joe Ante wrote: > > Yes, that is correct. On csc x == null *always* does a pointerwise > > comparison. I made mcs do this. In some ways it is an optimization (the > > user one will at the very least require a function call), in others a > > correctness (though that seems very pendantic -- I am not sure if there > > are any real life examples where it makes a difference). > In our game engine we wrap C++ objects with small mono objects. > The C++ representation might be destroyed. We use a lot of weak referencing > and I want it to be straightforward to use. > Comparing against null is the obvious way to do that. > > When invoking a member method of a C# wrapper this will always generate an > exception anyway. So i need some way to check if the actual C++ referenced > object is still around. > > > If you absolutely need it, have a static readonly variable with the > > value of null. However, I'd advise that your equals impl only return > > `true' for the equality of null to another null. > In the general case i agree but i think for what we are doing it makes > obvious sense to compare against nulll and return true if the C++ > representation is not around anymore, since it will generate exceptions if > you use it anyway. This usage lies somewhere in the gray, murkey watters between ugly and wrong. I'd advise you find some other way to do what you want. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Comparing against null
> Yes, that is correct. On csc x == null *always* does a pointerwise > comparison. I made mcs do this. In some ways it is an optimization (the > user one will at the very least require a function call), in others a > correctness (though that seems very pendantic -- I am not sure if there > are any real life examples where it makes a difference). In our game engine we wrap C++ objects with small mono objects. The C++ representation might be destroyed. We use a lot of weak referencing and I want it to be straightforward to use. Comparing against null is the obvious way to do that. When invoking a member method of a C# wrapper this will always generate an exception anyway. So i need some way to check if the actual C++ referenced object is still around. > If you absolutely need it, have a static readonly variable with the > value of null. However, I'd advise that your equals impl only return > `true' for the equality of null to another null. In the general case i agree but i think for what we are doing it makes obvious sense to compare against nulll and return true if the C++ representation is not around anymore, since it will generate exceptions if you use it anyway. Joachim Ante ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] patch for mkbundle
This patch adds a --static flag to mkbundle for statically linking
libmono and glib.
James
Index: mkbundle.cs
===
--- mkbundle.cs (revision 42590)
+++ mkbundle.cs (working copy)
@@ -23,6 +23,7 @@
static bool autodeps = false;
static bool keeptemp = false;
static bool compile_only = false;
+ static bool static_link = false;
static int Main (string [] args)
{
@@ -75,7 +76,9 @@
case "--keeptemp":
keeptemp = true;
break;
-
+ case "--static":
+static_link = true;
+break;
default:
sources.Add (args [i]);
break;
@@ -208,9 +211,19 @@
if (compile_only)
return;
-
- cmd = String.Format ("cc -o {2} -Wall {0} `pkg-config --cflags --libs mono` {1}",
- temp_c, temp_o, output);
+
+ if (static_link)
+cmd = String.Format ("cc -o {2} -Wall `pkg-config --cflags mono` {0} " +
+ "`pkg-config --libs-only-L mono` -Wl,-Bstatic " +
+ "`pkg-config --libs-only-l mono | sed -e \"s/\\-lm //\" | " +
+ "sed -e \"s/\\-ldl //\" | sed -e \"s/\\-lpthread //\"` " +
+ "-Wl,-Bdynamic -ldl -lm -lrt {1}",
+ temp_c, temp_o, output);
+ else
+cmd = String.Format ("cc -o {2} -Wall {0} `pkg-config --cflags --libs mono` {1}",
+ temp_c, temp_o, output);
+
+
Console.WriteLine (cmd);
ret = system (cmd);
if (ret != 0){
@@ -328,7 +341,8 @@
"-L path Adds `path' to the search path for assemblies\n" +
"--nodepsTurns off automatic dependency embedding (default)\n" +
"--deps Turns on automatic dependency embedding\n" +
- "--keeptemp Keeps the temporary files\n");
+ "--keeptemp Keeps the temporary files\n" +
+ "--staticStatically link to mono libs\n");
}
[DllImport ("libc")]
smime.p7s
Description: S/MIME cryptographic signature
[Mono-devel-list] On the way to make S.R.E generics API more usable
Hi!
On my work towards implementing generics emission in Nemerle I get into
following problems:
- MS is adding new methods to TypeBuilder for obtaining members of
instanciated generic types:
public static MethodInfo GetMethod (Type instanciated, MethodInfo meth)
public static ConstructorInfo GetConstructor (Type instanciated,
ConstructorInfo cons)
public static FieldInfo GetField (Type instanciated, FieldInfo fld)
see
http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=d507aff5-b1e3-49b4-8178-065a00d2f15e
they are already available in Feb CTP, though not documented anywhere.
And not suprisingly, I need them... I hacked something in mono sources, so
it is partially enough for my experiments now, but it would be nice to have
it implemented correctly.
I'm not sure what would be the *correct* way of implementing it. I tried
iterating on instanciated.GetMethods (), but comparing if member signatures
match isn't that easy (for example GetParameters () method sometimes throws
exception when used for TypeBuilder)
Any suggestions?
- There is a new MakeGenericType method in TypeBuilder, which simply replaces
BindGenericTypes, which gets obsoleted (attached patch to add this method to
TypeBuilder)
- I need the HasGenericArguments method from TypeBuilder, which currently in
mono is "throw NotImplementedException" - attached patch to make it simply
check for presence of generic_params.
Kamil Skalski
Index: class/corlib/System/Type.cs
===
--- class/corlib/System/Type.cs (wersja 42625)
+++ class/corlib/System/Type.cs (kopia robocza)
@@ -1040,6 +1040,11 @@
return res;
}
+public Type MakeGenericType (Type[] types)
+{
+ return BindGenericParameters (types);
+}
+
public abstract bool IsGenericParameter {
get;
}
Index: class/corlib/System.Reflection.Emit/TypeBuilder.cs
===
--- class/corlib/System.Reflection.Emit/TypeBuilder.cs (wersja 42625)
+++ class/corlib/System.Reflection.Emit/TypeBuilder.cs (kopia robocza)
@@ -1381,7 +1381,7 @@
public override bool HasGenericArguments {
get {
-throw new NotImplementedException ();
+return generic_params != null;
}
}
[Mono-devel-list] patch for bugs in ilasm
Attached is a patch for bugs in ilasm.
As almost all the fixes are on the same file (PEAPI.cs), so it wont be
possible to seperate them out.
Also attached are test cases for reproducing the bugs fixed. These were
discovered and fixed while trying to roundtripping on
Microsoft.VisualBasic.dll (monodis ms.vb.dll > vb.il; ilasm /dll vb.il;
PEVerify.exe vb.dll).
After this patch, PEVerify gives zero errors on the final .dll.
The major chunk is for fixing the handling of ValueTypes in ilasm.
case.cs :
"ref " .. not encoded correctly. Change required in
ClassRefInst.ctor, typeIndex(base) changed to a ValueType. (see patch)
case2.cs :
Two problems:
1. for array of ValueTypes
2. ClassRef to ValueType or Enum, gets encoded as a
valuetype. It should be encoded as a ClassRef to System.ValueType or
System.Enum. Only types derived from these are valuetypes.
i1.il :
IL allows method params to have same name. ilasm(mono) uses a hashtable to
store named params.. changed that.
i2.il :
Type not set for a ByteArrConst (eg. when .param[1] = bytearray (...) )
ByteArray is set to a string by default.
i3.il :
For a float method param
.param [1] = float64(0x3FBA)
ILParser converts (0x3f...) to an int64 and then later tries to convert it
into a float, instead of using the in64's exact bit image to build the float.
nes.cs:
For Nested classes, the entry in the TypeDef table for the nested class
should have namespace="", as it is built from the NestedClass &
EnclosingClass in the NestedClass table.
t3.il :
An enum declared in IL with no explicit "extends System.Enum" gets
incorrectly encoded as deriving from System.ValueType.
Fixed in the patch.
For testing the .cs testcases, do
mcs case.cs
monodis case.exe > case.il
ilasm case.il
PEVerify.exe case.exe -> This will show the errors..
For the .il files just ilasm and peverify them
The files are attached in bugzilla :
http://bugzilla.ximian.com/show_bug.cgi?id=74365
Eagerly awaiting feedback..
-Ankit
--
Blog :
Mono hacking : http://mono-nosip.blogspot.com
Personal : http://www.corewars.org/radical
Index: ilasm/codegen/TypeDef.cs
===
--- ilasm/codegen/TypeDef.cs (revision 42498)
+++ ilasm/codegen/TypeDef.cs (working copy)
@@ -69,7 +69,7 @@
is_intransit = false;
is_value_class = false;
-is_value_class = false;
+is_enum_class = false;
}
public string Name {
@@ -250,16 +250,27 @@
throw new Exception ("this type can not be a base type: "
+ parent);
}
+
+if (parent.PeapiClass.nameSpace != null &&
+parent.PeapiClass.nameSpace.CompareTo ("System") == 0) {
+
+if (parent.PeapiClass.name.CompareTo ("ValueType") == 0)
+is_value_class = true;
+else
+if (parent.PeapiClass.name.CompareTo ("Enum") == 0 )
+is_enum_class = true;
+}
+
if (outer != null) {
if (!outer.IsDefined)
outer.Define (code_gen);
classdef = outer.PeapiType.AddNestedClass (attr,
name_space, name, parent.PeapiClass);
} else {
-if (is_value_class) {
+if (is_value_class || is_enum_class) {
// Should probably confirm that the parent is System.ValueType
classdef = code_gen.PEFile.AddValueClass (attr,
-name_space, name);
+name_space, name, is_value_class ? PEAPI.ValueClass.ValueType : PEAPI.ValueClass.Enum);
} else {
classdef = code_gen.PEFile.AddClass (attr,
name_space, name, parent.PeapiClass);
@@ -272,9 +283,9 @@
classdef = outer.PeapiType.AddNestedClass (attr,
name_space, name);
} else {
-if (is_value_class) {
+
Re: [Mono-devel-list] Comparing against null
On Thu, 2005-04-07 at 11:12 +0200, Joe Ante wrote: > Hi, > > Is there a way to compare an object against null with a user defined > operator? > > In mono 1.0.4 i did get operator == called even if comparing against null. > In mono 1.1.6 that doesn't happen anymore. > Is this according to the standard? If it is how do i overload comparison > against null? Yes, that is correct. On csc x == null *always* does a pointerwise comparison. I made mcs do this. In some ways it is an optimization (the user one will at the very least require a function call), in others a correctness (though that seems very pendantic -- I am not sure if there are any real life examples where it makes a difference). If you absolutely need it, have a static readonly variable with the value of null. However, I'd advise that your equals impl only return `true' for the equality of null to another null. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Patch for DirectoryServices.DirectoryEntry
Hello all,
Attached is the patch for DirectoryEntry.cs :
- Implemented RefreshCache.
- Extract properties loading to dedicated method.
- Do not reload properties in CommitChanges.
- Use foreach loops instead of enumerators.
If no one objects, I'll commit.
Thanks,
Boris
--
Boris Kirzner
Mainsoft Corporation
http://www.mainsoft.com
Index: DirectoryEntry.cs
===
--- DirectoryEntry.cs (revision 42415)
+++ DirectoryEntry.cs (working copy)
@@ -501,51 +501,7 @@
public PropertyCollection Properties
{
get {
- if ( _Properties == null )
{
-
- _Properties = new
PropertyCollection(this);
- _inPropertiesLoading = true;
-
- try
{
- LdapSearchResults
lsc=conn.Search( Fdn,
-
LdapConnection.SCOPE_BASE,
-
"objectClass=*",
-
null,
-
false);
- while(lsc.hasMore())
{
-
- LdapEntry nextEntry =
null;
- try
{
- nextEntry =
lsc.next();
- }
- catch(LdapException e)
{
- // Exception is
thrown, go for next entry
- throw e;
- }
- LdapAttributeSet
attributeSet = nextEntry.getAttributeSet();
-
System.Collections.IEnumerator ienum=attributeSet.GetEnumerator();
- if(ienum!=null)
{
-
while(ienum.MoveNext()) {
-
LdapAttribute attribute=(LdapAttribute)ienum.Current;
- string
attributeName = attribute.Name;
-
_Properties[attributeName].AddRange(attribute.StringValueArray);
-
_Properties[attributeName].Mbit=false;
- //
string attributeVal =
attribute.StringValue;
- //
_Properties[attributeName].Add(attributeVal);
- }
- }
- break;
- }
- }
- catch( LdapException le)
{
- if(le.ResultCode ==
LdapException.NO_SUCH_OBJECT)
- { }
- }
- finally {
- _inPropertiesLoading = false;
- }
- }
- return _Properties;
+ return GetProperties(true);
}
}
@@ -584,6 +540,60 @@
}
}
+ ///
+ /// Returns entry properties.
+ ///
+ /// Specifies whenever to force the
properties load from the server if local property cache is empty.
+
[Mono-devel-list] MonoDevelop: German Translation
Hi, I've just translated the current svn version of MonoDevelop into German. Since there is no contact information on the MonoDevelop website I'm posting the file to this list. Gustl -- ICQ#: 49043936 de.po.tar.bz2 Description: application/tbz
[Mono-devel-list] how does xsp load assemblies from the gac?
Hi, I'm using a register-statement like this: <%@ Register TagPrefix="example" Namespace="Example.Web" Assembly="Example, Version=1.0.0.0, Culture=neutral, PublicKeyToken=95bc06375859a286" %> xsp can only load the Example-Assembly if i have a symlink to it in /usr/lib/mono/1.0/. And xsp just ignores the requested version. I can create a symlink to for instance version 1.1.0.0 and the webpage still loads without an error. Is this the correct behavior? The reason i stumbled upon this is that I have two different versions of an assembly, and i want some pages to use the version 1.0.0.0 and some other pages to use the version 1.1.0.0. Is this possible? mono 1.1.6 xsp 1.0.6 Gustl -- ICQ#: 49043936 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Comparing against null
Hi,
Is there a way to compare an object against null with a user defined
operator?
In mono 1.0.4 i did get operator == called even if comparing against null.
In mono 1.1.6 that doesn't happen anymore.
Is this according to the standard? If it is how do i overload comparison
against null?
using System;
public class Test
{
static public bool operator == (Test x, Test y)
{
System.Console.WriteLine ("The operator == is being
called");
return false;
}
static public bool operator != (Test x, Test y)
{
System.Console.WriteLine ("The operator != is being
called");
return true;
}
public override bool Equals (object o)
{
System.Console.WriteLine ("Equals function is being
called");
return false;
}
public override int GetHashCode ()
{
System.Console.WriteLine ("Hash function is being called");
return 0;
}
};
public class Bug
{
static void Main(string[] args)
{
Test t = new Test ();
if (t == null)
{
System.Console.WriteLine ("The operator correctly returned
false");
}
else
{
System.Console.WriteLine ("The operator is never called");
}
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
