Re: [Mono-dev] Architectural decisions behind mod_mono
Unfortunately Microsoft has a long history of confusion on this topic. I remember back when IIS5 was being developed I implored the IIS team make it possible to write filters as kernel modules. I insisted that the extra kernel transitions needed to invoke my legacy encryption filter was going to kill performance. Their reaction was 'No way! You might blue-screen the machine!'. They never did understand that, whether it was in user space or the kernel, if there was a fatal bug in my filter the machine was no more useful than a doorstop. Maybe but these kind of performance issues can usually be solved through horizontal scaling, something which applications like Facebook should have no problem with. Bluescreens on shared hosting boxes however would be very bad, and the shared hosting market is very important for webdevelopment frameworks to attract new developers. That and maybe debugging issues, it's tough to debug something if it keeps bluescreening on you. If a process dies because of a segmentation fault, you just restart the process so it can resume work while you figure out what happened. This is significantly less downtime, which means especially much for hosting with uptime guarantees. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono on Windows Native NT API
Hey, When you're thinking of implementing slimmed down versions of some kernel dll's, maybe you could lend some code from the Wine and/or ReactOS projects. Both projects implement the kernel api's too. Unless you ofcourse want to find out things for yourself, or don't want your project to be opensource :) Cool project you got anyways! --Tinco ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] .net reference license
From scott guthrie's blogpost on wednesday: Reference License The .NET Framework source is being released under a read-only reference license. When we announced that we were releasing the source back in October, some people had concerns about the potential impact of their viewing the source. To help clarify and address these concerns, we made a small change to the license to specifically call out that the license does not apply to users developing software for a non-Windows platform that has the same or substantially the same features or functionality as the .NET Framework. If the software you are developing is for Windows platforms, you can look at the code, even if that software has the same or substantially the same features or functionality as the .NET Framework. I guess this settles the reference license questions, no reading sources for mono developers. As was already suggested by Miquel and others. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-list] .net reference license
From scott guthrie's blogpost on wednesday: Reference License The .NET Framework source is being released under a read-only reference license. When we announced that we were releasing the source back in October, some people had concerns about the potential impact of their viewing the source. To help clarify and address these concerns, we made a small change to the license to specifically call out that the license does not apply to users developing software for a non-Windows platform that has the same or substantially the same features or functionality as the .NET Framework. If the software you are developing is for Windows platforms, you can look at the code, even if that software has the same or substantially the same features or functionality as the .NET Framework. I guess this settles the reference license questions, no reading sources for mono developers. As was already suggested by Miquel and others. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] String.GetHashCode()
(Woops, only replied to kamil) If Jerome is right and the overhead is only 4 bytes, then overhead shouldn't be a problem at all. The worst case size of a string would be 1 character, of 2 bytes + something to end it with, like an int containing its length, 2 bytes, or a terminating character, probably 2 bytes too. Making it at least 4 bytes. A worst case scenario of 100% extra data, that isn't so bad right? It's way less than the overhead of using unicode, since you almost never use the enormous range of character 2-3 bytes offers you. Speaking of unicode/utf-16 and memory, couldn't a lot of memory be spared if strings where stored as utf8 internally, which would be converted back to utf-16 when more than 256 different characters would be used? All you would need is a small translation table, and the view instructions it takes to look a char up in it. Or is this already being done? Just curious. Tinco Date: Fri, 30 Nov 2007 19:10:07 -0800 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] String.GetHashCode() Extra memory cost, which would hit all allocated strings, also those short ones. For some applications, which use millions of small strings this would be unacceptable hit. 2007/11/30, Alan McGovern [EMAIL PROTECTED]: A thought struck me while i was dozing on the plane on the way home from the summit. Since strings are immutable, shouldn't it be possible to compute the hashcode once and store it rather than recomputing it over and over again? Is there some really obvious reason that i can't think of that would make this a bad idea? Alan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Express yourself instantly with MSN Messenger! MSN Messenger _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] .net library shared source
Also, this might be a bit paranoid statement, but Microsoft will be able to tell from it's log wether a person has looked at a particular piece of source since the sourcecode will be provided as a webservice. When it would come to a courtcase (which I think is very unlikely) Microsoft probably will not hold back this kind of evidence. So caution really is necessary. Subject: Re: [Mono-dev] .net library shared source From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: mono-devel-list@lists.ximian.com Date: Thu, 4 Oct 2007 10:31:25 -0400If we can't even look at the source, it will make it virtually impossible for .net developers to contribute to mono, since the source viewing will be integrated with visual studio and will greatly enhance debugging, it would be stupid not to use it for regular developing. Soon everyone will have seen at least some part of the code. Then we will not accept their contributions. It is that easy. If you look at code in System.Net, it does not mean that you can not contribute to say System.Windows.Forms. So there is some nuance here. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] .net library shared source
Hey guys, Have you read this? http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source-code-for-the-net-framework-libraries.aspx How will this affect the mono project? Will we able to use it to make the framework match more to microsoft's or is it information we already have (from the spec)? From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Wed, 3 Oct 2007 13:46:11 -0400 CC: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Incorrect trunc() definition for MSVC in mono-compiler.h Hello, Thanks, I have commited a patch. Hi,mono/utils/mono-compiler.h has incorrect trunc() definition for Visual Studio, causing overflow exceptions to be thrown from int-float conversions with negative inputs. Line 88 is: #define trunc(x) floor((x)) when it should be something like: #define trunc(x) (((x) 0) ? ceil((x)) : floor((x))) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] .net library shared source
If we can't even look at the source, it will make it virtually impossible for .net developers to contribute to mono, since the source viewing will be integrated with visual studio and will greatly enhance debugging, it would be stupid not to use it for regular developing. Soon everyone will have seen at least some part of the code. Date: Wed, 3 Oct 2007 19:17:05 -0400From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: Re: [Mono-dev] .net library shared sourceCC: [EMAIL PROTECTED] Miguel's blog post: http://tirania.org/blog/archive/2007/Oct-03.htmlAlso, the rules for contributing are still in effect: http://www.mono-project.com/ContributingIf you have looked at Microsoft's implementation of .NET or their shared source code, you will not be able to contribute to Mono.- Jonathan On 10/3/07, Tinco Andringa [EMAIL PROTECTED] wrote: Hey guys, Have you read this? http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source-code-for-the-net-framework-libraries.aspx How will this affect the mono project? Will we able to use it to make the framework match more to microsoft's or is it information we already have (from the spec)? From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Wed, 3 Oct 2007 13:46:11 -0400 CC: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Incorrect trunc() definition for MSVC in mono-compiler.h Hello, Thanks, I have commited a patch. Hi,mono/utils/mono- compiler.h has incorrect trunc() definition for Visual Studio, causing overflow exceptions to be thrown from int-float conversions with negative inputs.Line 88 is: #define trunc(x) floor((x)) when it should be something like: #define trunc(x) (((x) 0) ? ceil((x)) : floor((x))) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Express yourself instantly with MSN Messenger! MSN Messenger___Mono-devel-list mailing [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-devel-list _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
