[Mono-docs-list] Updating mdvalidator
Currently mdvalidator doesn't like the documentation for generic types/members, as the XSD that mdvalidator uses hasn't been updated for the new XML tags like typeparam/. This is to be expected. However, some non-ECMA tags were added to the output of monodocer, in particular the /Type/TypeParameters, /Type/TypeParameters/TypeParameter, and /Type/Base/BaseTypeArguments elements added in October 9. I think we'll need to add /Type/Base/BaseTypeArguments to the XSD to permit validation, but do we need the TypeParameters/ element? This seems to just duplicate the information already within /Type/Docs/typeparam. Is this correct? Would it be possible to remove TypeParameters/ and instead use typeparam/ Thanks, - Jon ___ Mono-docs-list maillist - Mono-docs-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-docs-list
Re: [Mono-dev] [Mono-devel-list] Operating System in C# Project
Thought it might be worth bringing up this: http://research.microsoft.com/os/singularity/ Ms has a research project like this, and the paper describing the design is the first paper from Microsoft that states that Linux is faster than Windows :-) pgpNizoILMaPw.pgp Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-devel-list] Operating System in C# Project
Stefan Dösinger wrote: Thought it might be worth bringing up this: http://research.microsoft.com/os/singularity/ Ms has a research project like this, and the paper describing the design is the first paper from Microsoft that states that Linux is faster than Windows :-) An excellent paper to be sure. :-) Although, I think we're trying to move this discussion to the new [EMAIL PROTECTED] I'm afraid this thread is dominating mono-devel. Sign up for the new list here: http://lists.sharpos.org/listinfo.cgi/sharpos-devel-list-sharpos.org -- Michael Schurter ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] SharpOS.org
Michael Schurter escribió: Since the idea of a managed operating system has been discussed at length on the mono-devel-list, I went ahead and registered sharpos.org! I encourage anyone interested in developing a managed operating system to visit http://sharpos.org Please start editing the wiki and sign up for the mailing list[1] to continue this discussion. That way we can stop flooding Mono lists with OT posts! (Someone is welcome to register a SourceForge.net project as well. We can always move to SF.net when that project becomes available or split services between the two sites.) [1] http://lists.sharpos.org/listinfo.cgi/sharpos-devel-list-sharpos.org This idea is fantastic. I would propose the following: - Use NovellForge instead of SourceForge.net (the UI is much simpler and fast, and it supports bugzilla, much wonderful than the issue tracker of SF.net). - Create a gmane group that hosts the list (I can do this, just approve the idea please). Regards, Andrés [ knocte ] -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-devel-list] Operating System in C# Project
Hi, This sounds very interesting indeed, I'll be sure to watch this and possibly would like to get involved. On 10/30/06, Johann MacDonagh [EMAIL PROTECTED] wrote: So does anyone have any problems with calling this project SharpOS? If not, I'll register www.sharpos.org right now and set up a wiki. -- I also like O# to play on the acr. OS, but SharpOS is not bad. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] PATCH: NotWorkingCategoryTests
Hi, The attached patch contains tests that we added a NotWorking category attribute for them as they pass on .NET and fail on mono. This is part of an effort we make to get zero failures execution of the mono's System.Web 2.0 test suite. Having that, all NotWorking tests are bugs and regressions will be immediately caught. Please review. Tal notworking.patch Description: notworking.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
On 10/29/06 Kornél Pál wrote: I'll probably be able to fix that one as well, but my very-very big problem is that vbnc is so undarebly slow on Mono that it's quite impossible to wait for the compiler to reach again the stage where it's failing. If the results of previous stages could be serialized it could save a lot of time and the actual stage could be debugged. This is not going to happen, because it involves a lot of work and doesn't solve any problem. There are two issues here: *) vbnc's implementation makes it very slow *) vbnc running on mono hits some codepaths that makes it even slower than it is already Any help on speeding up vbnc is welcome. Someone should provide a current vbnc binary and any assemblies it depends on so that it runs on the current svn version of mono. Please do not include the ugly additional GC thread hack. Also include a largish VB program that vbnc can compile (in, say, 10-20 seconds on the MS runtime). When that is available, we can profile it on Linux and see where it spends all that time and why. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Fix Type.Equals to support user defined types (required by vbnc)
On 10/29/06 Kornél Pál wrote: I forgot to attach the diff file.:) You also forgot the nunit tests that are required to be able to commit a change so deep in the runtime a few days before a major release:) Also, please don't post patches marked as octect-stream, they are text files, post them as such. Index: mcs/class/corlib/System/Type.cs === --- mcs/class/corlib/System/Type.cs (revision 67080) +++ mcs/class/corlib/System/Type.cs (working copy) @@ -411,20 +411,26 @@ public override bool Equals (object o) { + return Equals (o as Type); + } + + [MethodImplAttribute (MethodImplOptions.InternalCall)] + internal static extern bool type_equals (Type type1, Type type2); + + public bool Equals (Type o) + { if (o == null) return false; - - // TODO: return UnderlyingSystemType == o.UnderlyingSystemType; - Type cmp = o as Type; - if (cmp == null) - return false; - return Equals (cmp); + + // User defined types depend on this behavior + Type type1 = UnderlyingSystemType; + Type type2 = o.UnderlyingSystemType; Can two user-defined types that are reference-equal not match in Equals()? It doesn't look possible, so the fast check should be placed first. + return type1 == type2 || + (type1 != null type2 != null type1.IsSystemType type2.IsSystemType type_equals (type1, type2)); It looks like you're optimizing for the case of user-defined types, by moving several checks from the icall to here where the common case is to perform the icall in any case. The rule to follow, instead, is: never speedup the usage of user-defined types if it means slowing down the types that every sane person uses A 1% speedup of common types is worth a 10x slowdown of user-defined types. } [MethodImplAttribute(MethodImplOptions.InternalCall)] - public extern bool Equals (Type type); - - [MethodImplAttribute(MethodImplOptions.InternalCall)] private static extern Type internal_from_handle (IntPtr handle); [MethodImplAttribute(MethodImplOptions.InternalCall)] @@ -690,7 +696,13 @@ public override int GetHashCode() { - return (int)_impl.Value; + // User defined types depend on this behavior For every such comment you put in the sources we need at least a nunit test. + Type type = UnderlyingSystemType; + + if (type != this) + return type.GetHashCode (); In the above code you check for UnderlyingSystemType being null: if it's the case here, too, you'll cause a nullref exception. + + return base.GetHashCode (); } public MemberInfo[] GetMember (string name) Index: mcs/class/corlib/System/MonoType.cs === --- mcs/class/corlib/System/MonoType.cs (revision 67080) +++ mcs/class/corlib/System/MonoType.cs (working copy) @@ -565,8 +565,23 @@ UnitySerializationHolder.GetTypeData (this, info, context); } - public override string ToString() + public override bool Equals (object o) { + if (o == this) + return true; + + Type type = o as Type; + + return type != null type.IsSystemType type_equals (this, type); Same comment about optimizing for the user-defined types. + } + + public override int GetHashCode () + { + return (int) _impl.Value; + } + + public override string ToString () + { return getFullName (false, false); } Index: mono/mono/metadata/icall-def.h === --- mono/mono/metadata/icall-def.h(revision 67080) +++ mono/mono/metadata/icall-def.h(working copy) @@ -797,26 +797,26 @@ ICALL(WAITH_3, WaitOne_internal, ves_icall_System_Threading_WaitHandle_WaitOne_internal) ICALL_TYPE(TYPE, System.Type, TYPE_1) -ICALL(TYPE_1, Equals, ves_icall_type_Equals) As the comment at the start of this file says, do not do useless renames of all the entries, there is no larger diff competition going on. Besides you can just name the method
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
Any help on speeding up vbnc is welcome. Ben got the impression that VBNC was keeping a linked list of all the tokens after the tokenization phase (which is brutal on the GC as it becomes a large link-list walk). In my opinion, instead of having a tokenization phase that keeps all the tokens in memory and then a second stage that walks this list, we should turn the compiler into a parser that calls the tokenizer and pulls tokens from it on demand (like mcs does). This would avoid keeping the huge list around, and would eliminate a phase. Alternatively, a quick hack might be to clear the tokens after the parsing (but am guessing here that the data is not used afterwards). Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] PATCH: NotWorkingCategoryTests
Hello, The attached patch contains tests that we added a NotWorking category attribute for them as they pass on .NET and fail on mono. This is part of an effort we make to get zero failures execution of the mono's System.Web 2.0 test suite. Having that, all NotWorking tests are bugs and regressions will be immediately caught. Am fine with this. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
On 10/31/06 Miguel de Icaza wrote: Any help on speeding up vbnc is welcome. Ben got the impression that VBNC was keeping a linked list of all the tokens after the tokenization phase (which is brutal on the GC as it becomes a large link-list walk). While that is clearly a very inefficient way to do things, we can't say it is the issue that is making vbnc unusable especially in mono. First, it depends if the tokens are kept for the whole source or just one file at a time: in the latter case it should not be so bad, since the vbnc compiler is spread over hundreds of tiny files, so the actual memory usage should be limited. Besides a non-moving GC can be faster at handling such long lists than a moving one (one of my long-linked-list stress tests for the new GC runs about two times slower on the jvm gc and about 30% slower on the mono sgen GC vs the Boehm GC). It may be more of an issue that the source is spread in so many files. Does the code properly dispose the file strem objects as sson as tokenization is done? Anyway, it would be better to have the binaries and sample programs so that we can actually profile on linux and see where time is actually spent instead of guessing. The token list might be a problem, but it might also be a tiny part of the whole picture. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Adding a new class to System.Net
Hi Jensen, You need to add the source file name to the lists of sources to compile the desired library, a file named like 'libraryname.dll.sources'. In this specific case the file you need to change is: mcs/class/System/System.dll.sources. I've seen that you are surrounded your source with the needed #ifdef. For us to accept your patch you also need to send a changelog entry for it, and it would be better to send it as a diff file ('svn diff' on mcs/class/System/ should do the trick, and contain the changes to Changelog, System.dll.sources and your new DecompressionMethods.cs). Unit tests for enumerations, AFAIK, aren't mandatory, but probably some is missing for the method that would use the enumeration (directly as a parameter, or contained in some field of a class/struct that is passed to it or contains the method). I tried to give a short overview, but the mandatory references are: http://www.mono-project.com/Contributing http://www.mono-project.com/Mono_Contribution_HOWTO Thanks, :) On 10/31/06, Jensen Somers [EMAIL PROTECTED] wrote: Hi, I have a small question. I noticed on the Class Status Page that the public enum DecompressionMethods hasn't been implemented yet. It's not a big enum so I gave it a shot. The next step is to test it. Unfortunately recompiling mono (make clean, autogen, make make install) did not include my .cs file in the System.Net namespace and thus giving me some errors when I try to access my enum. How can I include my enum into my mono test build, to see if it actually works ? Jensen ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Rafael Monoman Teixeira --- The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. George Bernard Shaw ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Adding a new class to System.Net
Hi, I have a small question. I noticed on the Class Status Page that the public enum DecompressionMethods hasn't been implemented yet. It's not a big enum so I gave it a shot. The next step is to test it. Unfortunately recompiling mono (make clean, autogen, make make install) did not include my .cs file in the System.Net namespace and thus giving me some errors when I try to access my enum. How can I include my enum into my mono test build, to see if it actually works ? Jensen // // System.Net.DecompressionMethods.cs // // Author: // Jensen Somers [EMAIL PROTECTED] // // // Permission is hereby granted, free of charge, to any person obtaining // a copy of this software and associated documentation files (the // Software), to deal in the Software without restriction, including // without limitation the rights to use, copy, modify, merge, publish, // distribute, sublicense, and/or sell copies of the Software, and to // permit persons to whom the Software is furnished to do so, subject to // the following conditions: // // The above copyright notice and this permission notice shall be // included in all copies or substantial portions of the Software. // // THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, // EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF // MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND // NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE // LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION // OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION // WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. // #if NET_2_0 namespace System.Net { [FlagsAttribute] public enum DecompressionMethods { None = 0, GZip = 1, Deflate = 2, } } #endif ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Adding a new class to System.Net
Hi, Added it, recompiled and everything worked. I tested it with a small Console.WriteLine statement and got the same output as it does on Windows using the .NET framework. I've attached the diff file with the ChangeLog and System.dll.sources entry and the class file. Jensen Rafael Teixeira wrote: Hi Jensen, You need to add the source file name to the lists of sources to compile the desired library, a file named like 'libraryname.dll.sources'. In this specific case the file you need to change is: mcs/class/System/System.dll.sources. I've seen that you are surrounded your source with the needed #ifdef. For us to accept your patch you also need to send a changelog entry for it, and it would be better to send it as a diff file ('svn diff' on mcs/class/System/ should do the trick, and contain the changes to Changelog, System.dll.sources and your new DecompressionMethods.cs). Unit tests for enumerations, AFAIK, aren't mandatory, but probably some is missing for the method that would use the enumeration (directly as a parameter, or contained in some field of a class/struct that is passed to it or contains the method). I tried to give a short overview, but the mandatory references are: http://www.mono-project.com/Contributing http://www.mono-project.com/Mono_Contribution_HOWTO Thanks, :) On 10/31/06, Jensen Somers [EMAIL PROTECTED] wrote: Hi, I have a small question. I noticed on the Class Status Page that the public enum DecompressionMethods hasn't been implemented yet. It's not a big enum so I gave it a shot. The next step is to test it. Unfortunately recompiling mono (make clean, autogen, make make install) did not include my .cs file in the System.Net namespace and thus giving me some errors when I try to access my enum. How can I include my enum into my mono test build, to see if it actually works ? Jensen ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Index: mcs/class/System/System.dll.sources === --- mcs/class/System/System.dll.sources (revision 67176) +++ mcs/class/System/System.dll.sources (working copy) @@ -587,6 +587,7 @@ System.Net/Cookie.cs System.Net/CookieException.cs System.Net/CredentialCache.cs +System.Net/DecompressionMethods.cs System.Net/DefaultCertificatePolicy.cs System.Net/DigestClient.cs System.Net/Dns.cs Index: mcs/class/System/System.Net/ChangeLog === --- mcs/class/System/System.Net/ChangeLog (revision 67176) +++ mcs/class/System/System.Net/ChangeLog (working copy) @@ -1,3 +1,7 @@ +2006-10-31 Jensen Somers [EMAIL PROTECTED] + + * DecompressionMethods.cs : added + 2006-10-30 Atsushi Enomoto [EMAIL PROTECTED] * FtpWebRequest.cs : more build fixes. Index: mcs/class/System/System.Net/DecompressionMethods.cs === --- mcs/class/System/System.Net/DecompressionMethods.cs (revision 0) +++ mcs/class/System/System.Net/DecompressionMethods.cs (revision 0) @@ -0,0 +1,42 @@ +// +// System.Net.DecompressionMethods.cs +// +// Author: +// Jensen Somers [EMAIL PROTECTED] +// + +// +// Permission is hereby granted, free of charge, to any person obtaining +// a copy of this software and associated documentation files (the +// Software), to deal in the Software without restriction, including +// without limitation the rights to use, copy, modify, merge, publish, +// distribute, sublicense, and/or sell copies of the Software, and to +// permit persons to whom the Software is furnished to do so, subject to +// the following conditions: +// +// The above copyright notice and this permission notice shall be +// included in all copies or substantial portions of the Software. +// +// THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, +// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF +// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND +// NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE +// LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION +// OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION +// WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. +// + +#if NET_2_0 + +namespace System.Net +{ + [FlagsAttribute] +public enum DecompressionMethods +{ +None = 0, +GZip = 1, +Deflate = 2, +} +} + +#endif ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Type not found when IConfigurationSectionHandler in bin
http://bugzilla.ximian.com/show_bug.cgi?id=79396Hi, if anyone can commit this before 1.2, or something better, I'd appreciate it.It's the same fix submitted by Marek Habersack for http://bugzilla.ximian.com/show_bug.cgi?id=78321, [2.0] ObjectDataSource fails to find the specified type which was applied to svn, so i guess it's on the right track.Thanksritchie ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] SharpOS.org
Andrés G. Aragoneses [ knocte ] wrote: Michael Schurter escribió: Since the idea of a managed operating system has been discussed at length on the mono-devel-list, I went ahead and registered sharpos.org! I encourage anyone interested in developing a managed operating system to visit http://sharpos.org Please start editing the wiki and sign up for the mailing list[1] to continue this discussion. That way we can stop flooding Mono lists with OT posts! (Someone is welcome to register a SourceForge.net project as well. We can always move to SF.net when that project becomes available or split services between the two sites.) [1] http://lists.sharpos.org/listinfo.cgi/sharpos-devel-list-sharpos.org This idea is fantastic. I would propose the following: - Use NovellForge instead of SourceForge.net (the UI is much simpler and fast, and it supports bugzilla, much wonderful than the issue tracker of SF.net). Just get it setup and we'll wear the merits of each service (including my hosting) when they're available. I can also setup Bugzilla and SVN on my host, so we don't need to worry about one of these service right away. - Create a gmane group that hosts the list (I can do this, just approve the idea please). Please do. Please continue discussion on the new mailing list: [EMAIL PROTECTED] Sign up: http://lists.sharpos.org/listinfo.cgi/sharpos-devel-list-sharpos.org Michael Schurter ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] SharpOS.org
On Tue, 2006-10-31 at 09:03 -0500, Abe Gillespie wrote: No one wants to host at Google? That would be my recommendation. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
On 10/31/06 Miguel de Icaza wrote: Any help on speeding up vbnc is welcome. Ben got the impression that VBNC was keeping a linked list of all the tokens after the tokenization phase (which is brutal on the GC as it becomes a large link-list walk). While that is clearly a very inefficient way to do things, we can't say it is the issue that is making vbnc unusable especially in mono. First, it depends if the tokens are kept for the whole source or just one file at a time: in the latter case it should not be so bad, since the vbnc compiler is spread over hundreds of tiny files, so the actual memory usage should be limited. Besides a non-moving GC can be faster at handling such long lists than a moving one (one of my long-linked-list stress It seems that the linked list for *all* files was kept for the *entire* duration of the gc, from my profiling on windows. Rolf, can you confirm this? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
Is there a sample app the compiles slowly somewhere (and instructs on how to use VBNC) that i can download it and run a few tests myself to see if i could lend a hand? I'm interested in this kind of stuff, but probably won't be able to help much :p But i'll try. Thanks,Alan.On 10/31/06, Ben Maurer [EMAIL PROTECTED] wrote: On 10/31/06 Miguel de Icaza wrote: Any help on speeding up vbnc is welcome. Ben got the impression that VBNC was keeping a linked list of all the tokens after the tokenization phase (which is brutal on the GC as it becomes a large link-list walk). While that is clearly a very inefficient way to do things, we can't say it is the issue that is making vbnc unusable especially in mono. First, it depends if the tokens are kept for the whole source or just one file at a time: in the latter case it should not be so bad, since the vbnc compiler is spread over hundreds of tiny files, so the actual memory usage should be limited. Besides a non-moving GC can be faster at handling such long lists than a moving one (one of my long-linked-list stressIt seems that the linked list for *all* files was kept for the *entire*duration of the gc, from my profiling on windows. Rolf, can you confirm this?___Mono-devel-list mailing listMono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
[Not approving the 700KB mail message to the list, just replying to some comments here] On 10/31/06 Kornél Pál wrote: Does the code properly dispose the file strem objects as sson as tokenization is done? http://svn.myrealbox.com/viewcvs/trunk/vbnc/vbnc/source/General/CodeFile.vb?rev=64447view=markup The entire file is read and then is stored as a string. (This was the same before my UTF-8 detection patch.) It looks like the file is closed on finally, so that's good. It seems also that the token list is kept just while a single file is parsed, so that should not be too bad. What is worrying is that it seems the list is also used as an array, with indexing by integer and this may have a significant impact on performance. gain, we can't tell for sure until someone provides a sample program as requested. Anyway, it would be better to have the binaries and sample programs so that we can actually profile on linux and see where time is actually spent instead of guessing. The token list might be a problem, but it might also be a tiny part of the whole picture. Is that a problem if the compilation cannot complete? Currently vbnc is able to finish the resolve phase on Mono when bootstrapping and fails in early define phase. How much time does it take to complete the resolve phase? I thought that was the issue given this thread subject. If there are other issues, they should be discussed in another thread. And yes, it is a problem if it makes the compiler so slow to be unusable as you claim it is. You need Mono SVN HEAD. Microsoft.VisualBasic.dll can be used from Mono 1.1.18 installer. And you need the corlib/runtime patch in http://lists.ximian.com/pipermail/mono-devel-list/2006-October/021093.html in order to finish resolve phase. After resolve phase I have no experience because it takes too long time to finish resolve and that makes quite impossible to debug the define phase on Mono. This is why I requested a sample program that can compile, instead of trying to profile a program that never finishes. When someone posts that we can start to profile, so far nobody did, I guess we have to wait for some vb programmers to show up. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
Is that a problem if the compilation cannot complete? Currently vbnc is able to finish the resolve phase on Mono when bootstrapping and fails in early define phase. How much time does it take to complete the resolve phase? I thought that was the issue given this thread subject. If there are other issues, they should be discussed in another thread. And yes, it is a problem if it makes the compiler so slow to be unusable as you claim it is. The resolve phase is part of compilation so the subject covers the problem. When doing bootstrap (compiling vbnc using vbnc) finishing the resolve phase takes up to 2 minutes on MS.NET. Doing the same on Mono takes at least 1 hour on the same machine. So I think it's worth to profile the bootstrap altough it cannot finish further phases yet. If that's a problem simply abort compilation arfter resolve phase is finished. This is why I requested a sample program that can compile, instead of trying to profile a program that never finishes. When someone posts that we can start to profile, so far nobody did, I guess we have to wait for some vb programmers to show up. I guess that vbnc is not able to finish compiling other huge programs just like itself. But I can't fix SRE to support vbnc because it takes at least 1 hour to reach the point when it fails that makes debugging and probing patches quite impossible. I think that you could profile the vbnc bootstrap until the end of resolve phase because it requires a lot of time and memory by itself. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
On 10/31/06 Kornél Pál wrote: The resolve phase is part of compilation so the subject covers the problem. When doing bootstrap (compiling vbnc using vbnc) finishing the resolve phase takes up to 2 minutes on MS.NET. Doing the same on Mono takes at least 1 hour on the same machine. So I think it's worth to profile the bootstrap altough it cannot finish further phases yet. If that's a problem simply abort compilation arfter resolve phase is finished. Well, I'm not going to waste time with this thread anymore, since you are not willing to understand or to cooperate. I asked for a program that takes less than that to compile, because it's obvious that trying to profile that is idiotic and a complete waste of time. Is that so hard to get through? Have fun. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
Well, I'm not going to waste time with this thread anymore, since you are not willing to understand or to cooperate. I asked for a program that takes less than that to compile, because it's obvious that trying to profile that is idiotic and a complete waste of time. Is that so hard to get through? Sorry if I don't understand what you need but I have no experience in profiling Mono. What is the sample program that you need? Sorry but I really didn't understand what exactly you need. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Type not found when IConfigurationSectionHandler in bin
You mean, we should ignore the comment from Kosta on bugzilla and apply your patch anyways, right? Why? Atsushi Eno blackdog wrote: http://bugzilla.ximian.com/show_bug.cgi?id=79396 Hi, if anyone can commit this before 1.2, or something better, I'd appreciate it. It's the same fix submitted by Marek Habersack for http://bugzilla.ximian.com/show_bug.cgi?id=78321, [2.0] ObjectDataSource fails to find the specified type which was applied to svn, so i guess it's on the right track. Thanks ritchie ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
What he needs and i need and anyone else who wants to help with this issue needs is a program that takes 5-15 minutes to compile using VBNC. Trying to profile a 1 hour compile that crashes is a waste of time. Profiling for 10 minutes allows reasonalby fast results when testing a new patch. Making a change that makes compiling 20% faster will be next to impossible to detect on a compile that takes over an hour and crashes. So, as soon as i see a smallish program and instructs on compiling i'll take a look at the issue. Other than that, i'll just watch the thread. I'm not going to go hunting for ages trying to find sample apps. I don't use VBNC, i don't care whether it works or not, but if i am handed a sample app with instructions, i will try to make it faster. Thanks,Alan.On 10/31/06, Kornél Pál [EMAIL PROTECTED] wrote: Well, I'm not going to waste time with this thread anymore, since you arenot willing to understand or to cooperate. I asked for a program that takesless than that to compile, because it's obvious that trying to profile that is idiotic and a complete waste of time. Is that so hard to get through?Sorry if I don't understand what you need but I have no experience inprofiling Mono.What is the sample program that you need? Sorry but I really didn't understand what exactly you need.Kornél___Mono-devel-list mailing listMono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
This is a small program that wraps normal executable to be services. Compile using: mono --debug vbnc.exe /reference:System.dll,System.ServiceProcess.dll ServiceHost.vb vbnc is able to successfully compile this program. Hope this helps. If you need small programs, you may want to try the files in trunk/vbnc/vbnc/tests. Kornél - Original Message - From: Alan McGovern [EMAIL PROTECTED] To: mono-devel-list@lists.ximian.com Sent: Tuesday, October 31, 2006 10:59 PM Subject: Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono What he needs and i need and anyone else who wants to help with this issue needs is a program that takes 5-15 minutes to compile using VBNC. Trying to profile a 1 hour compile that crashes is a waste of time. Profiling for 10 minutes allows reasonalby fast results when testing a new patch. Making a change that makes compiling 20% faster will be next to impossible to detect on a compile that takes over an hour and crashes. So, as soon as i see a smallish program and instructs on compiling i'll take a look at the issue. Other than that, i'll just watch the thread. I'm not going to go hunting for ages trying to find sample apps. I don't use VBNC, i don't care whether it works or not, but if i am handed a sample app with instructions, i will try to make it faster. Thanks, Alan. On 10/31/06, Kornél Pál [EMAIL PROTECTED] wrote: Well, I'm not going to waste time with this thread anymore, since you are not willing to understand or to cooperate. I asked for a program that takes less than that to compile, because it's obvious that trying to profile that is idiotic and a complete waste of time. Is that so hard to get through? Sorry if I don't understand what you need but I have no experience in profiling Mono. What is the sample program that you need? Sorry but I really didn't understand what exactly you need. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Option Strict On Imports ControlChars = Microsoft.VisualBasic.ControlChars Imports System Imports System.Diagnostics Imports System.IO Imports System.Runtime.InteropServices Imports System.ServiceProcess Imports System.Threading Namespace ServiceHost Friend NotInheritable Class ServiceHost Inherits ServiceBase Private Shared ArgSeparators As Char() Private Shared CmdAutoStart As Boolean Private Shared CmdPriority As ProcessPriorityClass Private Shared CmdFileName As String Private Shared CmdArguments As String Private AutoStart As Boolean Private Priority As ProcessPriorityClass Private FileName As String Private Arguments As String Private WorkingDirectory As String Private Process As Process Shared Sub New() ArgSeparators = New Char() { c, ControlChars.Tab} End Sub Private Sub New() MyBase.New() Me.ServiceName = ServiceHost Me.CanStop = True Me.EventLog.Source = Service Host Me.AutoLog = False End Sub MTAThread() _ Public Shared Sub Main() Dim Index As Integer Dim CommandLine As String Dim ArgName As String CmdPriority = ProcessPriorityClass.Normal CommandLine = Environment.CommandLine If CommandLine.Chars(0) = c Then Index = CommandLine.IndexOf(c, 1) Else Index = CommandLine.IndexOfAny(ArgSeparators) End If If Index 0 AndAlso Index + 1 CommandLine.Length Then CommandLine = CommandLine.Substring(Index + 1).TrimStart(ArgSeparators) Do While CommandLine.StartsWith(-) Index = CommandLine.IndexOfAny(ArgSeparators, 1) If Index = 0 Then ArgName = CommandLine.Substring(0, Index).ToLower Else ArgName = String.Empty End If If Index + 1 = CommandLine.Length Then CommandLine = String.Empty Else CommandLine = CommandLine.Substring(Index + 1).TrimStart(ArgSeparators) End If If ArgName.Equals(-autostart) Then CmdAutoStart = True ElseIf ArgName.Equals(-highpriority) Then CmdPriority = ProcessPriorityClass.High ElseIf ArgName.Equals(-lowpriority) Then CmdPriority = ProcessPriorityClass.Idle End If Loop
Re: [Mono-dev] Type not found when IConfigurationSectionHandler in bin
Please check the thread Re: [Mono-dev] [PATCH] Correction to the r65131 inSystem.Web.UI.WebControls/ObjectDataSourceView.csKosta replied that he didn't fix the bug, specifically: I did not make any fixes for http://bugzilla.ximian.com/show_bug.cgi?id=79396. My comment was made to avoid a potential error of using AppDomain.GetAssemblies() in the fix when it will be committed. At the time I tried recompiling svn with the fixes Kosta mentioned and it still didn't work, apart from that I have no clue of the status or what is for the best - maybe the AppDomain.GetAssemblies() that Kosta refers to has been committed, I don't know, but I'm still having to apply the patch - as of 1.1.18thanksRitchieOn 10/31/06, Atsushi Eno [EMAIL PROTECTED] wrote: You mean, we should ignore the comment from Kosta on bugzillaand apply your patch anyways, right? Why?Atsushi Enoblackdog wrote: http://bugzilla.ximian.com/show_bug.cgi?id=79396 Hi, if anyone can commit this before 1.2, or something better, I'd appreciate it. It's the same fix submitted by Marek Habersack for http://bugzilla.ximian.com/show_bug.cgi?id=78321, [2.0] ObjectDataSource fails to find the specified type which was applied to svn, so i guess it's on the right track. Thanks ritchie ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___Mono-devel-list mailing listMono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Type not found when IConfigurationSectionHandler in bin
Oh, okay, thanks for the clarification. I also prefer your fix and make some changes to ObjectDataSourceView as Kosta suggested, but at this state the svn tree is almost already frozen for 1.2 release which should not cause regression, it would be better to wait for 1.2.1 which won't be so far. Atsushi Eno blackdog wrote: Please check the thread *Re: [Mono-dev] [PATCH] Correction to the r65131 inSystem.Web.UI.WebControls/ObjectDataSourceView.cs *Kosta replied that he didn't fix the bug, specifically: I did not make any fixes for http://bugzilla.ximian.com/show_bug.cgi?id=79396. My comment was made to avoid a potential error of using AppDomain.GetAssemblies() in the fix when it will be committed. At the time I tried recompiling svn with the fixes Kosta mentioned and it still didn't work, apart from that I have no clue of the status or what is for the best - maybe the AppDomain.GetAssemblies() that Kosta refers to has been committed, I don't know, but I'm still having to apply the patch - as of 1.1.18 thanks Ritchie On 10/31/06, Atsushi Eno [EMAIL PROTECTED] wrote: You mean, we should ignore the comment from Kosta on bugzilla and apply your patch anyways, right? Why? Atsushi Eno blackdog wrote: http://bugzilla.ximian.com/show_bug.cgi?id=79396 Hi, if anyone can commit this before 1.2, or something better, I'd appreciate it. It's the same fix submitted by Marek Habersack for http://bugzilla.ximian.com/show_bug.cgi?id=78321, [2.0] ObjectDataSource fails to find the specified type which was applied to svn, so i guess it's on the right track. Thanks ritchie ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
On Tue, 2006-10-31 at 22:52 +0100, Kornél Pál wrote: Well, I'm not going to waste time with this thread anymore, since you are not willing to understand or to cooperate. I asked for a program that takes less than that to compile, because it's obvious that trying to profile that is idiotic and a complete waste of time. Is that so hard to get through? Sorry if I don't understand what you need but I have no experience in profiling Mono. What is the sample program that you need? Sorry but I really didn't understand what exactly you need. He needs Hello World: Imports System Public Module HelloWorld Public Shared Sub Main () Console.WriteLine (Hello, World!) End Sub End Module I don't know VB, so that probably won't work, but he needs a *small* VB source program that doesn't take 1 hour to compile, but instead (preferably) takes 1 minute. If Hello World can't be compiled in a reasonable time frame, then Ouch. - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Type not found when IConfigurationSectionHandler in bin
Hello, Oh, okay, thanks for the clarification. I also prefer your fix and make some changes to ObjectDataSourceView as Kosta suggested, but at this state the svn tree is almost already frozen for 1.2 release which should not cause regression, it would be better to wait for 1.2.1 which won't be so far. This is a 2.0 control, we can patch it. Which patch should I use? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
Hello, Sorry if I don't understand what you need but I have no experience in profiling Mono. What is the sample program that you need? Sorry but I really didn't understand what exactly you need. The profiler today only runs when the program exists successfully, so we need a shorter test case, something that will not take one hour to build, but something that will take, say, a minute to build. Once we have something that takes a minute to build (or even 10 seconds instead of instantaneous builds) we can start looking where the memory went. My take is that probably building a chunk of the VB runtime is probably good enough for this. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Type not found when IConfigurationSectionHandler in bin
It is pasted in http://bugzilla.ximian.com/show_bug.cgi?id=79396 . The issue remaining is, looks like ObjectDataSourceView had better be changed (simplified) as well. Atsushi Eno Miguel de Icaza wrote: Hello, Oh, okay, thanks for the clarification. I also prefer your fix and make some changes to ObjectDataSourceView as Kosta suggested, but at this state the svn tree is almost already frozen for 1.2 release which should not cause regression, it would be better to wait for 1.2.1 which won't be so far. This is a 2.0 control, we can patch it. Which patch should I use? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] SharpOS.org
Michael Schurter escribió: Since the idea of a managed operating system has been discussed at length on the mono-devel-list, I went ahead and registered sharpos.org! I encourage anyone interested in developing a managed operating system to visit http://sharpos.org Please start editing the wiki and sign up for the mailing list[1] to continue this discussion. That way we can stop flooding Mono lists with OT posts! (Someone is welcome to register a SourceForge.net project as well. We can always move to SF.net when that project becomes available or split services between the two sites.) [1] http://lists.sharpos.org/listinfo.cgi/sharpos-devel-list-sharpos.org This idea is fantastic. I would propose the following: - Use NovellForge instead of SourceForge.net (the UI is much simpler and fast, and it supports bugzilla, much wonderful than the issue tracker of SF.net). - Create a gmane group that hosts the list (I can do this, just approve the idea please). Regards, Andrés [ knocte ] -- ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] SharpOS.org
Andrés, - Use NovellForge instead of SourceForge.net (the UI is much simpler and fast, and it supports bugzilla, much wonderful than the issue tracker of SF.net). I used to have couple of projects on NovellForge: I cannot agree with you about the fact it is better than SourceForge for various reasons, in fact I switched all my project to the second one after a while. Having a faster or simpler UI than SF.net (and I don't agree on both of the concepts) is not something you have to consider when managing a project aiming to be important and accessed by many developers or simple users at the same time. You need a stable structure you can lean on in critical moments and you also need visibility among the development community: SourceForge.net is continuously monitored by millions of developers each day, some of them searching for projects to join. I could continue for hours debating why SourceForge is better than NovellForge, but I believe it's clear to many readers of this mailing list, so I don't want to go on this topic. Cheers Antonello On 10/31/06, Andrés G. Aragoneses [ knocte ] [EMAIL PROTECTED] wrote: Michael Schurter escribió: Since the idea of a managed operating system has been discussed at length on the mono-devel-list, I went ahead and registered sharpos.org! I encourage anyone interested in developing a managed operating system to visit http://sharpos.org Please start editing the wiki and sign up for the mailing list[1] to continue this discussion. That way we can stop flooding Mono lists with OT posts! (Someone is welcome to register a SourceForge.net project as well. We can always move to SF.net when that project becomes available or split services between the two sites.) [1] http://lists.sharpos.org/listinfo.cgi/sharpos-devel-list-sharpos.org This idea is fantastic. I would propose the following: - Use NovellForge instead of SourceForge.net (the UI is much simpler and fast, and it supports bugzilla, much wonderful than the issue tracker of SF.net). - Create a gmane group that hosts the list (I can do this, just approve the idea please). Regards, Andrés [ knocte ] -- ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Free report
Hi people, I'm looking to a free and nice report writer for asp.net 2.0, i saw this a few months ago but i don't remember. Anyone? Thanks, Jorge ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Helping out Windows Developers
The Run in Mono button removes the need to find the mono command line, and call mono on wherever your assembly happens to be. I think this feature absolutely needs to be ported to VS2005, and renamed something more like Mono Development Plugin or something. The other features can come along for the ride if they are ready, but I need this feature in VS2005 today. :) I created a buttons in system tray having C:\Program Files\Mono-1.1.17.1\bin\mono.exe c:\mydir\bin\debug\myapp.exe After pressing F6 in VCS I can press to this button to test my application in mono. This is even easier than selecting something from menu. Either way, this just needs to be a button on the image desktop that does all the work for you. That is, click the button titled Update Mono to latest version, wait for the command window to stop scrolling and say It's done, press Enter, and have fun. I don't see the need for SVN for most things since there is monocharge archieves compiled nightly. I'd like to see windows .bat file in monocharge archieves which refreshes mono automatically, by running something like for %%i in (*.dll) do mono ..\1.0\gacutil.exe /i %%i /f /package 2.0 Currently they contain only .sh skript. Andrus. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Free report
http://www.fyireporting.com Andrus. - Original Message - I'm looking to a free and nice report writer for asp.net 2.0, i saw this a few months ago but i don't remember. Anyone? ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Launching a Mono Apps on Ms.Net
Hi, I've developed a SWF Apps under Mono and i've tryed it on windows. Everythings looks nearly fine excepts some little stuff. One off them is annoying ... When I launch my apps under Mono/Linux, no console windows ... When I launch my apps under .Net/Windows, lauch a console then the windows ... Any idea ? Ps : is there a way to deisgn SWF on Mono/Linux. I've done directly by hand ... How to say ... :-) ! ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Launching a Mono Apps on Ms.Net
[EMAIL PROTECTED] wrote: Hi, I've developed a SWF Apps under Mono and i've tryed it on windows. Everythings looks nearly fine excepts some little stuff. One off them is annoying ... When I launch my apps under Mono/Linux, no console windows ... When I launch my apps under .Net/Windows, lauch a console then the windows ... Use the appropriate target: mcs /target:winexe ... Robert ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] SharpOS.org
On Tue, 2006-10-31 at 09:03 -0500, Abe Gillespie wrote: No one wants to host at Google? That would be my recommendation. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Types not found on 1.1.18
A couple months ago I stripped down a few pieces of my WinForms 2.0 application until it compiled on gmcs 1.1.13. The blocking issues where all 2.0 stuff, so now I got 1.1.18 and tried to recompile to see what I could re-enable to bring the code closer to the original project. (I really want to show the app working on Linux to a few people in the firm.) I found it strange that now in many places the compiler couldn't find the types 'DataRow', 'DateTime', 'DBNull', since the namespaces are imported and System.dll and System.Data.dll are referenced. Did somebody else experience this? Pedro ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Launching a Mono Apps on Ms.Net
On Tue, 2006-10-31 at 15:00 +0100, Robert Jordan wrote: [EMAIL PROTECTED] wrote: Hi, I've developed a SWF Apps under Mono and i've tryed it on windows. Everythings looks nearly fine excepts some little stuff. One off them is annoying ... When I launch my apps under Mono/Linux, no console windows ... When I launch my apps under .Net/Windows, lauch a console then the windows ... Use the appropriate target: mcs /target:winexe ... It's a common question and a great opportunity for someone to contribute a (very simple) rule for Gendarme ;-) E.g. Any .EXE that reference System.Windows.Forms.dll should have a winexe target (or we issue a warning). -- Sebastien Pouliot [EMAIL PROTECTED] Blog: http://pages.infinit.net/ctech/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Launching a Mono Apps on Ms.Net
Andrus wrote: Use the appropriate target: mcs /target:winexe ... It's a common question and a great opportunity for someone to contribute a (very simple) rule for Gendarme ;-) E.g. Any .EXE that reference System.Windows.Forms.dll should have a winexe target (or we issue a warning). mono mywinexetargetapplication.exe shows flashing console window when issued from icon in Windows. How to avoid this flashing window ? The initial console cannot be suppressed. It it shown because mono.exe is a native Win32 console application. This could be fixed by providing monow.exe, compiled for the native Win32 winexec target. Robert ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] SharpOS.org
Andrés G. Aragoneses [ knocte ] wrote: Michael Schurter escribió: Since the idea of a managed operating system has been discussed at length on the mono-devel-list, I went ahead and registered sharpos.org! I encourage anyone interested in developing a managed operating system to visit http://sharpos.org Please start editing the wiki and sign up for the mailing list[1] to continue this discussion. That way we can stop flooding Mono lists with OT posts! (Someone is welcome to register a SourceForge.net project as well. We can always move to SF.net when that project becomes available or split services between the two sites.) [1] http://lists.sharpos.org/listinfo.cgi/sharpos-devel-list-sharpos.org This idea is fantastic. I would propose the following: - Use NovellForge instead of SourceForge.net (the UI is much simpler and fast, and it supports bugzilla, much wonderful than the issue tracker of SF.net). Just get it setup and we'll wear the merits of each service (including my hosting) when they're available. I can also setup Bugzilla and SVN on my host, so we don't need to worry about one of these service right away. - Create a gmane group that hosts the list (I can do this, just approve the idea please). Please do. Please continue discussion on the new mailing list: [EMAIL PROTECTED] Sign up: http://lists.sharpos.org/listinfo.cgi/sharpos-devel-list-sharpos.org Michael Schurter ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Launching a Mono Apps on Ms.Net
Use the appropriate target: mcs /target:winexe ... It's a common question and a great opportunity for someone to contribute a (very simple) rule for Gendarme ;-) E.g. Any .EXE that reference System.Windows.Forms.dll should have a winexe target (or we issue a warning). mono mywinexetargetapplication.exe shows flashing console window when issued from icon in Windows. How to avoid this flashing window ? Andrus. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] libgaim
Has anyone see C# bindings for libgaim? If there aren't bindings would libgaim be the preferred route to provide IM network services to .NET applications (all networks or at least the most important types xmpp / oscar / msn / yahoo). ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] libgaim
2006/10/31, Corbin Hoenes [EMAIL PROTECTED]: Has anyone see C# bindings for libgaim? If there aren't bindings would libgaim be the preferred route to provide IM network services to .NET applications (all networks or at least the most important types xmpp / oscar / msn / yahoo). I don't know of any other libraries providing you with a variety of protocols. But as an alternative, you can consider using Jabber/XMPP library + transports.Regarding the managed libraries, AFAIK Galaxium is using one, but that's only for MSN. ---Olexandr Kynlem Melnyk, http://omelnyk.net/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] SharpOS.org
No one wants to host at Google? -Abe On 10/31/06, Antonello Provenzano [EMAIL PROTECTED] wrote: Andrés, - Use NovellForge instead of SourceForge.net (the UI is much simpler and fast, and it supports bugzilla, much wonderful than the issue tracker of SF.net). I used to have couple of projects on NovellForge: I cannot agree with you about the fact it is better than SourceForge for various reasons, in fact I switched all my project to the second one after a while. Having a faster or simpler UI than SF.net (and I don't agree on both of the concepts) is not something you have to consider when managing a project aiming to be important and accessed by many developers or simple users at the same time. You need a stable structure you can lean on in critical moments and you also need visibility among the development community: SourceForge.net is continuously monitored by millions of developers each day, some of them searching for projects to join. I could continue for hours debating why SourceForge is better than NovellForge, but I believe it's clear to many readers of this mailing list, so I don't want to go on this topic. Cheers Antonello On 10/31/06, Andrés G. Aragoneses [ knocte ] [EMAIL PROTECTED] wrote: Michael Schurter escribió: Since the idea of a managed operating system has been discussed at length on the mono-devel-list, I went ahead and registered sharpos.org! I encourage anyone interested in developing a managed operating system to visit http://sharpos.org Please start editing the wiki and sign up for the mailing list[1] to continue this discussion. That way we can stop flooding Mono lists with OT posts! (Someone is welcome to register a SourceForge.net project as well. We can always move to SF.net when that project becomes available or split services between the two sites.) [1] http://lists.sharpos.org/listinfo.cgi/sharpos-devel-list-sharpos.org This idea is fantastic. I would propose the following: - Use NovellForge instead of SourceForge.net (the UI is much simpler and fast, and it supports bugzilla, much wonderful than the issue tracker of SF.net). - Create a gmane group that hosts the list (I can do this, just approve the idea please). Regards, Andrés [ knocte ] -- ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Launching a Mono Apps on Ms.Net
The initial console cannot be suppressed. It it shown because mono.exe is a native Win32 console application. This could be fixed by providing monow.exe, compiled for the native Win32 winexec target. Can you include such exe with mono windows distribution like activestate python distro includes pythonw.exe ? ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] libgaim
MSN: http://www.xihsolutions.net/dotmsn/ Oscar: http://www.danielgrunwald.de/coding/NOscar/ Jabber http://jabberstudio.org/projects/jabber-net/project/view.php dont know if these libs are pure .net and will run under mono. nothing found about yahoo. but there are inofficial protocol descriptions around the web. perhaps you'll have to set up your own lib. :) perhaps out there is a usable jabber - yahoo gateway. HTH Olexandr Melnyk schrieb: 2006/10/31, Corbin Hoenes [EMAIL PROTECTED]: Has anyone see C# bindings for libgaim? If there aren't bindings would libgaim be the preferred route to provide IM network services to .NET applications (all networks or at least the most important types xmpp / oscar / msn / yahoo). I don't know of any other libraries providing you with a variety of protocols. But as an alternative, you can consider using Jabber/XMPP library + transports. Regarding the managed libraries, AFAIK Galaxium is using one, but that's only for MSN. --- Olexandr "Kynlem" Melnyk, http://omelnyk.net/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Launching a Mono Apps on Ms.Net
Andrus wrote: The initial console cannot be suppressed. It it shown because mono.exe is a native Win32 console application. This could be fixed by providing monow.exe, compiled for the native Win32 winexec target. Can you include such exe with mono windows distribution like activestate python distro includes pythonw.exe ? http://bugzilla.ximian.com/show_bug.cgi?id=79797 Robert ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Static linking
I don't know how I missed this: http://evain.net/blog/articles/2006/08/21/link-to-link Thanks Massi and JB Evain. Massimiliano Mantione wrote: On Mon, 2006-10-30 at 14:51 +, Colin JN Breame wrote: I know this is probably pretty far fetched, but is it possible to statically link an exe to all it's (non-mono) dll dependants? What I'd like to do is run something like make deploy that collects all dependants so I only have to deploy a single exe file. If this doesn't exist, how would one go about writing something like this? JB Evain wrote such a linker as a Google SoC 2006 project. Ciao, Massi ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list