Re: [Mono-dev] BIG ASP.NET BUG : SegFault when sending a Response of a size > 120Ko
Le mardi 18 octobre 2005 à 16:37 +0200, Hubert FONGARNAND a écrit :
I confirm it still fails with this test case (updated on bugzilla)
Well, thank you for the fix...
But it fails now with a length>200ko
you can try :
private void MyButton_Click(object sender,EventArgs e)
{
int length=20;
byte[] buffer=new byte[length];
Response.ClearHeaders();
Response.Clear();
Response.AddHeader("Content-Disposition","attachment;
filename=\""+"essai"+"\"");
Response.AppendHeader("Content-Length",length.ToString());
Response.StatusCode = 200;
Response.OutputStream.Write(buffer,0,length);
Response.End();
Response.Flush();
}
you will get :
[EMAIL PROTECTED] /home/monoapp/WebApplication1 $ xsp
xsp
Listening on port: 8080 (non-secure)
Listening on address: 0.0.0.0
Root directory: /home/monoapp/WebApplication1
Hit Return to stop the server.
** (process:11870): ERROR (recursed) **: file mini-trampolines.c: line
28 (mono_magic_trampoline): assertion failed: (addr)
aborting...
Erreur de segmentation
I've updated the bug report...
thank in advance
hubert
Le lundi 17 octobre 2005 à 20:49 -0400, Gonzalo Paniagua Javier a écrit :
On Mon, 2005-10-17 at 20:33 -0400, Gonzalo Paniagua Javier wrote:
> On Mon, 2005-10-17 at 11:08 +0200, Hubert FONGARNAND wrote:
> > http://bugzilla.ximian.com/show_bug.cgi?id=76460
It's fixed now.
For those of you seeing weird libc errors and xsp dying, please try
http://primates.ximian.com/~gonzalo/System.Web.dll.gz (gunzip + gacutil
-i), as I think it's the same problem as the one reported by Hubert.
Thanks.
-Gonzalo
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Ce message et les ventuels documents joints peuvent contenir des informations confidentielles.
Au cas oa il ne vous serait pas destin, nous vous remercions de bien vouloir le supprimer et en aviser immtdiatement l'expditeur. Toute utilisation de ce message non conforme sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite.
Les communications sur internet n'tant pas spcurises, l'intrgrit de ce message n'est pas assur e et la socit mettrice ne peut 0tre tenue pour responsable de son contenu.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___Ce message et les éventuels documents joints peuvent contenir des informations confidentielles.Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite.Les communications sur internet n'étant pas sécurisées, l'intégrité de ce message n'est pas assurée et la société émettrice ne peut être tenue pour responsable de son contenu.
Title: Test
<%@ Page language="c#" %>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] ImageList patches r51171 and r51889 are not compatible with MS.NET behaviour
Hi, MS.NET ImageList creates handle when you first time retrieve or draw any of it's images. Until that is stores the original image object, after handle creation it uses a native ImageList. It applies size and color depth when handle is created. (This is documented in ImageList.cs.) After handle is created modifying ColorDepth or ImageSize results in handle recreation and the loss of all images. As we don't create any handle at all I decided to create it when images are added and apply size and colordepth when handle is created in other words when they are added. Patches r51171 and r51889 are not compatible with MS.NET behaviour as they don't clear images after handle was created so these modifications should not be preserved. I belive that caching the images until using them is a bad idea as we don't use any native image list and doing time consuming operations at initializaion is better as if you create an ImageList you do it because you want to access the images. If you think caching before handle creation behaviour is important after considering the above things please let me know and I will implement that behaviour. Kornél ___ 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)
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.
Carlos.
Index: typemanager.cs
===
--- typemanager.cs (revisión: 51903)
+++ typemanager.cs (copia de trabajo)
@@ -215,6 +215,8 @@
//
static Assembly [] assemblies;
+ static Hashtable external_aliases;
+
//
// Keeps a list of modules. We used this to do lookups
// on the module using GetType -- needed for arrays
@@ -278,6 +280,7 @@
// Lets get everything clean so that we can collect before generating code
assemblies = null;
modules = null;
+ external_aliases = null;
builder_to_declspace = null;
builder_to_member_cache = null;
builder_to_ifaces = null;
@@ -379,6 +382,7 @@
assemblies = new Assembly [0];
modules = null;
+ external_aliases = new Hashtable ();
builder_to_declspace = new PtrHashtable ();
builder_to_member_cache = new PtrHashtable ();
builder_to_method = new PtrHashtable ();
@@ -504,11 +508,22 @@
assemblies = n;
}
+ public static void AddExternAlias (string alias, Assembly a)
+ {
+ // Keep the new as the chosen one
+ external_aliases [alias] = a;
+ }
+
public static Assembly [] GetAssemblies ()
{
return assemblies;
}
+ public static Assembly GetExternAlias (string alias)
+ {
+ return (Assembly) external_aliases [alias];
+ }
+
///
/// Registers a module builder to lookup types from
///
@@ -578,110 +593,26 @@
return (Type) ret;
}
- public static Type LookupTypeReflection (string name, Location loc)
- {
- Type found_type = null;
-
- foreach (Assembly a in assemblies) {
- Type t = a.GetType (name);
- if (t == null)
-continue;
-
- if (t.IsPointer)
-throw new InternalErrorException ("Use GetPointerType() to get a pointer");
-
- TypeAttributes ta = t.Attributes & TypeAttributes.VisibilityMask;
- if (ta != TypeAttributes.NotPublic && ta != TypeAttributes.NestedPrivate &&
-ta != TypeAttributes.NestedAssembly && ta != TypeAttributes.NestedFamANDAssem) {
-if (found_type == null) {
- found_type = t;
- continue;
-}
-
-Report.SymbolRelatedToPreviousError (found_type);
-Report.SymbolRelatedToPreviousError (t);
-Report.Error (433, loc, "The imported type `{0}' is defined multiple times", name);
-return found_type;
- }
- }
-
- foreach (Module mb in modules) {
- Type t = mb.GetType (name);
- if (t == null)
-continue;
-
- if (found_type == null) {
-found_type = t;
-continue;
- }
-
- Report.SymbolRelatedToPreviousError (t);
- Report.SymbolRelatedToPreviousError (found_type);
- Report.Warning (436, 2, loc, "Ignoring imported type `{0}' since the current assembly already has a declaration with the same name",
-TypeManager.CSharpName (t));
- return t;
- }
-
- return found_type;
- }
-
///
/// Computes the namespaces that we import from the assemblies we reference.
///
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);
+
+ foreach (Module m in modules)
+ GlobalRootNamespace.Global.AddModuleReference (m);
- Hashtable cache = null;
+ }
- //
- // First add the assembly namespaces
- //
- if (assembly_get_namespaces != null){
- int count = assemblies.Length;
-
- for (int i = 0; i < count; i++){
-Assembly a = assemblies [i];
-string [] namespaces = (string []) assembly_get_namespaces.Invoke (a, null);
-foreach (string ns in namespaces){
- if (ns.Length == 0)
- continue;
- Namespace.LookupNamespace (ns, true);
-}
- }
- } else {
- cache = new Hashtable ();
- cache.Add ("", null);
- foreach (Assembly a in assemblies) {
-foreach (Type t in a.GetExportedTypes ()) {
- string ns = t.Namespace;
- if (ns == null || cache.Contains (ns))
- continue;
-
- Namespace.LookupNamespace (ns, true);
- cache.Add (ns, null);
-}
- }
- }
-
- //
- // Then add module namespaces
- //
- foreach (Module m in modules) {
- if (m == CodeGen.Module.Builder)
-continue;
- if (cache == null) {
-cache = new Hashtable ();
-cache.Add ("", null);
- }
- foreach (Type t in m.GetTypes ()) {
-string ns = t.Namespace;
-if (ns == null || cache.Contains (ns))
- continue;
-Namespace.LookupNamespace (ns, true);
-cache.Add (ns, null);
- }
- }
+ public static Namespace ComputeNamespacesForAlias (string name)
+ {
+ Assembly assembly = (Assembly) external_aliases [name];
+ if (assembly == null)
+ return null;
+
+ return GlobalRootNamespace.DefineRootNames
Re: [Mono-dev] Extern alias patch (latest modifications)
Hello Carlos,
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.
It looks good to me.
Marek
Index: typemanager.cs
===
--- typemanager.cs (revisión: 51903)
+++ typemanager.cs (copia de trabajo)
@@ -215,6 +215,8 @@
//
static Assembly [] assemblies;
+ static Hashtable external_aliases;
+
//
// Keeps a list of modules. We used this to do lookups
// on the module using GetType -- needed for arrays
@@ -278,6 +280,7 @@
// Lets get everything clean so that we can collect before
generating code
assemblies = null;
modules = null;
+ external_aliases = null;
builder_to_declspace = null;
builder_to_member_cache = null;
builder_to_ifaces = null;
@@ -379,6 +382,7 @@
assemblies = new Assembly [0];
modules = null;
+ external_aliases = new Hashtable ();
builder_to_declspace = new PtrHashtable ();
builder_to_member_cache = new PtrHashtable ();
builder_to_method = new PtrHashtable ();
@@ -504,11 +508,22 @@
assemblies = n;
}
+ public static void AddExternAlias (string alias, Assembly a)
+ {
+ // Keep the new as the chosen one
+ external_aliases [alias] = a;
+ }
+
public static Assembly [] GetAssemblies ()
{
return assemblies;
}
+ public static Assembly GetExternAlias (string alias)
+ {
+ return (Assembly) external_aliases [alias];
+ }
+
///
/// Registers a module builder to lookup types from
///
@@ -578,110 +593,26 @@
return (Type) ret;
}
- public static Type LookupTypeReflection (string name, Location loc)
- {
- Type found_type = null;
-
- foreach (Assembly a in assemblies) {
- Type t = a.GetType (name);
- if (t == null)
- continue;
-
- if (t.IsPointer)
- throw new InternalErrorException ("Use
GetPointerType() to get a pointer");
-
- TypeAttributes ta = t.Attributes &
TypeAttributes.VisibilityMask;
- if (ta != TypeAttributes.NotPublic && ta !=
TypeAttributes.NestedPrivate &&
- ta != TypeAttributes.NestedAssembly && ta !=
TypeAttributes.NestedFamANDAssem) {
- if (found_type == null) {
- found_type = t;
- continue;
- }
-
- Report.SymbolRelatedToPreviousError
(found_type);
- Report.SymbolRelatedToPreviousError (t);
- Report.Error (433, loc, "The imported type `{0}' is
defined multiple times", name);
- return found_type;
- }
- }
-
- foreach (Module mb in modules) {
- Type t = mb.GetType (name);
- if (t == null)
- continue;
-
- if (found_type == null) {
- found_type = t;
- continue;
- }
-
- Report.SymbolRelatedToPreviousError (t);
- Report.SymbolRelatedToPreviousError (found_type);
- Report.Warning (436, 2, loc, "Ignoring imported type `{0}'
since the current assembly already has a declaration with the same name",
- TypeManager.CSharpName (t));
- return t;
- }
-
- return found_type;
- }
-
///
/// Computes the namespaces that we import from the assemblies we
reference.
///
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);
+
+ foreach (Module m in modules)
+ GlobalRootNamespace.Global.AddModuleReference (m);
- Hashtable cache = null;
+ }
- //
- // First add the assembly namespaces
-
[Mono-dev] Re: ImageList patches r51171 and r51889 are not compatible with MS.NET behaviour
On Wed, 2005-10-19 at 11:10 +0200, Kornél Pál wrote: > Hi, > > MS.NET ImageList creates handle when you first time retrieve or draw any of > it's images. Until that is stores the original image object, after handle > creation it uses a native ImageList. It applies size and color depth when > handle is created. (This is documented in ImageList.cs.) > > After handle is created modifying ColorDepth or ImageSize results in handle > recreation and the loss of all images. > > As we don't create any handle at all I decided to create it when images are > added and apply size and colordepth when handle is created in other words > when they are added. > > Patches r51171 and r51889 are not compatible with MS.NET behaviour as they > don't clear images after handle was created so these modifications should > not be preserved. Well what you had broke an existing application that runs fine on MS.NET, so you aren't entirely right. I'm writing a test application now to find out when the images are cleared. Jackson > I belive that caching the images until using them is a bad idea as we don't > use any native image list and doing time consuming operations at > initializaion is better as if you create an ImageList you do it because you > want to access the images. > > If you think caching before handle creation behaviour is important after > considering the above things please let me know and I will implement that > behaviour. > > Kornél > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Re: ImageList patches r51171 and r51889 are notcompatible with MS.NET behaviour
Hi, Please read my original message one again.:) I explained the differences between MS.NET and this implementation. This difference is documented in my previous message, in ImageList.cs and was documented when the modifications were approved. And told you that if you think that this difference is important let me know and I will modify ImageList to match MS.NET behaviour. I did not say that everything is the same as in MS.NET I only said that I don't think that MS.NET behaviour should be followed. Usually it's a bad practicle to add images befor setting ColorDepth and Images size but if you do so images will be cleared on Mono currently but will not be cleared on MS.NET if handle was not created yet. Note that on MS.NET if you modify ImageSize after adding images image strips will be added incorrectly (if their size matches new size) or exception will be thrown when creating handle and you will be unable to use the image list. Your patch should not be retained because images are not modified after handle was created the list is cleared instead. And reducing image size without using ReduceColorDepth will result in 32-bit images because of calculated colors. Kornél - Original Message - From: "Jackson Harper" <[EMAIL PROTECTED]> To: "Kornél Pál" <[EMAIL PROTECTED]> Cc: Sent: Wednesday, October 19, 2005 6:27 PM Subject: [Mono-dev] Re: ImageList patches r51171 and r51889 are notcompatible with MS.NET behaviour On Wed, 2005-10-19 at 11:10 +0200, Kornél Pál wrote: Hi, MS.NET ImageList creates handle when you first time retrieve or draw any of it's images. Until that is stores the original image object, after handle creation it uses a native ImageList. It applies size and color depth when handle is created. (This is documented in ImageList.cs.) After handle is created modifying ColorDepth or ImageSize results in handle recreation and the loss of all images. As we don't create any handle at all I decided to create it when images are added and apply size and colordepth when handle is created in other words when they are added. Patches r51171 and r51889 are not compatible with MS.NET behaviour as they don't clear images after handle was created so these modifications should not be preserved. Well what you had broke an existing application that runs fine on MS.NET, so you aren't entirely right. I'm writing a test application now to find out when the images are cleared. Jackson I belive that caching the images until using them is a bad idea as we don't use any native image list and doing time consuming operations at initializaion is better as if you create an ImageList you do it because you want to access the images. If you think caching before handle creation behaviour is important after considering the above things please let me know and I will implement that behaviour. Kornél ___ 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] Re: ImageList patches r51171 and r51889 are notcompatible with MS.NET behaviour
On Wed, 2005-10-19 at 19:05 +0200, Kornél Pál wrote: > Hi, > > Please read my original message one again.:) I explained the differences > between MS.NET and this implementation. This difference is documented in my > previous message, in ImageList.cs and was documented when the modifications > were approved. And told you that if you think that this difference is > important let me know and I will modify ImageList to match MS.NET behaviour. > I did not say that everything is the same as in MS.NET I only said that I > don't think that MS.NET behaviour should be followed. Well we need it to be in a state where it does not crash existing applictions. Please modify it to match the MS behavoir. Many apps are closed source and we can't modify them to use best practices, so we have to match their behavoir as closely as possible. Jackson > Usually it's a bad practicle to add images befor setting ColorDepth and > Images size but if you do so images will be cleared on Mono currently but > will not be cleared on MS.NET if handle was not created yet. Note that on > MS.NET if you modify ImageSize after adding images image strips will be > added incorrectly (if their size matches new size) or exception will be > thrown when creating handle and you will be unable to use the image list. > > Your patch should not be retained because images are not modified after > handle was created the list is cleared instead. > > And reducing image size without using ReduceColorDepth will result in 32-bit > images because of calculated colors. > > Kornél > > - Original Message - > From: "Jackson Harper" <[EMAIL PROTECTED]> > To: "Kornél Pál" <[EMAIL PROTECTED]> > Cc: > Sent: Wednesday, October 19, 2005 6:27 PM > Subject: [Mono-dev] Re: ImageList patches r51171 and r51889 are > notcompatible with MS.NET behaviour > > > > On Wed, 2005-10-19 at 11:10 +0200, Kornél Pál wrote: > >> Hi, > >> > >> MS.NET ImageList creates handle when you first time retrieve or draw any > >> of > >> it's images. Until that is stores the original image object, after handle > >> creation it uses a native ImageList. It applies size and color depth when > >> handle is created. (This is documented in ImageList.cs.) > >> > >> After handle is created modifying ColorDepth or ImageSize results in > >> handle > >> recreation and the loss of all images. > >> > >> As we don't create any handle at all I decided to create it when images > >> are > >> added and apply size and colordepth when handle is created in other words > >> when they are added. > >> > >> Patches r51171 and r51889 are not compatible with MS.NET behaviour as > >> they > >> don't clear images after handle was created so these modifications should > >> not be preserved. > > > > Well what you had broke an existing application that runs fine on > > MS.NET, so you aren't entirely right. I'm writing a test application > > now to find out when the images are cleared. > > > > Jackson > > > > > >> I belive that caching the images until using them is a bad idea as we > >> don't > >> use any native image list and doing time consuming operations at > >> initializaion is better as if you create an ImageList you do it because > >> you > >> want to access the images. > >> > >> If you think caching before handle creation behaviour is important after > >> considering the above things please let me know and I will implement that > >> behaviour. > >> > >> Kornél > >> > > > > ___ > > 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] System.Security.Cryptography : TripleDES Issue
Sebastien, I have opened bug for this issue (bug# 76483). Please see attached file for source code. To Compile : mcs TestEncryption.cs To Run : mono TestEncryption.exe Result : Unhandled Exception: System.Security.Cryptography.CryptographicException: IV length cannot be larger than block size in <0x000e0> System.Security.Cryptography.SymmetricAlgorithm:set_IV (System.Byte[] value) in <0x00020> System.Security.Cryptography.TripleDESCryptoServiceProvider:CreateEncryp tor (System.Byte[] rgbKey, System.Byte[] rgbIV) in <0x0013d> TestEncryption.TestEncryption:Main (System.String[] args) Regards, Yogendra Thakur -Original Message- From: Sebastien Pouliot [mailto:[EMAIL PROTECTED] Sent: Monday, October 17, 2005 7:18 PM To: Yogendra Thakur Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] System.Security.Cryptography : TripleDES Issue Hello Yogendra, On Mon, 2005-10-17 at 17:39 -0400, Yogendra Thakur wrote: > Hello, > > Is Triple DES Encryption supported in Mono? yes > I have small code which uses Triple DES algorithm to encrypt /Decrypt > data. > This works fine in MS .NET. When I run same code on Mono, it throws "IV > length can not be greater than Block Size" exception. Sorry I can't help you without more details. Please open a bug report at http://bugzilla.ximian.com and include a small source code sample that reproduce the problem. Don't forget to indicate which version of Mono you are using and on which platform. > I don't find any entry for this class in documentation. I searched data > base but couldn't find anything. You can access the documentation from http://www.mono-project.com Click on "manuals and docs" (icon on top right) then navigate the tree view to get to the desired class documentation. Here's a direct link to the TripleDES class http://www.go-mono.com/docs/monodoc.ashx?link=T% 3aSystem.Security.Cryptography.TripleDES > Also I see Crypto classes are implemented under two different namespaces > System.Security.Cryptography and Mono.Security.Cryptography. What is the > difference between them? System.Security.Cryptography implements the same classes (i.e. same features/same limites) as MS base class library. Mono.Security.Cryptography offer extra classes (i.e. not available on the MS framework). -- Sebastien Pouliot email: [EMAIL PROTECTED] blog: http://pages.infinit.net/ctech/ TestEncryption.cs Description: TestEncryption.cs ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] System.Security.Cryptography : TripleDES Issue
Hello Yogendra, As the exception says your IV size isn't right - it's 32 bytes long (256 bits) while it should be 8 bytes (64 bits) like the DES/3DES block size. Strangely this isn't detected by the MS implementation (but IIRC this is check for other crypto algorithms). Anyway I'll look into "fixing" this to ensure interoperability between Mono and MS. Thanks for reporting this. On Wed, 2005-10-19 at 14:05 -0400, Yogendra Thakur wrote: > Sebastien, > > I have opened bug for this issue (bug# 76483). > Please see attached file for source code. > > To Compile : mcs TestEncryption.cs > To Run : mono TestEncryption.exe > > Result : > > Unhandled Exception: > System.Security.Cryptography.CryptographicException: IV length cannot be > larger than block size > in <0x000e0> System.Security.Cryptography.SymmetricAlgorithm:set_IV > (System.Byte[] value) > in <0x00020> > System.Security.Cryptography.TripleDESCryptoServiceProvider:CreateEncryp > tor (System.Byte[] rgbKey, System.Byte[] rgbIV) > in <0x0013d> TestEncryption.TestEncryption:Main (System.String[] args) > > > > Regards, > Yogendra Thakur > > -Original Message- > From: Sebastien Pouliot [mailto:[EMAIL PROTECTED] > Sent: Monday, October 17, 2005 7:18 PM > To: Yogendra Thakur > Cc: mono-devel-list@lists.ximian.com > Subject: Re: [Mono-dev] System.Security.Cryptography : TripleDES Issue > > Hello Yogendra, > > On Mon, 2005-10-17 at 17:39 -0400, Yogendra Thakur wrote: > > Hello, > > > > Is Triple DES Encryption supported in Mono? > > yes > > > I have small code which uses Triple DES algorithm to encrypt /Decrypt > > data. > > This works fine in MS .NET. When I run same code on Mono, it throws > "IV > > length can not be greater than Block Size" exception. > > Sorry I can't help you without more details. > > Please open a bug report at http://bugzilla.ximian.com and include a > small source code sample that reproduce the problem. Don't forget to > indicate which version of Mono you are using and on which platform. > > > I don't find any entry for this class in documentation. I searched > data > > base but couldn't find anything. > > You can access the documentation from http://www.mono-project.com > Click on "manuals and docs" (icon on top right) then navigate the tree > view to get to the desired class documentation. > > Here's a direct link to the TripleDES class > http://www.go-mono.com/docs/monodoc.ashx?link=T% > 3aSystem.Security.Cryptography.TripleDES > > > Also I see Crypto classes are implemented under two different > namespaces > > System.Security.Cryptography and Mono.Security.Cryptography. What is > the > > difference between them? > > System.Security.Cryptography implements the same classes (i.e. same > features/same limites) as MS base class library. > > Mono.Security.Cryptography offer extra classes (i.e. not available on > the MS framework). -- Sebastien Pouliot email: [EMAIL PROTECTED] blog: http://pages.infinit.net/ctech/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Re: ImageList patches r51171 and r51889 arenotcompatible with MS.NET behaviour
OK, I'll post the modified version to the list for approval. I think the current version will not cause any exceptions but may result in wrong visual appearance so it can be used until the new version will be approved. There are no other differences than the documented ones in ImageList.cs if you think or know that any of them may or can break applications please let me know. Kornél - Original Message - From: "Jackson Harper" <[EMAIL PROTECTED]> To: "Kornél Pál" <[EMAIL PROTECTED]> Cc: Sent: Wednesday, October 19, 2005 7:36 PM Subject: Re: [Mono-dev] Re: ImageList patches r51171 and r51889 arenotcompatible with MS.NET behaviour On Wed, 2005-10-19 at 19:05 +0200, Kornél Pál wrote: Hi, Please read my original message one again.:) I explained the differences between MS.NET and this implementation. This difference is documented in my previous message, in ImageList.cs and was documented when the modifications were approved. And told you that if you think that this difference is important let me know and I will modify ImageList to match MS.NET behaviour. I did not say that everything is the same as in MS.NET I only said that I don't think that MS.NET behaviour should be followed. Well we need it to be in a state where it does not crash existing applictions. Please modify it to match the MS behavoir. Many apps are closed source and we can't modify them to use best practices, so we have to match their behavoir as closely as possible. Jackson Usually it's a bad practicle to add images befor setting ColorDepth and Images size but if you do so images will be cleared on Mono currently but will not be cleared on MS.NET if handle was not created yet. Note that on MS.NET if you modify ImageSize after adding images image strips will be added incorrectly (if their size matches new size) or exception will be thrown when creating handle and you will be unable to use the image list. Your patch should not be retained because images are not modified after handle was created the list is cleared instead. And reducing image size without using ReduceColorDepth will result in 32-bit images because of calculated colors. Kornél - Original Message - From: "Jackson Harper" <[EMAIL PROTECTED]> To: "Kornél Pál" <[EMAIL PROTECTED]> Cc: Sent: Wednesday, October 19, 2005 6:27 PM Subject: [Mono-dev] Re: ImageList patches r51171 and r51889 are notcompatible with MS.NET behaviour > On Wed, 2005-10-19 at 11:10 +0200, Kornél Pál wrote: >> Hi, >> >> MS.NET ImageList creates handle when you first time retrieve or draw >> any >> of >> it's images. Until that is stores the original image object, after >> handle >> creation it uses a native ImageList. It applies size and color depth >> when >> handle is created. (This is documented in ImageList.cs.) >> >> After handle is created modifying ColorDepth or ImageSize results in >> handle >> recreation and the loss of all images. >> >> As we don't create any handle at all I decided to create it when >> images >> are >> added and apply size and colordepth when handle is created in other >> words >> when they are added. >> >> Patches r51171 and r51889 are not compatible with MS.NET behaviour as >> they >> don't clear images after handle was created so these modifications >> should >> not be preserved. > > Well what you had broke an existing application that runs fine on > MS.NET, so you aren't entirely right. I'm writing a test application > now to find out when the images are cleared. > > Jackson > > >> I belive that caching the images until using them is a bad idea as we >> don't >> use any native image list and doing time consuming operations at >> initializaion is better as if you create an ImageList you do it >> because >> you >> want to access the images. >> >> If you think caching before handle creation behaviour is important >> after >> considering the above things please let me know and I will implement >> that >> behaviour. >> >> Kornél >> > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] gmcs patch to fix gcs0310-3.cs test working
Hi,
I noticed that mcs/errors/gcs0310-3.cs is not rejected as expected.
The attached patch fixes this problem. Does it look OK to commit?
Atsushi Eno
Index: generic.cs
===
--- generic.cs (revision 51926)
+++ generic.cs (working copy)
@@ -1395,7 +1395,22 @@
if (TypeManager.IsBuiltinType (atype) ||
atype.IsValueType)
return true;
+ if (HasDefaultConstructor (ec, atype))
+ return true;
+
+ Report.Error (310, loc, "The type `{0}' must have a
public " +
+ "parameterless constructor in order to
use it " +
+ "as parameter `{1}' in the generic type
or " +
+ "method `{2}'", atype, ptype,
DeclarationName);
+ return false;
+ }
+
+ bool HasDefaultConstructor (EmitContext ec, Type atype)
+ {
if (atype is TypeBuilder) {
+ if (atype.IsAbstract)
+ return false;
+
TypeContainer tc =
TypeManager.LookupTypeContainer (atype);
foreach (Constructor c in
tc.InstanceConstructors) {
if ((c.ModFlags & Modifiers.PUBLIC) ==
0)
@@ -1425,10 +1440,6 @@
}
}
- Report.Error (310, loc, "The type `{0}' must have a
public " +
- "parameterless constructor in order to
use it " +
- "as parameter `{1}' in the generic type
or " +
- "method `{2}'", atype, ptype,
DeclarationName);
return false;
}
Index: ChangeLog
===
--- ChangeLog (revision 51926)
+++ ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2005-10-19 Atsushi Enomoto <[EMAIL PROTECTED]>
+
+ * generic.cs : (ConstructedType.CheckConstraints) warn CS0310 when
+ 1) "new()" is specified as generic parameter constraint and 2) the
+ type is TypeBuilder and 3) the type is abstract even if it has a
+ default .ctor(). Now errors/gcs0310-3.cs is correctly rejected.
+
2005-10-19 Martin Baulig <[EMAIL PROTECTED]>
* class.cs (TypeContainer.DefineType): Only use ResolveAsTypeStep(),
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono
When will there be a C++ compiler for Mono? __ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] profiler patch
Anyone have any problems with this small patch so the profiler prints
names correctly when they aren't in a namespace?
Thanks
Jackson
Index: mono/metadata/profiler.c
===
--- mono/metadata/profiler.c (revision 51942)
+++ mono/metadata/profiler.c (working copy)
@@ -706,7 +706,8 @@
char *sig, *res;
sig = mono_signature_get_desc (mono_method_signature (method), FALSE);
- res = g_strdup_printf ("%s.%s::%s(%s)", method->klass->name_space, method->klass->name,
+ res = g_strdup_printf ("%s%s%s::%s(%s)", method->klass->name_space,
+ method->klass->name_space ? "." : "", method->klass->name,
method->name, sig);
g_free (sig);
return res;
@@ -874,8 +875,8 @@
} else {
isarray = "";
}
- g_snprintf (buf, sizeof (buf), "%s.%s%s",
-klass->name_space, klass->name, isarray);
+ g_snprintf (buf, sizeof (buf), "%s%%s%s",
+klass->name_space, klass->name_space ? "." : "", klass->name, isarray);
g_print ("%8" G_GUINT64_FORMAT " KB %8" G_GUINT64_FORMAT " %-48s\n", (ainfo->mem / 1024), ainfo->count, buf);
}
/* callers */
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] profiler patch
This is ok to check in. On 10/19/05, Jackson Harper <[EMAIL PROTECTED]> wrote: > Anyone have any problems with this small patch so the profiler prints > names correctly when they aren't in a namespace? > > Thanks > Jackson > > > > > ___ > 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] gmcs patch to fix gcs0310-3.cs test working
On Thu, 2005-10-20 at 04:03 +0900, Atsushi Eno wrote:
> I noticed that mcs/errors/gcs0310-3.cs is not rejected as expected.
> The attached patch fixes this problem. Does it look OK to commit?
Hi,
patch looks good, but you may run into conflicts when committing due to
my recent changes.
Cool to have you working on gmcs :-)
Martin
>
> Atsushi Eno
> Plain text document attachment (fix-cs0310-3.patch)
> Index: generic.cs
> ===
> --- generic.cs(revision 51926)
> +++ generic.cs(working copy)
> @@ -1395,7 +1395,22 @@
> if (TypeManager.IsBuiltinType (atype) ||
> atype.IsValueType)
> return true;
>
> + if (HasDefaultConstructor (ec, atype))
> + return true;
> +
> + Report.Error (310, loc, "The type `{0}' must have a
> public " +
> + "parameterless constructor in order to
> use it " +
> + "as parameter `{1}' in the generic type
> or " +
> + "method `{2}'", atype, ptype,
> DeclarationName);
> + return false;
> + }
> +
> + bool HasDefaultConstructor (EmitContext ec, Type atype)
> + {
> if (atype is TypeBuilder) {
> + if (atype.IsAbstract)
> + return false;
> +
> TypeContainer tc =
> TypeManager.LookupTypeContainer (atype);
> foreach (Constructor c in
> tc.InstanceConstructors) {
> if ((c.ModFlags & Modifiers.PUBLIC) ==
> 0)
> @@ -1425,10 +1440,6 @@
> }
> }
>
> - Report.Error (310, loc, "The type `{0}' must have a
> public " +
> - "parameterless constructor in order to
> use it " +
> - "as parameter `{1}' in the generic type
> or " +
> - "method `{2}'", atype, ptype,
> DeclarationName);
> return false;
> }
>
> Index: ChangeLog
> ===
> --- ChangeLog (revision 51926)
> +++ ChangeLog (working copy)
> @@ -1,3 +1,10 @@
> +2005-10-19 Atsushi Enomoto <[EMAIL PROTECTED]>
> +
> + * generic.cs : (ConstructedType.CheckConstraints) warn CS0310 when
> + 1) "new()" is specified as generic parameter constraint and 2) the
> + type is TypeBuilder and 3) the type is abstract even if it has a
> + default .ctor(). Now errors/gcs0310-3.cs is correctly rejected.
> +
> 2005-10-19 Martin Baulig <[EMAIL PROTECTED]>
>
> * class.cs (TypeContainer.DefineType): Only use ResolveAsTypeStep(),
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] C# and SWT
Hi, I'm working on a C# GUI-based project, which I want to run on Windows/Mac/Linux, and with native widgets. It seems my only choice at the moment is wxWidgets + C# bindings. What I'd really like to use is SWT, the excellent Java GUI toolkit. Once upon a time, there was a project to port SWT to C#, but that project seems to have quietly died. 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. Any ideas or thoughts? Thanks, -elan ___ 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
Hi Elan, Why you dont uses Gtk#? Is a nice toolkit and run under Linux and Windows (I am not sure about Mac). Some months ago I make a GUI frontend to OpenVPN and I use GTK# and works fine on Windows and Linux. http://www.expl0it.de/OpenVPNAdminScreenshots.html http://www.expl0it.de/wizard.html The source code is avaliable at SourceForge, take a look at code, maybe can help you: http://sourceforge.net/projects/openvpnadmin Best resgards, Everaldo [EMAIL PROTECTED] Em Qua, 2005-10-19 às 20:08 -0700, Elan Feingold escreveu: > Hi, > > I'm working on a C# GUI-based project, which I want to run on > Windows/Mac/Linux, and with native widgets. It seems my only choice at the > moment is wxWidgets + C# bindings. What I'd really like to use is SWT, the > excellent Java GUI toolkit. > > Once upon a time, there was a project to port SWT to C#, but that project > seems to have quietly died. 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. > > Any ideas or thoughts? > > Thanks, > > -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
> 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
Re: [Mono-dev] gmcs patch to fix gcs0310-3.cs test working
Hi, >> I noticed that mcs/errors/gcs0310-3.cs is not rejected as expected. >> The attached patch fixes this problem. Does it look OK to commit? > > Hi, > > patch looks good, but you may run into conflicts when committing due to > my recent changes. Ok it's in svn now. There was no conflict. > Cool to have you working on gmcs :-) My pleasure :-) Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Re: [Mono-list] generic KeyedCollection implementation
Hi, I think this patch does what we need - some protected virtual methods such as SetItem() should be used for every content-changing methods. Can anyone review it? Atsushi Eno Carlo Kok wrote: Attached to this email an incremental patch for the KeyedCollection ( to be applied in the \mcs\class\corlib\System.Collections.ObjectModel directory. Also included is a testcase, tested with both Beta2 and my own implementation. I followed the existing testcases I could find in SVN. The two almost idental guides on the wiki seem to be out of date: http://www.mono-project.com/Test_Suite http://www.mono-project.com/Mono_Contribution_HOWTO comments? I used the SVN Patch ability of tortoisesvn, if I did that wrong, please tell me what I should use instead. -- Carlo Kok ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
