Re: [Mono-dev] workflow foundation 4
Just a guess here, but I think maybe you took the Microsoft System.Activities.dll assembly out of: C:\Program Files (x86)\Reference Assemblies\ These assemblies have been stripped of all code and are simply empty methods and classes to compile against. You will want to get the full assembly out of the MS GAC. Jon On 11/16/2012 10:11 AM, Chris Camplejohn wrote: Yes I understand that this is the case for some of their assemblies, but I am interested from a technical perspective what is the limitation? I would like to get it running with their assemblies before considering if we begin to rewrite them for Mono. But for example when I try to run a test workflow application under Mono using the Microsoft System.Activities.dll I get the following error. Unhandled Exception: System.InvalidProgramException: Invalid IL code in System.Activities.Activity:.ctor (): method body is empty. at MonoWorkflowConsoleTest.Workflow1..ctor () [0x0] in filename unknown:0 at MonoWorkflowConsoleTest.Program.Main (System.String[] args) [0x0] in filename unknown:0 [ERROR] FATAL UNHANDLED EXCEPTION: System.InvalidProgramException: Invalid IL code in System.Activities.Activity:.ctor (): method body is empty. at MonoWorkflowConsoleTest.Workflow1..ctor () [0x0] in filename unknown:0 at MonoWorkflowConsoleTest.Program.Main (System.String[] args) [0x0] in filename unknown:0 Thanks Chris -- View this message in context: http://mono.1490590.n4.nabble.com/workflow-foundation-4-tp1539102p4657422.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ 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] MoMA
The tool to generate the definition files is in github: https://github.com/mono/moma/tree/master/MoMAExtractor You will need to update AssemblyManager.cs to point to both the .NET and Mono assemblies. You might also want to update to .NET 4.5. After that, you put them in a zip file with a little bit of metadata and they're ready. (See existing definition packs.) I am guessing if you put them somewhere for Xamarin, they can upload them to the definition update web service. Jonathan On 10/21/2012 3:40 PM, Leszek Ciesielski wrote: Hi, MoMA is indeed a very useful tool and it's a pity that it seems no longer to be supported. What would it take to update the masterinfos that it uses for reporting? They're missing for the last couple of release (about two years, I would say?). A lot of people start their migration/multiplatform work with MoMA and currently it under-reports Mono capabilities significantly. I understand that Xamarin no longer has the commercial interest in maintaining this tool, but it's valuable to the community, so perhaps it should transition to being maintained by community members? As it stands, MoMA relies on a webservice that is no longer updated and I'm guessing the report uploads aren't analysed as well? Kind regards, Leszek Ciesielski On Mon, Oct 8, 2012 at 3:29 PM, David Schmitt da...@dasz.at wrote: Hi, could someone please remove or update the wikipage at http://www.mono-project.com/MoMA ? the download there only can check against 2.8 and File MoMA bugs still links to the novell bugzilla. Thanks love, David ___ 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] Has Mono an equivalent to the Microsoft Roslyn API?
The MonoDevelop team contributes to NRefactory 5, which provides pretty much exactly the same functionality as Roslyn for C#. This will power the MonoDevelop C# support in a future version. https://github.com/icsharpcode/NRefactory/ Jonathan On 1/24/2012 9:54 AM, JochenHuck wrote: I need something like the Mircosoft Roslyn API (http://msdn.microsoft.com/en-en/roslyn) to do static source code analysis. Since the Roslyn API is just a developer preview I wanted to know whether Mono offers similar features as the Roslyn API (since Mono has a C# compiler written in C# and the Roslyn API is a C# compiler API I thought this would be possible). I am especially interested in syntax trees, semantic analysis (binding), dataflow and controlflow features (to answer questions like: which variables are read in this basic block, etc.) Thanks, Jochen -- View this message in context: http://mono.1490590.n4.nabble.com/Has-Mono-an-equivalent-to-the-Microsoft-Roslyn-API-tp4324128p4324128.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ 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] substantial performance regression between 2.10 and 2.6 or impl diff?
You could probably install the Mac OSX 2.6.7 Mono pretty quickly to see if it's a difference caused by architectures or by a change between Mono versions. http://www.go-mono.com/mono-downloads/download.html Jonathan On 8/27/2011 2:36 PM, Jonathan Shore wrote: Ok. When you have a chance can you indicate your marks CPU? I expect a reasonably modern CPU to be 2 - 6x fast than my sluggish cpu. Thanks. So for instance my mac X5130 rates at 12.7 CINT 2006 vs 28.6 On Aug 27, 2011, at 2:57 PM, Slide wrote: I just ran on ubuntu 64bit with mono 2.10.1 and got better numbers than your 2.6.7. I had to run somewhere quick but will publish the numbers when I get back. On Aug 27, 2011 11:16 AM, Jonathan Shore jonathan.sh...@gmail.com mailto:jonathan.sh...@gmail.com wrote: My machine is an old 2006 Mac Pro 1,1 2 x Xeon 5130 (64 bit) running OSX lion. Here are the respective versions of mono: Mono on OSX: Mono JIT compiler version 2.10.4 (tarball Mon Aug 8 22:03:39 EDT 2011) Copyright (C) 2002-2011 Novell, Inc, Xamarin, Inc and Contributors. www.mono-project.com http://www.mono-project.com/ TLS: normal SIGSEGV: normal Notification: kqueue Architecture: x86 Disabled: none Misc: debugger softdebug LLVM: yes(2.9svn-mono) GC: Included Boehm (with typed GC) Mono on Ubuntu 11.04 (running in VMWare VM on same machine): Mono JIT compiler version 2.6.7 (Debian 2.6.7-5ubuntu3) Copyright (C) 2002-2010 Novell, Inc and Contributors. www.mono-project.com http://www.mono-project.com/ TLS: __thread GC: Included Boehm (with typed GC and Parallel Mark) SIGSEGV: altstack Notifications: epoll Architecture: amd64 Disabled: none Here is the Mac OSX mono 2.10.4 run: $ mono main.exe Running benchmark struct sum: 589998356.48, time: 9.010549 secs class sum: 589998356.48, time: 30.67357 secs Here is the Ubuntu 11.04 mono 2.6.7 run: $ mono main.exe Running benchmark struct sum: 589998356.48, time: 2.737732 secs class sum: 589998356.48, time: 7.83984 secs Note that the running time for mono 2.6.7 is ~4x faster than mono 2.10.4 on the same box (and the linux run has the disadvantage of running on a VM). The struct test is most likely not exercising the GC and the later is. I suspect given the consistent performance difference is *not* a GC issue, rather a difference in the JIT code generation. Let me know if there is other information I can provide. Thanks. Jonathan On Aug 27, 2011, at 1:52 PM, Slide wrote: On Sat, Aug 27, 2011 at 10:27 AM, Jonathan Shore jonathan.sh...@gmail.com mailto:jonathan.sh...@gmail.com wrote: Hi, I was doing some benchmarks of struct vs class based creation (I have an application that will generate millions of small objects). I was doing the tests in a ubuntu 11.4 VM on my mac pro and found the following: mono 2.6.7 was 4x faster on my linux VM than 2.10.4 running on OSX (same machine) I don't know whether this may be because of one of the following: - performance in 2.10.4 regressed vs 2.6.7 - mono JIT implementation for OSX has a completely different JiT codebase and does not perform - difference in GC (only relevant for second part of the test) Note that I tried this with separate compilations with mcs -optimize+ on both environments as well as running the same exe on both. I can live with slower performance on OSX, but want to make sure that linux and windows versions of mono 2.10.x have the performance of 2.6.7 or better. Can someone clue me in? I've included the simple test code with this posting. Thanks Jonathan Can you publish your benchmark numbers and for what machines you are running on? slide -- slide-o-blog http://slide-o-blog.blogspot.com/ ___ 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] What directories/files needed to distribute a mono runtime from a build?
On 12/28/2010 10:53 AM, CodeSlinger wrote: In Windows the assemblies are under a version dir and in mono the assembly versions are under a common dir by assembly type though maybe there is a good reason for that which I don't know. There are two copies of each class library assembly, one copy for compiling and one copy for running. This is true for both Mono and .Net. Compiling copies: Mono - lib/mono/[2.0 3.5 4.0]/ .Net - \Program Files\Reference Assemblies\Microsoft\Framework\... Running copies: Mono - lib/mono/gac .Net - \Windows\assembly On Mono on Linux, the compiling copies should be a symlink to the running copy so they don't take up twice as much space, like they do on Windows. If your application is not going to be compiling any code [CodeDom], you do not need the compiling copies. Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] What directories/files needed to distribute a mono runtime from a build?
The absolute bare minimum you need to run a Mono app (hello world) is the runtime (mono) and mscorlib.dll. Anything past that depends on what your application uses. Jonathan On 12/27/2010 10:53 PM, CodeSlinger wrote: I've basically asked this before, so sorry for the repost, but my other thread got garbled when I had to delete posts in order to keep from getting continuous warnings about not being approved even though I had registered after posting them. Basically I want just a minimal runtime or even the whole runtime but nothing else from the build. It was essentially suggested to just delete what you don't need which is sort of like telling someone wanting a wooden bear to just get a log and cut away the parts that don't look like a bear (ya I live in the mountains and there are a lot of wooden bear wood carvers here and I'm not one of them). After custom building 2.8.1 on my RHEL45 system, my /usr/mono directory is 1.2G and I would like to zip a fairly minimal runtime for deployment to other boxes. According to the doc on assembly search order, all needed dlls are supposedly in the GAC but that is obviously not the whole story since mscorlib.dll is in the /usr/mono/lib/mono/4.0 directory. And in the GAC there are 2.0 and 4.0 components under the component type rather than under the version so it is harder to distribute just once version such as 4.0. So anyway, I might then think all I needed was (prefix=/usr/mono) - /usr/mono/bin - for the mono program /usr/mono/lib/mono/gac - for all the 4.0 system assemblies except my own and 3rd party /usr/mono/lib/mono/4.0 - for mscorlib.dll and that should be sufficient to run my command line mono app. Is it? I did not delete several /usr/mono directories to test that theory. To run a command line 4.0 app, do I need anything besides the above 3 directories? Also, someone suggested just ship what is referenced by my pgm which makes sense but for example, mscorlib.dll is not referenced in my VS2010 built project (in fact I deleted ALL references in the VS2010 references section) yet mscorlib.dll is in fact needed and is NOT in the GAC but rather found in /usr/mono/lib/mono/4.0. I could experiment, and delete files and directories to see what works and what does not but I think a true need would be served by having some script or whatever package up a runtime either based on your exe or on general requirements, or even just ALL of the runtime would be better than distributing all of the 1.2G of files including source, compilers etc. resulting from the build. All suggestions appreciated. Maybe this is not a problem for some but I have to think there are other developers in the same boat as myself not wanting to cut away all the parts that don't look like a runtime. Thanks, Dave ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] What directories/files needed to distribute a mono runtime from a build?
On 12/27/2010 11:30 PM, CodeSlinger wrote: Would mono/bin, mono/lib/mono/gac and mono/lib/mono/4.0 then be EVERYTHING for a 4.0 runtime? Probably not, to have EVERYTHING for a 4.0 runtime, you would probably need EVERYTHING. For example, there is some stuff in /etc/mono/4.0 that your application may need for cryptography, asp.net support, etc. If you are using the Winforms browser control, you would need xulrunner. If you are using System.Drawing, you would need libgdiplus. etc. I would assume *most* everything that Mono ships is needed for some use case, or else it wouldn't be shipped. Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] What is best environment for building mono-2.8.1 for Windows?
The official Mono release for Windows is built using Cygwin. I'm pretty sure it's an XP machine. Jonathan On 12/20/2010 3:00 PM, greenaj wrote: Hello, I am relatively new to mono. I am trying to build it for Windows to run in under WinPE. The more stripped down the better. I download mono-2.8.1.tar.bz2 and tried to build in Windows 7 under Cygwin. No luck; weird sharing violation errors. I have successfully built the code cross compiling in a SUSE 11.3 virtual environment. The tools seem to be a lot nicer than Cygwin. However, keeping my prejudices aside, I would like to know in general how the Mono Team builds mono for its Windows release. Do they use Cygwin on Windows or cross compile on some flavor of Linux? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Messaging error assemblye reference
On 11/15/2010 9:18 PM, caralbgm wrote: When compile (in MonoDevelop), I obtain this error: error CS0234: The type or namespace name `Messaging' does not exist in the namespace `System'. Are you missing an assembly reference? This may sound obvious, but are you missing an assembly reference? Specifically, have you added a reference to System.Messaging.dll? Either: - MonoDevelop with Project - Add Reference - gmcs with -r:System.Messaging Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mysql connector Mono 2.6.7 - Cannot find assembly
Did you try capitalizing the assembly as it is requested (MySql.Data.dll)? http://stackoverflow.com/questions/3987266/mysql-connector-with-mod-mono-and-mono-2-6-7 Jonathan On 10/21/2010 10:35 AM, Frank Cohen wrote: Hey V, Thanks for your reply. I did as you suggested but I still get the same error message w/out any more information. I've actually placed the DLLs in the same folder as the exe (not mono, Main.exe). So shouldn't it pick them up? Here are a couple more pieces of info: while I was able to get the Windows command line test working, when I tried to run the web-app in Mono's web server, I got the same error about the DLL. On the Cent OS box, I had an earlier version of Mono installed, then installed from source again. I think it's installed correctly as when I run mono --version, it's showing me 2.6.8. Below is the output from the test program: ** (./Main.exe:17396): WARNING **: The following assembly referenced from /san/home/www/testproj/Main.exe could not be loaded: Assembly: MySql.Data(assemblyref_index=1) Version:6.3.5.0 Public Key: c5687fc88969c44d The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/san/home/www/testproj/). ** (./Main.exe:17421): WARNING **: Could not load file or assembly 'MySql.Data, Version=6.3.5.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d' or one of its dependencies. ** (./Main.exe:17421): WARNING **: Missing method .ctor in assembly /san/home/ww/testproj/Main.exe, type MySql.Data.MySqlClient.MySqlConnection Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'MySql.Data, Version=6.3.5.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d' or one of its dependencies. Thanks, Frank On Thu, Oct 21, 2010 at 11:02 AM, Veerapuram Varadhan vvarad...@novell.com mailto:vvarad...@novell.com wrote: Hello Frank, Check whether you have any system version of Mono running, if so take a look at http://www.mono-project.com/Parallel_Mono_Environments Also, you can try running your sample with: MONO_LOG_LEVEL=dll mono ./your-mono-compiled-exe which will give you the location where mono searches for the MySql assembly. HTH, V. Varadhan On Thu, 2010-10-21 at 08:16 -0400, Frank Cohen wrote: I've been having quite a bit of trouble getting an MVC2 web application to find the MySQL connector. I am running CentOS 5. I've installed the DLL into the GAC using the 2.0 version of the tool *mono /usr/local/lib/mono/2.0/gacutil.exe -i v2/mysql.data.dll* *Installed v2/mysql.data.dll into the gac (/usr/local/lib/mono/gac)* I verify that it updated the GAC: *# ls /usr/local/lib/mono/gac/MySql.Data/6.3.5.0__c5687fc88969c44d/mysql.data.dll* I get the following error when I run the application: Failed to find or load the registered .Net Framework Data Provider MySql.Data.MySqlClient'. I created a simple command line application described here: http://www.mono-project.com/MySQL, which works under Mono and .NET on my Windows machine, but does not work on my Linux box. Thanks, Frank ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com mailto: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] how to get MonoDroid download password?
On 9/6/2010 9:59 AM, Barry Song wrote: Hi All, According to http://monodroid.net/Installation, we can download the MonoDroid for Visual Studio 2010 Plugin at http://go-mono.com/monodroid-download. But I wonder how to get a password for the download. Can anyone tell me? According to http://monodroid.net/, you need to sign up for the private beta, and wait to get invited. Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Standard name for mcs
On 6/27/2010 8:20 PM, jmalcolm wrote: I think this is a fair question. I am not sure the original poster deserved so much grief. I have certainly compiled C programs from source that were written more than five or six years ago. It does not seem implausible that I might try to compile the original posters code a decade from now and that I might find that 'gmcs' is indeed not available at that time. Likely, when gmcs goes away, an alias script called 'gmcs' will be left in it's place that points to the current compiler. Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Standard name for mcs
On 6/27/2010 9:25 PM, Russell Wallace wrote: On Mon, Jun 28, 2010 at 2:52 AM, Jonathan Pobstmon...@jpobst.com wrote: Likely, when gmcs goes away, an alias script called 'gmcs' will be left in it's place that points to the current compiler. Yes, please do this -- that would be the preferred solution. It would be nice if the same could also be done with mcs once it's formally removed from the standard Mono distribution as a separate program -- being just a one line script, hopefully this could be put back into the version shipped with Ubuntu? In Mono trunk, where the '1.1 mcs' has been removed, mcs is now a script pointing to gmcs.exe. We cannot guarantee all distros will ship this script, but it is created by default when you make and install Mono from the Mono tree/tarball. Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] sh#
On 4/10/2010 12:50 PM, Jerry Maine - KF5ADY wrote: Do you think we should start our own group to do this (on a separate website) or ask the mono project to host it for us (on svn)? For the most part, the mono project has stopped hosting external projects. We do not have a fancy setup that allows for advanced permissions and such, so any time you want to add a user, you have to email miguel who does it manually, and all users have write access to the whole mono svn. (So we can't restrict everyone else from committing to your project, or visa-versa.) There are many great other places that are dedicated to the type of hosting you need, like Google Code, SourceForge, CodePlex, GitHub, Gitorious, or Launchpad. Best of luck! Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Method marked in MoMA as MonoTodo is already implemented
You are looking at the wrong file. ;)
You want ConfigurationManager.get_ConnectionStrings, not
ConnectionStringSettings.get_ConnectionString.
http://anonsvn.mono-project.com/source/trunk/mcs/class/System.Configuration/System.Configuration/ConfigurationManager.cs
Jonathan
On 4/6/2010 4:43 PM, Alexander M. Batishchev wrote:
Hi.
After scanning my assemblies the latest MoMA said:
Method with [MonoTodo]
ConnectionStringSettingsCollection
ConfigurationManager.get_ConnectionStrings ()
But at
http://anonsvn.mono-project.com/source/trunk/mcs/class/System.Configuration/System.Configuration/ConnectionStringSettings.cs
class ConnectionStringSettings has appropriate property:
public string ConnectionString { get; set; }
How to update MoMA implementation database?
Thanks.
Alex
___
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] Test Suite Failures, Revision 2
[Updated list of test failures since last week] Hey guys! We have accumulated many test suite failures in the past month. If you commit to mono, please take the time to regularly check the buildbots to ensure you are not breaking things. The buildbot results are available here: http://wrench.mono-project.com/builds Our new buildbots build every revision, so it's easy to track down where something regressed. Current Regressions (all on SLE11 32 bit) --- -- test-compiler-2.0 -- test-454.cs http://build.mono-project.com/GetFile.aspx?id=2257661 -- test-corlib-2.0 -- http://build.mono-project.com/GetFile.aspx?id=2257690 MonoTests.System.Reflection.Emit.AssemblyBuilderTest.GetType : #1 regressed in r154231 (Kumpera) MonoTests.System.Reflection.Emit.ModuleBuilderTest.DefineType_Name_Null : #5 regressed in r154486 (Zoltan) MonoTests.System.Reflection.Emit.ModuleBuilderTest.TestGlobalMethods regressed in r154592 (Kumpera) -- test-System_Xml_Linq-3.5 -- castdatetimes Caused by DST time change http://build.mono-project.com/GetFile.aspx?id=2257798 -- test-System_ServiceModel -- 6 sporadic timeouts started in r154243 (Gonzalo) http://build.mono-project.com/GetFile.aspx?id=2257888 -- test-System_ServiceModel_Web -- 1 timeout started in r154243 (Gonzalo) 1 json failure since test suite added: r154188 (Atsushi) http://build.mono-project.com/GetFile.aspx?id=2257906 Thanks for your help in keeping Mono from regressing! Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Yet another problem compiling sources under cygwin
On 4/1/2010 8:23 PM, Wayne Kelly wrote: I'm receiving a make error: undefined reference to _wapi_clear_interruption this reference is from mini-exception.c reported when linking libmono-2.0.la There is a definition function wapi_clear_interruption in mono/io-layer/wthreads.c but this source code is not included if HOST_WIN32 is true. This was fixed earlier today in revision 154651. Grab the latest and you should be good to go. :) Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Test Suite Failures
Hey guys! We have accumulated many test suite failures in the past month. If you commit to mono, please take the time to regularly check the buildbots to ensure you are not breaking things. The buildbot results are available here: http://wrench.mono-project.com/builds Our new buildbots build every revision, so it's easy to track down where something regressed. Current Regressions (all on SLE11 32 bit) --- test-runtime mkbundle error http://build.mono-project.com/WebServices/Download.aspx?workfile_id=2166773 test-mini simd error 154183 - kumpera http://build.mono-project.com/GetFile.aspx?id=2163467 test-aot simd error 154183 - kumpera http://build.mono-project.com/GetFile.aspx?id=2166777 tests-verify Mvc Error 153615 - mhabersack http://build.mono-project.com/GetFile.aspx?id=2166784 test-compiler-2.0 test-454.cs http://build.mono-project.com/WebServices/Download.aspx?workfile_id=2166786 test-System-2.0 LicenseManagerTests 153687 - kumpera http://build.mono-project.com/WebServices/Download.aspx?workfile_id=2083269 test-System_Runtime_Remoting Timeout 153687 - kumpera http://build.mono-project.com/WebServices/Download.aspx?workfile_id=2166905 test-Microsoft_Build_Tasks-2.0 TaskBatchingTest 153687 - kumpera http://build.mono-project.com/GetFile.aspx?id=2166925 test-Mono_C5-2.0 generics sharing error 154072 - zoltan http://build.mono-project.com/GetFile.aspx?id=2166929 test-System_Xml_Linq-3.5 castdatetimes 153558 - atsushi http://build.mono-project.com/WebServices/Download.aspx?workfile_id=2166934 Thanks for your help in keeping Mono from regressing! Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Question on the number of closed vs. open bugs
Hey! Closed bugs on that report is only the bugs closed in the past 7 days. (That helps QA track which bugs have recently been closed so they can verify them.) The number of bugs is actually pretty irrelevant to the usefulness of a piece of software. What matters is whether those bugs are keeping people from using the software. The bugs that really affect people tend to get fixed much faster, and the obscure or unreproducible cases tend to sit in Bugzilla forever, piling up over the past decade of Mono. For reference: Ubuntu has 76,565 open bugs (https://bugs.launchpad.net/ubuntu) Firefox has 17,953 open bugs (http://tinyurl.com/yjzrb3s) I've heard numbers thrown around for Windows having something like over a million open bugs. Jonathan On 3/18/2010 12:13 PM, Robert Braun wrote: Hi, At http://mono-project.com/Bugs Mono's bug tracker is linked. As of today it counts 2572 open and 31 closed bugs (plus a larger number of unclosed new bugs and requests for enhancements). That ratio is extraordinarily high compared with any other bug trackers I've seen. In fact I'm wondering how a software project is able to survive with such a huge number of unfixed bugs. I'd be grateful for any reasonable explanation or background. Thanks. Regards 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] Removing Obsolete Code from Mono 2.8
On 3/1/2010 12:54 AM, Miguel de Icaza wrote: * Drop Microsoft.JScript and `mjs' What are: mcs/jerrors mcs/jtests They look like tests for a javascript implementation(?). Can they be dropped as well? Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Removing Obsolete Code from Mono 2.8
On 3/1/2010 12:54 AM, Miguel de Icaza wrote: In addition to this, I would like to stop distributing some libraries that were either never completed and are not being actively maintained. We could move these libraries to a separate module if people would like to maintain them or keep distributing them. Some other candidates are: - Mono.GetOptions - SharpZipLib We currently ship two copies of this: 0.6 and 0.84. We should probably drop 0.6, and possibly look at upgrading 0.84 to their latest, 0.85.5. Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Removing Obsolete Code from Mono 2.8
On 3/1/2010 5:20 PM, Atsushi Eno wrote: Mono.GetOptions is used in a couple of our tools. I wouldn't mind much you volunteer to replace them with newer ones though (but others still may). Which ones? Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono SVN trunk assert failure in class.c:4021 while building Mono
Yes, this was caused by r149419. The correct people have been notified. Until it is fixed, r149418 should build correctly. Sorry for the inconvenience! Jonathan On 1/12/2010 1:20 PM, Tom Philpot wrote: Trying to build mono/ and mcs/ from SVN r149419 on Mac OS X 10.6 I get an assertion failure in class.c:4021 at which point Mono consumes about 75% of one core and must be kill -9'd Compilation succeeded - 31 warning(s) Assembly ../../class/lib/net_2_0/System.Core.dll signed. Creating ../../build/deps/net_2_0_Mono.Security.dll.makefrag ... Creating ../../build/deps/Mono.Security_test_net_2_0.dll.response ... Creating ../../build/deps/Mono.Security_test_net_2_0.dll.makefrag ... make all-local MCS [net_2_0] Mono.Security.dll ** ERROR:class.c:4021:initialize_object_slots: assertion failed: (finalize_slot 0) Note that r149400 doesn't have this issue. ___ 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] Understanding Resolving MoMA Issue Messages
The issue is that the most recent MoMA definitions are for Mono 2.4. This method was implemented in r128397 (March 2nd, 2009), so it is not in Mono 2.4. It is however in the later 2.4.x releases. I was under the (obviously mistaken) impression that the public API would not be changing in these minor bugfix releases. I will release a new set of MoMA definitions with the upcoming Mono 2.4.3. Thanks for reporting this! Jonathan Miguel de Icaza wrote: Hello, Method missing from Mono - NameValueCollection HttpResponse.get_Headers () This has to be a bug in Moma or somewhere else, because this method is not only present in Mono, it is a fundamental part of ASP.NET, you should not have to change any code that uses that at all. We should not be flagging this method at all. Do you have a test case that we can look at, to double check? ___ 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] SharpDevelop under Linux
Paul wrote: My question is therefore two fold - first can I install SD with just the mono framework somehow and second is it worth the effort (in terms of hacking around) for just the winforms designer? I am pretty sure that SD just uses the Winforms designer that comes in the .Net framework (System.Design). Therefore, even if you can get it to run on Mono, it will not solve your goal, since this isn't really implemented in Mono. Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] 2.6 preview 1
Fixed. Thanks! Jon Rafael Teixeira wrote: Small typing error on the Release Notes Users of mkbundle can now pass runtime options to the generated executable by setting the codetMONO_BUNDLED_OPTIONS/code environment variable. Where is codet it should be code, I think. Rafael Monoman Teixeira --- To be creative means to be in love with life. You can be creative only if you love life enough that you want to enhance its beauty, you want to bring a little more music to it, a little more poetry to it, a little more dance to it. Osho On Wed, Sep 30, 2009 at 11:30 PM, Andrew Jorgensen ajorgen...@novell.com wrote: The first preview build of 2.6 has been published to http://mono.ximian.com/monobuild/preview/download-preview/ The windows installer in this build is known to contain a number of problems, including but not limited to: * Has an older build (2.4.x) of gluezilla * Does not contain mono-tools (monodoc browser, gsharp, gendarme, etc.) or gnome-sharp * Is larger than it was previously despite missing mono-tools, etc. We are working through these problems but felt that it was more important to get the build (and the preview tarballs) out into your hands. SLE_10 and openSUSE_10.3 binary packages have been dropped (mono-tools now requires a more recent gtk than available in SLE_10 and 10.3 will be end-of-life around the time we publish 2.6-final). The DRAFT release notes are here: http://www.mono-project.com/Release_Notes_Mono_2.6 ___ 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-dev] Windows MSVC build broken
The windows MSVC build was broken in r142528. C:\mono-workspace\mono\msvc\mono.sln (default target) (1) - (Libraries\libmono target) - ..\mono\utils\mono-logger.c(144): error C2065: '__func__' : undeclared identifier ..\mono\utils\mono-logger.c(168): error C2065: '__func__' : undeclared identifier Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Gtk-sharp-list] Gtk depends on Winform s ¿?
Stefanos A. wrote: Την Wed, 09 Sep 2009 18:05:42 +0300,ο(η) Christian Hoff christian_h...@gmx.net έγραψε: I would really appreciate some feedback from the community as to whether the new approach works (that is, if the attached application appears with visual styles enabled). Just reply with a screenshot of the running app on XP if you're not sure what I mean :-) . Didn't render with visual styles here (Vista x86 Business w/ SP2). What magic sauce is Application.DoEvents using? I wonder if it is performing any static initialization (static constructors and/or fields). You may need to look at the static constructor for XplatUIWin32.cs. It does some stuff you may need like creating a foster window. Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Windows Eglib Build Broken
Hey guys, The Windows Eglib (MSVC) build is broken. The error is this: C:\mono-workspace\mono\msvc\mono.sln (default target) (1) - (Libraries\monoposixhelper target) - c:\Program Files\Microsoft Visual Studio 9.0\VC\include\stdio.h(358): error C3163: '_vsnprintf': attributes inconsistent with previous declaration This error began in r140515 (gonzalo), but was probably introduced in r140453 (gonzalo). (r140453 - r140512 were broken for a different reason.) If anyone with some better C skills than me could take a look, I'd appreciate it. Thanks! Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] NET_4_0 Configure Flags
Recently we added the .Net 4.0 profile to the Mono build. Unfortunately, at this point, there isn't much there for the majority of users, and it nearly doubles the build time. Do we have a make guru who can resurrect our --with-preview=no configure flag and change it so it turns off the 4.0 profile instead of the 2.0 profile? (Or a new, similar flag if we want to still be able to turn off the 2.0 profile.) I would suggest that until we are doing sizable development on 4.0, this should default to no. For bonus points, it would be nice to have a --with-legacy flag that turns off building the 1.1 profile (except what is needed for bootstrap of course). ;) Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] NET_4_0 Configure Flags
Marek informed me we have these flags: --with-profile2=no --with-profile4=no I have updated the documentation here: http://www.mono-project.com/Unsupported_Advanced_Mono_Compile_Options I would still argue we should default 4.0 to off, but at least I can turn it off and save myself some time. :) Jonathan Jonathan Pobst wrote: Recently we added the .Net 4.0 profile to the Mono build. Unfortunately, at this point, there isn't much there for the majority of users, and it nearly doubles the build time. Do we have a make guru who can resurrect our --with-preview=no configure flag and change it so it turns off the 4.0 profile instead of the 2.0 profile? (Or a new, similar flag if we want to still be able to turn off the 2.0 profile.) I would suggest that until we are doing sizable development on 4.0, this should default to no. For bonus points, it would be nice to have a --with-legacy flag that turns off building the 1.1 profile (except what is needed for bootstrap of course). ;) Jonathan ___ 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] Installers
I am definitely against having a separate installer for these libraries, so I like the way you are thinking. :) Some of these make sense to put with the Gtk# installer, like Mono.Posix. Generally on Windows, you ship your dependencies with your application. I would say something like SharpZipLib should be shipped with MD. I would say the same for Mono.GetOptions, *especially* since it is deprecated. I could see Mono.Addins going either way. It probably is used by enough Gtk# apps to justify it being in the Gtk# installer. Jonathan Mike Kestner wrote: I am currently working to provide some additional installation capabilities to support the porting of MD to windows. This includes shipping libraries like Mono.Posix, Mono.GetOptions, SharpZipLib, and Mono.Addins. We've previously received requests to include Mono.Posix in the Gtk# for .net installer, as projects designed with the stetic designer in MD generally contain a Catalog dependency for string translation. The Gtk# installer already ships Mono.Cairo. The above examples indicate that many gtk-sharp applications will likely contain dependencies drilling down into the mono stack. Tomboy uses mono-addins. MD uses several mono libs. My inclination is to just merge these additional libraries needed by MD into the current installer, as opposed to maintaining a separate installer which applications will need to add to their deployment instructions. The current Gtk# for .Net installer weighs in at around 8MB. These additional libraries currently take up just under 1MB in a standalone installer, so the addition of them to the current installer is roughly a 12% increase in download size. I think the user convenience of being able to download all the mono stack goodness in one installer outweighs any advantage to be obtained by carving out subsets of the stack into independent installers. It's conceivable we could add additional libraries from the stack in the future if the demand is high. Thus, my proposal is that we move to a single Mono Libraries for .Net installer which contains these mono stack libraries, including Gtk#. I believe I would probably name the installer mono-libraries.msi and version it with the major/minor version number of the mono release, and an installer version to support updating gtk-sharp and mono-addins and other libraries we might add which don't conform to the mono release schedule. We can probably head off any potential issues related to the disappearance of the Gtk# for .net installer by providing some more detailed information about the contents of the installer on the Downloads page, but there may be some inertia out there around the existing installer name on some application download sites, ie Download the latest version of the Gtk# for .Net installer from the mono project downloads page. Feedback appreciated. In particular I'd like to hear from those of you using the current Gtk# for .net installer or those considering win32 ports in the future. Which would you prefer, one installer or two? If one, should it remain the Gtk# for .net installer for historical purposes, even containing the infusion of mono tastiness, or do we rename it to Mono Libraries for .Net? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] as mentor for GSoC
Hey! Thank you for your interest, but it's a bit late to be a mentor. All student applications have been finalized, and the ones that we are considering accepting already have people willing to mentor them. Thanks! Jonathan Sharique uddin Ahmed Farooqui wrote: Hi, I have applied for mentor in GSoC for mono last week. I'm a regular reader of mono and monodevelop mailing list. I'm trying to get more INvolve in mono. I believe my comments will be helpful for stundets. Am I late to apply? I'm involved with various open source related work. My favorite FOSS projects are mono, monodevelop, drupal, Kde, fedora. I'm also mentor for Drupal this year. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] New Mono API status pages.
It looks like adding the XHTML transitional doctype to this would help, at least in IE8. !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; Jonathan Eyal Alaluf wrote: Hi, Miguel. I like the visibility this page provides into how close Mono is to the target .Net platform in the various configurations. I am missing two things - I'd like to know how many symbols are in the .Net assembly (to put things in the right perspective), and for some reason in my browser (IE 7, white foreground, black background) I see only the numbers and only the tooltip says what they mean. It looks like this: mscorlib.dll 47 20 9 494 419 I'd think that arranging it in a table or giving titles will make this much more readable and easy to use. Thanks, Eyal. -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Miguel de Icaza Sent: Friday, April 10, 2009 1:48 AM To: mono-devel-list Subject: [Mono-dev] New Mono API status pages. Hello folks, We have updated the Mono status pages to be both faster and provide now two levels of detail: http://www.go-mono.com/status The default view mode will remove many of the missing attributes that do not apply to Mono (for example, DebuggerVisibility attributes or bits that are not supported in Mono). The new status pages should be more useful for developers contributing code to Mono. ___ 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] ContextMenuStrip Work incorrectly
Hey!
Can you please file this in our bugzilla so we can track it?
http://www.mono-project.com/Bugs
Thanks!
Jonathan
jingnan si wrote:
Hi,
When the context menu contains ToolStripDropDownItem and a normal
ToolStripItem, the normal ToolStripItem will not function after the
ToolStripDropDown show and hide, I have attached the simple test
project. Just right click on the form and bring up the context menu.
I am using the lastest code from svn.
After some research, I create a simple fix to make the ToolStripItem
Work, but I don't think the fix solved the bug, it just solved my
program, please find the diff below.
Best Regards,
Jingnan Si
Index: class/Managed.Windows.Forms/System.Windows.Forms/ToolStrip.cs
===
--- class/Managed.Windows.Forms/System.Windows.Forms/ToolStrip.cs
（Version 131066）
+++ class/Managed.Windows.Forms/System.Windows.Forms/ToolStrip.cs
（Work copy）
@@ -1521,6 +1521,12 @@
foreach (ToolStripItem tsi2 in this.Items)
if (tsi != tsi2)
tsi2.Dismiss (ToolStripDropDownCloseReason.Keyboard);
+
+ if (Application.KeyboardCapture != this) {
+ Application.KeyboardCapture = this;
+ }
+
+ KeyboardActive = true;
}
internal virtual bool OnMenuKey ()
___
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] 2.4RC3 build problems (and code problems with the build)
You can compare the warnings to a Linux build to see which are something unique to ppc: http://mono.ximian.com/monobuild/builds/HEAD/sles-10-x86_64/mono/129882/logs/build.log Jay reports the same warnings on Linux as well. Jonathan Paul wrote: Hi, I'm a tad worried about the build problems on mono. Looking at the throwback and comments coming from the compiler, I'm seeing lots of these sorts of problems which indicates bison problems and quite a lot of warnings while compiling the likes of boehm-gc.c (gc_priv.h line 1931 - warning function declaration isn't a prototype - lots of these) and also a bit later on ../doltcompile gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include-DGC_LINUX_THREADS -D_GNU_SOURCE -D_REENTRANT -DUSE_MMAP -DUSE_MUNMAP -D_FILE_OFFSET_BITS=64 -D__mono_ppc__ -DUSE_COMPILER_TLS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -fno-strict-aliasing -fno-strict-aliasing -Wdeclaration-after-statement -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual -Wcast-align -Wwrite-strings -MT jni.lo -MD -MP -MF .deps/jni.Tpo -c -o jni.lo jni.c jni.c:490: warning: function declaration isn't a prototype jni.c:494: warning: no previous prototype for 'ikvm_MarshalDelegate' jni.c:501: warning: no previous prototype for 'ikvm_CallOnLoad' mv -f .deps/jni.Tpo .deps/jni.Plo a load more of the same sort of warnings in macros.c, serial.c, zlib_macros.c and minizip/zip.c and finally before System.Xml.dll throws a big style wobbler, make[8]: Entering directory `/builddir/build/BUILD/mono-2.4/mcs/class/System.XML' ./../../jay/jay -ct ./../../jay/skeleton.cs System.Xml.XPath/Parser.jay System.Xml.XPath/Parser.cs ./../../jay/jay: 21 rules never reduced ./../../jay/jay: 1 shift/reduce conflict, 42 reduce/reduce conflicts. sed s/\%start Expr/\%start Pattern/ System.Xml.XPath/Parser.jay Mono.Xml.Xsl/PatternParser.jay echo #define XSLT_PATTERN Mono.Xml.Xsl/PatternParser.cs ./../../jay/jay -ct Mono.Xml.Xsl/PatternParser.jay ./../../jay/skeleton.cs Mono.Xml.Xsl/PatternParser.cs ./../../jay/jay: 3 rules never reduced ./../../jay/jay: 1 shift/reduce conflict, 46 reduce/reduce conflicts. These conflicts are the most worrying and is more than likely the cause for the ppc build to fail. I'm not sure if this is a bison style problem but it is worrying that the likes of not checking a return value for fwrite when building mcs to start with is still being overlooked. I would suggest that before 2.4 hits the roads properly, these issues are carefully looked at (that is unless I'm needlessly worrying, but given that the likes of the gcc people stop when these problems occur suggests otherwise). TTFN Paul ___ 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] Announcing the release of Mono 2.2... use http instead of ftp for mono windows installer
Just change the ftp:// to http:// and it should work: http://ftp.novell.com/pub/mono/archive/2.2/windows-installer/5/mono-2.2-gtksharp-2.12.7-win32-5.exe Jonathan Daniel Morgan wrote: Can you please make the download of Mono for Windows setup exe via http instead of ftp please? FTP is restricted where I work. ftp://ftp.novell.com/pub/mono/archive/2.2/windows-installer/5/mono-2.2-gtksharp-2.12.7-win32-5.exe --- On Tue, 1/13/09, Thomas Wiest twi...@novell.com wrote: From: Thomas Wiest twi...@novell.com Subject: [Mono-dev] Announcing the release of Mono 2.2... To: mono-devel mono-devel-list@lists.ximian.com Date: Tuesday, January 13, 2009, 5:43 PM Today we're announcing the immediate release of Mono 2.2. The release notes are here: http://www.mono-project.com/Release_Notes_Mono_2.2 and downloads are available here: http://www.mono-project.com/Downloads Thanks to all those who contributed to this release! :) Thomas ___ 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] Ideas for Mono on Windows
It's not ideal, but you can grab daily precompiled assemblies from here: http://mono.ximian.com/daily/ , and place them in your Mono's GAC: C:\Program Files\Mono-2.2\lib\mono\gac. (Or use Mono's gacutil to register them.) Jonathan SuperCiccio wrote: Hello, I'm writing a .NET application that uses Spring.NET and NHibernate, my development tool is VS 2008 standard (I've also tried MonoDevelop, but it is a bit far from VS for now). My final goal is to create an application that runs without (major) changes on Win/.NET and Linux/Mono, I strongly believe in this fantastic project (Mono) and in free OSes. In my intentions the (cyclic) dev process will be: 1. develop on Win/VS 2. quick test on Win/.NET and Win/Mono for architecture validation 3. unit test on Win/.NET and Linux/Mono Unfortunately, I'me blocked on stage 2. because of a bug in Mono that prevents Spring XmlApplicationContext from initializing correctly by assembly embedded resources. This bug has been resolved a few days ago (http://lists.ximian.com/pipermail/mono-bugs/2009-January/084625.html). I could grab a snapshot of source code and build it by myself, but I haven't time for setting up the needed environment and build Mono, I have to go on quickly on my project. Sadly, I have to wait for the next Windows/Linux build to go ahead on step 2. If I had a simple way to build Mono on Windows, the (in)famous F5, I could go on peacefully. Despite this hassle, I think Mono is a great work and I hope It will play an important role in my future. Thanks to all! ___ 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] Fwd: Ideas for Mono on Windows
3) the build process hang when building mono/docs, so I looked in the Makefile of that directory and did a touch on the files it tried to create (some *.tree and *.zip files). I figured since it's only documentation it doesn't matter if I have those files or not. We probably need a --disable-docs compile flag. Unless I am mistaken, there is no reason for 99% of people to build the documentation on every compile. Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Complex script / international support in Winforms/libgdiplus
I don't have all the formatting options supported yet, but then again, it doesn't look like the current cairo text module does either. Right. Only the most common formatting options are supported. A few of them have some limitations as well. Another thing we had looked at was implementing Pango in 2.0's System.Windows.Forms.TextRenderer instead of going through System.Drawing. (We have an internal version for 1.1, so we don't need separate code paths.) It supports a different set of formatting options that may be easier to replicate. Also, implementing it here would not have the potential to break as much existing code, as not as many things use it. Once it is implemented, controls would need to be updated to use this instead of System.Drawing. Updating every control will not be fun, but as you already noticed, every control assumes LTR, so they would all have to be changed to support RTL anyways. I'm not saying one approach is better than the other, just another option you may wish to consider. :) Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] XIM problem with Winforms (svn)
You can see if it is a XIM problem by disabling XIM and trying it: MONO_WINFORMS_XIM_STYLE=disabled Jonathan Paul wrote: Hi, I have a number of winforms applications which are failing to start correctly. They work fine until about 123650 under svn. Under 123775, I had problems with FUTEX_WAIT (and it never completed). Under 123860, when I run using mono -v filename.exe, I get at the end (sorry for any mistakes, I'm on a different machine to the one the code is on) Method System.Windows.Forms.X11Keyboard:SetupXIM() emitted at 0x5e7560 to 0x5e765e (code length 254) [colourmixer.exe] Method (wrapper managed-to-native) System.Windows.Forms.X11Keyboard:XSupportLocale () emitted 0x5e7688 to 0x5e76cc (code length 68) [colourmixer.exe] Method (wrapper managed-to-native) System.Windows.Forms.X11Keyboard:XSetLocaleModifiers (string) emitted at 0x5e76d0 to 0x5e773b (code length 107) [colourmixer.exe] Method (wrapper to native) System.Windows.Forms.X11Keyboard:XOpenIM (intptr, intptr, intptr, intptr) emitted at 0x5e7740 to 0x5e7793 (code length 83) [colourmixer.exe] strace suggests something is either in an endless loop (I get a (time(NULL) = 1232452591, 4 semops, waitpid(3977, 0x3f8294, WNOHANG)=0, nanosleep((10, 0), null) = 0) continually) Is there a simple fix for this or something I can look at to see if it is mono at fault or my X server? Using Fedora rawhide, x86 TTFN Paul ___ 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] XIM problem with Winforms (svn)
We have bug #436000. If this is different, please create a new bug for it. Thanks! Jonathan Paul wrote: Hi, You can see if it is a XIM problem by disabling XIM and trying it: MONO_WINFORMS_XIM_STYLE=disabled D'oh! It is a XIM problem. It's still there in 123918 as well. Do I need to put it into the Novell BZ? TTFN Paul ___ 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] [PATCH] System.Windows.Forms.ListViewItem.ListViewSubItem nre fix.
I wrote a test for this, and committed both in r121709. Thanks! Jonathan Bill Holmes wrote: Hi, The attached patch fixes the attached Program.cs. 2008-12-17 Bill Holmes billholme...@gmail.com * ListViewItem.cs (ListViewSubItem.ctor): Initalizing the SubItemStyle member field. Contributed under MIT/X11 license. -bill ___ 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] Eglib_test patch
Attached patch returns the number of failed tests for the program exit code instead of always returning 0. I have a local automated build system building winmono/eglib and use this to determine if the tests failed or not. Ok to commit? Jonathan Index: eglib/test/driver.c === --- eglib/test/driver.c (revision 121616) +++ eglib/test/driver.c (working copy) @@ -238,7 +238,7 @@ string_array_free(tests_to_run); } - return 0; + return global_tests - global_passed; } ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
Hey Jonathan, My interest is mainly the first approach, but building class libraries is an important part of either approach, so thank you for your effort on this. :) I would say especially for your use case, we probably don't need to worry about the 1.1 profile currently. All contributing is probably going to happen in the 2.0+ profile, given how complete and obsolete 1.1 is. The only concern then is libraries that we only ship runtime 1.1 versions of. Mono.Cecil.dll had been mentioned as one of these. We probably need to come up with the list of assemblies that this includes. Most, if not all, would probably be fine if they were compiled against 2.0 for users' local testing. Obviously, there are other factors in play such as correctness and cross-platformness, but I don't see any reason why users' patches wouldn't be accepted if they were written on Windows. jpobst Jonathan Chambers wrote: Hello, I broke down the 'Mono on Windows' topic into two distinct approaches. I have mainly been working on the second approach as it seemed to be easier and provide more value. The first approach is to provide a way to build mono on windows without cygwin installed. This approach provides uses no MS tools and provides no VS integration for the class libraries. The runtime would still be built with MSVC at this point in the plan. It's simply a way for Windows developers to quickly build mono on windows. It should be much faster than the current cygwin based build and require let setup. The second approach (the one I have been working on) was to provide a 'prepare' tool to generate csproj files for all the class libs. I also generate a solution containing all the projects. The user can then build all the mono class libraries (and unit tests) with one click (it's also per profile 1.1, 2.0, 3.5). So as for an update to the second approach. I have a rudimentary Makefile parser and am using it to generate csproj files for the class libraries. I have run into a few problems/issues: 1. The conscensus on #monodev was that the build could use the MS compiler, but that we should reference mono class libraries as references. So, I build corlib first and then try and build the System.dll referencing our corlib rather than the MS one via -nostdlib compiler option (for the 1.1 profile). Visual Studio 2008 allows users to specify what framework version to target for a specific project, but 2.0 is the minimum version (2.0, 3.0, and 3.5 are the options). The csc compiler errors out when building System.dll as it is looking for 2.0 specific items in corlib. The specific error is: error CS0656: Missing compiler required member 'System.Threading.Thread.get_ManagedThreadId' I hacked around this by making that field public when build inside of Visual Studio. However, that is a hack and some in #monodev seemed to indicate we'd hit more issues going down this path. So, in short I think we may be stuck trying to build 1.1 profile libraries (referencing our 1.1 corlib) using the csc compiler. I have a couple questions that hopefully I can get some responses on. 1. What's the impact of building the 1.1 class libraries against the 2.0 corlib? 2. Should this approach (VS integration) be able to build a fully working mono image? 3. If so, are we confident enough that contributors could use this build mechanism to make changes/patches? Or would this be viewed as a second class, and we would expect them to build on Linux or with cygwin before actually commiting changes? 4. If we don't expect this approach to build a fully working mono image, what exactly is the goal/use case? Is it just so Windows hackers can quickly build a single class library in VS? They can debug a class library in VS? I'm still hoping to make things better on Windows for mono, but am not sure which direction to go now. Any (potential) mono hackers on Windows please let your opinions be known. Thanks, Jonathan On Fri, Nov 14, 2008 at 4:42 PM, Miguel de Icaza [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hello, The upside of the mechanism I am using is that all of that would still work the same, because I am still using the .sources files instead of having a .csproj. The downside is we still wouldn't have .csproj's, so it doesn't make working in VS any easier, it just makes it possible to build Mono for Windows in under two hours. Thanks for this information. Is there a reason why we could not generate the .csproj files from the .sources and the Makefile settings for the entire tree in one prepare step? We need to have a good Visual Studio experience from the get-go and not only a faster command line buidl. Miguel ___ Mono-devel-list mailing list
Re: [Mono-dev] Fwd: Patch for DataGridView crash after Columsn.Clear
jingnan si wrote: Hi!, The r119060 code fix my previous problem, but it introduce another crash, my application is too complex, so I put a simple test code in the attachment to show how the crash occurs . I just take a simple look at the crash, it seems the DataGridView.OnColumnRemovedInternal has a bug. The test code is a simple form with DataGridView and a Button, click on the button will crash the application. Regards, Jingnan Trust me, I much prefer a simple test case than having to dig through a complex application. :) Should be fixed in r119164. Thanks! Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Fwd: Patch for DataGridView crash after Columsn.Clear
Hi! When I started writing some tests to verify your changes, I realized that RowTemplate should never contain any Cells. I made changes to make us behave more like .Net. I don't know what your original issue is, so I do not know if this fixes it, but the changes I made are in r119060. If you can still reproduce a crash, please let us know. Thanks! Jonathan jingnan si wrote: -- Forwarded message -- From: *jingnan si* jingnan.si http://jingnan.si@gmail.com http://gmail.com Date: 2008/11/17 Subject: Re: [Mono-dev] Patch for DataGridView crash after Columsn.Clear To: Andreas Färber [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Hi, I checked with latest version from svn, the bug is partially fixed, but still crash the application, I re-make the diff file and attached based on the svn latest code (At revision 118988), please check. Regards, Jingnan 2008/11/16 Andreas Färber [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Hi, Am 13.11.2008 um 02:35 schrieb jingnan si: diff -r mono-2.0/mcs/class/Managed.Windows.Forms/System.Windows.Forms/DataGridViewColumnCollection.cs original/mono-2.0/mcs/class/Managed.Windows.Forms/System.Windows.Forms/DataGridViewColumnCollection.cs 105,108c105 //list.Clear(); while(Count 0) RemoveAt(0); --- base.List.Clear (); [...] Please use unified diffs (`diff -u` or `svn diff`) for readability. Did you check it's not already fixed in SVN trunk? Regards, Andreas ___ 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] TableLayout problem in winforms between Win32 (.NET) and mono
Please file a bug. Thanks! Jon Paul wrote: Hi, I've built an application which runs happily under Win32 and mono. The design work was done under VS C# 2008, was compiled on there and tested on both my Linux (fedora) boxes and an XP box. On XP, everything works fine. Under Linux, the text boxes are not correctly sized. The setup code from the Win designer for the table is this this.table.ColumnCount = 6; this.table.ColumnStyles.Add(new System.Windows.Forms.ColumnStyle(System.Windows.Forms.SizeType.Absolute, 60F)); this.table.ColumnStyles.Add(new System.Windows.Forms.ColumnStyle(System.Windows.Forms.SizeType.Percent, 25F)); this.table.ColumnStyles.Add(new System.Windows.Forms.ColumnStyle(System.Windows.Forms.SizeType.Percent, 25F)); this.table.ColumnStyles.Add(new System.Windows.Forms.ColumnStyle(System.Windows.Forms.SizeType.Percent, 25F)); this.table.ColumnStyles.Add(new System.Windows.Forms.ColumnStyle(System.Windows.Forms.SizeType.Percent, 25F)); this.table.ColumnStyles.Add(new System.Windows.Forms.ColumnStyle(System.Windows.Forms.SizeType.Absolute, 40F)); this.table.Controls.Add(this.checkBox4, 5, 4); this.table.Controls.Add(this.checkBox3, 5, 3); this.table.Controls.Add(this.checkBox2, 5, 2); this.table.Controls.Add(this.diff4, 4, 4); this.table.Controls.Add(this.ass4, 3, 4); this.table.Controls.Add(this.teach4, 2, 4); this.table.Controls.Add(this.active4, 1, 4); this.table.Controls.Add(this.diff3, 4, 3); this.table.Controls.Add(this.ass3, 3, 3); this.table.Controls.Add(this.teach3, 2, 3); this.table.Controls.Add(this.active3, 1, 3); this.table.Controls.Add(this.diff2, 4, 2); this.table.Controls.Add(this.ass2, 3, 2); this.table.Controls.Add(this.teach2, 2, 2); this.table.Controls.Add(this.active2, 1, 2); this.table.Controls.Add(this.diff1, 4, 1); this.table.Controls.Add(this.ass1, 3, 1); this.table.Controls.Add(this.teach1, 2, 1); this.table.Controls.Add(this.label6, 5, 0); this.table.Controls.Add(this.label5, 4, 0); this.table.Controls.Add(this.label4, 3, 0); this.table.Controls.Add(this.label3, 2, 0); this.table.Controls.Add(this.label2, 1, 0); this.table.Controls.Add(this.label1, 0, 0); this.table.Controls.Add(this.numericUpDown1, 0, 1); this.table.Controls.Add(this.numericUpDown2, 0, 2); this.table.Controls.Add(this.numericUpDown3, 0, 3); this.table.Controls.Add(this.numericUpDown4, 0, 4); this.table.Controls.Add(this.active1, 1, 1); this.table.Controls.Add(this.checkBox1, 5, 1); this.table.Location = new System.Drawing.Point(6, 6); this.table.Name = table; this.table.RowCount = 5; this.table.RowStyles.Add(new System.Windows.Forms.RowStyle(System.Windows.Forms.SizeType.Absolute, 20F)); this.table.RowStyles.Add(new System.Windows.Forms.RowStyle(System.Windows.Forms.SizeType.Percent, 25F)); this.table.RowStyles.Add(new System.Windows.Forms.RowStyle(System.Windows.Forms.SizeType.Percent, 25F)); this.table.RowStyles.Add(new System.Windows.Forms.RowStyle(System.Windows.Forms.SizeType.Percent, 25F)); this.table.RowStyles.Add(new System.Windows.Forms.RowStyle(System.Windows.Forms.SizeType.Percent, 25F)); this.table.Size = new System.Drawing.Size(605, 202); this.table.TabIndex = 1; So, as you can see, the table width is 605, two columns make 100 leaving 505, there is a gap between each cell so the largest textbox there can be is 495 in length). The window itself has a radio button which that does the following 1. Makes all except active1-4 visible=false 2. Sets the column span to 4 3. Makes the active1-4 textboxes 495,39 The other radio button does the reverse. The problem is that under Linux there are gaps where they shouldn't be. I've uploaded two screenshots showing what is happening http://www.all-the-johnsons.co.uk/mono-bugs/ofstead.png http://www.all-the-johnsons.co.uk/mono-bugs/standardview.png Is this a known bug or do I need to put it into BZ? TTFN Paul ___ 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] Ideas for Mono on Windows
Atsushi Eno wrote: Here is what I do for adding new source files into svn: - Update *.dll.sources file: ls ../../build/common/*.cs */*.cs | sort System.Foo.Bar.dll.sources make - Collect which files should be mentioned in ChangeLog: svn diff FooBar.dll.sources - copy the rectangle(s) on the console output - Add new files to svn (and svn propdel svn:executable): copypaste those lines in svn add command line. Can these tasks ever easier by switching to your beautiful xml csproj? In MWF land did we create csproj-sources converter? The upside of the mechanism I am using is that all of that would still work the same, because I am still using the .sources files instead of having a .csproj. The downside is we still wouldn't have .csproj's, so it doesn't make working in VS any easier, it just makes it possible to build Mono for Windows in under two hours. Classlib hackers who uses Visual Studio: how do you do those tasks? I manually add new classes to the project in VS. Before I commit, I manually add those classes to the .sources file. I then write my ChangeLog by hand. I then commit using TortoiseSVN, where I just click the files I want to commit, and TortoiseSVN handles doing adds or commits or whatever. In MWF, there is script that builds the .csproj from the .sources file, however it is written in bash, so it isn't usable on Windows without cygwin/bash. Therefore, I just manually maintain my own .csproj. This works for MWF because it is very rare at this point to add any new classes. For other projects, that may not be true. Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
Daniel Morgan wrote: Where is this sources-csproj converter and how do you setup and use it? It is part of the normal mcs checkout. Go to mcs/class/Managed.Windows.Forms, and run build-csproj2k5. Note that it is all hardcoded to build the MWF csproj. It is not a general .sources - .csproj converter. Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
Avery Pennarun wrote: Have you thought about using a gcc-to-cygwin cross compiler running on Linux? I do that with some of my projects, and it's a whole lot faster. I'd never want to go back to building on pure cygwin. We do have cross-compiling: http://www.mono-project.com/Compiling_Mono#Cross-compiling_on_Linux_using_MinGW But if we have things setup to run without cygwin/make on Windows, we can probably do a full compile in the same amount of time on Windows without having to have a second machine or VM to do it. Chambers is quoting 30-120 seconds for the unmanaged part. Based on my work, I would guess about 4-5 minutes for the managed part, significantly less if parallelized. The linux buildbots are currently taking about 25-30 minutes to build. I don't know why that is, they used to take around 7-8 minutes to build. Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
Hey Jonathan, I'm glad to hear that you have the runtime building nicely on Windows. In my spare time, I have been playing with making an MSBuild script for the managed pieces, and was hoping you might have something similar for the unmanaged part. (Which I know nothing about.) The route I took (and this is my first time playing with MSBuild) was to write an McsTask that simply calls (g)mcs with the same command line as the make system. In this way, I simply use the existing .sources files. This may be an easier scenario to achieve than switching over to .csproj files, as it allows people to continue doing things the way they always have. It would be nice to have all platforms build with xbuild, but if that's not possible, at least the burden of maintaining two build systems this way is a lot less than if we tried to maintain changes to .csproj files. Jonathan Jonathan Chambers wrote: Hello All, Mono on Windows has never been easy. However, lately things to have continually gotten worse (or I and others have just gotten more annoyed). Setting up an environment takes a lot of effort for a normal windows developer. Cygwin and the whole Makefile based process is very foreign for Windows developers. Not to mention the busted make in cygwin and cygwin issues on Vista (amd64). Most people have had enough interest in building mono on windows that they took the time to work things out (usually at least a day). But that's just the first time; try setting everything up again on a different machine or updating your cygwin and things start over. I see the basic issues as: 1) Cygwin development environment is less than ideal. It's foreign to most Windows developers and is a barrier to entry for most people. 2) Debugging is mostly impossible. gdb seems to provide little help on Windows (echoed by others on #monodev) 3) Compilation takes forever. I am working on a Dual Quad Core machine (8 cores) at 3.6 Ghz. The mono build process still takes hours on my machine. This may be aggravated by virus scanners or other similar software, but the fact remains that all Windows users run virus scanners. As to not just be a complainer, I am offering some suggestions/ideas and hoping for others to do the same (or at least critique mine ;-)). Before I offer any suggestions, I think we need to balance between two things. One is making life easy for the mono build/package team to produce a Windows product. It's not real easy now, but we shouldn't make it any harder. The second thing is making life easy for those who wish to work/contribute to mono on Windows. This second item is tough at this point. 1) We should consider using MSVC as the default compiler for C code on Windows. I can compile the entire Visual Studio solution for the runtime in minutes. It takes 20-30 seconds if I do a parallel build. We can also use the Visual Studio debugger on Windows, which IMO is betten than gdb on Windows. 2) Two propositions for the class libraries have been mentioned previously. One is a lightweight, 'managed make' system that could be run easily on windows in place of all the build infrastructure provided by cgywin. This obviously allows us to keep using Makefiles on other platforms and keep a unified build process, but requires someone write the tool (and maintain it). Another option is to moved to MSBuild/xbuild for the class libraries. This would change the build process on all platforms, and require some fixing of our current xbuild tool. MSYS/MinGW has also been mentioned, but I don't consider that much better than Cygwin. I attempted to get it working one time, but gave up after a few days of hacking. Simply opening a csproj file for a class library, hacking on it, testing under .Net and mono, and then contributing the changes seems a like a good goal to aim for in regards to contributors. The build/packaging guys can respond with what they are looking for on Windows. Any thoughts/responses on making mono better on Windows is appreciated. Thanks, Jonathan ___ 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] Mono 2.0 download
The biggest reason is that Debian/Ubuntu ships Mono with their system, and chops it up differently than Suse does. This means there is a good chance that our packages would cause problems on your machine when we overwrite those packages with the new ones. IE: things like Banshee, F-Spot, and Tomboy might no longer work. Therefore, we believe it is better to let Debian/Ubuntu make packages that are compatible with their systems. Hopefully, 2.0 packages for Debian/Ubuntu will soon start appearing in the places listed on http://www.mono-project.com/Other_Downloads. Jonathan Casper Bang wrote: I know SUSE sponsors the project, but is there a good reason for not producing .deb packages for Debian/*buntu, the most popular line of distro? Anyway congrats with the release, looking forward to taking it for a spin! /Casper ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ListViewSubItemCollection different behaviour in .net mono enviroment
Weird, I wonder why it adds a subitem for the item passed in as the
owner. But it does, please file a bug and we'll fix it.
http://www.mono-project.com/Bugs
Thanks!
Jonathan
marcos b wrote:
If i run the following test using .net environment subItems.Count returns 2,
if I do it using mono environment subItems.Count returns 1.
I'm having other problems also with the list view so my question is if there
are many bugs reported about this control and related classes.
[Test]
public void ListViewSubItemCollectionTest()
{
System.Windows.Forms.ListViewItem.ListViewSubItemCollection
subItems;
subItems = new
System.Windows.Forms.ListViewItem.ListViewSubItemCollection(new
ListViewItem());
subItems.Add(bla bla);
Console.WriteLine(subItems.Count);
}
Thanks in advance
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Is Moma (Mono migration analyzer) available for mono 2.0 rc1 version?
Not officially. There is a preview available here: http://jpobst.com/moma2-0.zip Note that report submission is disabled in this version. Jonathan marcos b wrote: Is Moma (Mono migration analyzer) available for mono 2.0 rc1 version? Thanks ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.0 Preview 1 is out!!
1) On screenshot you can see that there is a problem with buttons
alignment in New image dialog.
Yep, that's definitely a bug.
2) MDI broken again. Next code cause a message box with error:
var child = new Form {MdiParent = this};
child.Show();
error is next: Failed to create window, calss 'SWFClass0' Error: 0
If that's for paint-mono, it is being ported to run on Linux. It will
not run on Windows. If that's a general bug, please file it.
3) You asked post bug reports. OK. I looked in tracker - there are 171
bugs only in SWF (some of them are mine). Some bugs assigned to
developers. But most of them not assigned. What do you plan to do with
such bugs? Will you ignore them and make 2.0 release?
We do our best to fix as many of them as we can. However, they may or
may not be fixed in the future depending on their severity and our
manpower. This is expected with all software development. All
non-trivial software is released with known bugs.
For example:
Winforms has ~180 open bugs.
Mono has ~1050 open bugs.
Ubuntu has ~46,500 open bugs.
Apache's httpd has ~840 open bugs.
Firefox has ~14,300 open bugs.
Jonathan
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] does mono runtime fully implemented?
Hey The WebBrowser control is implemented. There are a few bugs that cause native crashes that we plan to have fixed in time for 2.0. Jonathan Ray Wang wrote: hello folks i have a very simple script to test WebBrowser control in System.Windows.Forms but when i instancelize a class to an object. it dumps errors. does mono runtime fully implemented? or there is a bug? the attachments are a error message and a sample Ray ___ 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] does mono runtime fully implemented?
We currently have about 5 bug reports on it, so I think its covered. ;) Jonathan Ray Wang wrote: Hello Jonathan, thank you very much for reply, should i fire a bug for it? Or i should wait for the WebBrowser control issue to be fixed until 2.0 is released? Ray Jonathan Pobst [EMAIL PROTECTED] 08/19/08 10:07 PM Hey The WebBrowser control is implemented. There are a few bugs that cause native crashes that we plan to have fixed in time for 2.0. Jonathan Ray Wang wrote: hello folks i have a very simple script to test WebBrowser control in System.Windows.Forms but when i instancelize a class to an object. it dumps errors. does mono runtime fully implemented? or there is a bug? the attachments are a error message and a sample Ray ___ 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] Mono 2.0 Preview 1 is out!!
Here is the ported version running on Mono/openSUSE: http://code.google.com/p/paint-mono/ My guess is that the unported version is hitting an exception somewhere in paint code (probably from a win32 call) and exiting the drawing loop early. Jonathan sasha wrote: Maybe some parts of Paint.NET has specific Win32 code, but there are problems with toolbars, with status bars, with dialogs, ets... Compare next screenshots: 1) Screenshot from .NET: http://picasaweb.google.ru/trofimich/Mono/photo#5233262846349449314 2) Screenshot from Mono: http://picasaweb.google.ru/trofimich/Mono/photo#5233262848186024290 It is clear that most of this problems are SWF implementation bugs? isn't it? ___ 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] DataGridView Virtual Mode
No, datagridview's virtual mode is not currently implemented in a release or SVN. Jonathan Cetin Sert wrote: Dear Mono Devs, Is the virtual mode of winforms DataGridView already usable in the latest mono releases or at least in the SVN repository? Best Regards, Cetin Sert ___ 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] DataGridView virtual mode, exception
No, it will not be in Mono 2.0. Perhaps it will be in 2.1 or 2.2. Jonathan Anhell wrote: Jonathan Pobst wrote: Virtual mode, and indeed much of DataGridView, does not work under Mono 1.9. I have been improving it for Mono 2.0, but it is highly unlikely that virtual mode will be working by then. So, what are the current plans for the DataGridView virtual mode. Any chances we will see it on Mono 2.0 final release? Thanks in advance. View this message in context: Re: DataGridView virtual mode, exception http://www.nabble.com/DataGridView-virtual-mode%2C-exception-tp16498531p18383750.html Sent from the Mono - Dev mailing list archive http://www.nabble.com/Mono---Dev-f1369.html at Nabble.com. ___ 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] One Version of Mono.Cairo
Currently we ship 2 versions of Mono.Cairo.dll in Mono, a 1.0 and a 2.0 version. However, there is no difference in these versions. This can cause issues if different assemblies reference different versions and the runtime tries to load them both. I think we need to: - Not ship a 2.0 version. - Ship a policy file that maps both versions to the 1.0 version. This should allow existing programs to work while reducing us to only one version Mono.Cairo. Some other assemblies that we appear to ship 1.0 and 2.0 versions of without any differences between them (looking at the 1.9.1 Win/Mono Gac): - CustomMarshallers.dll - Mono.Data.dll - Mono.Data.SybaseClient.dll - Mono.Data.TdsClient.dll - Mono.Http.dll - Mono.Posix.dll - Mono.Security.Win32.dll - Novell.Directory.Ldap.dll - Npgsql.dll - OpenSystem.C.dll Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Patch] Implement basic AutoComplete support for ComboBox
Looks fine. Please commit. Jonathan Carlos Alberto Cortez wrote: Hey! Attached is a patch that implements support for ComboBox. The idea is to use the available support in TextBox, so the TextBox has direct access to our items. Since this is not the clearest approach, it's the better in terms of performance, since otherwise we should create a IList of item's text, and modifying or updating it as items are modified in ComboBox.Items collection. Observe that this patch only makes use of the basic properties of Auto complete in TextBox. As soon as I check in the keyboard navigation in TextBox for automplete, I will come with a second patch for ComboBox ;-) Carlos. ___ 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] DirectoryInfo.GetDirectories Bug
Nevermind, this function is dependent on the underlying filesystem on Windows. NTFS and CDFS are alphabetic case-insensitive as listed, however on FAT, it is the order in which the files were created. I will do the sort in winforms. Jonathan Jonathan Pobst wrote: Hey guys, I am working on bug #393931. Basically the bug is that winforms' open file dialog sorts directories case sensitive instead of insensitive, so directories like Mono and Projects come before bin. The code we use is this: DirectoryInfo di = new DirectoryInfo (Environment.CurrentDirectory); DirectoryInfo[] dirs = di.GetDirectories (); foreach (DirectoryInfo d in dirs) Console.WriteLine (d.Name); On Windows, this would return: A, b, C On Linux, this would return: A, C, b I realize the Linux filesystem is different, but my question is do we want to replicate the Windows behavior on Linux or not? If not, I can work around it in winforms, but I thought this might be something we wanted to emulate MS on. (MONO_IOMAP has no effect either.) Thanks! Jonathan ___ 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] Migrating Mono 2.0. Crossplatform GUI components.
I guess it depends on your requirements. .Net (and Mono) comes with a toolbar, grid, and tree. So part of it will be figuring out what additional functionality you need that you are getting from third party controls. Right now, I do not know of any third party controls that work out of the box with Mono. Hopefully, with the release of Mono 2.0, this will change as we work with some third party vendors to get their controls working on Mono. Jonathan Yakov Danilov wrote: Hi everyone. Because of Mono 2.0. release our firm has some plans about creation of crossplatorm client that could be used with .Net 2.0 on Windows and Mono 2.0 on Linux systems. Business logic can be used without any problem, but GUI has been created using Infragistics components that have too many Win Api calls and can be used only on Windows. Thats why we need components written in managed C# and WinForms that can be used on both platforms. Basically we need Toobar, Grid, Tree. At this time I find only SourceGrid. Can anybody advice us such components? Writing own components too laborious. p.s. Sorry if my English is not so well. ___ 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] Mono.Media for GSOC
There were a lot more organizations participating this year, and as a result we received less slots than we would have liked. So we had to make some really hard decisions on which projects to choose based not only on the projects but the applicants themselves. In the end, we obviously felt the projects and applicants we chose were more interesting and had higher chances of success. :) Jonathan Justin Cherniak wrote: I'm just curious, does anyone know why nobody was selected for this project for GSOC? Even without the codec capabilities, it seemed like a very useful worthwile project, so I'm just curious why it wasn't selected? On another note, for at least the PCM audio portions, if someone would want to mentor me, I would be willing to invest some time into getting it up and running; even without GSOC funding as it is in my opinion one of the biggest lackings of Mono/.NET. Thanks, Justin On Tue, Apr 29, 2008 at 3:57 PM, BlueWall [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: This is very interesting! Especially the midi framework! It would be great if it would connect to jack-midi as well. Prashant Vaibhav wrote: Dear Miguel, Dear All, Glad to hear codecs are not a focus for Mono.Media (at present). Somehow most discussion in this area seems to be focused on re-implementing gstreamer or creating bindings for it (a/v format coding/decoding in general). Last weekend I submitted an application for Mono.Media GSoC. My proposal seeks to provide high performance, low-level audio/MIDI features for Mono, rather than a generic coder/decoder framework. One thing I have focused on is fairly complete MIDI support. I didn't base my proposal on the Java media framework (I don't have much, if any, experience with Java, plus I saw discussion on how JMF's heavily asynchronous design is undesirable), so I might be missing some obvious features. I'll appreciate if the Mono dev community could comment on my design. Following is an excerpt from the proposal: The architecture of the Mono.Media.Audio section would be as follows: - Classes representing audio devices will be implemented. These will abstract out platform-specific code (ie. the same AudioDevice would use WDM/KS on Windows and Jack/Alsa on Linux) - Classes representing audio sources will be implemented. These will have methods to *provide* audio. - Classes representing audio consumers will be implemented. These act like sinks. An AudioSourcePlayer for example will continuously stream audio from an AudioSource to an AudioDevice. The AudioDevice will have a callback method on its own high priority thread to get audio buffers. - Further classes like Mixer, CrossFader, Equalizer etc. might be implemented as a combination of sinks and sources. - Classes for reading/writing simple audio files (.wav, .aiff etc.) will also be implemented. The MIDI architecture will consist of : - Classes for MIDI input and output devices. These will represent actual devices on Windows (which does not support the concept of virtual devices), and software ports on Linux and Mac. The winmm API will be used on Windows, CoreMIDI on Mac, and ALSA sequencer API on Linux. - Classes for MIDI events (a generic event, NoteOn, NoteOff events, SysEx, MetaEvents, Controller etc.). These will allow easy creation/manipulation of MIDI data, shielding the programmer from the actual byte-stream. - Classes for storing/manipulating these (e.g. MidiTrack, MidiSequence, MidiRecorder etc.) - Classes for handling MIDI file input/output - Classes for handling MIDI time code and transport control messages Basically the MIDI framework will be a fairly complete implementation of everything that MIDI has to offer (except perhaps highly specialized standards like Sample Dump Standard). If we have time, an OSC interface might also be implemented. Of course this design is open to discussion. Thanks for your time! Best, Prashant On 07/04/2008, Miguel de Icaza [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I'm interested in applying for GSOC to work on Mono.Media and I was just wondering if I could get a few more details about the project. Has any work been completed on it? How comprehensive in terms of codec support are you looking for? I do not believe that there is much along
Re: [Mono-dev] Exception when disassembling using Reflector
I've already fixed this in SVN. Thanks! Jonathan Xerxes Battiwalla wrote: Hi, I received the following error while using Reflector under Ubuntu Gutsy and submitted it to their bug list. Lutz replied back and said it was a Mono bug. I couldn't find a bugzilla report matching this, and didn't want to dupe it just in case. should i log this under bugzilla? thanks xerxes. -- Forwarded message -- From: *Lutz Roeder* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Date: 21 Apr 2008 03:36 Subject: Re: Bug Report for .NET Reflector 5.1.0.0 http://5.1.0.0 To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] This is a mono issue Sent from my iPhone On Apr 20, 2008, at 4:25 AM, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Tried to run a disassemble on System.Configuration.ClientSettingsSection.Properties, using Reflector on Ubuntu Gutsy. the problem occurs when trying to disassemble any member. '2' is not a valid value for 'Value'. 'Value' should be between 'Minimum' and 'Maximum' Parameter name: Value System.ArgumentOutOfRangeException at System.Windows.Forms.ScrollBar.set_Value (Int32 value) [0x0] at (wrapper remoting-invoke-with-check) System.Windows.Forms.ScrollBar:set_Value (int) at System.Windows.Forms.TextBoxBase.CaretMoved (System.Object sender, System.EventArgs e) [0x0] at System.Windows.Forms.TextBoxBase.ScrollToCaret () [0x0] at System.Windows.Forms.TextBoxBase.CreateHandle () [0x0] at System.Windows.Forms.Control.CreateGraphics () [0x0] at System.Windows.Forms.RichTextBox.HandleControl (System.Windows.Forms.RTF.RTF rtf) [0x0] at (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_RTF (System.Windows.Forms.RTF.RTF) at System.Windows.Forms.RTF.RTF.RouteToken () [0x0] at System.Windows.Forms.RTF.RTF.Read () [0x0] at System.Windows.Forms.RichTextBox.InsertRTFFromStream (System.IO.Stream data, Int32 cursor_x, Int32 cursor_y, System.Int32 to_x, System.Int32 to_y, System.Int32 chars) [0x0] at System.Windows.Forms.RichTextBox.InsertRTFFromStream (System.IO.Stream data, Int32 cursor_x, Int32 cursor_y) [0x0] at System.Windows.Forms.RichTextBox.set_Rtf (System.String value) [0x0] at (wrapper remoting-invoke-with-check) System.Windows.Forms.RichTextBox:set_Rtf (string) at ?.? () [0x0] at ?.? (Boolean A_0, Boolean A_1, Boolean A_2) [0x0] at ?.? (System.EventArgs A_0) [0x0] at System.Windows.Forms.Control.ChangeParent (System.Windows.Forms.Control new_parent) [0x0] at (wrapper remoting-invoke-with-check) System.Windows.Forms.Control:ChangeParent (System.Windows.Forms.Control) at System.Windows.Forms.Control+ControlCollection.Add (System.Windows.Forms.Control value) [0x0] at System.Windows.Forms.Control+ControlCollection.AddRange (System.Windows.Forms.Control[] controls) [0x0] at ?.? () [0x0] at ?.? (IWindow A_0) [0x0] at (wrapper remoting-invoke-with-check) ?:? (Reflector.IWindow) at ?.? (System.String A_0) [0x0] at (wrapper remoting-invoke-with-check) ?:? (string) at ?+?.? (Boolean A_0) [0x0] at ?.? () [0x0] at ?.? (System.String A_0) [0x0] at ?.? (System.String A_0) [0x0] at ?.? (System.String A_0) [0x0] at Reflector.Application.ApplicationManager.? (System.Object A_0, System.EventArgs A_1) [0x0] at (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_EventArgs (object,System.EventArgs) at System.Windows.Forms.MenuItem.OnClick (System.EventArgs e) [0x0] at System.Windows.Forms.MenuItem.PerformClick () [0x0] at (wrapper remoting-invoke-with-check) System.Windows.Forms.MenuItem:PerformClick () at System.Windows.Forms.MenuTracker.OnMouseUp (System.Windows.Forms.MouseEventArgs args) [0x0] at System.Windows.Forms.Form.WndProc (System.Windows.Forms.Message m) [0x0] at ?.? (System.Windows.Forms.Message A_0) [0x0] at System.Windows.Forms.Control+ControlWindowTarget.OnMessage (System.Windows.Forms.Message m) [0x0] at System.Windows.Forms.Control+ControlNativeWindow.WndProc (System.Windows.Forms.Message m) [0x0] at System.Windows.Forms.NativeWindow.WndProc (IntPtr hWnd, Msg msg, IntPtr wParam, IntPtr lParam) [0x0] .NET Reflector 5.1.0.0 http://5.1.0.0 .NET Framework 2.0.50727.42 Unix 2.6.22.14 http://2.6.22.14 Culture: en-AU (en-AU) [AssemblyCache] %SystemRoot%\Microsoft.net %ProgramFiles%\Reference Assemblies %ProgramFiles%\Microsoft.net %ProgramFiles%\Microsoft Silverlight
Re: [Mono-dev] DataGridView virtual mode, exception
Virtual mode, and indeed much of DataGridView, does not work under Mono
1.9. I have been improving it for Mono 2.0, but it is highly unlikely
that virtual mode will be working by then.
I do not know of any alternatives either. Perhaps someone else does.
Jonathan
Cetin Sert wrote:
Dear Mono Devs,
mono DGVV.exe
Unhandled Exception: System.NullReferenceException: Object reference not
set to an instance of an object
at System.Windows.Forms.DataGridView.set_RowCount (Int32 value) [0x0]
at (wrapper remoting-invoke-with-check)
System.Windows.Forms.DataGridView:set_RowCount (int)
at DGVV.Form1..ctor () [0x0]
at (wrapper remoting-invoke-with-check) DGVV.Form1:.ctor ()
at DGVV.Program.Main () [0x0]
when setting RowCount property on a DataGridView instance in virtual
mode, I get the above exception with Mono 1.2.4, 1.2.6 and 1.9.
Is virtual mode of DataGridView usable in Mono (1.9)?
If it is, what am I doing wrong?
If it is not, what other winforms grid control do you suggest me to use?
(It should have a virtual mode support... I tested SourceGrid but it
does not draw properly when in virtual mode.)
Best Regards,
Cetin Sert
http://corsis.de
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
namespace DGVV
{
public partial class Form1 : Form
{
public DataGridView dgv = new DataGridView();
public Form1()
{
InitializeComponent();
dgv.VirtualMode = true;
dgv.CellValueNeeded += new
DataGridViewCellValueEventHandler(dgv_CellValueNeeded);
// Add columns to the DataGridView.
DataGridViewTextBoxColumn companyNameColumn = new
DataGridViewTextBoxColumn();
companyNameColumn.HeaderText = Company Name;
companyNameColumn.Name = Company Name;
DataGridViewTextBoxColumn contactNameColumn = new
DataGridViewTextBoxColumn();
contactNameColumn.HeaderText = Contact Name;
contactNameColumn.Name = Contact Name;
dgv.Columns.Add(companyNameColumn);
dgv.Columns.Add(contactNameColumn);
dgv.AutoSizeColumnsMode =
DataGridViewAutoSizeColumnsMode.AllCells;
dgv.EditMode = DataGridViewEditMode.EditProgrammatically;
dgv.AllowUserToAddRows = false;
dgv.RowCount = 4;
}
void dgv_CellValueNeeded(object sender,
DataGridViewCellValueEventArgs e)
{
switch (e.ColumnIndex)
{
case 0:
e.Value = Sertcom;
break;
case 1:
e.Value = e.RowIndex 2 ? Cetin : Metin;
break;
}
}
}
}
___
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] Contribute to the Mono project
There is also: http://www.mono-project.com/Todo though I am unsure how updated it is, so I would propose a topic before actually starting it. Jonathan Michael Hutchinson wrote: On Sun, Mar 30, 2008 at 12:22 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, we are two Italian undergraduate students in Computer Science. Until now we developed only university-related projects for our exams, but we' d like to contribute to the Mono project. We know that it could be challenging because we have never been involved in a big project, but we think that our current skills are enough to face the issues we will have. We already read the to-do list and we'd like to know if it's updated or not and if there is some other new project/task to assign. Our idea is take a task like a thesis subject and develop it as a team. We look forward to hear from you, Andrea Carpineti Igor Leboroni I suggest looking at some of the larger, more complex tasks at http://www.mono-project.com/StudentProjects. Although that page is used for listing possible google summer of code projects, many of the projects would be ideal for thesis work, and we'd be happy to give advice on how to go about implementing them. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] GSoC anyone?
Hey, We generally don't pick mentors until we go through the applications and decide which ones to accept. Pretty much the whole Mono team is signed up as mentors, we will just see whose skills are needed based on the applications. Most of us felt there was no need to spam introductions to the GSoC mentors list, so we have refrained so far. :) Jonathan [EMAIL PROTECTED] wrote: Hi there, I've tried to reach the list yesterday, but I'm afraid my email was rejected. I was accepted as Mentor for GSoC at the mono project, and I'm now receiving tons of emails with introductions. I didn't realize any other mono mentors out there (I probably missed the emails), so I'd like to who is going to be mentoring which projects... I'll try to help in the MonoDevelop debugger integration. pablo www.plasticscm.com ___ 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] RightToLeftLayout functions
I don't really think there are many left to be stubbed. The only places I see ones that are missing or throw notimplement are: - AxHost - we don't support any of this, everything throws notimplement - DataGridView - we aren't supporting this in time for Mono 2.0 - WebBrowser - andreia is taking care of implementing and stubbing everything here All the other ones are already implemented as TODO, unless I am missing something? Jonathan Dennis Hayes wrote: I am considering going through and stubbing out the RightToLeftLayout functions that are missing, and adding ToDO: needs implementing. Why? 1) These show up a good bit in the MoMa reports. 2) If they are missing, or even throw notimplment, the application will not run. 3) If the sets do nothing, and the gets always return false (or a value from the parent or client) it will be correct in almost all cases, and worst case, will be displayed backwards. This seems beter than always crashing. Good idea? Bad Idea? Comments or suggestions? Thanks, Dennis Never miss a thing. Make Yahoo your homepage. http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs ___ 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] Deprecating some Mono commands, Cecil mono-api-info
Additionally, I believe that the Cecil-based mono-api-info is a better implementation than the SRE-based implementation. And am wondering if we should just replace our current implementation with the version living in cecil (this would also eliminate mono-api-info and mono-api-info2). I just tried running both versions on 2.0's Accessibility.dll. The SRE one is 122k, the Cecil one is 55k. So I don't think the Cecil one is ready yet for primetime. SRE: http://jpobst.com/Accessibility.xml Cecil: http://jpobst.com/Accessibility.Cecil.xml Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Deprecating some Mono commands, Cecil mono-api-info
Right, it is more condensed because it is missing the rest of the information. :) For your example, it is missing the attributes on the parameters. Both files should be exactly the same. Jonathan Alan McGovern wrote: Well, if you look at the output you'll see that the cecil one is considerably more condensed and readable than the SRE one, so that could easily explain the filesize difference. For example, the 'ClearProps(in System.Byte, in System.UInt32, in System.Guid, in System.Int32)' method is 7 lines in the cecil version but about 24 lines in the SRE version. Alan. On Mon, Mar 3, 2008 at 5:06 PM, Jonathan Pobst [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Additionally, I believe that the Cecil-based mono-api-info is a better implementation than the SRE-based implementation. And am wondering if we should just replace our current implementation with the version living in cecil (this would also eliminate mono-api-info and mono-api-info2). I just tried running both versions on 2.0's Accessibility.dll. The SRE one is 122k, the Cecil one is 55k. So I don't think the Cecil one is ready yet for primetime. SRE: http://jpobst.com/Accessibility.xml Cecil: http://jpobst.com/Accessibility.Cecil.xml Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com mailto: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] Mono 1.9.0 Preview 3 is out - mono 1.9 pre3 / gtk# 2.10.3 not working on Win32
I filed this bug, which I think is the same issue: https://bugzilla.novell.com/show_bug.cgi?id=364881 Jonathan Brad Taylor wrote: Hey, I'm not sure if there is a bug for this or not. The gtk# 2.10.3 that comes with the mono 1.9.0 preview 3 windows installer is broken. In particular, setting or getting a value from a tree model. Weird, we at Medsphere haven't had any issues with this installer when running applications that make extensive use of TreeView. Do you have a test case you can provide for this issue? Best, -Brad ___ 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] Mono 1.9.0 Preview 3 is out - mono 1.9 pre3 / gtk# 2.10.3 not working on Win32
Yes, I think they are going to make a 2.10.4 to ship with Mono 1.9. Jonathan Daniel Morgan wrote: Will the gtk# fix that Mike Kestner did make it into the Mono 1.9 windows installer? --- Jonathan Pobst [EMAIL PROTECTED] wrote: I filed this bug, which I think is the same issue: https://bugzilla.novell.com/show_bug.cgi?id=364881 Jonathan Brad Taylor wrote: Hey, I'm not sure if there is a bug for this or not. The gtk# 2.10.3 that comes with the mono 1.9.0 preview 3 windows installer is broken. In particular, setting or getting a value from a tree model. Weird, we at Medsphere haven't had any issues with this installer when running applications that make extensive use of TreeView. Do you have a test case you can provide for this issue? Best, -Brad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] MonoDevelop on Windows
I pretty much just compiled trunk on Linux with --disable-gnomeplatform, and don't put an option for gtksourceview2, and it will just use the new managed source editor. Later I wrote a WindowsPlatform addin, and got Lluis to remove a few Unix-isms. After that, Geoff Norton pretty much took over and made the real progress. He made a lot of fixes for remoting and such to make it work much better. Next week, when he gets back from the conference he is at, I will try to prod him to put his changes into SVN. Jonathan Daniel Morgan wrote: Jonathan, What steps did you use to build and run MonoDevelop on Windows? And what dependencies did you use? I understand from your blog that a lot of it does not work, but I still would like to see it at least run. I'm sure others would be interested in helping and/or testing it. Hopefully, you can commit your fixes to svn so others can try it out. Thanks, Daniel Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ 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.9
I'm pretty sure the support is 0%. Although we have implemented some of the 3.0 and 3.5 base class libraries, they are not shipped yet in our releases. These are done in our Olive module: http://www.mono-project.com/Olive. Oh, 1.9 will ship with nearly complete support for C# 3, but none of the base class libraries. Jonathan Scott Fluto wrote: I was wondering if anyone knows what percentage of support 1.9 has with regards to .net 3.0 and 3.5 , is there a place to see the percentage of method coverage it has or will have? thanks scott ___ 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] mono 1.9
No, it will be pretty much 0% complete for 3.0 and 3.5. The ONLY post-2.0 piece that will be available is the C# compiler which will support the new C# 3 language features (such as extensions and partial LINQ support) and the one base class library needed to support this. It will not support any of the 3.0 base class libraries (WCF, WF, WPF) or any of the new 3.5 base class libraries (other than parts of System.Core.dll). I know its complicated, the thing to remember is C# 3 is not .Net 3.0 or .Net 3.5. It's just an enhancement to the language which shipped (ironically enough) in .Net 3.5. :) Hope this helps! Jonathan Scott Fluto wrote: hmm, so what I can gather then is that it will be pretty much 3.0 complete but just partially 3.5 complete given 3.5 has a lot of base class library enchantments? scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Pryor Sent: February-20-08 10:33 AM To: Jonathan Pobst Cc: Scott Fluto; mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] mono 1.9 On Wed, 2008-02-20 at 09:11 -0600, Jonathan Pobst wrote: I'm pretty sure the support is 0%. Although we have implemented some of the 3.0 and 3.5 base class libraries, they are not shipped yet in our releases. These are done in our Olive module: http://www.mono-project.com/Olive. Oh, 1.9 will ship with nearly complete support for C# 3, but none of the base class libraries. System.Core.dll should be in 1.9, which is required for such C# 3 features as extension methods and LINQ. - Jon ___ 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] MoMA: Changes in 1.2.6 Version
UPDATE: I forgot that the new definitions contained a method signature that MoMA was unable to handle, so you actually DO have to download a new copy from the MoMA home page for 1.2.6 to work. Sorry for the confusion. :( http://www.mono-project.com/MoMA Jonathan Jonathan Pobst wrote: Hey guys! I generally don't make any announcement when I release a new MoMA for the new Mono release. This is because you just click the Check for newer version link, which magically downloads the new definition file and life is chock full of rainbows and ponies. However, for the 1.2.6 release, we made 2 important changes to the definition files that warrant a mention. - Removal of Design Namespaces - One of our awesome mono-vangelists pointed out that people scan their app (and third party controls) and see all kinds of warnings about things missing in the Design classes. However, these classes are not used to run apps, just for designers such as Visual Studio. So we are potentially scaring off users for no reason. Therefore, beginning with 1.2.6, we no longer include the Design namespaces in MoMA reports. (If you really want the Design stuffs, you can download the definition file that includes them on the MoMA home page: http://www.mono-project.com/MoMA) - Addition of .Net 3.0/3.5 Classes - Beginning with 1.2.6, we include the definitions needed to scan your .Net 3.0 and 3.5 apps. At this point, we report everything as missing. Even though we have implemented some of these classes in our Olive (http://www.mono-project.com/Olive) project, we do not currently ship this with the released Mono, and MoMA tracks the Mono releases. So what good is adding the 3.0/3.5 stuffs if we are going to report it all as missing? We will soon be getting to the point where we need to figure out what new stuff to implement next. By scanning your app with MoMA and submitting the missing report, we can see which parts are the most important to our users so we can prioritize. (And yes, we _really_ use this data. MoMA reports [http://primates.ximian.com/~miguel/momareports/] have pretty much dictated our prioritization since it was released a year ago.) - How Do I Get These New Features? - So how do you get the new stuff? Just click on the Check for newer version link in MoMA, sit back, relax, and enjoy the rainbows and ponies. Or if you don't already have MoMA, you can grab it at: http://www.mono-project.com/MoMA. Thanks! Jonathan ___ 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] MoMA: Changes in 1.2.6 Version
Hey guys! I generally don't make any announcement when I release a new MoMA for the new Mono release. This is because you just click the Check for newer version link, which magically downloads the new definition file and life is chock full of rainbows and ponies. However, for the 1.2.6 release, we made 2 important changes to the definition files that warrant a mention. - Removal of Design Namespaces - One of our awesome mono-vangelists pointed out that people scan their app (and third party controls) and see all kinds of warnings about things missing in the Design classes. However, these classes are not used to run apps, just for designers such as Visual Studio. So we are potentially scaring off users for no reason. Therefore, beginning with 1.2.6, we no longer include the Design namespaces in MoMA reports. (If you really want the Design stuffs, you can download the definition file that includes them on the MoMA home page: http://www.mono-project.com/MoMA) - Addition of .Net 3.0/3.5 Classes - Beginning with 1.2.6, we include the definitions needed to scan your .Net 3.0 and 3.5 apps. At this point, we report everything as missing. Even though we have implemented some of these classes in our Olive (http://www.mono-project.com/Olive) project, we do not currently ship this with the released Mono, and MoMA tracks the Mono releases. So what good is adding the 3.0/3.5 stuffs if we are going to report it all as missing? We will soon be getting to the point where we need to figure out what new stuff to implement next. By scanning your app with MoMA and submitting the missing report, we can see which parts are the most important to our users so we can prioritize. (And yes, we _really_ use this data. MoMA reports [http://primates.ximian.com/~miguel/momareports/] have pretty much dictated our prioritization since it was released a year ago.) - How Do I Get These New Features? - So how do you get the new stuff? Just click on the Check for newer version link in MoMA, sit back, relax, and enjoy the rainbows and ponies. Or if you don't already have MoMA, you can grab it at: http://www.mono-project.com/MoMA. Thanks! Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] MoMA: Changes in 1.2.6 Version (Jonathan Pobst)
Aw crap. Download the new executable from http://www.mono-project.com/MoMA, it should contain the fix for that. Jonathan Engler, Eric wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 for the 1.2.6 release, we made 2 important changes to the definition files I can't use these new files at all. Every time I try to analyze an assembly I get this (running on Windows with MS CLR): See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box. ** Exception Text ** System.ArgumentOutOfRangeException: Length cannot be less than zero. Parameter name: length at System.String.InternalSubStringWithChecks(Int32 startIndex, Int32 length, Boolean fAlwaysCopy) at MoMA.Analyzer.Method.ParseMethod() at MoMA.Analyzer.BaseChecker..ctor(Stream input) at MoMA.Analyzer.AssemblyAnalyzer.LoadDefinitions(Stream monoTodoDefinitions, Stream notImplementedDefinitions, Stream missingDefinitions) at MoMA.Analyzer.AssemblyAnalyzer.LoadDefinitions(String definitionBundlePath) at MoMA.MainForm.AnalyzeAssemblies() at MoMA.MainForm.NextButton_Click(Object sender, EventArgs e) at System.Windows.Forms.Control.OnClick(EventArgs e) at System.Windows.Forms.Button.OnClick(EventArgs e) at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent) at System.Windows.Forms.Control.WmMouseUp(Message m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message m) at System.Windows.Forms.ButtonBase.WndProc(Message m) at System.Windows.Forms.Button.WndProc(Message m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) Eric NOTICE: The information contained in this electronic mail transmission is intended by the sender for the sole use of the named individual or entity to which it is directed and may contain information that is privileged or otherwise confidential. Please do not copy it or use it for any purposes, or disclose its contents to any other person. To do so could violate state and Federal privacy laws. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email or by telephone, so that the sender's address records can be corrected. Thank you for your cooperation. -BEGIN PGP SIGNATURE- Version: PGP Universal 2.6.2 Charset: us-ascii wsBVAwUBR2HCQ8hfyUs+le7yAQhwBAf/Sg63CQdE7Qtd4cRmZpOo3QxzDTECiap7 /mdwi6qGDGk1sTdBdd9OAmYPU+lPacRl5DEze8p1Mfe51iatWDhU9NU4UvVahvHF SEkzBg2+x5IY7MQPmEE92CwCEddoQfB1pKHHHN8TvAiyxvr+SINZy2wL3Aw+soyR Lh5FUjQQSQveVEXL64q3RnnPRMDxK1djonGFqVXjHTyIHsCVnOYWUXyvwwmpmAUI Rx3F82/JigQsLa+uc4feMtp1FN9OG7RdBBlK8m6X8b87x39hGMxkTzJV9u8MCSVV sZbN+cZfqWd+6wCvNjggRK94PvRP9LTBvtPZ0xzwp9uTwPiLegtTLQ== =vPC2 -END PGP SIGNATURE- ___ 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] should we really use Mono[NotSupported|Limitation|Blah]Attributes?
MoMA has been updated to report: - MonoTODO - MonoLimitation - MonoNotSupported It will not report: - MonoDocumentationNote - MonoExtension - MonoInternalNote However, they all just show as TODO on MoMA reports/GUI, so developers are still encouraged to include a message explaining what is missing. This is a definition file change, so if you are using definition files for 1.2.3 or 1.2.4, you have this update. You do not need a new version of MoMA. The class status pages have not been modified, and currently only report the traditional MonoTODO. Jon Atsushi Eno wrote: Hello, I just noticed that after replacing MonoTODO attributes with one of those derived ones such as MonoNotSupported, they get *hidden* from the class status pages. As a result, we're getting wrong MoMA reports. Is it really intended, or should we avoid using those derived attributes? (For example see System.ComponentModel.MemberDescriptor.GetInvocationTarget() in System.dll) I don't think those attributes are ready to be used unless corcompare stuff are changed to consider them. Atsushi Eno ___ 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] mono builder down?
It had moved. The new one is: http://mono.ximian.com/monobuild/ Which wiki page needs to be updated? Thanks! Jon [EMAIL PROTECTED] wrote: Hi, Is it ok that builder for calss status in down for a long time? Or it have moved and wiki page is not update? http://mono.ximian.com:8008/x86-64-head-mono regards, Olivier Dufour ___ 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] Mono 1.2.4, preparation rituals.
Jackson ported it to 1.2.4 in SVN r76147, so it will be in the final 1.2.4 release. Thanks! Jon Frederik Carlier wrote: Pressing ENTER in a single line textbox on a form that has a default button causes an extra character to be added to the textbox instead of the button being pressed. Also, pressing backspace to remove this non-printable character leaves a relic. Thanks for filing the bug. Although this bug report came too late, we have already branched the tree and it does not seem like there is a bug fix yet. A bug fix has been commited (Bug 81408, SVN r76143). Is there a possibility this fix can find its way into 1.2.4? Frederik. ___ 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] Mono 1.2.4, preparation rituals.
Can you elaborate any on this? There are no bugs about this in bugzilla, and it's the first I've heard of it. If you could file a bug with a test case, we will definitely look into it because it sounds pretty serious. Thanks! Jon Paul wrote: Hi, I humbly request that the ThreadPool patches that were posted in completionPortThreads in threadpool.c not used? on April 1st make it in. And that keyboard events actually work on a Winform. TTFN Paul ___ 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] Binding navigator patch
Often times we don't keep the VS projects in sync with the .sources file used to build mono. Generally you already have the file from SVN, you just need to add it to your project. In this case, the file should be EventLogger.cs. Jon [EMAIL PROTECTED] wrote: Hi, For my second patch, I have take the first class missing in mono winforms ;). I have try to fit to coding guideline. If there are still issue, make a feed back... I have issue on winforms test project because Eventlogger is not recognize. So I can not compile it and launch test. So maybe my test do not pass on windows dlls. So, if someone know how fix that, I will test it and resend the patch. regards, ___ 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] missing class scrollProperties (system.windows.forms)
Hey Olivier! Thanks for your patch! I took it and added the implementation and tests as well. It is committed in SVN as r75208. Please read up on our coding guidelines (http://www.mono-project.com/Coding_Guidelines) if you submit more stuff in the future. I fixed it all this time, but next time we won't accept it until it's up to standards. Thanks for your work! Jon [EMAIL PROTECTED] wrote: Hi All, I am making a winform gui for monotorrent and I see with moma that some properties are missing to make my code compile on mono. So I just code a basic structure for missing class but it is still unfinished (Monotodo attributes) because I do not know very well the internal things of mono framework. Hope It can help. If I do bad, make a feed back and I will fix my code. There are no methodes (only properties) so I have done no unit test. bye, Duff (olivier dufour) ___ 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] Race to Linux
Hey Paul, The splash page is available here: http://www.mono-project.com/RaceToLinux Which has links to regular download packages as well: http://mono.ximian.com/monobuild/rtl/download-rtl/ The release is primarily fixes to ASP.Net that should be helpful for people porting their webapps for Race to Linux, but of course anyone is welcome to download and use it. We are hoping to do a regular full release in a month or so. Enjoy! Jon Paul wrote: Hi, I've noticed there is a different version available of Mono for the Race to Linux thing. Is this different version going to be made available to the rest of us in the near future as a non-VM version? TTFN Paul ___ 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] Class Status Pages (was: NET_2_0 class status not available)
Speaking of the class status pages, it has this really great feature where if you Ctrl-Click on a node, it takes you to the SVN for that class. However, it is still set to cvs.hispalinux.es. If it's not too hard, could this be updated to point to the current SVN? Jon Miguel de Icaza wrote: Hello, The NET_2_0 class status seems to be broken: http://mono.ximian.com/class-status/mono-HEAD-vs-fx-2/class-status-mscorlib.html It is sometimes broken when the build is broken. When it is broken, check the build status: http://mono.ximian.com/monobuild/python/monobuild.py Wade changed the setup so that the generation of pages would not break even if the build does. ___ 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] Windows Shell
My opinion, but what I think we need to achieve, and how to get there is roughly: - Get the Moma results of P/Invoke calls, sorted by call frequency. - For each one: - Try to figure out why it's being called (what the user is trying to accomplish, which is not always easy or possible) - Determine if there is something already in the managed API that we should be pointing users to. - If not, design a .Net style function that accomplishes what the user is trying to do (which may or may not look like the Win32 API call) - *!!* Document on the wiki every API call we examine, and what the suggested replacement is. Another route is to simply duplicate the exact Win32 API syntax and try to make it perform the same on *nix. This route would probably be easier for porters, at the expense of new users who would prefer to accomplish the task without learning Win32 API. (IMO, a large, large percentage of .Net developers have no desire to touch Win32, think VB.) Most likely, it would be a mix of both. SendMessage would be a pretty straight call, whereas GetIconFromFile could be made easier to use. Place all the results in a .dll called Mono.Compatibility or Mono.Platform or something. Position it as both a library to help people porting to Mono, as well as an abstraction layer to make the Win32 easier for .Net people. Jon Steve K wrote: Aplologies for replying to my own message, but I have a few questions to field. 1) Does Mono simply need to provide an API to get the icons for files and folders, and find the location in the filesystem of the Recent Documents list? 2) Or do we need to expose the Shell/Nautilus/etc Namespace in more detail, for example, being able to enumerate over the contents of folders. ___ 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] Moma early results.
Usage frequency I suppose. If DataRowCollection.Count is listed 100 times for example, it doesn't mean the property is called 100 times at runtime, it actually means the user has typed it out 100 times in their code, and would need to replace/change/fix all 100 occurrences. It's probably more useful for the user's results report than the submitted report, but we can still use it to determine that implementing this one little property is going to alleviate 1000 calls across 10 apps instead of 10 calls over 10 apps. Jon Alan McGovern wrote: Not sure if this has been fixed already or not, but if you look at the largest file in the archive, it has the same methods reported multiple times (100's of times?). Is there any point to that? Alan. On 11/27/06, *Miguel de Icaza* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hey folks, I have posted the 102 results that have been submitted so far from running Moma on people's binaries. The results have been cleaned up a little bit, I removed a few methods that were implemented and methods that had bogus MonoTODO entries, which were removed in the last couple of weeks since the original databases for Moma were created. The results are available here: http://primates.ximian.com/~miguel/tmp/results-moma.tar.gz http://primates.ximian.com/~miguel/tmp/results-moma.tar.gz It is worth noticing that in some cases, an API in the documentation is flagged as existing in 1.1 and 2.0, while the actual method was introduced in 2.0. This happens because in 1.1 you could still call the method, and the call would be satisfied by calling into the parent class of a method. For example Exception.GetType() is a method that calls into base.GetType(), it is flagged in the documentation as available in 1.1, but it did not actually exist back then. So to implement methods like this, the #if NET_2_0 must be used; The same happens extensively in Windows.Forms, when they had to override a few methods to catch some values (is my guess), they are documented as being in 1.1, but they were not. It is important thus to check the results of corcompare, see: http://mono.ximian.com/class-status/mono-HEAD-vs-fx-2/ http://mono.ximian.com/class-status/mono-HEAD-vs-fx-2/ and: http://mono.ximian.com/class-status/mono-HEAD-vs-fx-1-1/ Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com mailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list 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-dev] 2.0 Class Status Page Not Updating
The 2.0 Class Status page hasn't been updated since July 10th. (http://mono.ximian.com/class-status/mono-HEAD-vs-fx-2/index.html) Can someone please put updating this back into the daily build cycle? Thanks, Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Implement Graphics.ReleaseHdc()
Patch to implement 2.0 parameterless Graphics.ReleaseHdc()
- Creates a private variable to hold the IntPtr that GetHdc() returns.
- Stores IntPtr to private variable in GetHdc().
- In ReleaseHdc(), call ReleaseHdc(IntPtr) passing stored IntPtr.
- Set private variable back to IntPtr.Zero.
Please review and commit.
Thanks,
Jonathan
Index: Graphics.cs
===
--- Graphics.cs (revision 62615)
+++ Graphics.cs (working copy)
@@ -52,6 +52,9 @@
private bool disposed = false;
private static float defDpiX = 0;
private static float defDpiY = 0;
+#if NET_2_0
+ internal IntPtr deviceContextHdc = IntPtr.Zero;
+#endif
#if !NET_2_0
[ComVisible(false)]
@@ -1771,6 +1774,9 @@
{
IntPtr hdc;
GDIPlus.CheckStatus (GDIPlus.GdipGetDC
(this.nativeObject, out hdc));
+#if NET_2_0
+ deviceContextHdc = hdc;
+#endif
return hdc;
}
@@ -2034,11 +2040,18 @@
{
Status status = GDIPlus.GdipReleaseDC (nativeObject,
hdc);
GDIPlus.CheckStatus (status);
+
+#if NET_2_0
+ if(hdc == deviceContextHdc)
+ deviceContextHdc = IntPtr.Zero;
+#endif
+
}
#if NET_2_0
public void ReleaseHdc()
{
-
+ if(deviceContextHdc != IntPtr.Zero)
+ ReleaseHdc(deviceContextHdc);
}
#endif
[MonoTODO]
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
