[Mono-dev] mono linker - mscorlib.dll
Hi, I am using monolinker to remove some functionality that I don't want users to have in my embedded mono application. My application uses two different C# dlls and users can change/replace one of them. However, I don't want them to have file read/write access (ex. to write viruses...). I removed those functionality from mscorlib.dll using monolinker successfully, but the application crashes afterwards. I am not using Sytem.IO at all in my original dlls. Can monolinker be used this way? If so, what might possible be wrong? Unfortunately, I don't have any debug information since Visual Studio does not show where the program crashed. The linker is from mono-2.8.1 tarball release. Thanks for any help. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Embedding Mono - NULL return value in C#
Hi, I call a c++ function from C# using mono. For instance, [MethodImplAttribute(MethodImplOptions.InternalCall)] extern internal static Object get_ai_behavior_object(int id); When the function returns a NULL object, there is a NullReferenceException. I think it occurs because C# tries to cast null to System.Object. Is there a way to avoid this without using try-catch which slows the program or a dummy Null object I need to create? Thanks, Mesut, ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] mono-Interop with Native Libraries
Hi, I've just started reading about Interop with Native Libraries in C# and Mono, so before I started doing something I want to ask more experienced people as a last resort. I wanna send a managed class (which extends another class, has another class as a field and some methods) to unmanaged C++ side. The question is, is there a way to do this without preparing the class for marshaling using something like these? [StructLayout(LayoutKind.Sequential)] [MarshalAs(UnmanagedType.LPWStr)] etc. Thanks. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] debug embedded mono
Hi, I have a C++ application that uses C sharp classes which also use C++ functions. Thus, both C++ and C sharp call each other, but main project that I run is C++. The question is how to debug this project? I tried to create a dummy start up C sharp project and call my C sharp code from there. The mono debugger works for the C sharp code, but it does not find the C++ functions that are called from within C sharp. MethodNotImplemented exception is thrown. The mono debugger does not work on C++ and regular debugger cannot access to the Mono code in C sharp. So, any information on how to do it? Sorry if it is confusing and thanks for your help. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] reloading mono domain or assemblies
Hi Lucas, you can use mono_domain_create() and mono_domain_unload() just fine from c. In fact, I suspect it's actually easier to do from native code these days. basically what you should do is: create domain set it active load your assemblies run your code when you want to reload code, unload the domain load your assemblies again run your code. I actually found similar reply from you in another discussion and I am using this solution. However, I have a problem with one of the DLLs. I cannot delete it because there are internal calls registered (mono_add_internal_call) from that DLL. I cannot delete that DLL even after unloading the domain. I don't think it is related to loading an assembly from the disk instead of memory because other DLL that does not have any method registered with mono can be deleted after unloading the domain. Do you have any idea how to solve this? Thanks. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] reloading mono domain or assemblies
Hi, We are developing a game and using C# and C++ with the help of mono. There are two dlls we use; Dll1 and Dll2. At run-time, I want to change (update) these dlls without restarting the game (which takes a while). Here is the code we use: mono_domain = mono_jit_init(Dll1); mono_world_assembly = mono_domain_assembly_open(mono_domain,Dll1); mono_world_image = mono_assembly_get_image(mono_world_assembly); mono_module_assembly = mono_domain_assembly_open(mono_domain, Dll2); mono_module_image = mono_assembly_get_image(mono_module_assembly); I tried two diferent ways, but neither was successful. I don't even know what is the exact error since I don't know how to debug mono in C++. First approach was to use mono_jit_cleanup and then when the dlls are recompiled use the code above to reload the dlls. Second approach was to close the assemblies and images and reopen them when the dlls are replaced. Did I make a mistake and/or is there a way to do this? Thanks. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] reloading mono domain or assemblies
On 13.08.2010 15:10, marcus julius wrote: Did I make a mistake and/or is there a way to do this? There are 2 ways to reload an assembly: 2) Use app domains which can be unloaded together with their assemblies by design. Thanks for the quick reply. Ok, I know how to do this in C#. Is there a way to create app domain using mono in C++? If there is, I can create my monoDomain and assemblies in that app domain, so I can unload them. Otherwise, It won't help me to create an appdomain in C# since the Dlls I want to change are locked by the mono in C++. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] SerialPort and OnDataReceived event
Hi! I was trying to run a .NET assembly generated by Microsoft tools under Mono (Linux). The application accesses the serial port and installs an event handler for the DataReceived event. Unfortunately, this handler is never called! Digging into the sources of Mono/MCS (from svn) showed that this event is never raised in SerialPort.cs. As far as I can see, this is addressed by the bug report 323892 (SerialDataReceived events/callbacks are not implemented) from 2007. (Even moma does not report this incompatibility since the event handler is implemented but the event itself is never raised) My question is now: is there any (technical) reason why this functionality is not implemented in Mono? Are you interested in a patch which might fix this? Best regards from Chemnitz/Germany! Marcus ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono.Simd and Threefish256
As part of my free time, I decided to start down the path to SIMD-ing some cryptography algorithms. As a starter exercise, I took Threefish256 from the SHA-3 submission Skein. The experience was very enlightening, and as I haven't been able to find anything of substance out there about working with Mono.Simd, I thought I'd write some articles about it. I'm posting my experience to my blog in a 5-part series. The first of the posts has already been published, and I'll have the rest ready by the end of the weekend: http://blog.xpdm.us/2009/10/01/skein-threefish-and-mono-simd-part-1/ Thanks to all the folks who've been keeping the Mono.Simd project going. -- Marcus Griep signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Update C5 to v1.1.0
I have posted an update with the unit tests disabled. Because the first patch was large and difficult to prepare in the first place, I have let it be, and added a second, meta patch, which is to be applied to the results of the first patch. Here are the links again: http://wiki.xpdm.us/_media/mono/v1.1.0.patch.gz http://wiki.xpdm.us/_media/mono/v1.1.0.meta.patch They should be applied in that order, and the result should `make check` properly. I still have not heard back from the original maintainers, so I will be working proactively to maintain the library going forward, including fixing up the test cases and general code base to quality expectations. On Fri, 2009-07-31 at 13:46 +0200, Zoltan Varga wrote: Hi, Since the old version could run its unit tests under mono, the new version should too, or the failing tests should be disabled. Zoltan On Fri, Jul 31, 2009 at 1:48 AM, Marcus Griep mar...@griep.us wrote: I did notice these, and I'll go over each of them. I figured that the priority was getting the verbatim upstream ported over and then fixing them since the upstream hasn't been maintained since this version was released. Several hash table tests depend on DEBUG-mode specific behavior; when compiled with DEBUG defined, hash tables use a preset seed, but when compiled for release, hash tables are randomized. The majority of the failures in the unit tests are due to this. There is one failure that is due to a method not being implemented in v1.1.0, hence the not implemented exception. I can correct this as well. What would be the proper way to proceed here? On Thu, 2009-07-30 at 22:40 +0200, Zoltan Varga wrote: Hi, The patch applies cleanly, but there are some test failures when running 'make check' in the Mono.C5 directory. Zoltan On Thu, Jul 30, 2009 at 5:49 PM, Marcus Griep mar...@griep.us wrote: I am not attaching the patch here directly because, even gzip'ed, it stands at over 450KB. Instead, it is being hosted at http://wiki.xpdm.us/_media/mono/v1.1.0.patch.gz The library in general is still in need of some TLC, and as the upstream hasn't been updated in a year and a half, I am trying to contact the original developers of C5 to determine if there will be further development. If not, I will likely be maintaining a new repository for C5 and plan to continue maintaining and developing the C5 library, as well as providing updates for Mono.C5. Also, be aware that there may be line ending issues when applying this patch. -- Marcus Griep GPG Key ID: 0x070E3F2D —— https://torproj.xpdm.us Ακακια את.ψο´, 3° ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Marcus Griep GPG Key ID: 0x070E3F2D —— https://torproj.xpdm.us Ακακια את.ψο´, 3° -- Marcus Griep GPG Key ID: 0x070E3F2D —— https://torproj.xpdm.us Ακακια את.ψο´, 3° signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Update C5 to v1.1.0
I am not attaching the patch here directly because, even gzip'ed, it stands at over 450KB. Instead, it is being hosted at http://wiki.xpdm.us/_media/mono/v1.1.0.patch.gz The library in general is still in need of some TLC, and as the upstream hasn't been updated in a year and a half, I am trying to contact the original developers of C5 to determine if there will be further development. If not, I will likely be maintaining a new repository for C5 and plan to continue maintaining and developing the C5 library, as well as providing updates for Mono.C5. Also, be aware that there may be line ending issues when applying this patch. -- Marcus Griep GPG Key ID: 0x070E3F2D —— https://torproj.xpdm.us Ακακια את.ψο´, 3° signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Update C5 to v1.1.0
I did notice these, and I'll go over each of them. I figured that the priority was getting the verbatim upstream ported over and then fixing them since the upstream hasn't been maintained since this version was released. Several hash table tests depend on DEBUG-mode specific behavior; when compiled with DEBUG defined, hash tables use a preset seed, but when compiled for release, hash tables are randomized. The majority of the failures in the unit tests are due to this. There is one failure that is due to a method not being implemented in v1.1.0, hence the not implemented exception. I can correct this as well. What would be the proper way to proceed here? On Thu, 2009-07-30 at 22:40 +0200, Zoltan Varga wrote: Hi, The patch applies cleanly, but there are some test failures when running 'make check' in the Mono.C5 directory. Zoltan On Thu, Jul 30, 2009 at 5:49 PM, Marcus Griep mar...@griep.us wrote: I am not attaching the patch here directly because, even gzip'ed, it stands at over 450KB. Instead, it is being hosted at http://wiki.xpdm.us/_media/mono/v1.1.0.patch.gz The library in general is still in need of some TLC, and as the upstream hasn't been updated in a year and a half, I am trying to contact the original developers of C5 to determine if there will be further development. If not, I will likely be maintaining a new repository for C5 and plan to continue maintaining and developing the C5 library, as well as providing updates for Mono.C5. Also, be aware that there may be line ending issues when applying this patch. -- Marcus Griep GPG Key ID: 0x070E3F2D —— https://torproj.xpdm.us Ακακια את.ψο´, 3° ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Marcus Griep GPG Key ID: 0x070E3F2D —— https://torproj.xpdm.us Ακακια את.ψο´, 3° signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Change Mono.C5 from common lib to net_2_0 lib
Currently Mono.C5 builds even as part of the net_1_1 profile. This is unnecessary as Mono.C5 provides and consumes generics, and thus depends on net_2_0 at minimum. In order to build in net_1_1, all the files in Mono.C5 are surrounded by #ifdef NET_2_0 directives, leading to effectively empty files being built into an uninstalled library in the net_1_1 profile. This patch cleans up the Mono.C5 build by moving it to the net_2_0 profile and removing the now unnecessary #ifdef guards. -- Marcus Griep GPG Key ID: 0x070E3F2D —— https://torproj.xpdm.us Ακακια את.ψο´, 3° Index: class/Makefile === --- class/Makefile (revision 137818) +++ class/Makefile (working copy) @@ -39,7 +39,6 @@ System.Drawing \ System.Transactions \ System.EnterpriseServices \ - Mono.C5\ Mono.Data.Tds \ System.Data \ Mono.Data \ @@ -116,6 +115,7 @@ System.ServiceModel \ System.ServiceModel.Web \ System.Web.Mvc \ + Mono.C5\ Mono.Management \ Mono.Options \ Mono.Simd \ Index: class/Mono.C5/add-conditional.pl === --- class/Mono.C5/add-conditional.pl (revision 137818) +++ class/Mono.C5/add-conditional.pl (working copy) @@ -1,16 +0,0 @@ -#!/usr/bin/perl -w -use strict; - -foreach my $file (@ARGV) { -open FILE,+,$file; -my $contents = ; -while (defined ($_ = FILE)) { - $contents .= $_; -} -truncate FILE, 0; -seek FILE, 0, 0; -print FILE #if NET_2_0\n; -print FILE $contents . \n; -print FILE #endif\n; -close FILE; -} Index: class/Mono.C5/C5/Dictionaries.cs === --- class/Mono.C5/C5/Dictionaries.cs (revision 137818) +++ class/Mono.C5/C5/Dictionaries.cs (working copy) @@ -1,4 +1,3 @@ -#if NET_2_0 /* Copyright (c) 2003-2006 Niels Kokholm and Peter Sestoft Permission is hereby granted, free of charge, to any person obtaining a copy @@ -1294,4 +1293,3 @@ } } -#endif Index: class/Mono.C5/C5/hashing/HashTable.cs === --- class/Mono.C5/C5/hashing/HashTable.cs (revision 137818) +++ class/Mono.C5/C5/hashing/HashTable.cs (working copy) @@ -1,4 +1,3 @@ -#if NET_2_0 /* Copyright (c) 2003-2006 Niels Kokholm and Peter Sestoft Permission is hereby granted, free of charge, to any person obtaining a copy @@ -1599,5 +1598,3 @@ } } - -#endif Index: class/Mono.C5/C5/hashing/HashBag.cs === --- class/Mono.C5/C5/hashing/HashBag.cs (revision 137818) +++ class/Mono.C5/C5/hashing/HashBag.cs (working copy) @@ -1,4 +1,3 @@ -#if NET_2_0 /* Copyright (c) 2003-2006 Niels Kokholm and Peter Sestoft Permission is hereby granted, free of charge, to any person obtaining a copy @@ -677,5 +676,3 @@ #endregion } } - -#endif Index: class/Mono.C5/C5/hashing/HashDictionary.cs === --- class/Mono.C5/C5/hashing/HashDictionary.cs (revision 137818) +++ class/Mono.C5/C5/hashing/HashDictionary.cs (working copy) @@ -1,4 +1,3 @@ -#if NET_2_0 /* Copyright (c) 2003-2006 Niels Kokholm and Peter Sestoft Permission is hereby granted, free of charge, to any person obtaining a copy @@ -76,4 +75,3 @@ } } -#endif Index: class/Mono.C5/C5/Collections.cs === --- class/Mono.C5/C5/Collections.cs (revision 137818) +++ class/Mono.C5/C5/Collections.cs (working copy) @@ -1,4 +1,3 @@ -#if NET_2_0 /* Copyright (c) 2003-2006 Niels Kokholm and Peter Sestoft Permission is hereby granted, free of charge, to any person obtaining a copy @@ -1519,5 +1518,3 @@ #endregion } } - -#endif Index: class/Mono.C5/C5/trees/RedBlackTreeDictionary.cs === --- class/Mono.C5/C5/trees/RedBlackTreeDictionary.cs (revision 137818) +++ class/Mono.C5/C5/trees/RedBlackTreeDictionary.cs (working copy) @@ -1,4 +1,3 @@ -#if NET_2_0 /* Copyright (c) 2003-2006 Niels Kokholm and Peter Sestoft Permission is hereby granted, free of charge, to any person obtaining a copy @@ -79,4 +78,3 @@ } } -#endif Index: class/Mono.C5/C5/trees/RedBlackTreeBag.cs === --- class/Mono.C5/C5/trees/RedBlackTreeBag.cs (revision 137818) +++ class/Mono.C5/C5/trees/RedBlackTreeBag.cs (working copy) @@ -1,4 +1,3 @@ -#if NET_2_0 /* Copyright (c) 2003-2006 Niels Kokholm and Peter Sestoft Permission is hereby granted, free of charge, to any person obtaining a copy @@ -4488,6 +4487,3 @@ } } - - -#endif Index: class/Mono.C5/C5/trees/RedBlackTreeSet.cs === --- class/Mono.C5/C5/trees/RedBlackTreeSet.cs (revision 137818) +++ class/Mono.C5/C5/trees/RedBlackTreeSet.cs (working copy
[Mono-dev] [PATCH] Squash 444388 and catch miss on 323096
Bug 444388 [https://bugzilla.novell.com/show_bug.cgi?id=444388] is a pretty obscure bug that hits very few people, but I find myself among them. Attempting to bring the latest version of C5 to Mono, I found an issue with member resolution when interfaces hide members of parent interfaces. After sitting on it for a while, I was able to reach my own itch. The full explanation is long, and if you're interested in the background of the bug and how I came to this patch, check my *full* writeup here: http://wiki.xpdm.us/mono/bug444388. The executive summary is that this patch fixes 444388, and also fixes a bug introduced by the fix to 323096 (which caused incorrect resolution in similar cases). As well, it adds two additional test cases to the test suite to prevent future regressions. If that's too succinct, let me know, and I'll respond more fully to the list. -- Marcus Griep GPG Key ID: 0x070E3F2D —— https://torproj.xpdm.us Ακακια את.ψο´, 3° Index: tests/ver-il-gmcs.xml === --- tests/ver-il-gmcs.xml (revision 137658) +++ tests/ver-il-gmcs.xml (working copy) @@ -42689,4 +42689,49 @@ /method /type /test -/tests \ No newline at end of file + test name=test-723.cs +type name=Test + method name=Void .ctor() +size7/size + /method + method name=Int32 get_Count() +size2/size + /method +/type +type name=Maine + method name=Void .ctor() +size7/size + /method + method name=Int32 Main() +size21/size + /method +/type + /test + test name=test-724.cs +type name=Concrete + method name=Void .ctor() +size7/size + /method + method name=String A.get_Spec() +size6/size + /method + method name=String B.get_Spec() +size6/size + /method + method name=String get_Spec() +size6/size + /method +/type +type name=Test + method name=Void .ctor() +size7/size + /method + method name=Int32 DoTest(String, String, String, Int32) +size29/size + /method + method name=Int32 Main() +size110/size + /method +/type + /test +/tests Index: tests/test-724.cs === --- tests/test-724.cs (revision 0) +++ tests/test-724.cs (revision 0) @@ -0,0 +1,46 @@ +public class Test +{ + private static int DoTest (string type, string expected, string actual, int failcode) + { + if (! actual.Equals (expected)) { + System.Console.WriteLine (Bad {0}: Expected {1}, Was {2}, + type, expected, actual); + return failcode; + } + return 0; + } + + public static int Main () + { + int failure = 0; + Concrete val = new Concrete (); + + failure |= DoTest(A, A, ((A) val).Spec, 0x01); + failure |= DoTest(B, B, ((B) val).Spec, 0x02); + failure |= DoTest(C, B, ((C) val).Spec, 0x04); + failure |= DoTest(Concrete, Concrete, val.Spec, 0x08); + + return failure; + } +} + +interface A +{ + string Spec { get; } +} + +interface B : A +{ + new string Spec { get; } +} + +interface C : B +{ +} + +class Concrete : C +{ + string A.Spec { get { return A; } } + string B.Spec { get { return B; } } + public string Spec { get { return Concrete; } } +} Index: tests/test-723.cs === --- tests/test-723.cs (revision 0) +++ tests/test-723.cs (revision 0) @@ -0,0 +1,34 @@ +interface ICollectionValue +{ + int Count { get; } +} + +interface ISCGCollection +{ + int Count { get; } +} + +interface ICollection : ISCGCollection, ICollectionValue +{ + new int Count { get; } +} + +interface ISequenced : ICollection +{ +} + +class Test : ISequenced +{ + public int Count { get { return 0; } } +} + +static class Maine +{ + public static int Main () + { +ISequenced t = new Test (); +if (t.Count != 0) + return 1; +return 0; + } +} Index: mcs/ecore.cs === --- mcs/ecore.cs (revision 137658) +++ mcs/ecore.cs (working copy) @@ -715,27 +715,34 @@ continue; } - if (non_methods == null) { + if (non_methods == null) non_methods = new ArrayList (2); - non_methods.Add (m); - continue; - } - foreach (MemberInfo n_m in non_methods) { - if (m.DeclaringType.IsInterface TypeManager.ImplementsInterface (m.DeclaringType, n_m.DeclaringType)) + foreach (MemberInfo n_m in (ArrayList)non_methods.Clone()) { + if (n_m.DeclaringType.IsInterface TypeManager.ImplementsInterface (m.DeclaringType, n_m.DeclaringType)) { + non_methods.Remove (n_m); + } else if (m.DeclaringType.IsInterface TypeManager.ImplementsInterface (n_m.DeclaringType, m.DeclaringType)) { continue; - - Report.SymbolRelatedToPreviousError (m); - Report.Error (229, loc, Ambiguity between `{0}' and `{1
[Mono-dev] Integrating Mono.Simd into Mono.Math, Mono.Security
Hello all, First, by way of introduction, I'm Marcus Griep, a .NET/Mono developer for some time now, and a contributor to such projects as Boo, C5, and git. In a sort of scratch-my-own-itch style, I'm looking to speed up the computationally time consuming steps of BigInteger math by using Mono.Simd in Mono.Math. This would then vicariously speed up various cryptographic functions that rely on BigIntegers, such as primality tests in RSA, and could be futher extended to using Mono.Simd throughout Mono.Security. Mono.Math resides within Mono.Security, so I would be creating a dependency from Mono.Security to Mono.Simd. Also, Mono.Math is incorporated internally within corlib, which would probably mean interning Mono.Simd in corlib as well. One confounding factor is that Mono.Simd uses extension methods, thus depending on System.Core, and being a 2.0-only library. With the 1.1 world still around, incorporation of Mono.Simd into corlib and Mono.Security will probably require some precision cuts to get 1.1 working independently of Mono.Simd, while letting 2.0 utilize it. (Another option is to reduce the dependency on the VectorOperations extension methods, making them normal static methods when built to 1.1). The intended outcome is that Mono's cryptographic libraries will see a nice speedup when run on systems supporting SIMD. Since this is my first major delve into Mono, in a contributory sense, any input, corrections, or advice are welcome as I try to wrap my head around what actually needs to be done. -- Marcus Griep GPG Key ID: 0x070E3F2D —— https://torproj.xpdm.us Ακακια את.ψο´, 3° signature.asc Description: OpenPGP digital signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] C/C++ Compiler for Mono environment?
I've googled, but I don't find any info on C or C++ compilers that target the CLR. I did find a couple of partial results, but nothing that actually seems to work. Is there a working C/C++ Compiler for Mono? (Other than MSFT VS) Do you need something that will compile C and C++ or just C? Are you looking something with capabilities like MS's compiler that can interface with both existing C++ libs and C# code and has IJW (it just works) marshaling? Not strictly mono, but also open source project implementing the .Net runtime and tools, Portable.Net has a C compiler they claim works: http://www.dotgnu.org/pnet.html I haven't ever used it personally nor looked at it, but it probably works fine when compiling C to IL. It won't run under mono, though - you need the pnet runtime. The assemblies produced by the Portable.NET C compiler will run under Mono once you install the OpenSystem.C.dll and libc.dll assemblies. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] What about the new GC?
I can't answer the question about when Mono will have a precise garbage collector, but I think that you might be confusing several issues involving garbage collection. The current Boehm GC is designed so that it will work in environments that traditionally do not use garbage collection, such as C++. Similar collectors have been used in languages such as Modula-3 that do not have a distinct barrier between managed and unmanaged pointers. During the a garbage collection phase, it is possible to find a word that that might possibly be a valid pointer into the garbage collected heap. In this case, a conservative collection has to assume that it is a valid pointer and not free the storage to which the word might point. When you mentioned not really releasing memory to the OS, that sounds more like the problem that the Boehm GC (at least the version used in Mono) does not compact the heap. I think that Mono's variant of Boehm does try harder to fit objects into exactly the right sized hole, though. But if enough objects of just the wrong size are allocated, it's possible to end up an ever-expanding, horribly-fragmented heap with lots of unused spaces in the middle. On Thursday 15 December 2005 6:51 am, Hubert FONGARNAND wrote: Hi! I know that mono uses today a conservative garbage collector (it means that, the GC doesn't really release the memory to the OS). I've read that a new Precise Garbage Collector (maybe the intel's one) would be used. When do you plan do deploy this new GC? Because today, the same application ask more heap memory on mono that on MS.NET (which use a precise garbage collector) ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] 64 bit time
When I got my new motherboard and processor (AMD64), I just built from the source tarball for the latest release. Then I updated to the latest SVN version after that. I also use --libdir=/usr/local/lib64, as I do for all my 64-bit libs, but Mono's platform independent libs (managed DLLs) still install in /usr/local/lib. If I recall, I have installed the 32-bit and 64-bit versions in parallel, but I am not positive about this. On Monday 05 December 2005 2:28 pm, Paul wrote: Hi, I'm moving onto a 64 bit platform tonight (new mobo and processor). Is there anything I need to be aware of when I recompile Mono? (for example, make get-monolite-latest will grab the 32 bit version, will the final version installed be 64 bit?) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-list] JIT Developers Grants Offered
DotGNU opens 2 grants of $4500 each: one grant for work on libJIT, a library to make JITs, another to implement a JIT with libJIT in Portable.NET. The money will be divided in proportion to all contributors to each project according to their work on the project. The percentage of participation will be decided by Rhys Weatherley, the original author of libJIT, most active contributor to the Portable.NET project during last years, and director of Southern Storm Software. Those who are interested in taking part in the grant should join the #DotGNU channel of freenode.net and the Developers and libJIT mailing lists (see http://dotgnu.org/mailman/listinfo). ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] how to improve mono performance
From the measurements I've taken, MS .NET is generally 2 to 3 times faster than Mono, both using micro-benchmarks and applications that do real work. I would also point out that your .NET test was on MS, whereas your Mono test was on Linux. Exception-handling on MS is thought to be very slow. So that might explain part of the reason why Mono was so much faster on that component. As for the strings and StringBuilder, in MS, string and StringBuilder share some internal data structures and use a helper class. So their string operations and conversions between string and StringBuilder are very fast. That being said, some possible reasons for slowness: ArrayList/StringBuilder: Likely the GC. Floating Point: I think msft may be taking advantage of some special hardware stuff. I highly doubt this is relevant to your application. Exceptions: We super optimized this path :-) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-list] XSP Configuration
Hi! Where can I find some documentation about the possible configurations of XSP? I installed XSP and the ASP.NET examples an Debian Sarge and found these two files: /etc/xsp/debian.webapp /etc/xsp/conf.d/asp.net-examples/10_asp.net-examples How does XSP know about debian.webapp and why does 10_asp.net-examples has this 10_ prefix? I tried to port a ASP.NET Application from IIS to Debian, but whenever I call another file than default.aspx, I get HTTP 401 (Unauthorized). How can I grant access to all files to everyone? Greetings, Marcus ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-dev] System.DLL
Hi! I send this email to Mono-list@lists.ximian.com and I did not get any answer. Since I searched the web and I did nod found any useful information, I'm trying my luck here. If you know a better place to look or to ask for help, please tell me. I want to run .net windows forms applications on debian sarge. Apparently, some .dll - .so mappings are missing in my /etc/mono/config, since the applications can't find most of the DLLs, e.g. System.Dll, etc. Where can I lookup the .dll - .so mappings and correct the config file manually? I think there must be some documentation about this, but all I can find is a description about the syntax of the config file, not about the used mappings within mono ... Or did I make the wrong conclusion on the error message An exception was thrown by the type initializer for Mono.Unixe.Native.Syscall --- System.DllNotFoundException? Thanks for any assistance. Greetings, Marcus ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Re: Questions in Interop
The Mono layout looks similar to IBM's JVM, but not to Sun's reference implementation. For ordinary objects in Sun's reference implementation, the first field contains a pointer to a header. The first element of the header points to the instrance variables. The second element of the header points to method table. IBM reorganized the state so that an object points to a method table first, then a lock word, and then goes a list of instance variable. I can find some more details if you are interested, especially Paolo. On Tuesday 04 October 2005 9:26 am, Paolo Molaro wrote: Also, can I assume that the runtime object layout would be similar to windows as described in the msdn document http://msdn.microsoft.com/msdnmag/issues/05/05/JITCompiler/default.aspx. Currently Mono objects have a two word header, followed by the fields. the first word in the header is a MonoVTable pointer. Inside the MonoVTable you can find a pointer to the MonoClass describing the object. I guess basically all the java, .net etc runtimes have a very similar layout as this. lupus ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Re: On Mono and Patents ... again
These issues about patents could be said about every piece of software out there. On Saturday 01 October 2005 3:46 pm, Ralf Reiterer wrote: This kind of thread seems to pop up quarterly or semiannually. I long for a mono-fud or mono-patents or some such mailing list to keep this from cluttering the main list. You should not underestimate the importance of this issue as it is one of the *few* arguments that Mono/.NET opponents bring up against that technology at every occasion, just look in diverse forums and blogs. But more important, it might keep off companies from using Mono. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Re: On Mono and Patents ... again
This kind of thread seems to pop up quarterly or semiannually. I long for a mono-fud or mono-patents or some such mailing list to keep this from cluttering the main list. On Friday 30 September 2005 8:20 am, Robert Jordan wrote: It's really useless to talk about patents. It's even unclear whether MSFT owns (or has licenced from the respective owners) all patents for the BCL. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] C# 3.0
Most of the features look like solutions in search of a problem, especially implicitly typed local variables and object and collection initializers. I have used languages that do have these features, and I really do not miss them in C#. Some of the other features like lambda expressions and anonymous types might be useful in some cases, but I'm afraid that people will they will be over-used by programmers who just cannot resist using these new features. If you give someone a hammer, he will find something that needs hammering. On Wednesday 14 September 2005 4:48 pm, Paul wrote: Hi There are some interesting new features being proposed for C# 3.0If your interested then look at http://msdn.microsoft.com/vcsharp/future/default.aspx (in particular the hands-on-lab .doc file). ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono on AMD64
I filed a bug report: http://bugs.ximian.com/show_bug.cgi?id=75839 On Wednesday 17 August 2005 8:56 am, Miguel de Icaza wrote: I think I fixed my problem. This is going to sound strange, and I cannot explain exactly why this behavior occurred. I just hope that it helps someone who is searching the archives. I upgraded my system from Athlon to Athlon64 recently, moving from i585 SUSE to x86_64. I installed mono-1.1.8.3 from the source tarball. The mono process would just freeze when I tried to use it. However, I remembered that my SUSE 9.3 DVD had a copy of mono on it, and it worked fine. I then used the SUSE 9.3 DVD version to build recent CVS version of Mono. But when I tried to the recent CVS (after installing it and removing Mono RPM from SUSE 9.3), it would freeze, too. Finally, I had a thought that maybe I needed to remove ~/.wapi. It was just a hunch. Apparently, that fixed my problems. I had kept /home when I upgraded and reinstalled SUSE, and apparently, some newer versions of Mono do not like having the old ~/.wapi around. I guess that's why the SUSE 9.3 RPM worked all right, but I'm not really sure. Mhm, that does ring a bell, someone else had mentioned that a few days ago. I guess we need to take care of this. Could you file a report? ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Mono on AMD64
Is there some special trick to getting Mono to run on AMD64? I downloaded and built mono-1.1.8.3 on SUSE 9.3 x86_64. Attempting to run mono apps like mcs (even with no parameters) just results in Mono's consuming lots of CPU time. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono on AMD64
I think I fixed my problem. This is going to sound strange, and I cannot explain exactly why this behavior occurred. I just hope that it helps someone who is searching the archives. I upgraded my system from Athlon to Athlon64 recently, moving from i585 SUSE to x86_64. I installed mono-1.1.8.3 from the source tarball. The mono process would just freeze when I tried to use it. However, I remembered that my SUSE 9.3 DVD had a copy of mono on it, and it worked fine. I then used the SUSE 9.3 DVD version to build recent CVS version of Mono. But when I tried to the recent CVS (after installing it and removing Mono RPM from SUSE 9.3), it would freeze, too. Finally, I had a thought that maybe I needed to remove ~/.wapi. It was just a hunch. Apparently, that fixed my problems. I had kept /home when I upgraded and reinstalled SUSE, and apparently, some newer versions of Mono do not like having the old ~/.wapi around. I guess that's why the SUSE 9.3 RPM worked all right, but I'm not really sure. On Monday 15 August 2005 11:41 pm, Marcus wrote: Is there some special trick to getting Mono to run on AMD64? I downloaded and built mono-1.1.8.3 on SUSE 9.3 x86_64. Attempting to run mono apps like mcs (even with no parameters) just results in Mono's consuming lots of CPU time. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] mcs compiler options
When invoking mcs, I have noticed that non-csc variants of options, such as -o instead of -out: now produce a warning. Is there a timeline for eliminating those old-style options from mcs? ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-devel-list] Guidelines: Application Deployment; Feedback requested.
I remember that MSBuild originally did not use the GAC. Then they changed their minds. A brief summary of the situation is given in http://channel9.msdn.com/wiki/default.aspx/MSBuild.MsbuildAssembliesInTheGac. I do wish that they had elaborated on the problems that putting the assemblies in the GAC created. On Sunday 26 June 2005 3:27 pm, Ben Maurer wrote: Of course, one other advantage of non-gac'd installs is that they are more relocatable. In fact, you could do xcopy deploy that way. It really only makes sense to use the GAC if what you are deploying is a shared library, right? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] MSBuild implementation and Google Summer of code
MS's implementation does not use the XmlSerializer class to read and parse the project build files. I have not been able to find detailed information about many aspects of MSBuild. Some of the big picture items are covered in articles, but there are many methods those precise effect is not clear. The docs that I have found are mostly stubs with no substantial description. On Monday 13 June 2005 2:38 pm, Marek Sieradzki wrote: 2. Am i right with that: MSBuild implementation should consist of 3 parts: xml parser(using XmlSerializer), classes from 4 above mentioned namespaces and a command line tool? 3. Which documentation should I use? There are(in MSDN): .NET Framework reference about Longhorn and some notes about msbuild app. 4. What about methods typical to Win32 API? Like Microsoft.Build.Utilities.ToolLocationHelper.GetDotNetFrameworkRootRegistry Key(). 5. Is anyone able to contact with Rob Tillie [EMAIL PROTECTED]? He started the implementation that is available in svn/md. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Contribution to MSBuild
I have looked at that documentation. That documentation appears to be automatically generated by reflection on the MSBuild assemblies. There is no human-written documentation that elaborates on how things work and fit together. On Tuesday 03 May 2005 12:10 am, Anirudh Chandrakant wrote: Hi marcus, i am not very familiar with MSBuild as yet... but have decided to look into it asap. Regarding documentation of microsoft.build.* namespaces... you might want to have a look at the vs2005 documentation at http://msdn2.microsoft.com/library/ms123457(en-us,vs.80).aspx hope that helps... let me know if you are interested in pursuing this further, we can work out something... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] export C issues
I do not fully understand what you are asking, but I can try to help. I'm not familiar with directive 'export C ', although I have used `extern C'. In any case, when a library is compiled as C++, the symbols in the resulting binary will be mangled. For example, _Z16freyjaCSharpTestv looks like the kind of mangled name that GCC = 3.0 generates. It varies from compiler to compiler. The Mono runtime does not know about mangling, so with [DllImport(libname, EntryPoint=freyjaSpawn)] public extern static void run(); the runtime looks for a name freyjaSpawn and does not find it because the actual symbol in the library appears as _Z [mangled name]. The mangling varies from compiler to compiler (MS's C++ compilers mangle symbols very differently from GCC) and from version to version. GCC prior to 3.0 mangled symbols in a completely different way from GCC since 3.0. But even within the 3.x series of GCC there have been changes to mangling (due to misinterpretations of the mangling documentation, as far as I know). Marcus On Saturday 30 April 2005 10:42 pm, Mongoose wrote: I have confirmed it. C export won't work with DllImport. C# [DllImport(libname, EntryPoint=_Z16freyjaCSharpTestv)] public extern static void run2(); [DllImport(libname, EntryPoint=freyjaSpawn)] public extern static void run(); C++ - export C { void freyjaSpawn(); } void freyjaCSharpTest(); Test() imports and Spawn() doesn't. Test is actually a C++ function that calls Spawn, so I guess I can use mangled symbols for binary releases until mono is fixed. I may write an auto demangler in C# if it's too much work to resymbol every build. =) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Mono licence
This issue comes up every few months. If everyone quit distributing software because of fear that the software *might* infringe on someone's patent, nothing would ever get distributed. Also, even if MS were to agree not to enforce any patents that Mono might violate, that does not mean that some company other than MS might try to enforce their patents. By your logic, Fedora should stop distributing the Linux kernel until they have patent releases from HP, since the Linux kernel might violate some patent related to VMS. On Saturday 19 March 2005 6:13 pm, Paul wrote: Hi, The licensing info is right on the web site http://www.mono-project.com/FAQ:_Licensing Soo, we're all basically entrusting a company which has been proven to lie and deceive not to turn the knife. Just because there is something verbal to EMCA does not a legal waiver make. As it stands, until there is a written waiver in the hands of Novell from MS, the code cannot be legally released under the GPL as it infringes on the held and provable patents of another company. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-devel-list] Mono tested on CLI-Grande
CLI-Grande is a port of the well-known Java-Grande set of tests to the CLI. I'm attaching some results for recent CVS (15 March 2005) Mono versus the 1.0.6 branch. It probably is not meaning simplify to average all of the subtest together. However, it is instructive to look at each test across the versions and to see how the optimization selection affects different tests. I will recant some of what I have said recently about performance increases. There are some improvements in Mono's execution speed since the 1.0.6 release. I do not know whether binaries attachments to mailing list items work correctly or the best format. Mono hacker types seem to read OO.org spreadsheet, so I'll try that initially. If anyone cannot get it or wants CSV, let me know. I'm looking for an online copy, but the author of the program seems to have let his domain name expire. Ouch! Marcus tests.sxc Description: OpenOffice Calc spreadsheet
Re: [Mono-list] Computer Language Shootout Benchmarks
On the benchmark tests like CLI-Grande (port of Java-Grande), Scimark, and so forth, I have not seen an overall speed increase in approximately the past year. I suspect that on average, Mono 1.1.4 will not be any faster than 1.0.6. In fact, with -O=all, recent releases are actually slower than older ones. (The ssapre optimization in particular seems to slow things down substantially.) On Friday 11 March 2005 6:25 pm, Mario Sopena wrote: Hello, We really welcome improvements/alternatives to the existing programs, and contributions for the micro-benchmarks we haven't done yet. I've realized you use Mono 1.0.5. You should use Mono 1.1.4. Is the one suggested by experts (a lot of improvements aren't backported). Look in the released notes of the 1.0.6: ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] random numbers
Look in the class System.Random. On Tuesday 01 March 2005 10:43 pm, Thomas E. Vaughan wrote: Browsing through the mono documentation, I did not stumble upon a random number generator. Is there a good random number generator available in the mon-1.1.4 distribution? ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Problem converting a string to double
I am a Mono newbie and this may be a real stupid question. I am running Mono 1.0 on Fedora Core 1, setup to Brazilian locale. I am beginning to port the front-end of a scientific application from C to C# and intend to use Mono+C#+GTK# to get user input, read/pase/write data and P/Invoke the mathematical back-end written in C. I have lots of data files, with all my data stored in CSV format. So, I wrote a class to open a file, read its lines, split the fields and fill a matrix with its values. In this process, I invoke the String.ToDouble method to convert the strings read from the file to double values. The problem is that the ToDouble method is giving weird results, ignoring the (default) point decimal separator. For instance, there is a sample output from the last line of a small datafile, showing line number, column number, string representing the value and the value converted with ToDouble: aux = 13, aux2 = 0, colunas[0] = 14, matriz[13,0] = 14 aux = 13, aux2 = 1, colunas[1] = 18.015, matriz[13,1] = 18015 aux = 13, aux2 = 2, colunas[2] = 647.3, matriz[13,2] = 6473 aux = 13, aux2 = 3, colunas[3] = 221.2, matriz[13,3] = 2212 aux = 13, aux2 = 4, colunas[4] = 0.0571, matriz[13,4] = 571 aux = 13, aux2 = 5, colunas[5] = 0.235, matriz[13,5] = 235 aux = 13, aux2 = 6, colunas[6] = 0.344, matriz[13,6] = 344 aux = 13, aux2 = 7, colunas[7] = 32.24, matriz[13,7] = 3224 aux = 13, aux2 = 8, colunas[8] = 0.001924, matriz[13,8] = 1924 aux = 13, aux2 = 9, colunas[9] = 1.055e-05, matriz[13,9] = 0,01055 aux = 13, aux2 = 10, colunas[10] = -3.596e-09, matriz[13,10] = -3,596E-06 aux = 13, aux2 = 11, colunas[11] = -242000, matriz[13,11] = -242000 aux = 13, aux2 = 12, colunas[12] = 373.2, matriz[13,12] = 3732 For aux2=8, the string read is 0.001924, but ToDouble(0.001924) gives 1924. And so on The only way to get a correct result is using ToDouble(strvalue,provider), with provider set as NumberFormatInfo provider = new NumberFormatInfo( ); provider.NumberDecimalSeparator = .; With this code, I get aux = 13, aux2 = 0, colunas[0] = 14, matriz[13,0] = 14 aux = 13, aux2 = 1, colunas[1] = 18.015, matriz[13,1] = 18,015 aux = 13, aux2 = 2, colunas[2] = 647.3, matriz[13,2] = 647,3 aux = 13, aux2 = 3, colunas[3] = 221.2, matriz[13,3] = 221,2 aux = 13, aux2 = 4, colunas[4] = 0.0571, matriz[13,4] = 0,0571 aux = 13, aux2 = 5, colunas[5] = 0.235, matriz[13,5] = 0,235 aux = 13, aux2 = 6, colunas[6] = 0.344, matriz[13,6] = 0,344 aux = 13, aux2 = 7, colunas[7] = 32.24, matriz[13,7] = 32,24 aux = 13, aux2 = 8, colunas[8] = 0.001924, matriz[13,8] = 0,001924 aux = 13, aux2 = 9, colunas[9] = 1.055e-05, matriz[13,9] = 1,055E-05 aux = 13, aux2 = 10, colunas[10] = -3.596e-09, matriz[13,10] = -3,596E-09 aux = 13, aux2 = 11, colunas[11] = -242000, matriz[13,11] = -242000 aux = 13, aux2 = 12, colunas[12] = 373.2, matriz[13,12] = 373,2 Which is the expected and printed with the brazilian setup's comma decimal separator, instead of the point which I coded into the class. My question is: should it be really necessary to set the culture information to perform such a simple task, when the decimal separator is the default point? I thought I would only have to do it if I was using a localized decimal separetor (as the portuguese-style comma). Is this the expected behavior? Or the environmental locale should really affect the internal conversion? Thanks in advance, Marcus Vinicius P.S.: The demo code is below (with NumberFormatInfo) : // created on 28/12/2004 at 13:34 using System; using System.IO; using System.Text.RegularExpressions; using System.Globalization; public class ReadData { public static void Main(string [] args) { string filename = compostos.csv; string[] colunas; string[] linhas; string text; int aux, aux2; NumberFormatInfo provider = new NumberFormatInfo( ); provider.NumberDecimalSeparator = .; using (TextReader reader = File.OpenText(filename)) { text = reader.ReadToEnd(); linhas = text.Split('\n'); } Console.WriteLine(text); colunas = linhas[0].Split(','); int nlinhas = linhas.GetLength(0) - 1; int ncolunas = colunas.GetLength(0); for(aux = 0; aux ncolunas; aux++) { Console.Write({0}, ,colunas[aux]); } Console.WriteLine(); double[,] matriz = new double[nlinhas, ncolunas]; for(aux = 0; aux nlinhas; aux++) { if(aux 0) { colunas = linhas[aux].Split(','); } for(aux2 = 0; aux2
Re: [Mono-list] How to start a non mono program
Use System.Diagnostics.Process.Start(). You will most likely want to use one of the variations that uses an instance of ProcessStartInfo. Here's one example: /*! Invokes the C++ compiler to compile the given file. The output filename is specified as objectFile. Additional compiler options can be given using the compilerOptions parameter. */ public bool CompileCPPFile(string sourceFile, string objectFile, string compilerOptions) { string totalCompilerOptions; if (compilerOptions == null) totalCompilerOptions = String.Format(-o {1} {0} {2}, sourceFile, objectFile); else totalCompilerOptions = String.Format(-o {1} {0} {2}, sourceFile, objectFile, compilerOptions); ProcessStartInfo startInfo = new ProcessStartInfo( g++, totalCompilerOptions); Debug.WriteLine(Starting C++ compiler: + startInfo.FileName + + startInfo.Arguments); startInfo.UseShellExecute = false; startInfo.RedirectStandardError = true; startInfo.RedirectStandardOutput = true; Process compiler = Process.Start(startInfo); compiler.StandardError.ReadToEnd(); compiler.StandardOutput.ReadToEnd(); compiler.WaitForExit(); Debug.WriteLine( String.Format(C++ compiler returns {0}, compiler.ExitCode) ); return compiler.ExitCode == 0? true : false; } On Wednesday 22 December 2004 11:38 am, Andreas Sliwka wrote: Greetings, how would I start another program from within a mono program? I'm also interested in catching the programs output, but its secondary. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] StringDictionary Class
Short version: The Item property is really an indexer, which permits array-like access to the data structure. For example, code fragment below should print ``Apple'': StringDictionary dict = new StringDictionary(); dict.Add(a, Apple); Console.WriteLine(dict[a]); Longer version: This is one of the cases where the C# representation differs from that of the underlying metadata. From C#'s perspective, properties do not have parameters, and they only have code associated with getting and setting. The metadata that the CLI seems actually permits properties with zero or many parameters, even though C# does not directly support declaring them. In the case of StringDictionary, there is a property names Item, which takes a parameter. From C#'s perspective, this is an indexer. On Thursday 25 November 2004 10:33 pm, Ryan wrote: I'm trying to use the System.Collections.Specialized.StringDictionary class but when I try to use the Item property it say it doesn't contain a definition for it. The documentation doesn't mark it as incomplete though. The same goes for ListDictionary.Item Are these incomplete or and I doing something wrong? I know I'm not mistyping it. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] C#/Mono Serial port communication
I'm not sure if Mono provides its own version of such a class. It appears that .NET 2.0 will add a System.IO.Ports namespace to provide support for serial ports. I do not see such a namespace in current SVN (subversion) for Mono. If there is not yet a working version, it might be a nice idea for someone to stack on it. On Tuesday 23 November 2004 8:01 pm, Jon-Eirik Pettersen wrote: Is it possible to open a commuication to a serial port using /dev/rcomm0? This application do not need to run on other systems than Linux. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Newbie question: GUI choice
Qt# is not going very quickly, but it is not dead. On Tuesday 09 November 2004 11:00 am, Christian Convey wrote: Qt# looks like its going nowhere. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Custom Marshalling
I'm a little confused by your description. I am not trying to be difficult, but you use the pronoun it in many places where the antecedent is unclear. Also, the phrase on its way out is not clear. Perhaps if you demonstrated the problem using a P/Invoke method with fewer parameters and explained any problems with in, out, and ref parameters separately, I could better understand. Marcus On Thursday 28 October 2004 1:12 pm, [EMAIL PROTECTED] wrote: I've implemented some custom marshalling for an external call so that the parameters being sent gets massaged as required by the external routine. In addition, it is supposed to massage data after the call. However, while it will do so on the way out, it's not being driven the other way. I found that if I specified ref on the parameters being passed then the MarshalManagedToNative method will not be driven, if I specify nothing or out then neither the ToNative or ToManaged methods are being called. [DllImport(libname, EntryPoint = scumbag)] private unsafe static extern void scumbag (ref XXXCB cb, [MarshalAs(UnmanagedType.CustomMarshaler, MarshalTypeRef = typeof (AdaByteBuffer))] XXXBuffer fb, [MarshalAs(UnmanagedType.CustomMarshaler, MarshalTypeRef = typeof (AdaByteBuffer))] XXXBuffer rb, [MarshalAs(UnmanagedType.CustomMarshaler, MarshalTypeRef = typeof (AdaByteBuffer))] XXXBuffer sb, [MarshalAs(UnmanagedType.CustomMarshaler, MarshalTypeRef = typeof (AdaByteBuffer))] XXXBuffer vb, [MarshalAs(UnmanagedType.CustomMarshaler, MarshalTypeRef = typeof (AdaIntBuffer))] XXXIB ib); ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] [Off-topic] if else or switch ?
I will try to dig up the tests or to recreate them. You are probably correct that this is not a very large problem in practice. As I recall, I had to make the number of iterations quite large to see a substantial difference in time. On the other hand, I did this test because I have a program that needs to perform a large number of three-way decisions like this. Marcus On Sunday 17 October 2004 9:45 am, Paolo Molaro wrote: We may add the code to turn a switch with less than 3-4 destinations to a if/else sequence, but I'm not sure if this is really a speed problem in practice. Marcus reported behaviour may be due to different IL code generated by the compiler: I'd like to see the actual IL code to determine what actually caused the performance issue he reported. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] [Off-topic] if else or switch ?
On Saturday 16 October 2004 3:53 am, Michal Moskal wrote: No, I don't think that it's a completely a runtime issue. There are at least three fundamentally-different mechanisms for handling a switch statement, including hashing, binary search, and a linear if/else. With CIL, there is the further complication of using the switch instruction versus the compare and branch sequences. I guess the entire idea behind the .NET is that the compiler don't have to deal with choices like switch vs if -- the runtime is going to take care of it. Using switch in the IL should be just a hint for the runtime. So there is nothing to change in the mcs. The runtime is what should be fixed, if anything. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] [Off-topic] if else or switch ?
On Saturday 16 October 2004 7:20 am, Mike Welham wrote: Yes, and in fact, according to the CLI spec, it is difficult for the JIT to determine whether the a tail call can be used when the ldloca and ldarga instructions are involved. I must admit that I do not quite understand how ldloca and ldarga interact would interact with tail calls. Indeed. What I meant (and should have said) was that the optimization of spotting when the calling method frame can be discarded and pre-pending the .tail IL instruction should be in the compiler, rather than having the JIT trying to work out whether or not each and every call can be .tailed. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] [Off-topic] if else or switch ?
Performance will depend on both the C# compiler used and the runtime/JIT. I have not tested four-way decisions, which is what you have, but I did test three-way decisions not too long ago. With Mono's C# compiler + mono runtime, if-statements were about 3 times faster than switch. Interestingly, with Portable.NET's C# compiler, if-statements and switch performed almost identically to each other (and to Mono's C# if-statement version). So Mono's C# compiler is definitely not producing the best code for the mono-runtime. On Friday 15 October 2004 9:35 am, Fabien Meghazi wrote: I was wondering if mono would generate diferent code between a switch and an if else suite. I guess yes. But I would like to know wich of the two code would be faster ? (I know we are speaking of a few cpu cycles of difference, but I would like to know anyway) I would have benchmark this but I've nothing to do this, and I guess that this question could be theorically answered easily by those how put their hand in mono compiler. So which of those two methods generate faster code ? PS: orientation is a string and the following code is in a for loop : // -- for (int i = 0; i orientation.Length; i++) Method 1 * switch (orientation[i]) { case 'l': left = true; break; case 'r': left = false; break; case 't': top = true; break; case 'b': top = false; //break; } Method 2 * char or = orientation[i]; if (or == 'l') left = true; else if (or == 'r') left = false; else if (or == 't') top = true; else if (or == 'b') top = false; ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] How many strings do I have?
On the subject of switches on strings, I tested how mcs and the Mono runtime performed. Specifically, I tested the code that mcs produces for switches on strings versus nested if-statements for a three-way decision. The if-statement version was substantally faster (about 3-5 times, as I recall). The difference was due to how mcs handles switch statements. Using a different C# compiler, there was no difference between if-statements and switch under the Mono runtime. On Thursday 07 October 2004 6:21 pm, Jonathan Gilbert wrote: 'switch' performs about the same with strings as it does with ints. How does it do this? It has to do with the fact that every separate object on the system has an object ID, which can be treated as an 'int'. This alone isn't enough, but coupled with the string intern pool, it is possible to come up with a definitive object ID that represents a given string. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Indirect calling
It might want to look into delegates. They're an object-oriented equivalent to function pointers. On Sunday 26 September 2004 12:13 am, Eric Damron wrote: I'm looking for a way to execute a function indirectly but I'm not sure that C# supports this. I'm just learning C# so please don't be too hard on me for the simple question. For those of you that have ever programmed in the old z-80 assembler language, do you remember indirect calling of code. You would load up an address variable with the address of the function that you wanted to call and then execute an indirect call and that function would be executed. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Memory Allocation in unmanaged code
I do not know what shared library you are invoking, so I haven't been able to test this with the actual shared lib. Inside, I wrote a skeleton C lib that fills in the structure when called. If I change the C# declaration of CupsPrinterStruct from a struct to a class, it works. On Friday 03 September 2004 7:10 pm, Jim Fehlig wrote: I am having difficulty with a C# wrapper for some unmanaged C code that allocates a list. Unmanaged code snippet: typedef struct CupsPrinterListStruct { char printerUri[1024]; char printerCupsUri[1024]; char printerName[1024]; char printerMakeAndModel[256]; struct CupsPrinterListStruct *nextPtr; }CupsPrinterList; int ListLocalPrinters(CupsPrinterList **printerList); int FreeLocalPrinterList(CupsPrinterList *listHead); Wrapper code: [ StructLayout(LayoutKind.Sequential) ] public struct PrinterList { [ MarshalAs(UnmanagedType.ByValTStr, SizeConst=1024) ] public string printerUri; [ MarshalAs(UnmanagedType.ByValTStr, SizeConst=1024) ] public string printerCupsUri; [ MarshalAs(UnmanagedType.ByValTStr, SizeConst=1024) ] public string printerName; [ MarshalAs(UnmanagedType.ByValTStr, SizeConst=256) ] public string printerMakeModel; public IntPtr nextElement; } public class PrintLibWrapper { [ DllImport(print) ] public static extern int ListLocalPrinters( ref PrinterList pl); } Usage: PrinterList printers = new PrinterList(); printers.nextElement = IntPtr.Zero; int ccode = PrintLibWrapper.ListLocalPrinters(ref printers); Console.WriteLine(printer name = + printers.printerName); // printers.printerName is empty I can successfully call ListLocalPrinters but unable to read even 1 result let alone iterate through the list. Seems I need another level of indirection (perhaps an IntPtr) when calling PrintLibWrapper.ListLocalPrinters(). ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Separate Files
With the original C# standard, no, you can't, but C# 2.0 supports dividing the class into several files at including the keyword partial in the class declarations. On Saturday 28 August 2004 9:16 pm, Eric Damron wrote: I just started using mono, C# and monodevelop so forgive the beginner question. If I have a class with a particular nasty function, is there a way to put the source for that one function into a separate file to make the code more manageable? ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] popt
I'm not sure about popt. There is a somewhat different package for handling options in the Mono.GetOptions namespace. It handles parsing options by attaching attributes to fields/properties that correspond to options and using reflection at runtime to set them. On Thursday 26 August 2004 3:50 am, Rob Brown-Bayliss wrote: Hi, is there a c# version of popt for handling command line options? ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] popt
I'm not sure if Mono.GetOptions is compiled by default. If you're building from source, you can do a make in Mono.GetOptions directory. The resulting assembly to be installed is Mono.GetOptions.dll. On Thursday 26 August 2004 10:18 pm, Rob Brown-Bayliss wrote: But I cant find any mention of Mono.GetOptions in monodoc, and I get this error with the example: Cannot find type `Options'(CS0246) ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Problem using p/invoke on mono 1.0.1
I think that the problem has to do with some changes that were made to Mono regarding its handling of strings as return types from P/Invoke method. Behind the scenes, a char* is being returned, and the runtime converts the char* into a System.String. In addition, MS.NET calls CoTaskFree() on the char*. At one time Mono did not do this, but for compatibility with MS.NET, its behavior changed. Apparently, libcrypt does not want user to free the pointer that crypt() returns. The work-around for this is to have your method return an IntPtr and then convert the IntPtr to a string manually. For example, use the following in the place of your WriteLine() statement: string encrypted = Marshal.PtrToStringAnsi(UnixCrypt(arg,arg)); Console.WriteLine(UnixEncrypting {0} : {1},arg,encrypted); I am trying to use libcrypt.so.2.3.2 with c#. This code has been working for quite a while but stopped to work now. here is a little sample program I wrote snip using System; using System.Text; using System.Security.Cryptography; using System.Web.Security; using System.Runtime.InteropServices; namespace CryptTest { class CryptTest { [DllImport (crypt, EntryPoint=crypt, SetLastError=true)] private static extern string UnixCrypt(string text, string salt); [STAThread] static void Main(string[] args) { Console.WriteLine(have {0} args,args.Length); string arg = args[0]; Console.WriteLine(UnixEncrypting {0} : {1},arg,UnixCrypt(arg,arg)); } } } /snip When I try to run this with mono encrypt.exe rainer I get a NullReference Exception. I am a bit lost here since this code has been working beautifully for months. Either my debian upgraded its libcrypt version (which could easily be true) or upgrading to mono-1.0.1 introduced the problem (which is less likely since I remember having the same issue on mono-1.0). ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Custom marshalling
Unfortunately, UnmanagedMarshal.DefineCustom is a Mono-only class and not part of .NET. The normal .NET mechanism is to create a custom attribute using CustomAttributeBuilder to obtain an instance of MarshalAsAttribute with the custom marshaler specified. That does not seem to work under Mono. It is possible to implement custom marshalers without having to use reflection, as long as you know what what types you want to marshal to what at compile time. public class MyMarshal: ICustomMarshaler {...} private static extern void PrintObject( [MarshalAs( UnmanagedType.CustomMarshaler, MarshalTypeRef = typeof(MyMarshal ) )] object o ); On Sunday 25 July 2004 5:12 pm, Alan Jenkins wrote: As far as I can tell, Mono supports custom marshalling outside of function calls (like PInvoke), - ie using Marshal.StructToPtr and PtrToStruct, but you have to use UnmanagedMarshal.DefineCustom, which would involve reflection of some sort - possibly creating your class with custom marshalled fields by reflection. Does UnmanagedMarshal.DefineCustom work? Is it efficient (as far as custom marshalling can be)? Is it supported (or undocumented and likely to disappear/break)? Would it be (technically) possible to access its functionality through an attribute, in the same way that non-custom marshalling is done? Is this likely to happen? ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Cross-platform GUI.
Qt is Free on Mac. On Sunday 25 July 2004 1:54 pm, Daniel Carrera wrote: Thanks. Am I wrong, or is Qt not free under Windows and Mac? ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Documentation page down
That one also fails: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [EMAIL PROTECTED] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. Apache/2.0.49 (Fedora) Server at www.go-mono.com Port 80 On Saturday 17 July 2004 3:47 am, Daniel Carrera wrote: On Sat, Jul 17, 2004 at 02:04:13AM -0400, Daniel Carrera wrote: http://www.go-mono.com/docs/ Actually, although that page doesn't work, this one does: http://www.go-mono.com/docs/index.html Perhaps someone can fix the server... or perhaps just the link. FWIW, I have seen this on Mozilla running on Linux Debian Sid and Windows XP. Cheers, ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Strict evaluation
Are you talking about not using short-circuiting? Short-circuit evaluation is part of the standard behavior of the and || operators. If you're looking for something that evaluates both (not sure why), you can use or |. On Friday 16 July 2004 1:55 am, Juergen Moeller wrote: Hi, is there a mcs-switch for strict evaluation of boolean expressions? Default is non-strict evaluation, isn't ist? ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Re: Bootstrapping
Pnet's cscc can compile mcs itself, if you use make BOOT_COMPILE=cscc. Mono's corlib still causes a few problems, which actually seem to be related to issues with the response files. On Wednesday 07 July 2004 11:39 pm, Iain McCoy wrote: The components written in c# were initially compiled on windows using csc. If you look back in the history of the mono project, you'll find a few announcements from when they got the c# components to be self-hosting. If you want to do a full bootstrap from scratch, I think you can still use microsoft's implementation to do so. It may be possible to use the pnet c# compiler as well, but I haven't heard of anyone doing so. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Using qt#
By the way, you might get more help on the Qt# mailing list, although obvious I read both. Does Qt.dll exist in /usr/local/lib? Is your version of Mono configured to look in /usr/local/lib or just /usr/lib? If Mono is installed in the /usr prefix, I'm not sure whether it will look in /usr/local/lib by default. You can use the MONO_PATH to set where the runtime looks for libs. See the mono manpage. Marcus On Wednesday 07 July 2004 5:59 pm, Paul wrote: Hi, I've compiled qt# from sourceforge and installed it into /usr/local/lib. How do I link it to source code? mcs -r: Qt just gives that Qt can't be found. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Re: Bootstrapping
I have to quote from the page http://gcc.gnu.org/install/prerequisites.html: ``Tools/packages necessary for building GCC ``ISO C90 compiler Necessary to bootstrap the GCC package, although versions of GCC prior to 3.4 also allow bootstrapping with a traditional (KR) C compiler. ``To make all languages in a cross-compiler or other configuration where 3-stage bootstrap is not performed, you need to start with an existing GCC binary (version 2.95 or later) because source code for language frontends other than C might use GCC extensions.'' On Wednesday 07 July 2004 11:22 pm, Brandon Knitter wrote: How did you compile GCC? You need to have a pre-compiled or cross-compiled version of the compiler to build it the first time. It's the same story here. GCC has a valid 3 phased bootstraping which builds the compiler in stages. GCC doesn't require a C compiler to be compiled, although it does speed up the process. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] PInvoke Marshaling problem
I reported this bug a couple days ago: http://bugs.ximian.com/show_bug.cgi?id=61134 On Saturday 03 July 2004 4:06 pm, Kai Reichert wrote: Hi! I want to pass an array of bytes to a method compiled in c/c++. The first naiv method works and looks like this : - - xx.c : void takeArray( unsigned char array[] ){ /* do something useful with it */ } xy.cs : [ DllImport(myclib.so) ] static extern void takeArray( byte[] array ); byte[] array = new byte[10]; takeArray( array ); - -- O.K., this one works perfectly. But now consider you have a c-method that takes the array as takeArray( const void *pointer ) YES, it makes sense, e.g. the OpenGL method glTexImage2D. Since all structures are passed by reference the parameter of the method is just the pointer to the beginning of the structure in memory. so I only need a way to access this pointer. my aproach was the following : takeArray ( GCHandle.Alloc( array, GCHandleType.Pinned).AddrOfPinnedObject() ); BUT this method invocation is not associated with the right piece of memory that the subsequent c-method gets :-) Yes I know that Mono has a garbage collection and there are mechanisms in the runtimes that copy memory from managed to unmanaged. This wouldn't be a problem ... I just want to know why it is not possible to pass System.IntPtr --C-- const void* since byte[]--C-- unsigned char array[] works ;-) Thx for reading boring PInvoke problems :-) Kai ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Re: P/Invoke IntPtr versus byte[]
I was writing my reply, saying that you probably pasted the wrong method signature. Is there some particular reason that you do not know the type in advance? It would be easier if you could do that because you would then be able to write a precise signature for the P/Invoke method. By the way, is mdArray a field or local variable? On Saturday 03 July 2004 3:26 pm, Tim Rädisch wrote: One CopyPaste-error. The first DllImport was not byte[] but IntPtr :) [...] Because it is a const void* I used the following DllImport statement [ DllImport(lib) ] static extern void multiDimArrayTest( IntPtr elems ); and this methode call multiDimArrayTest( GCHandle.Alloc( mdArray, GCHandleType.Pinned).AddrOfPinnedObject() ); [...] ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Bootstrapping
The DLLs are not DLLs in the sense of binary shared libraries for Windows. The files in mono/runtime are CLI/.NET assemblies (libraries, in this case). The mono.tar.gz file contains prebuilt mcs.exe and DLLs. Once you have the prebuild versions installed, you can download mcs.tar.gz and build your own from source. You need the prebuild versions installed because the Mono C# compiler is written in C#. Without a C# compiler, you could not compile mcs. Also, note that the mono CVS module does *not* contain the prebuilt files. On Saturday 03 July 2004 5:24 pm, Brandon Knitter wrote: I read through the docs for the CVS compile, as well as looked at the Mono Runtime source code disrtibution and the MCS source code distribution. What I found was that the mcs package requires the mono package to be compiled and installed. When I looked into the mono/runtime dir, I found a bunch of windows .dll files. So now I'm confused. Is Mono just a wrapper around some Microsoft.NET Windows .dlls? It wouldn't appear so cause the .dll files don't have the Microsoft stamp on them!?! :-/ So I guess it comes down to this: where are the bootstrap build directions? I want to build everything from scratch...i.e. I want to see the .dll files and .exe files get built on my machine. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Mono xsd invocation problems
Invoking Mono's xsd program seems to have a serious problem in that it's impossible to specify a path to the .xsd file. Instead, one must invoke in xsd from the directory that contains the .xds file. Attaching to specify a path results in errors: xsd /home/marcus/Schemas/file.xsd /classes Unknown option home/marcus/Schemas/file.xsd System.Exception: Unknown option home/marcus/Schemas/file.xsd in 0x00039 Mono.Util.Driver:Error (string,string) in 0x007fa Mono.Util.Driver:Run (string[]) in 0x0005e Mono.Util.Driver:Main (string[]) Quoting the path does not fix the problem. Rotor's version of xsd.exe does work correctly when a path is specified. I would have reported this in Bugzilla, but I could not find an appropriate category. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Casting and Plugin Issue
I think that you need to put IPlugin in the shared assembly (that the main program and plugins both references). On Sunday 27 June 2004 9:19 pm, Pablo Fischer wrote: Hi! I don't have any other idea, but I thought that maybe instead of doing: snip my_method = t.GetMethod(MGetPosts); object retVal = my_method.Invoke(activator, BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.InvokeMethod, null, new Object[]{3, user}, null); /snip You could do: IPluging p = (IPlugin)t; object retVal = p.MGetPosts(3, user); Sounds great, I tried what you said with two assemblies: one is the Structs.dll (*Struct.cs) and the other Plugin.dll (Plugin.cs and the interface IPlugin.cs), then I compiled MyApp with mcs MyApp.cs -r Structs.dll And then tried to cast it, and it fails: Test7.cs(20) error CS0246: Cannot find type `IPlugin' Also I did a Console.WriteLine to 't' (Type) and prints MBloggy.Plugins.IPlugin. Seems that I can't cast an interface, or what I'm doing wrong?. Assembly a; Type t; MethodInfo my_method; a = Assembly.LoadFrom(BloggerPlugin.dll); t = a.GetType(MBloggy.Plugins.IPlugin); Console.WriteLine(t); As I said, I'm testing what you suggested, but with Reflections the plugins are working great! Thanks Pablo ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] CLI-Grande Test Results
I recently obtained a copy of the CLI-Grande benchmark suite, which is a port of Java-Grande. It is available from CVS at :pserver:[EMAIL PROTECTED]:/cvs. Check out module cli-grande. I wanted to post the results in case anyone was interested. I observed that using full optimization (-O=all) with Mono sometimes made results worse. Also, the Create:Array tests run so much faster with full optimization that I am not sure how to interpret the results. Finally, ilrun failed during the Serial:Reading:BinaryTree test, which aborted the benchmark. So the remaining 4 tests did not run. CLI Grande Benchmark Suite - Version 2.0 - Section 1, OS: Unix 2.4.21.144 CLI: 1.1.4322.573, ,mono -O=all,mono (default),ilrun,mint,mono-opt/mono-default,ilrun/mono-opt,ilrun/mint,, , Section1:Arith:Add:Int,221190500,235948900,206204280,9584203,0.937450863301333,0.93224745185711,21.5150159069043,, (adds/s) Section1:Arith:Add:Long ,179951900,197343700,6903719.5,8671307,0.911870508154048,0.0383642490020944,0.796156738540107,, (adds/s) Section1:Arith:Add:Float ,110815900,111283400,57196664,6694502,0.995799014048816,0.516141311851458,8.54382656096002,, (adds/s) Section1:Arith:Add:Double ,108419600,46860440,58760308,7984470,2.31367012345595,0.541971267187852,7.35932478924713,, (adds/s) Section1:Arith:Mult:Int ,161486500,158719100,119963360,9613009,1.01743583475461,0.742869280094621,12.4792726190103,, (multiplies/s) Section1:Arith:Mult:Long ,39700480,37110090,6116030,8089773,1.06980284876701,0.154054308663271,0.756019977321984,, (multiplies/s) Section1:Arith:Mult:Float ,88500380,89552900,54192044,7431890,0.98824694677671,0.612336850983013,7.29182536340016,, (multiplies/s) Section1:Arith:Mult:Double,88517490,50837480,54735644,8945791,1.74118563705361,0.618359648471731,6.11859186068622,, (multiplies/s) Section1:Arith:Div:Int,26305810,26304620,24554168,7652796,1.4523920133,0.933412352632365,3.2085224798884,, (divides/s) Section1:Arith:Div:Long ,8042728,7919320,3874991,4986261,1.01558315612957,0.481800578112302,0.777133607727313,, (divides/s) Section1:Arith:Div:Float ,37746460,37105660,27710100,6782400,1.01726960253503,0.734111225264568,4.08558917197452,, (divides/s) Section1:Arith:Div:Double ,53415090,37523440,39626440,8809686,1.42351260971809,0.741858527243893,4.49805361961823,, (divides/s) Section1:Assign:Same:Scalar:Local ,620827500,846611700,599959420,16967150,0.733308434079047,0.966386669404947,35.3600587016676,, (assignments/s) Section1:Assign:Same:Scalar:Instance ,793268200,787358500,217401870,8975077,1.00750572960094,0.274058471019007,24.2228417650344,, (assignments/s) Section1:Assign:Same:Scalar:Class ,341011900,342017900,21406904,4912664,0.997058633480879,0.0627746539050397,4.35749401953808,, (assignments/s) Section1:Assign:Same:Array:Local ,119135500,125996300,138440090,4694022,0.945547607350374,1.16203893885534,29.4928506939252,, (assignments/s) Section1:Assign:Same:Array:Instance ,63705430,59535560,44387680,1829450,1.07003998954574,0.696764467330336,24.2628549564077,, (assignments/s) Section1:Assign:Same:Array:Class ,131722600,131707300,17462705,4151987,1.00011616668173,0.132571821388281,4.20586697405363,, (assignments/s) Section1:Assign:Other:Scalar:Instance ,814437800,763728900,190996190,9770939,1.06639646607586,0.234512924129995,19.5473730825666,, (assignments/s) Section1:Assign:Other:Scalar:Class,667766800,667856900,4392104,4898740,0.999865090860033,0.00657730213601515,0.896578303808735,, (assignments/s) Section1:Assign:Other:Array:Instance ,126032400,125998800,70286504,3703004,1.0002920637,0.557685991856062,18.980941959555,, (assignments/s) Section1:Assign:Other:Array:Class ,131748200,130704700,4193471.25,4150006,1.00798364557663,0.0318294386564674,1.0104735390744,, (assignments/s) Section1:Cast:IntFloat,57291080,53036550,16287968,12643340,1.0802188302218,0.28430198907055,1.28826465158732,, (casts/s) Section1:Cast:IntDouble ,57300250,44932720,17423172,12417110,1.27524552263918,0.304067992722545,1.40315838387515,, (casts/s) Section1:Cast:LongFloat ,32967550,31849230,9498018,10277280,1.03511293679627,0.288102027599867,0.924176241184438,, (casts/s) Section1:Cast:LongDouble ,36798260,31699070,9509921,10260570,1.16086244801504,0.258433985737369,0.926841393801709,, (casts/s) Section1:Create:Array:Int:1 ,8685521000,1926683,1209995,1054746,4508.01766559418,0.000139311735012787,1.14719088766395,, (arrays/s) Section1:Create:Array:Int:2 ,8693961000,1924005,1214885.25,1053181,4518.67900551194,0.000139738980885698,1.15353889787226,, (arrays/s) Section1:Create:Array:Int:4 ,8701608000,1666781,1121622.875,964445.6,5220.6038269,0.000128898345570152,1.1629716336515,, (arrays/s)
Re: [Mono-list] CLI-Grande Test Results
I think that the idea is to test overall performance, independent of JIT time. When real users run the applications, the JIT time is part of the performance issue. The results are available at http://mylinuxisp.com/~mathpup/results.sxc I tried to attach them to the email, but that did not seem to work. Of course, you're welcome to run the tests themselves. The total battery of tests takes quite a while to run -- perhaps 45 minutes. I'm not entirely sure because I run them while I'm away from the machine. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] CLI-Grande Test Results
I recently obtained a copy of the CLI-Grande benchmark suite, which is a port of Java-Grande. It is available from CVS at :pserver:[EMAIL PROTECTED]:/cvs. Check out module cli-grande. I wanted to post the results in case anyone was interested. I observed that using full optimization (-O=all) with Mono sometimes made results worse. Also, the Create:Array tests run so much faster with full optimization that I am not sure how to interpret the results. Finally, ilrun failed during the Serial:Reading:BinaryTree test, which aborted the benchmark. So the remaining 4 tests did not run. results.sxc Description: OpenOffice Calc spreadsheet
Re: [Mono-list] InteropServices: DllNotFoundException...?
I ran a short test, and it appears the Mono runtime still does not free strings returned from P/Invoke methods. Do you know if there is a bug report about this? I did a query and could not find one. I was not sure about Mono's behavior, so I wrote a short test case, which I can file with the bug report if there isn't one already. On Saturday 22 May 2004 11:01 pm, Jonathan Pryor wrote: However, there is another issue present: strings. Your DllImport declarations specify that System.String is the return type. This will cause the runtime to attempt to free the strings returned by those functions. IIRC, Mono will use g_free() to free that memory. If those strings weren't allocated by g_malloc(), this could lead to heap corruption. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] What is the best way to ...
Process.Start() is the portable way to do this. On Monday 24 May 2004 12:47 am, Peter Foley wrote: call a Unix command or shell file from Mono? Should I use PInvoke or Process.Start? Something else? ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] How to use the Boehm garbage collector
With Mono and Boehm GC, the collector never compacts the heap. I think that's why your memory usage does not decrease. (More sophisticated collectors like MS.NET, various LISP systems, Modula-3 do compact the heap by moving object references during collections.) Also, my general obsevation for garbage collectors is that Collect() should be interpreted as a hint to the GC that now would be a good time to collect. On Monday 03 May 2004 9:41 am, HannibAl Bundie wrote: The method GC.Collect() uses the Boehm collector ?? Because with my application, GC.Collect() doesn't reduce the total memory used. And for this reason I thought that GC.Collect wasn't implemented. So I wanted to use an other collector. Is there any other way to force to reduce the memory used by my program ? ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Mono + GCC 3.4
I recently upgraded to GCC 3.4. Any idea why I get errors like make[2]: Entering directory `/home/marcus/src/mcs/jay' cc -DSKEL_DIRECTORY=\/usr/local/share/jay\ -g -O2 -c -o closure.o closure.c In file included from closure.c:41: defs.h:306: warning: conflicting types for built-in function 'calloc' defs.h:307: warning: conflicting types for built-in function 'malloc' Other apps like XMMS, Qt, gettext, KDE build without any problems, so I'm wondering what kind of problem this might be. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono + GCC 3.4
If I then disable the definitions of calloc and malloc in jay/defs.h, I get an error from cs -d:NET_1_1 -d:ONLY_1_1 -g /target:exe /out:mcs.exe AssemblyInfo.cs anonymous.cs assign.cs attribute.cs driver.cs cs-tokenizer.cs cfold.cs class.cs codegen.cs const.cs constant.cs convert.cs decl.cs delegate.cs enum.cs ecore.cs expression.cs flowanalysis.cs genericparser.cs iterators.cs literal.cs location.cs modifiers.cs namespace.cs parameter.cs pending.cs report.cs rootcontext.cs statement.cs support.cs typemanager.cs symbolwriter.cs tree.cs CryptoConvert.cs cs-parser.cs cs-tokenizer.cs(31) error CS0246: Cannot find type `yyParser.yyInput' On Saturday 01 May 2004 3:09 am, Marcus wrote: I recently upgraded to GCC 3.4. Any idea why I get errors like make[2]: Entering directory `/home/marcus/src/mcs/jay' cc -DSKEL_DIRECTORY=\/usr/local/share/jay\ -g -O2 -c -o closure.o closure.c In file included from closure.c:41: defs.h:306: warning: conflicting types for built-in function 'calloc' defs.h:307: warning: conflicting types for built-in function 'malloc' Other apps like XMMS, Qt, gettext, KDE build without any problems, so I'm wondering what kind of problem this might be. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Re: The Mauve unicode testcase and VM performance
I get almost identical results overall on SciMark with AOT and JIT compilation. The overall results are 97.0 MFlops (JIT) versus 95.4 MFlops (AOT). Some subtests are faster with JIT; some are faster with AOT. This difference is less than what I see from week to week comparing JIT-to-JIT, as various components of the runtime change. On Tuesday 13 April 2004 5:08 pm, Jonathan Pryor wrote: AOT (or pre-JITing) assemblies is not as useful as you'd think. It has two primary effects: - Reduce memory requirements, as memory doesn't need to be allocated for the JITed code - Decrease startup time, as (again) the JITing doesn't need to be done. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] foreach issues
The collection sizes and run times are so small that I question whether this is a valid comparison. As the size of the collection increases, some of mechanisms become much, much slower. For example, with 40,000 instead of 1000 elements, I get the times foreach list: : 00:00:00.1349930 foreach array:: 00:00:00.0061260 IEnumerable list : 00:00:00.1076430 IEnumerable array : 00:00:00.1416560 On Saturday 10 April 2004 3:18 am, Pedro Santos wrote: Hi, I was wondering what would be faster when using foreach: an ArrayList ou an Array. At first, would be expected that foreach with an ArrayList would be slower than with an array, and it is a lot slower. But, doesn't foreach see the Array and the ArrayList has a IEnumerable? Whouldnt it be the same in the foreach prespective? It appears not to be, If I do the same, but pass an IEnumerable to the foreach it is alot faster, in this case the foreach with the ArrayList is faster. The test is in attachement. This were the times: bash-2.05b$ mono test.exe foreach list: : 00:00:00.0159550 foreach array:: 00:00:00.420 IEnumerable list : 00:00:00.830 IEnumerable array : 00:00:00.0001040 Can someonte elaborate on this? I am curious. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] I give up
On Thursday 08 April 2004 1:31 am, Michael J. Ryan wrote: Also have to mention that GTK# can be used on the windows side. First Qt was bad because it wasn't GPL. Now it's bad because it's GPL. I don't get it. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] I give up
On Friday 09 April 2004 1:35 am, George Farris wrote: Nonsense. Mono and Gtk# work extremely well today. I know, I've built a fully functional app (Gfax) and all one has to do is look at a few other apps such as F-Spot, Muine, Monodoc and Monodevelop to realize this. If someone would actually take the time, Qt# can be used to write good applications. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Agent for Service
Who is Novel/Ximian's agent for service in Houston, TX? ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] I give up
After trying to work with Mono, Portable.NET, Qt, and KDE, I've realized that I'm fighting a battle that I cannot win. Mono supports Gtk# (and GTK+) to the exclusion of any other platform. Portable.NET is behind their own SWF implementation, but at least they are a bit more agnostic. The Qt/KDE community seems to find the entire concept of C# and its use of metadata and JIT compilation repulsive. I'm tired of trying and failing. I'm tired of having no one to support me. I'm tired of feeling isolated and alone. It's just not worth it. Maybe I will end up Windows XP and .NET. Who knows. I just know that the Free software community has got to be the most hostile and intolerant group of people I have ever encountered. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Starting processes with parameters from Mono 0.31 and mono-0.31.99.20040331
Are you using Windows or Linux? As I understand UseShellExecute, when set to false, Process.Start() will treat the filename as a binary image and attempt to execute it directly. This is really the only option that makes sense under vanilla Unix. On Windows, when UseShellExecute == true, it causes Windows to use the windows shell to process the filename. If the filename is a document, Windows will attempt to use an appropriate application to open the document. GNOME and KDE both provide mechanisms equivalent to the Windows Shell from what I understand, but whether to use these or not (and how to choose which one if both are present) seems unclear. Rotor under Linux simply throws an exception if UseShellExecute == true. On Sunday 04 April 2004 12:06 pm, Ivan Guvinec wrote: Hi, I stumbled upon then same problem in my project after upgrading to Mono 0.31. The workaround with UseShellExecute = false works, but I have noticed a considerable performance penalty. So I wonder: 1. Is the fact that arguments are not used without UseShellExecute a bug in Mono 0.31 release? 2. Is using UseShellExecute = false slower in comparison to UseShellExecute = true? ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] About performance
On SciMark, the performance drop is much worse, with Mono taking about 2.2X long as .NET. On Tuesday 23 March 2004 7:06 pm, Philippe Lavoie wrote: Simple inquiry here, I have a program which takes 20 seconds with .NET from Microsoft and it takes 28 seconds on mono (both run are made inside a Windows 2000 laptop). So it's about 30% slower to run it on mono. The code does multiple least square fit of data points to generate an array of NURBS curves, it also use log4net to write log information to a file and it uses XML deserialization to load all the input data (about 2Mb worth). So it's heavy on maths (lots a loops) with some IO tasks thrown in. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] GUI, threads, etc...
On Monday 15 March 2004 10:52 pm, Jonathan Pryor wrote: A *direct* equivalent to fork(2)? No. The nearest equivalent is System.Diagnostics.Process, which is a fork(2)/exec(3) equivalent. (Minor side question: what would happen if you P/Invoked out to fork(2) in libc.so? Is it safe for managed apps to do that?) I believe that some special magic is required to start up the Mono runtime in a new process or thread that's created using facilitiies outside the managed libraries (e.g. fork or normal OS thread creation functions). There is some documentation about that in the mono directory. I tried to use Qt's QProcess class to start a new process, following those docs, but I was never successful. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Mono logo
The scalable logo provided with Mono seems to have been generated from the raster one, and is of such low quality that it's practically non-scalable. I've taken the liberty of creating a scalable (vector) version of the logo from scratch; I sincerely hope that something like it replaces the current one. This new rendition is available at www.cs.ttu.edu/~brennema/downloads/mono-logo.svg _ a href=http://www.gamedev.net;GameDev.net Email Service/a - Plenty of 1's and 0's ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] How to create C++ library and call it's functions from C# program?
On Friday 12 March 2004 12:14 am, Jonathan Pryor wrote: 2. C++ compilers use a technique called name mangling, so that you can have function overloads. For example, your print (const char*) function is *actually* the linker symbol: The right way is to instead tell the C++ compiler to disable name mangling. This is done by using an ``extern C'' modifier in your C++ code. The downside to this is that you can not have two C++ function overloads that are both marked as ``extern C'', as this would cause confusion. I would also add that the ``extern C'' does not help in situations where you need to communicate with C++ classes. In this case, with GCC an intermediate C library is almost certainly necessary. If something similar VS.NET's Managed Extensions for C++ existed for GCC, this might be avoided. There at least 3 reasons why an intermediate layer is needed. First, there is no way to create a new instance of a C++ object from outside C++ unless the C++ library provides an appropriate function. There is no obvious way to determine how much memory to allocate for a given C++ object, so even if it were possible to call a C++ constructor directly to initialize the object, allocating the object in the first place seems impossible. Second, C++ compilers use name-mangling to avoid duplication of symbols when several classes define the same method and when overloaded methods are used. This mangling is platform dependent. It is possible to use system-specific utilities to produce a list of mangled and unmanagled names and then match them up to create a conversion table. So this is more of an annoyance than an an outright dead-end. Third, when optimization is specified, C++ compilers frequently inline any methods those bodies are defined within the class scope (and possibly other methods as well). Moreover, if every invocation of a method is inlined, some compilers do not by default emit an out-of-line copy for the method. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] How to create C++ library and call it's functions from C# program?
On Friday 12 March 2004 1:16 am, Jonathan Pryor wrote: Finally, it can be noted that the intermediate C library, and a C# wrapper for the C library, can be automatically generated (with some programmer assistance). See the SWIG project: I've looked at SWIG, and found it unsatisfactory. The C/C# code generated was very difficult to read. Also, different C++ classes require different memory management strategies, and I setting that up in SWIG looked impossible. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Platform comparison
Some editions of the Rotor and MSDN docs have errors with regard to directory separator characters. I've seen at least once instance where the errors are fixed, however. On Tuesday 09 March 2004 12:57 am, Jonathan Gilbert wrote: The character stored in this field cannot be in InvalidPathChars. This field can be set to the same value as DirectorySeparatorChar. AltDirectorySeparatorChar and DirectorySeparatorChar are both valid for separating directory levels in a path string. The value of this field is a backslash ('\') on Unix, and a slash ('/') on Windows and Macintosh operating systems. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Bug related to operator += and instance fields
It appears to be a mono runtime bug. Note that it disappears with -O=all or using the Mono interpreter (mint) instead. I filed a bug report: http://bugs.ximian.com/show_bug.cgi?id=54710 ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Reflection...
I think that this is an mcs bug. I think I narrowed it down to mcs's mark handling the custom attribute correctly. I filed a bug report for you. http://bugs.ximian.com/show_bug.cgi?id=54679 On Friday 20 February 2004 2:06 pm, Giuseppe Greco wrote: Hi all, since const fields are implicitly static, the following code fragment should work fine: ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] evangelizing mono
Also, I know that this is getting a bit off-topic, but as I recall, even old-fashioned OS's like VMS used special extensions for executables. (Did VMS used .COM or something else?) On Monday 16 February 2004 4:25 pm, Gustavo Ramos wrote: If someone gets irritated with the .exe extension, just crop it and run mono myprogram. I don't think this is a technical issue, just an anti-ms-ism. Well, but there's a good reason to leave the .exe extension there: That executable is multiplatform, and no changes or recompilation are needed to run it on windows. For ebay apps, surely the majority of the client deployment will be for windows clients. Anyways, if you develop it with C/C++/Pascal/Whatever, you'll have to deal with .exe's, unless you use javascript or any other scripting language. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Re: Executing mono program: was evangelizing mono
AFAIK, you can use whatever filename you want for the executable. It does not have to end in .exe (at last with Mono). What's more, the Linux kernel called binfmt-misc, which allows running programs under Mono as though they were native binary executables. Here's a link to a script that does that: http://www.atoker.com/mono/mono.init Depending on your Linux configuration, you might need to modprobe binfmt_misc, and you might need to change the path to mono from /usr/bin/mono. Finally, mcs seems to set the executable bit on output files, but other C# compilers (e.g. csc, cscc) do not. On Saturday 14 February 2004 3:00 pm, Jeffrey McManus wrote: One tactical thing they seem to be getting hung up on is the fact that you need to run Mono apps with a command line (and, secondarily, an executable that ends in *.exe reeks of evil Windows; I explained to them that this is what chmod +x is for, but anyway). ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Double-buffered graphics solutions in mono
It is also possible to use double-buffered display in Qt#. See ScribbeWindow for an example. On Thursday 12 February 2004 12:26 pm, Stuart Ballard wrote: I'm looking for a way to do a simple double-buffered graphics display that will work with Mono on Linux. I know how to do it (at least so it works, even if I'm not doing it right) in WinForms, but I heard that WinForms is currently just broken in Mono, and besides, it's not the world's most elegant GUI toolkit anyway. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] unicode trouble
As I recall, when the CM3 Modula-3 compiler added support for unicode, they used a hybrid scheme where TEXTs (their equivalent of System.String) can contain both 8-bit and 16-bit chars. So only the portions of the string that require more than 8 bits use it. Something similar could be done with 32-bit characters in some future library is compactness were a concern. By the way, how much performance penality is there for accessing a single 8 one modern 32-bit processors? On Monday 09 February 2004 7:16 am, Jonathan Pryor wrote: I imagine it's due to a memory trade-off. The easiest way for the programmer do deal with things would be to just use UCS-32 for all Unicode strings. You wouldn't have to worry about code pairs or anything else like that. It would also mean that all strings would require 32-bits for each character, which would eat up *lots* of memory for all strings. The most common code points -- US, Europe, Asia -- all easily fit within 16-bits, *by design*. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Maths
By the way, the more usual method of rounding *is* used when rounding occurs as a result of a format-string conversion, which results in such surprising output: Console.WriteLine({0:n0}, 2.5 ); // prints 3 Console.WriteLine( Math.Round(2.5) ); // prints 2 On Monday 09 February 2004 1:39 pm, Tom Cabanski wrote: In the science disciplines, n.5 is rounded to the nearest even integer (e.g. 1.5 rounds to 2, 2.5 rounds to 3 and 3.5 rounds to 4). If you think about it, that is actually more accurate that always rounding as .5 is exactly in the middle and we should round up about half the time and down the other half of the time. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Handling file paths for different operating systems
I'm not sure that I understand your question. The class Path defines things like DirectorySeparatorChar, GetDirectoryName(), GetFileName(), and so forth. You might peek around in there and see if anything looks promising. On Saturday 07 February 2004 2:20 am, Timothy Parez wrote: Hi, I'm wondering, if you have an application which uses a file path for one of its setttings, for example in the .config file of the application there's an entry: add key=PluginDirectory value=) Of course I could have an entry for each different OS, but that's not exactly nice design, how can I write down a path in a universal way, or make it so that it works on all systems ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Problem with String.Replace
I did want to point out a bug that I posted to Bugzilla because of its potential severity: When calling String.Replace on a string, the comparison seems to be done on a case-insensitive basis. For example, in the test program: using System; public class Testing { private static void Main() { string str = Piggy; Console.WriteLine( str.Replace( I, ) ); } } On Mono in current CVS, it prints Pggy, but on Mono 0.29 and .NET it prints Piggy. The null-string does not seem to be the culprit itself, since str.Replace(G, t) will turn Piggy into Pitty on mono. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Cairo dependency issues and Xft
I wanted to mention this in case anyone else runs into this problem. Cairo was recently added to Mono as a dependency. (If Cairo were detected and its use disabled when not present, I might call it an *optional* dependency, but this is not the case. One of the (recursive?) dependencies of Cairo is xft.pc, which is not part of the XFree86 development packages on my distro (SuSE 8.0). So I installed xft-2.1.2 and subsequently built Cairo, et. al. Things worked fine until I attempted to rebuild by KDE system from sources: the resulting KDE system refused to work. It appears that the problem is that XFree11 includes its own libXft.so.1, and the libXft.so.2 from xft-2.1.2 was getting picked up instead, resulting in bizarre problems. I finally removed xft-2.1.2 and rebuild KDE, which fixed all the problems. Of course, I cannot use Cairo now, but the problems are gone. I wrote this hoping to save some people some trouble. (Standard disclaimer: I'm very happy with SuSE in general. I know that my distro version is aging. SuSE costs $40, and downloading isn't an option because dialup is the only game in my area of town.) ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Re: [DotGNU]pnet/mono packaging conflicts
Doesn't a similar situation exist with the various Java installations available. It is not uncommon to have several implementations or versions of Java installed (i.e. IBM 1.3.1, Sun 1.4.x, etc) for compatability testing and so forth. Not being a Java developer, I don't know how this is handled in practice, perhaps an explanation of Java's issue would be helpful. Another possibility is to handle Pnet and Mono the way that Rotor is handled on Linux/BSD. Rotor is localized into its own directory root, similar to the way Qt is installed. Some initial startup scripts are used to add the needed binary paths and library paths. Executables (.exe) and libraries (.dll) that are not part of Rotor itself can still be installed in the normal Unixy places like /usr/local/lib, since they should not depend on the particular CLR in use. On Tuesday 21 October 2003 2:49 am, Fergus Henderson wrote: On 21-Oct-2003, Rhys Weatherley [EMAIL PROTECTED] wrote: Recently, some packaging conflicts between Portable.NET and Mono have come to light, revolving around binaries in both packages with the same names (especially ilasm). This is causing problems for users of all major GNU/Linux distributions. Portable.NET has been using those names since early 2001, well before the Mono project was first publicly announced I hate to be the one to break it to you, Rhys, but I think Microsoft was using the name ilasm as a command name privately since _at least_ 1999, and publically since the July 2000 PDC conference. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] FUCK OFF AND DIE
FUCK YOU MONO ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list