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
