Re: [Mono-list] Mono: Post 1.0 plans and development update.
Hello, I use mono essencially to make WebApplications, and i can't seen new good features in that area. For example the XSP sucks. We cannot use this kind of server in a production environment and i think this component should evolute for this server work as iqual as IIS. We have been working on an improved version of XSP/mod_mono, but if you are using it and experiencing problems, we need to know about them. If we do not know about them, it is very hard for us to fix the problem. We have a test suite and various programs that we run against it, but it is not enough. Miguel ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono: Post 1.0 plans and development update.
Hello, There are a number of areas in which we are focusing for the Mono 1.2 release: Is a working/bulletproof implementation of AppDomain.Unload on the radar for 1.2? Is it likely to make it back into the 1.0 branch, since it would be a bugfix in a sense? That is an important bug, and we would backport the fix to the 1.0 branch as soon as we have one. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono: Post 1.0 plans and development update.
I have always run into pretty fundamental problems while trying to port my ASP.NET apps over to run on xsp. Much to the credit of gonzalo, these issues have usually been fixed very quickly (and I've supplied a patch or two as well), but I've always run out of time before I could get my app functioning under xsp. Solid ASP.NET support is very important to me within mono, ASP.NET 2.0 support is also going to be important to me soon. Is this work for an improved xsp/mod_mono taking place in the 'xsp' module, or in a separate module? Is there a road map for xsp? Has there been any work, or are there any plans, to support the ASP.NET 2.0 features? How can someone like myself (who unfortunately is very spotty in terms of time he has to contribute to mono) make xsp/mod_mono better? Are there bite-sized improvements I could tackle? -David Waite On Fri, 16 Jul 2004 11:12:58 -0400, Miguel de Icaza [EMAIL PROTECTED] wrote: Hello, I use mono essencially to make WebApplications, and i can't seen new good features in that area. For example the XSP sucks. We cannot use this kind of server in a production environment and i think this component should evolute for this server work as iqual as IIS. We have been working on an improved version of XSP/mod_mono, but if you are using it and experiencing problems, we need to know about them. If we do not know about them, it is very hard for us to fix the problem. We have a test suite and various programs that we run against it, but it is not enough. Miguel ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono: Post 1.0 plans and development update.
I don't know why I am asking about this, but wasn't there a plan for smaller ECMA profiles for things like mobile devices? When I attended a .NET user group meeting a few months ago this seemed to be a major point of interest among the existing .NET users there. Forgive me if I missed an obvious answer somewhere. On Wed, 14 Jul 2004 18:41:11 -0400, Miguel de Icaza [EMAIL PROTECTED] wrote: Hello, Well, this release was fairly intense, thanks to everyone that contributed, the time has come to plan for the new features in Mono. * Releases Mono has been branched on the CVS repository and today we have two development tracks: the mono-1-0 branches and the HEAD branch. The mono-1-0 is only getting bug fixes and no new developments are happening there. The HEAD branch is where all the new features are being developed and where we are landing many of the patches that we did not get into the 1.0 release for various reasons. We will follow the Linux kernel model for release numbering, which means that we will release bug fixes and updates to the Mono 1.0 distribution, and those will be named 1.0.1, 1.0.2 and so on. The development versions of Mono will be released as well and will be named Mono 1.1.0, 1.1.1 and so on. * Updated Mono Roadmap. I am working on an updated version of the Mono roadmap to plan our upcoming releases, at this point we are completing the feature list of the things that my team inside Novell will be working on. Since Mono is developed by a large community outside of Novell the release will likely contain more than what my team is commited to do, purely based on external contributors, but the roadmap will try to be as conservative as possible in our time and feature estimates. I would like to make a release of Mono 1.2 (the next stable release) by February of next year, which means that we have roughly six months of development before we go into pure bug fixing mode. * Focus of the Novell team. There are a number of areas in which we are focusing for the Mono 1.2 release: * C# 2.1 implementation * AMD64 JIT port. * Visual Basic compiler. * Improved IO-Layer and Internationalization framework. * Gtk# improvement and GUI designer. * Mono Debugger. * Windows.Forms support. * JIT performance work. * Integration of patches that were too big to make it into the 1.0 release. * Code Access Security Framework. * Continued bug fixing of major and critical bugs. Those are the areas that people have expressed their most interest. Notice also that the above is still pretty much work aimed at the .NET 1.1 framework. Only a couple of developers are working on new features from the .NET 2.0 platform, but we do not believe that we can complete the .NET 2.0 API in time for the 1.2 release, so it is best to only deliver the bits listed above. As usual, a preview of the .NET 2.0 API will be available, but wont be complete. * .NET 2.0 work The Framework almost doubled in size in some parts of the framework. A handful of the Novell developers (Atsushi, Gonzalo and Lluis) will be working on the .NET 2.0 APIs in parallel, hopefully we can release some of the .NET 2.0 features a few months after the 1.2 release comes out. If you want to help, this is an area where we could use your contributions. Details about the large areas that need work are available on the CVS module called `release', look in the directory called mono_2_0. If enough people want, we can transform that list into something Web-browsable. An early ran of the API difference is available here: http://primates.ximian.com/~jackson/net_2_0/class-status.html We will automate this process and upload to mono-project.com on a constant basis. * Tinderbox setup Duncan has setup a tinderbox setup that keeps a close eye on both the stable and unstable branches of Mono, you can see the state of the build here: http://www.go-mono.com:8008/ * Some recent developments A few interesting developments have happened recently on the HEAD version of Mono: * A new, more robust, more complete, more aggressive Arrays Bounds Check Elimination. * Many x86 code generation peephole optimizations.
Re: [Mono-list] Mono: Post 1.0 plans and development update.
Hello! I don't know why I am asking about this, but wasn't there a plan for smaller ECMA profiles for things like mobile devices? When I attended a .NET user group meeting a few months ago this seemed to be a major point of interest among the existing .NET users there. Forgive me if I missed an obvious answer somewhere. There was a plan, but it never quite matured, it really needs someone with the interest to drive that process. One of the problems with the Compact Framework is that it defines what someone thought would be a good subset, and it typically has lots of things that you do not need, and it lacks things that a lot of people would like to have. What we have been considering is a tool that would take as input a set of classes and methods that are required, and the tool would generate a new DLL with everything required. It would pull those types and any dependencies required to satisfy that dependency, and would operate entirely at the assembly level, without any source code level changes. This, I feel is a better way of creating embedded versions of Mono than having ifdefs everywhere. That being said, for people that need even more, it is possible that certain dependencies would have to be manually removed, but in general I think this is a direction that I want to pursue for embedded versions of Mono. Miguel. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono: Post 1.0 plans and development update.
Just a small request plz. Dont CC the mailing list, put the mailing list address in the TO field so that people's filters work correctly. If you need to CC someone, CC a person not the mailing list. On Friday 16 July 2004 18:46, Miguel de Icaza wrote: Hello! I don't know why I am asking about this, but wasn't there a plan for smaller ECMA profiles for things like mobile devices? When I attended a .NET user group meeting a few months ago this seemed to be a major point of interest among the existing .NET users there. Forgive me if I missed an obvious answer somewhere. There was a plan, but it never quite matured, it really needs someone with the interest to drive that process. One of the problems with the Compact Framework is that it defines what someone thought would be a good subset, and it typically has lots of things that you do not need, and it lacks things that a lot of people would like to have. What we have been considering is a tool that would take as input a set of classes and methods that are required, and the tool would generate a new DLL with everything required. It would pull those types and any dependencies required to satisfy that dependency, and would operate entirely at the assembly level, without any source code level changes. This, I feel is a better way of creating embedded versions of Mono than having ifdefs everywhere. That being said, for people that need even more, it is possible that certain dependencies would have to be manually removed, but in general I think this is a direction that I want to pursue for embedded versions of Mono. Miguel. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono: Post 1.0 plans and development update.
Paulo Aboim Pinto wrote: I use mono essencially to make WebApplications, and i can't seen new good features in that area. Most importanat feature for ASP.NET in my opinion is 2.0's Client Callback Feature. For example the XSP sucks. We cannot use this kind of server in a production environment and i think this component should evolute for this server work as iqual as IIS. I could not get what new good features means here... (I think clarification is needed here). It just confused me, because I won't expect new good features for a server in a production environment (such things usually unstabilizes the product). Maybe you could use apache+mod_mono instead of just xsp. It sounds like demanding the early tomcat being rich as apache (with many rich modules) is. Atsushi Eno OK. You have a choise show up IIS in the net or use apache/mod_mono. I prefer apache/mod_mono. It requires some extra work at present time to avoid some mono bugs, but i can sleep peacefully :))) GLHF --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.719 / Virus Database: 475 - Release Date: 12.07.2004 ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono: Post 1.0 plans and development update.
Hey! What about ADO.NET ? I forgot about ADO.NET, am sorry about that. A couple of developers from Novell are also working on the new System.Data from the 2.x tree as well as maintaining the 1.x tree. Am sure I forgot other bits as well, I apologize in advance. Miguel ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono: Post 1.0 plans and development update.
On Thu, 2004-07-15 at 03:04, Igor Georgiev wrote: Most importanat feature for ASP.NET in my opinion is 2.0's Client Callback Feature. Yes, finally they implemented that useful feature, something I already implemented 4 years ago in my XML/XSLT web framework written in ASP/VB6. For those not knowing what Client Callback means see: http://www.dotnetjunkies.com/Tutorial/E80EC96F-1C32-4855-85AE-9E30EECF13D7.dcik Well we can do it, and as I've done back them we can get it without needing XMLHTTP: we can just use a hidden IFRAME a secondary form and some inter-frame javascripting, not very pretty, but effective and able to run in any modern browser. Im my previous framework, besides on-demand expanding tree-views I've built paged-combo-boxes and on-the-fly lookup-filled controls (the user filled a key value in one input box, and a server-lookup brought dependent values). So we can do a lot better in that area... Any volunteers? Currently I can help only with advice/guidance, because I'm very busy with mbas. Cheers, -- Rafael Monoman Teixeira Mono Hacker since 16 Jul 2001 - http://www.go-mono.org/ Mono Brasil Founding Member - http://monobrasil.redesolbrasil.org/ English Blog: http://monoblog.blogspot.com/ Brazilian Portuguese Blog: http://monoblog.weblogger.terra.com.br/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono: Post 1.0 plans and development update.
Miguel de Icaza wrote: There are a number of areas in which we are focusing for the Mono 1.2 release: Is a working/bulletproof implementation of AppDomain.Unload on the radar for 1.2? Is it likely to make it back into the 1.0 branch, since it would be a bugfix in a sense? Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono: Post 1.0 plans and development update.
Hello I've read all the new feature and i think that is a very promissing work you have ahead. I think that WinForms is important and must be a goal if you can implement it. I use mono essencially to make WebApplications, and i can't seen new good features in that area. For example the XSP sucks. We cannot use this kind of server in a production environment and i think this component should evolute for this server work as iqual as IIS. Hope you can insert this feature in next release of Mono. Continues the good work. (()) Paulo Aboim Pinto Odivelas - Portugal Miguel de Icaza wrote: Hello, Well, this release was fairly intense, thanks to everyone that contributed, the time has come to plan for the new features in Mono. * Releases Mono has been branched on the CVS repository and today we have two development tracks: the mono-1-0 branches and the HEAD branch. The mono-1-0 is only getting bug fixes and no new developments are happening there. The HEAD branch is where all the new features are being developed and where we are landing many of the patches that we did not get into the 1.0 release for various reasons. We will follow the Linux kernel model for release numbering, which means that we will release bug fixes and updates to the Mono 1.0 distribution, and those will be named 1.0.1, 1.0.2 and so on. The development versions of Mono will be released as well and will be named Mono 1.1.0, 1.1.1 and so on. * Updated Mono Roadmap. I am working on an updated version of the Mono roadmap to plan our upcoming releases, at this point we are completing the feature list of the things that my team inside Novell will be working on. Since Mono is developed by a large community outside of Novell the release will likely contain more than what my team is commited to do, purely based on external contributors, but the roadmap will try to be as conservative as possible in our time and feature estimates. I would like to make a release of Mono 1.2 (the next stable release) by February of next year, which means that we have roughly six months of development before we go into pure bug fixing mode. * Focus of the Novell team. There are a number of areas in which we are focusing for the Mono 1.2 release: * C# 2.1 implementation * AMD64 JIT port. * Visual Basic compiler. * Improved IO-Layer and Internationalization framework. * Gtk# improvement and GUI designer. * Mono Debugger. * Windows.Forms support. * JIT performance work. * Integration of patches that were too big to make it into the 1.0 release. * Code Access Security Framework. * Continued bug fixing of major and critical bugs. Those are the areas that people have expressed their most interest. Notice also that the above is still pretty much work aimed at the .NET 1.1 framework. Only a couple of developers are working on new features from the .NET 2.0 platform, but we do not believe that we can complete the .NET 2.0 API in time for the 1.2 release, so it is best to only deliver the bits listed above. As usual, a preview of the .NET 2.0 API will be available, but wont be complete. * .NET 2.0 work The Framework almost doubled in size in some parts of the framework. A handful of the Novell developers (Atsushi, Gonzalo and Lluis) will be working on the .NET 2.0 APIs in parallel, hopefully we can release some of the .NET 2.0 features a few months after the 1.2 release comes out. If you want to help, this is an area where we could use your contributions. Details about the large areas that need work are available on the CVS module called `release', look in the directory called mono_2_0. If enough people want, we can transform that list into something Web-browsable. An early ran of the API difference is available here: http://primates.ximian.com/~jackson/net_2_0/class-status.html We will automate this process and upload to mono-project.com on a constant basis. * Tinderbox setup Duncan has setup a tinderbox setup that keeps a close eye on both the stable and unstable branches of Mono, you can see the state of the build here: http://www.go-mono.com:8008/ * Some recent developments A few interesting developments have happened recently on the HEAD version of Mono: * A new, more robust, more complete, more aggressive
