[Mono-dev] Problem with Mono in Fedora 6
Hi, nbsp;nbsp; I was using Mono in Fedora 3 and it was working fine. I Need to upgrade itnbsp;to Fedora 6 and mono doens't works anymore. Can you help me? I dont find any error message in the log records. All I have is a 500 internal error error message. nbsp;nbsp; I have installed Apache 2.2.3 andnbsp;mono version 1.2.3.1 (JIT). Mono was recompiled as mod_mono so far. nbsp;nbsp; I have no clues to help where can I find the error. nbsp;nbsp; mod_mono.conf is like this: nbsp;nbsp;nbsp; LoadModule mono_module /usr/lib/httpd/modules/mod_mono.so nbsp;nbsp;nbsp; AddType application/x-asp-net .aspx nbsp;nbsp;nbsp; AddType application/x-asp-net .asmx nbsp;nbsp;nbsp; AddType application/x-asp-net .ashx nbsp;nbsp;nbsp; AddType application/x-asp-net .asax nbsp;nbsp;nbsp; AddType application/x-asp-net .ascx nbsp;nbsp;nbsp; AddType application/x-asp-net .soap nbsp;nbsp;nbsp; AddType application/x-asp-net .rem nbsp;nbsp;nbsp; AddType application/x-asp-net .axd nbsp;nbsp;nbsp; AddType application/x-asp-net .cs nbsp;nbsp;nbsp; AddType application/x-asp-net .config nbsp;nbsp;nbsp; AddType application/x-asp-net .Config nbsp;nbsp;nbsp; AddType application/x-asp-net .dll nbsp;nbsp;nbsp; DirectoryIndex index.aspx nbsp;nbsp;nbsp; DirectoryIndex Default.aspx nbsp;nbsp;nbsp; DirectoryIndex default.aspx Alias /aspNFD32 /home/paginas/mcsoft/wwwroot/aspNFD32 MonoApplications /aspNFD32:/home/paginas/mcsoft/wwwroot/aspNFD32 nbsp; SetHandler mono nbsp;nbsp; Thanks for any help. nbsp;nbsp; Marco Castro ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problem with Mono in Fedora 6
Can you post the apache server logs for one of your sessions that are yielding the 500 error? That may help us determine some possible causes. Marco Castro wrote: Hi, I was using Mono in Fedora 3 and it was working fine. I Need to upgrade it to Fedora 6 and mono doens't works anymore. Can you help me? I dont find any error message in the log records. All I have is a 500 internal error error message. I have installed Apache 2.2.3 and mono version 1.2.3.1 (JIT). Mono was recompiled as mod_mono so far. I have no clues to help where can I find the error. mod_mono.conf is like this: LoadModule mono_module /usr/lib/httpd/modules/mod_mono.so AddType application/x-asp-net .aspx AddType application/x-asp-net .asmx AddType application/x-asp-net .ashx AddType application/x-asp-net .asax AddType application/x-asp-net .ascx AddType application/x-asp-net .soap AddType application/x-asp-net .rem AddType application/x-asp-net .axd AddType application/x-asp-net .cs AddType application/x-asp-net .config AddType application/x-asp-net .Config AddType application/x-asp-net .dll DirectoryIndex index.aspx DirectoryIndex Default.aspx DirectoryIndex default.aspx Alias /aspNFD32 /home/paginas/mcsoft/wwwroot/aspNFD32 MonoApplications /aspNFD32:/home/paginas/mcsoft/wwwroot/aspNFD32 SetHandler mono Thanks for any help. Marco Castro ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- -- | Cullen Linn | Linn Logistics LLC | | (928) 279-8620 office | (866) 882-1526 fax | | [EMAIL PROTECTED] | | http://www.LinnLogistics.com -- begin:vcard fn:Cullen Linn n:Linn;Cullen org:Linn Logistics LLC adr;dom:;;;Kingman;AZ;86409 email;internet:[EMAIL PROTECTED] tel;work:928-279-8620 tel;fax:866-882-1526 x-mozilla-html:FALSE url:http://www.LinnLogistics.com version:2.1 end:vcard ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] GetAddrOf mono-basic vb.net
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of LB Audio Uchoa NET Sent: viernes, 04 de mayo de 2007 16:37 To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] GetAddrOf mono-basic vb.net It is in VB6. Public Declare Function GetAddrOf Lib kernel32 Alias MulDiv (nNumber As Any, Optional ByVal nNumerator As Long = 1, Optional ByVal nDenominator As Long = 1) As Long The VB.Net version should be something like Public Declare Function GetAddrOf Lib kernel32 Alias MulDiv (ByVal nNumber As Integer, Optional ByVal Numerator As Integer = 1, Optional ByVal Denominator As Integer = 1) As Integer At least according to the declaration of MulDiv in MSDN. Now why do you rename a function called MulDiv to GetAddrOf? Rolf ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Silverlight early implementation thoughts.
Hey folks, This is a repost from an internal email that really should have been public. Apologies for not sharing with the team my thoughts on Silverlight as the conference was unwrapping. I think folks found out about my interest on Silverlight from Martin LaMonica's blog entry. Silverlight 1.1 is obviously very aligned with the work that we are doing, and if someone is going to implement that it is a natural fit for our team to do so. For one, the majority of the work are the upgrades to the 3.5 libraries (System.Core.dll, completing generics, C# 3). Today our main goal is to allow a smooth migration of developers from Windows to Linux (ok, it is not smooth at all right now, you kind of have to be a Unix user to do the transition at all). Silverlight brings another component into the equation: a lack of Linux/Silverlight will prevent the Linux desktop from getting some content. Whether it will be a big or small issue is yet to be debated, but regardless of this, it seems that Silverlight is a lot of fun to implement. WPF is too big, and there is very little gain, at least in the next 3-4 years, because there is no migration strategy for every ISV that has invested in Winforms, so the only usage scenarios for WPF were new applications, or people that were willing to throw out their investments and pretty much start from scratch. On the other hand, Silverlight is a tiny subset of WPF, relatively easy to implement (a weekend hack, two at most as it has been pointed out by some of you) and it will be used to spice up existing web-based applications as opposed to rewriting an application. Now, we have a bunch of challenges ahead of us, and it is not clear when we should start work on a Mono-based Silverlight, I think we should but we must: * Ship MonoDevelop 1.0, and continue improving it as we wont be a kick-ass development platform until we move beyond Makefiles and debugging with gdb and mdb on the command line. We keep saying Mono is a better development platform, but it wont be for the unwashed massed until we get this. * Ship Windows.Forms and ASP.NET 2.0: there are hundreds of people trying to move their applications to Mono today, and we are going to need to complete both of these before we can enable the next wave of migrations. Which is sadly the majority of applications. (caveat: I rather have Mainsoft do Webparts that doing it ourselves) Implicit in the above is completing the 2.0 profile, and determine what we can implement, and what we can postpone. * Visual Studio integration: we are going to have to come up with a strategy to get VS developers to deploy on Linux. A major blocker for the VS integration is that it wont be a great experience today until we finish Winforms and ASP. In a way, am ok with the lack of a Visual Studio plugin today if only because we would not look very good to Windows developers in our current conditions. Once we finish 2.0, it would be good to have the plugin ready. Andreia started a bit of a specification here: http://www.mono-project.com/Visual_Studio_Integration But it is a bit of a how-to. I would want to figure out instead *what* is that we want to achieve, what kind of experience people will get, and then discuss how we get there. Considering the above, am not sure when and how we could start work on Silverlight. That being said, am obviously excited, and I have done some early research on the various areas that will need work, I have posted the details here: http://www.mono-project.com/Moonlight The name was suggested by Sebastien (who also has done some research that I hope he will post into that wiki page as well). Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] GetAddrOf mono-basic vb.net
At 05:00 PM 5/4/2007 +0200, Rolf Bjarne wrote: It is in VB6. Public Declare Function GetAddrOf Lib kernel32 Alias MulDiv (nNumber As Any, Optional ByVal nNumerator As Long = 1, Optional ByVal nDenominator As Long = 1) As Long The VB.Net version should be something like Public Declare Function GetAddrOf Lib kernel32 Alias MulDiv (ByVal nNumber As Integer, Optional ByVal Numerator As Integer = 1, Optional ByVal Denominator As Integer = 1) As Integer At least according to the declaration of MulDiv in MSDN. Now why do you rename a function called MulDiv to GetAddrOf? What it is is an ingenious use of an API function to achieve something the original author thought VB didn't have built-in. (The original author should be directed to the help file pages for VarPtr, StrPtr and ObjPtr.) Note that in the original VB6 declaration, the nNumber parameter is not declared correctly as a ByVal Long, but rather is left As Any. When the parameter is As Any, VB6 will pass it ByRef unless you explicitly ask it not to in the call. This means the caller receives a pointer on the stack. Note that the MulDiv API function expects the actual value on the stack. What then happens if you, say, call GetAddrOf(my_local_variable), is that the Optional parameters default to one, and you end up asking the OS to take the memory address of my_local_variable, multiply it by 1, and then divide it by 1. Obviously this returns simply the memory address, unchanged. (Why is there an API function just to multiply and then divide a number? So that programming languages that cannot easily work with 64-bit values can scale a 32-bit value by a fraction where the intermediate value, multiplied by the numerator but not yet divided, does not fit into 32 bits.) In VB6, as I mentioned, there is a built-in function to do this: VarPtr (or StrPtr if you want the string data of a String (which is just a BSTR in VB6), or ObjPtr if you want a pointer to the interface you have selected for a given object reference). In VB.NET, the idiom is, for the most part, completely unneeded, especially if you are hoping to write code that runs both on Windows and on other platforms in Mono. The only situation I can think of where you would directly need the memory address of data is where you have an unmanaged structure which has a member that points at the data, a structure which you would then pass into some system-specific API function. I'm no VB.NET expert; in C#, you would simply write an unsafe code block and use the address-of operator '' to get your pointer (using 'fixed' for arrays). Perhaps there is a better way, but if you *really* need to pass a value by its memory address in VB.NET, all that comes to my mind would be to use Marshal.AllocHGlobal, store the resulting IntPtr in the unmanaged structure, and then use Marshal.WriteInt32 (or one of its friends) to fill the data at the memory address you just allocated. Of course, if all you need is to pass a local variable directly into an API function ByRef, then instead of declaring that function with a ByVal memory address, declare it with a ByRef parameter of the actual data type and .NET's P/Invoke marshalling will automatically give the API a pointer. I'd be academically interested to know if there's a better way in VB.NET, but that just about sums up what this GetAddrOf is all about. Jonathan Gilbert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] where is the moonlight svn
Hi, the question is in the title? I want to help on it but found nothing on svn... is there a special SVN for incubator project? Thanks bye duff ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] where is the moonlight svn
Hello, the question is in the title? I want to help on it but found nothing on svn... is there a special SVN for incubator project? Well, the various pieces are part of different namespaces already covered by Mono. See the web page with details about it, but basically we need to setup the API-corcompare framework to find out what we are missing (am working on it). The modules will be mcs and olive for now (and unmanaged code will likely go elsewhere, like we do today with libgdiplus). Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.2.3.1 SO_REUSEPORT / System.Net.Sockets.SocketOptionName.ReusePort Patch
I understand that, but without the SO_REUSEPORT socket option certain applications will not function properly under FreeBSD. So either the option needs to be added to mono conditionally at compile time, or there needs to be a mechanism to easily set the option. Would setting SO_REUSEPORT when SO_REUSEADDR is set be more acceptable? Robert Jordan wrote: Slava Shirokov wrote: This patch adds the ability to set the SO_REUSEPORT socket option using System.Net.Sockets.SocketOptionName.ReusePort in mono 1.2.3.1 Patch also available here: http://slava.cyberwang.net/files/Code/Mono/mono-1.2.3.1-ReusePort.patch Since there is no SocketOptionName.ReusePort in MS.NET 1.1 or 2.0, this patch cannot be accepted. Robert ___ 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] Silverlight early implementation thoughts.
Miguel wrote:
Silverlight brings another component into the equation:
Hey,
I don't think I usually chime in on these things, but this time I
figured I would.
IMO, the Mono community/project tends to spread itself very thin. Lots
of things get started but not polished up and finished very well. I
don't think that's always a bad thing --- in fact, the renewed
enthusiasm that tends to follow new APIs from MS, for instance, is
really nice to see. And it's certainly not without exception --
MonoDevelop is polished, and impressively so despite the fact that it
continues to undergo significant progress.
But the unpolished things include:
Debugging (MD integration, or *some* GUI debugger)
mod_mono (configuration is very awkward, problems are hard to
diagnose, restarting the Mono process is still strange)
Class library documentation
Doc tools for independent libraries (we need a proper editor GUI)
(Some may know that I've taken small stabs at improving the last three
over the years, and I'm guilty for leaving things in unpolished states.)
Other random things that I think are important:
The new GC
Runtime performance
Was CAS ever finished?
AOT on 2.0 assemblies (at least for non-generic types)
Internal testing of the Web pipelines, by having mono-project.com run
on the Mono stack
And that's just what comes to mind right now. (SWF, ASP.NET 2.0, and
finishing the existing APIs go without saying.) There are a lot of parts
of Mono that I've never even touched that I'm sure have unpolished
aspects too.
Anyway, I'm definitely of the mentality that if you want something done
in an open source project that's not getting done, you should do it
yourself. So I'm not trying to sound like I have expectations that all
of these things should somehow magically just get done.
OTOH, since there are people being paid to work on Mono, it doesn't hurt
to suggest what I think their priorities should involve---namely,
polishing existing parts of the project.
And, besides that, before Mono hackers get too involved with an entirely
new API that may very well flop, I think it would be useful to consider
whether there are existing parts of the project that need polishing that
you'd also enjoy working on.
My two cents.
--
- Josh Tauberer
http://razor.occams.info
Yields falsehood when preceded by its quotation! Yields
falsehood when preceded by its quotation! Achilles to
Tortoise (in Gödel, Escher, Bach by Douglas Hofstadter)
Miguel de Icaza wrote:
Hey folks,
This is a repost from an internal email that really should have been
public.
Apologies for not sharing with the team my thoughts on Silverlight
as the conference was unwrapping. I think folks found out about my
interest on Silverlight from Martin LaMonica's blog entry.
Silverlight 1.1 is obviously very aligned with the work that we are
doing, and if someone is going to implement that it is a natural fit for
our team to do so. For one, the majority of the work are the upgrades
to the 3.5 libraries (System.Core.dll, completing generics, C# 3).
Today our main goal is to allow a smooth migration of developers
from Windows to Linux (ok, it is not smooth at all right now, you kind
of have to be a Unix user to do the transition at all).
Silverlight brings another component into the equation: a lack of
Linux/Silverlight will prevent the Linux desktop from getting some
content. Whether it will be a big or small issue is yet to be debated,
but regardless of this, it seems that Silverlight is a lot of fun to
implement.
WPF is too big, and there is very little gain, at least in the next
3-4 years, because there is no migration strategy for every ISV that has
invested in Winforms, so the only usage scenarios for WPF were new
applications, or people that were willing to throw out their investments
and pretty much start from scratch.
On the other hand, Silverlight is a tiny subset of WPF, relatively
easy to implement (a weekend hack, two at most as it has been pointed
out by some of you) and it will be used to spice up existing web-based
applications as opposed to rewriting an application.
Now, we have a bunch of challenges ahead of us, and it is not clear
when we should start work on a Mono-based Silverlight, I think we should
but we must:
* Ship MonoDevelop 1.0, and continue improving it as we wont be
a kick-ass development platform until we move beyond
Makefiles and debugging with gdb and mdb on the command line.
We keep saying Mono is a better development platform, but it
wont be for the unwashed massed until we get this.
* Ship Windows.Forms and ASP.NET 2.0: there are hundreds of
people trying to move their applications to Mono today, and
we are going to need to complete both of these before we can
Re: [Mono-dev] Silverlight early implementation thoughts.
On 5/5/07, Joshua Tauberer [EMAIL PROTECTED] wrote: But the unpolished things include: Most of these are addressed in the upcoming Google Summer of Code... Debugging (MD integration, or *some* GUI debugger) MonoDevelop Debugger http://code.google.com/soc/mono/appinfo.html?csaid=F894C9ED094FC38 mod_mono (configuration is very awkward, problems are hard to diagnose, restarting the Mono process is still strange) FastCGI ASP.NET Server http://code.google.com/soc/mono/appinfo.html?csaid=7D9BFE2E183364B9 Class library documentation Doc tools for independent libraries (we need a proper editor GUI) WYSIWYG Editor for Monodoc and MonoDevelop http://code.google.com/soc/mono/appinfo.html?csaid=69D5900719093384 -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.2.3.1 SO_REUSEPORT / System.Net.Sockets.SocketOptionName.ReusePort Patch
Slava Shirokov wrote: I understand that, but without the SO_REUSEPORT socket option certain applications will not function properly under FreeBSD. So either the option needs to be added to mono conditionally at compile time, or there needs to be a mechanism to easily set the option. Would setting SO_REUSEPORT when SO_REUSEADDR is set be more acceptable? Well, this introduces a security issue on BSD and it will also break applications that expect bind() to fail. Can you elaborate which operations on what kind of sockets are failing on BSD? Robert Robert Jordan wrote: Slava Shirokov wrote: This patch adds the ability to set the SO_REUSEPORT socket option using System.Net.Sockets.SocketOptionName.ReusePort in mono 1.2.3.1 Patch also available here: http://slava.cyberwang.net/files/Code/Mono/mono-1.2.3.1-ReusePort.patch Since there is no SocketOptionName.ReusePort in MS.NET 1.1 or 2.0, this patch cannot be accepted. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] NHibernate 1.2 problem on mono 1.2.4 preview
Hi, It seems that the new NHibernate major release (1.2 - 3 may 2007) can't be used on mono, a method is missing that throw a NotImplementedException ( http://bugzilla.ximian.com/show_bug.cgi?id=78637 ) in auto-generated proxies. Any chance to have a fix in 1.2.4 release ? Thanks, Pascal ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Debugger
Hi, What is the debugger current status? Pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Silverlight early implementation thoughts.
On Sat, 2007-05-05 at 18:09 -0400, Joshua Tauberer wrote: Miguel wrote: Silverlight brings another component into the equation: IMO, the Mono community/project tends to spread itself very thin. Lots of things get started but not polished up and finished very well. For the most part, agreed -- there's just too much that fits within the current Mono umbrella and not enough resources (paid Novell developers and contributors combined) to cover them all. I'm not entirely sure that this is a bad thing per-se, it just requires that we prioritize things appropriately. snip/ And, besides that, before Mono hackers get too involved with an entirely new API that may very well flop, I think it would be useful to consider whether there are existing parts of the project that need polishing that you'd also enjoy working on. The thing to keep in mind is that the entirely new API is fairly minimal here. Most of it is a trimmed down .NET 2.0 API + Linq -- most of which we already have or need to do anyway. The new API portions are fairly minimal in the grand scheme of things -- we already have the JIT, GC, 90%+ of the needed class libraries (or more). So what this mostly amounts to is a new use of existing code, which can lead to additional polish/completion of existing APIs that need to be done anyway (i.e. add missing .NET 2.0 methods), which can only be a good thing. (There's also the question of how best to create the stripped down v2.1.0.0 assemblies, and one of the suggestions is to use Cecil to write a subset generator, which can result in only more polish to Cecil and similar libraries. It's all good. :-) The implementation of new API and a browser plugin may be a diversion of resources, but it's a diversion that will mostly add polish (and users) to what we already have. From this perspective, how can we NOT do it? :-) - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] FW: Problem with Mono in Fedora 6
Hi, nbsp; The erro messege is not of a big help. Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [EMAIL PROTECTED] More information about this error may be available in the server error log. Apache/2.2.3 (Fedora) Server at www3.mcsoft.com.br nbsp; Thanks, nbsp; Marco Castro De: Marco Castro Data de Envio: Para: mono-devel-list@lists.ximian.com Assunto: Problem with Mono in Fedora 6 Hi, nbsp;nbsp; I was using Mono in Fedora 3 and it was working fine. I Need to upgrade itnbsp;to Fedora 6 and mono doens't works anymore. Can you help me? I dont find any error message in the log records. All I have is a 500 internal error error message. nbsp;nbsp; I have installed Apache 2.2.3 andnbsp;mono version 1.2.3.1 (JIT). Mono was recompiled as mod_mono so far. nbsp;nbsp; I have no clues to help where can I find the error. nbsp;nbsp; mod_mono.conf is like this: nbsp;nbsp;nbsp; LoadModule mono_module /usr/lib/httpd/modules/mod_mono.so nbsp;nbsp;nbsp; AddType application/x-asp-net .aspx nbsp;nbsp;nbsp; AddType application/x-asp-net .asmx nbsp;nbsp;nbsp; AddType application/x-asp-net .ashx nbsp;nbsp;nbsp; AddType application/x-asp-net .asax nbsp;nbsp;nbsp; AddType application/x-asp-net .ascx nbsp;nbsp;nbsp; AddType application/x-asp-net .soap nbsp;nbsp;nbsp; AddType application/x-asp-net .rem nbsp;nbsp;nbsp; AddType application/x-asp-net .axd nbsp;nbsp;nbsp; AddType application/x-asp-net .cs nbsp;nbsp;nbsp; AddType application/x-asp-net .config nbsp;nbsp;nbsp; AddType application/x-asp-net .Config nbsp;nbsp;nbsp; AddType application/x-asp-net .dll nbsp;nbsp;nbsp; DirectoryIndex index.aspx nbsp;nbsp;nbsp; DirectoryIndex Default.aspx nbsp;nbsp;nbsp; DirectoryIndex default.aspx Alias /aspNFD32 '/home/paginas/mcsoft/wwwroot/aspNFD32' MonoApplications '/aspNFD32:/home/paginas/mcsoft/wwwroot/aspNFD32' aspNFD32 nbsp; SetHandler mono nbsp;nbsp; Thanks for any help. nbsp;nbsp; Marco Castro ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Silverlight early implementation thoughts.
Hello Joshua, IMO, the Mono community/project tends to spread itself very thin. Lots of things get started but not polished up and finished very well. I don't think that's always a bad thing --- in fact, the renewed enthusiasm that tends to follow new APIs from MS, for instance, is really nice to see. And it's certainly not without exception -- MonoDevelop is polished, and impressively so despite the fact that it continues to undergo significant progress. I agree with you. There are certain projects that we have abandoned or that we have outright decided not to implement due to this nature (the various WSE attempts for example, some of the EnterpriseServices projects, maintenance of third-party libraries). But the unpolished things include: Debugging (MD integration, or *some* GUI debugger) Yes, the issue here is that the debugger has only recently became complete enough to debug applications, and even then, it is still missing support for certain features (some people report issues with AppDomain debugging). It is now possible to build some integration with it, but it was impossible before we had the debugger working. mod_mono (configuration is very awkward, problems are hard to diagnose, restarting the Mono process is still strange) Mod_mono configuration is the area I hate the most about Mono, for one I can never remember how it works and I *always* have to look up the manual pages myself. I guess that part of the problem here is that we never defined a clear goal in terms of what the end-user experience was. Auto-hosting was a step in that direction, but am not sure that we have explored all the areas here (recently I had some issues, but I forgot to take notes, and I can no longer remember what was it that annoyed me so much about it, but I know things annoyed me). Class library documentation Doc tools for independent libraries (we need a proper editor GUI) Yes, I wish we had one. Maybe one will come out of the Summer of Code, but you never know. In general, I have tried to get people to write documentation when they write their code (inside my team). Some people do not like writing docs, but also there is the fact that although docs are important, we always have someone screaming for an urgent task to be fixed. So urgent tends to trump important. (Some may know that I've taken small stabs at improving the last three over the years, and I'm guilty for leaving things in unpolished states.) And am incredibly thankful for this work. Other random things that I think are important: The new GC It continues to be under development, although Paolo has been pulled into a few projects every once in a while, so this has slowed down progress. For a while we only had Paolo and Massi working on the JIT, a situation that is changing as Zoltan joins the team again, and two new JIT developers start in May and June. Runtime performance This is not for lack of trying. A few months ago we got a major boost from the work that Massi did for almost six months. There are large projects underway, Zoltan's linear-il branch will be the future base for optimizations and Massi was working on a new register allocator for it, but we changed directions during Massi's research. I wish for one that Massi blogged more often, because the tale of what happened ended up merely on a discussion in our internal mailing lists and our internal emails. And as Jon Udell was saying a few days ago, this is not a good way of maximizing keystrokes, this should have been blogged or posted. But the story goes like this: Massi was working on the new register allocator (the major source of pain for the extra spills/reloads in our code generator) and noticed that a lot of passes could be avoided if we just made our JIT work only with SSA-based representations. He consulted with me, the performance loss was not significant, so I told him to keep working on it. Then we discovered that JIT time although not an issue for large systems would be a big issue for embedded devices (things like the Zing) so we reset the work to go with the original plan, loosing the SSA-only setup (the whole story is more interesting, but am trying to keep this short). Anyways, Massi was doing this, when we realized that people were adopting GMCS in droves even if it is not supported, and a problem here was that Arrays were creating thousands of interfaces (because of all the implicit interfaces implemented). In an app like Banshee, 1 meg gets JITed and 1 meg ends up being allocated for vtables! (vtables were basically empty). So Massi has gone to implement a way of compressing the vtables as this has much higher priority than improving the performance. But these are not one-week hacks, these are multi-week changes, and the register allocator is a six month effort for example; The linear-ir branch is probably going to take a year before it can be rolled out. Nothing visible
Re: [Mono-dev] Debugger
Hello, What is the debugger current status? It is working, and we hope that people test it with real code, send us feedback and help us improve it. We have reached the point where we think it is usable, but the only way of knowing if it is, is if people give us feedback. Miguel. Pablo ___ 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
