Re: [Mono-dev] Recent xbuild fixes causing issues with finding mcs
TBH this seems like a runtime bug, it should not rely on itself being in PATH. On 17 February 2014 09:34, Michael Franz mvfr...@gmail.com wrote: On Mon, Feb 17, 2014 at 7:38 AM, Rafael Teixeira mono...@gmail.com wrote: Michael Franz, please check if your custom built version of the mono binary is in the path during the rest of the build, or that code Michael Hutchinson pointed out will fail... Adding the bin directory of my Mono installation to the PATH does solve the problem. I can work with this, it is just a change in the usage. Hope it helps, Rafael Teixeira O..:.) On Mon, Feb 17, 2014 at 2:50 AM, Michael Hutchinson m.j.hutchin...@gmail.com wrote: No, this is not the same as launching exe files directly from the OS using binfmt-misc. If you launch an exe file *from Mono's implementation of Process.Start*, Mono will detect managed executables and run them with Mono automatically. https://github.com/mono/mono/blob/master/mono/io-layer/processes.c#L808 On 16 February 2014 09:00, Michael Franz mvfr...@gmail.com wrote: On Sun, Feb 16, 2014 at 7:34 AM, Andrés G. Aragoneses kno...@gmail.com wrote: On 16/02/14 10:15, Michael Hutchinson wrote: ... which automatically executes exe files using Mono. Are you sure that statement applies to all distros? I read somewhere some time ago that the only distro so far that implemented the ability to run .exe files automatically by calling mono under the hood was Debian (and derivatives), by installing some system hook by default when mono packages are installed. Maybe Michael Franz is not using Debian? Or maybe that hook doesn't work for him because he's using a custom mono install (instead of debian packages)? I am using CentOS 6.5 with a locally built Mono installation. I have read about how you can modify the kernel to understand launching Mono applications - http://www.mono-project.com/Guide:Running_Mono_Applications - this was probably after I ran into this problem. If this has become a requirement to use Mono for development it should probably be documented somewhere. ___ 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 -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Recent xbuild fixes causing issues with finding mcs
Yes, but xbuild uses Process.Start, which automatically executes exe files using Mono. Not sure why that's failing on your machine. On 15 February 2014 22:13, Michael Franz mvfr...@gmail.com wrote: On Sat, Feb 15, 2014 at 10:02 PM, Michael Hutchinson m.j.hutchin...@gmail.com wrote: AFAIK something's wrong with the installation if $prefix/lib/mono/4.5/mcs.exe is missing. What does your $prefix/bin/mcs point to? It points to a binary that does not run on its own. bash-4.1$ ./lib/mono/4.5/mcs.exe --version bash: ./lib/mono/4.5/mcs.exe: cannot execute binary file but, if I run it with mono it will work. bash-4.1$ bin/mono ./lib/mono/4.5/mcs.exe --version Mono C# compiler version 3.2.7.0 Prior to the change, it was the mcs wrapper that was being executed, after the change, it is trying to run the .NET binary directly. The contents of mcs is: #!/bin/sh exec /opt/local/JenkinsBuilds/bin/mono $MONO_OPTIONS /opt/local/JenkinsBuilds/lib/mono/4.5/mcs.exe $@ On 15 February 2014 10:51, Michael Franz mvfr...@gmail.com wrote: On Sat, Feb 15, 2014 at 9:46 AM, Michael Franz mvfr...@gmail.com wrote: Hi, I see there have been a few changes to xbuild since February 10th, 2014. February 10th is the last time I was able to build my local C# project using mono head. This is a simple project that I have just started and am planing to build on both mono and .NET. The issue seems to be that xbuild has changed how it finds mcs. /opt/local/JenkinsBuilds/bin/mcs - /opt/local/JenkinsBuilds/lib/mono/4.5/mcs.exe - see below. My locally build mono install is in /opt/local/JenkinsBuilds and my builds are all run via Jenkins. The build process is: - use premake5 to generate Visual Studio 2012 project files (note I am using .net 4.5 specific features) - use xbuild to build - use mono version of nunit to test The working build out put was like this: + /opt/local/JenkinsBuilds/bin/xbuild QTS.sln XBuild Engine Version 12.0 Mono, Version 3.2.7.0 Copyright (C) 2005-2013 Various Mono authors Build started 2/10/2014 9:56:00 PM. __ Project /var/lib/jenkins/jobs/CI/workspace/QTS.sln (default target(s)): Target ValidateSolutionConfiguration: Building solution configuration Debug|Any CPU. Target Build: Project /var/lib/jenkins/jobs/CI/workspace/QTS/QTS.csproj (default target(s)): Target PrepareForBuild: Configuration: Debug Platform: AnyCPU Target GenerateSatelliteAssemblies: No input files were specified for target GenerateSatelliteAssemblies, skipping. Target GenerateTargetFrameworkMonikerAttribute: Skipping target GenerateTargetFrameworkMonikerAttribute because its outputs are up-to-date. Target CoreCompile: Tool /opt/local/JenkinsBuilds/bin/mcs execution started with arguments: /noconfig /debug:full /debug+ /optimize- /out:obj/Debug/QTS.dll Properties/AssemblyInfo.cs Utilities/Measurements/PerformanceStatistics.cs /target:library /define:DEBUG;TRACE /platform:AnyCPU /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/System.dll /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/System.Core.dll /warn:4 The broken build is now producing: + /opt/local/JenkinsBuilds/bin/xbuild QTS.sln XBuild Engine Version 12.0 Mono, Version 3.2.7.0 Copyright (C) 2005-2013 Various Mono authors Build started 2/15/2014 8:50:52 AM. __ Project /var/lib/jenkins/jobs/CI/workspace/QTS.sln (default target(s)): Target ValidateSolutionConfiguration: Building solution configuration Debug|Any CPU. Target Build: Project /var/lib/jenkins/jobs/CI/workspace/QTS/QTS.csproj (default target(s)): Target PrepareForBuild: Configuration: Debug Platform: AnyCPU Created directory bin/Debug/ Created directory obj/Debug/ Target CopyFilesMarkedCopyLocal: Copying file from '/opt/local/JenkinsBuilds/lib/mono/4.5/mscorlib.dll' to '/var/lib/jenkins/jobs/CI/workspace/QTS/bin/Debug/mscorlib.dll' Copying file from '/opt/local/JenkinsBuilds/lib/mono/4.5/mscorlib.dll.mdb' to '/var/lib/jenkins/jobs/CI/workspace/QTS/bin/Debug/mscorlib.dll.mdb' Target GenerateSatelliteAssemblies: No input files were specified for target GenerateSatelliteAssemblies, skipping. Target CoreCompile: Tool /opt/local/JenkinsBuilds/lib/mono/4.5/mcs.exe execution started with arguments
Re: [Mono-dev] Recent xbuild fixes causing issues with finding mcs
No, this is not the same as launching exe files directly from the OS using binfmt-misc. If you launch an exe file *from Mono's implementation of Process.Start*, Mono will detect managed executables and run them with Mono automatically. https://github.com/mono/mono/blob/master/mono/io-layer/processes.c#L808 On 16 February 2014 09:00, Michael Franz mvfr...@gmail.com wrote: On Sun, Feb 16, 2014 at 7:34 AM, Andrés G. Aragoneses kno...@gmail.com wrote: On 16/02/14 10:15, Michael Hutchinson wrote: ... which automatically executes exe files using Mono. Are you sure that statement applies to all distros? I read somewhere some time ago that the only distro so far that implemented the ability to run .exe files automatically by calling mono under the hood was Debian (and derivatives), by installing some system hook by default when mono packages are installed. Maybe Michael Franz is not using Debian? Or maybe that hook doesn't work for him because he's using a custom mono install (instead of debian packages)? I am using CentOS 6.5 with a locally built Mono installation. I have read about how you can modify the kernel to understand launching Mono applications - http://www.mono-project.com/Guide:Running_Mono_Applications - this was probably after I ran into this problem. If this has become a requirement to use Mono for development it should probably be documented somewhere. ___ 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 -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Recent xbuild fixes causing issues with finding mcs
AFAIK something's wrong with the installation if $prefix/lib/mono/4.5/mcs.exe is missing. What does your $prefix/bin/mcs point to? On 15 February 2014 10:51, Michael Franz mvfr...@gmail.com wrote: On Sat, Feb 15, 2014 at 9:46 AM, Michael Franz mvfr...@gmail.com wrote: Hi, I see there have been a few changes to xbuild since February 10th, 2014. February 10th is the last time I was able to build my local C# project using mono head. This is a simple project that I have just started and am planing to build on both mono and .NET. The issue seems to be that xbuild has changed how it finds mcs. /opt/local/JenkinsBuilds/bin/mcs - /opt/local/JenkinsBuilds/lib/mono/4.5/mcs.exe - see below. My locally build mono install is in /opt/local/JenkinsBuilds and my builds are all run via Jenkins. The build process is: - use premake5 to generate Visual Studio 2012 project files (note I am using .net 4.5 specific features) - use xbuild to build - use mono version of nunit to test The working build out put was like this: + /opt/local/JenkinsBuilds/bin/xbuild QTS.sln XBuild Engine Version 12.0 Mono, Version 3.2.7.0 Copyright (C) 2005-2013 Various Mono authors Build started 2/10/2014 9:56:00 PM. __ Project /var/lib/jenkins/jobs/CI/workspace/QTS.sln (default target(s)): Target ValidateSolutionConfiguration: Building solution configuration Debug|Any CPU. Target Build: Project /var/lib/jenkins/jobs/CI/workspace/QTS/QTS.csproj (default target(s)): Target PrepareForBuild: Configuration: Debug Platform: AnyCPU Target GenerateSatelliteAssemblies: No input files were specified for target GenerateSatelliteAssemblies, skipping. Target GenerateTargetFrameworkMonikerAttribute: Skipping target GenerateTargetFrameworkMonikerAttribute because its outputs are up-to-date. Target CoreCompile: Tool /opt/local/JenkinsBuilds/bin/mcs execution started with arguments: /noconfig /debug:full /debug+ /optimize- /out:obj/Debug/QTS.dll Properties/AssemblyInfo.cs Utilities/Measurements/PerformanceStatistics.cs /target:library /define:DEBUG;TRACE /platform:AnyCPU /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/System.dll /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/System.Core.dll /warn:4 The broken build is now producing: + /opt/local/JenkinsBuilds/bin/xbuild QTS.sln XBuild Engine Version 12.0 Mono, Version 3.2.7.0 Copyright (C) 2005-2013 Various Mono authors Build started 2/15/2014 8:50:52 AM. __ Project /var/lib/jenkins/jobs/CI/workspace/QTS.sln (default target(s)): Target ValidateSolutionConfiguration: Building solution configuration Debug|Any CPU. Target Build: Project /var/lib/jenkins/jobs/CI/workspace/QTS/QTS.csproj (default target(s)): Target PrepareForBuild: Configuration: Debug Platform: AnyCPU Created directory bin/Debug/ Created directory obj/Debug/ Target CopyFilesMarkedCopyLocal: Copying file from '/opt/local/JenkinsBuilds/lib/mono/4.5/mscorlib.dll' to '/var/lib/jenkins/jobs/CI/workspace/QTS/bin/Debug/mscorlib.dll' Copying file from '/opt/local/JenkinsBuilds/lib/mono/4.5/mscorlib.dll.mdb' to '/var/lib/jenkins/jobs/CI/workspace/QTS/bin/Debug/mscorlib.dll.mdb' Target GenerateSatelliteAssemblies: No input files were specified for target GenerateSatelliteAssemblies, skipping. Target CoreCompile: Tool /opt/local/JenkinsBuilds/lib/mono/4.5/mcs.exe execution started with arguments: /noconfig /debug:full /debug+ /optimize- /out:obj/Debug/QTS.dll Properties/AssemblyInfo.cs Utilities/Math.cs Utilities/Measurements/PerformanceStatistics.cs obj/Debug/.NETFramework,Version=v4.5.AssemblyAttribute.cs /target:library /define:DEBUG;TRACE /nostdlib /platform:AnyCPU /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/System.dll /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/System.Core.dll /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/mscorlib.dll /warn:4 /opt/local/JenkinsBuilds/lib/mono/4.5/Microsoft.CSharp.targets: error : Error executing tool '/opt/local/JenkinsBuilds/lib/mono/4.5/mcs.exe': I checked the commit logs, and it looks like there are commits that would affect this behavior. Now, it might be that I was doing something wrong from the start and now I need to fix the process, but it seems like a simple process. e753ca2 Michael Hutchinson [xbuild] Fix dependency in C# targets c197478 Michael Hutchinson
Re: [Mono-dev] sub-process invocation on posix
FWIW, you actually just need to double quote each argument and escape
double quotes so you can very easily write a helper to do this in a way
that works on both Mono and .NET:
static Process StartProcess (string name, params string[] args)
{
string a = null;
if (args != null args.Length 0)
a = \ + string.Join (args.Select (s = s.Replace (\,
\\\)).ToArray (), \ \) + \;
return Process.Start (
new ProcessStartInfo (name, a) {
ShellExecute = false,
}
);
}
Obviously this could be done more efficiently with a StringBuilder.
Apologies for any errors, I'm writing this on my phone...
- Michael
On Jun 6, 2013 1:18 PM, Ian Norton inor...@gmail.com wrote:
Hiya, I'm aware that I can use Process.Start() but I'd really really like
to be able to directly pass a list of strings to my child process as
arguments rather than having to escape shell characters and spaces etc.
Ie, In perl or C I'd do:
system(df,-m,/home/foo/Documents/Pictures/My Holiday);
Where in c# I'm forced to escape the space - My\ Holiday
Ian
___
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] ASP.NET Xarmin - GSoC 2013
On 21 April 2013 14:09, Rauf Butt raufb...@gmail.com wrote: Hi All, Thanks for your valuable input. I had gone through MonoDevelop source code, documentation and the requirements that were mentioned in the previous emails. Based on the study, I have come across the following features of ASP.NET to be incorporated into MonoDevelop. *Run in Browser of choice *Run/debug support on Remote server These would be nice to have but are not enough to make a complete proposal. *Support for MVC3 *Support for Razor and Razor templates These have already been implemented. This is a very flexible project - I expect any student applying for it to look at the existing ASP.NET support in MonoDevelop and identify things that they would like to fix or improve to make it better. There is no set list of things to do - the items students choose to put in their proposal will demonstrate their understanding of what makes a good development experience :) -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Reference to System.Data.Entity in monodevelop trunk
On 15 September 2012 13:07, Steven Boswell II ulat...@yahoo.com wrote: After building and installing a Fedora Core 17 RPM for the trunk version of mono, I tried to do the same for the trunk version of monodevelop. When I tried to install the new monodevelop RPM, it reported a failed dependency of mono(System.Data.Entity) = 4.0.0.0. Latest mono doesn't have a System.Data.Entity in its .NET 4.0 assemblies. The enclosed patch shows my attempt to remove all references to System.Data.Entity, but it didn't work. For now, I forced the install by adding --nodeps to my RPM install command line. So far, monodevelop is running, but I haven't beaten it up very much yet. Just an FYI for the monodevelop maintainers, and cc'd to the mono-devel list in case System.Data.Entity was supposed to be there. That's a bug in the Fedora packages, you should report it to the Fedora packagers. MD does not depend on System.Data.Entity. The patch is incorrect, that's simply MD's definition of what is expected to be in certain target frameworks but does not affect its actual dependencies at all. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Show Linux . hidden directories
On 12 June 2012 17:40, Rob Wilkens robwilk...@gmail.com wrote: Well, as much as i would like to take a guess at an answer, my suggestion is to contact the Duplicati developers rather than the mono developers. They would know what they used as a 'file browser' and what the options it has are. Probably Windows Forms. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Current Implementation of Async Sockets
On 16 May 2012 16:33, longway77 longwa...@gmail.com wrote: Hi, I am currently doing some research on the best platform for a high performance socket server. I want it to be capable of handling a large number of small requests and a high number of Clients at the same time. So far I've read, that I/O Completion Ports are implemented pretty well under Windows but Linux seems to use another model. In some other thread I found, that implementation was a rather badly performing wrapper in Mono under Linux. Has this changed in the last time? Is it good to use Mono for that purpose or should I rather stick with Java? I'm also thinking of going the C++ way, but I'm not yet sure if the result would justify the additional work. It's possible, see https://github.com/jacksonh/manos -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Question about GSoC projects
On 21 March 2012 09:37, qqq qqq tupieur...@gmail.com wrote: I preview Mono GSoC projects list and pre-select some of them: Make ASP.NET Awesome in MonoDevelop A Sweet HTML/Text Editor Modul C# Refactorings Can someone say about difficult of this projects and what problems will i meet? I also would be glad if you would advise another project from Mono projects list. We can certainly answer specific questions if you're having trouble figuring things out, but you'll need to be able to do some research/investigation yourself in order to write a good proposal. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] GSoC 2012 - GTK# App
On 21 March 2012 17:56, homerf44 szbad...@gmail.com wrote: Hi, I would like to take part in GSoC this year. During my research i had found many interesting projects, but only one truly got my attention: GTK# Applications Mono is something new to me. To be honest, today i used it for the first time :) (but i heard about it though) To the point: My head is usually full of concepts, two for starters 1.Application better life which will help people in fields such as: -planning home budget, -sport (training planner etc), -diet planner -maybe some plugin for social networks -... example of use case: User want to lose a little bit weight. Application will help people turn their motivation into the regular training. So, user chooses a 'sport' from menu, then he sets the training program (maybe by himself, maybe there will be some prepared a priori) and from now, he will be reminded about events that are in his plan User sets home budget planner with his personal data such as salary and loans. He wants to save 10% of his salary this month. Application will measure how much money user can spent daily that at the end of month he will have 10% of salary saved. ... 2. Entertain me! application which will be perfect for procrastination time :) Application will search Internet for interesting informations, pictures, news etc. (this is very wide area to discuss) ... I will make some concept sketches later, maybe that will help clarify my ideas. About me: My name is Simon and i was born 23 years ago. I'm studying at Gdansk University of Technology (Poland). I have an engineer(bachelor) degree, and i am still learning to gain MSc. I'm using Fedora/Ubuntu/Windows. I know c# c++ c python java , but i am open-minded person and i am eager to learn something new :) As you can see I am not a native speaker and i hope that we will understand each other. :) You're certainly welcome to submit this proposal, but you should be aware that the bar for new applications like this is much higher, since you have to argue that the app is viable and needed as well as demonstrating your ability to implement it. Note also that you can submit multiple proposals, if there are other projects that interest you. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [MonoDevelop] GSoC Application 2011 for Axiom
Hi, Applications must be made directly to the Google GSoC site, and should include a project proposal. If you are having trouble finding ideas for the project, I suggest you approach the Axiom developers on their mailing list or IRC. - Michael On Wed, Apr 6, 2011 at 8:23 PM, Shivansh Srivastava shivansh.b...@gmail.com wrote: Hi, I have been interacting frequently on the monodevelop mailing list, but havnt got a chance to discuss any idea regarding Building/developing apps with Axiom engine. Also, i am not able to join the mono...@googlegroups.com googlegroup, where they could really help me. Kindly find attached my application for GSoC 2011. I have a sound experience in developing apps/games in C# using XNA Framework (3.0, 3.1, 4.0) for Windows Windows Phone 7. I have compiled/built OGRE am going through its code for better understanding. I dont have any idea(s) as such, but would really appreciate if any mentor would guide me help me with how I can help in the development. I would be glad to help in the development of Axiom Engine. I really apologise for submitting my Application this late. I had a few family problems/commitments that I had to take care of. Waiting for a reply. With regards, Shivansh. -- Shivansh Srivastava | +91-955-243-5407 | shivansh.b...@gmail.com 2nd Year Undergraduate | B.E. (Hons.) - Electronics Instrumentation BITS-Pilani. ___ Monodevelop-list mailing list monodevelop-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monodevelop-list -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] GSOC MonoDevelop Project
On Tue, Apr 5, 2011 at 1:28 PM, darshan.modani88 darshan.modan...@gmail.com wrote: Hiii, I am Darshan Modani, a Computer Science a graduate student. I am GSOC aspirant. I consider myself to be good in C# and thats what my area of interest is. Until GSOC list of accepted organisations was released i didn't knew about Mono-project. I really feel the concept and idea is great. I installed my mono-framework on mac-osx, and was amazed to find ASP.NET working on mac. I am very much interested in mono-project and would like to contribute. Browsing through the list of project ideas, i found that improvements in mono-develop IDE interests me such as Webkit based HTML editor, CSS support or JS support. I clearly understand the project requirements but still very skeptic. I am proficient in C# but very new to mono. Any suggestions and some pointers before applying would be greatly appreciated. Also I want to know the mentors of the projects Webkit based HTML editor, CSS support or JS support under Web Tools. There isn't a pre-assigned mentor, you should apply and if a mentor likes your proposal they will pick it up. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Faster
On Thu, Mar 24, 2011 at 12:51 PM, Rodrigo Kumpera kump...@gmail.com wrote: Now onto the null check. Such a null check will exploit a cpu feature known as branch prediction, which guesses the outcome of the conditional jump. Since in the majority of the cases the value won't be null, the cpu can pretend the branch doesn't exist and keep executing as it was not taken. This means the null check costs virtually nothing on a modern cpu. Could we have the JIT recognize the if (foo == null) throw ... pattern and add a branch hint? -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] GSoC 2011 - Interest
On Thu, Mar 17, 2011 at 12:35 PM, Abdul Rauf raufb...@gmail.com wrote: Dear Team Mono, I am very excited to contribute in open source community through the platform of Google Summer of Code 2011. I have visited the web page of “Mono” at http://mono-project.com/Gsoc and have seen project ideas for GSoC 2011. I am interested in two projects. The reason for my interest is that I have previously worked on .NET related projects both in VB and C# and want to develop skills of IDE development. I am writing you to let you know my understanding of the project and required knowledge of technologies. I would like your feedback on it. My understanding of the requirements is as follows: “Debugger Visualizer” 1. Implement a debugger visualizer (Can “Debugger Visualizer” template from .NET framework be used?) There is no debugger visualizer infrastructure in .NET, only VS, and MD doesn't implement the VS API. MD has its own visualizer infrastructure. 2. A DataType assembly will be loaded into the debugger visualizer at runtime and display the desired properties in a presentable form. That sounds like more like the DebuggerTypeProxy. That's also a possible GSoC project, but would have to take place in the Mono framework, not the MonoDevelop IDE. 3. I need to specify which visualizers are to be implemented. Yes, this is only an idea for a GSoC project. You would have to define a project that is big enough for the GSoC period, and it can consist of several smaller tasks, such as a number of different visualizers, or you could find other debugger enhancements and combine them into the project. You'd need to describe what visualizers you want to create, explain why they're useful, and so on. “Translation Resources Editor” 1. Implement an editor for different language resources to help people edit resources files without modifying XML files directly. 2. The program should load strings from .resx file and provide an interface to enter the required translations. Also, it says Should extend or share code with the Gettext addin. I am not quite sure about this at the moment. Does it mean that this Resource Editor is required to be integrated with Gettext? Any help is appreciated in this regard. MonoDevelop already has a Translation addin, which has a GUI for editing Gettext translation catalogs. The idea here is that the resx translation editor would be able to re-use some of the code (particularly some of the GUI) from the Gettext addin. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] GSoC 2011 - Documentation Addin
On Sat, Mar 19, 2011 at 7:22 PM, zur13 zur...@i.ua wrote: Hi Team Mono I want to take part in Documentation Addin project. I think that work in your team will be very exciting experience. I want to get skills in IDE programming and to familiarize with basics of code parsing and automation of documentation processing. What is final result should look like (this is only my point of view and I likely discuss it): it will be the interractive pad, that will show the part of documentation for the current (under or nearest to the text cursor) part of code and provide basic text editing features and maybe feature of template generating document for the current part of code if it hasn`t documentation yet. Yes, there are a bunch of different ideas in this area. The project is essentially to improve MD's support for documentation. As it is, there are two kinds of documentation: * inline XML doc comments * MonoDoc files MD supports XML doc comments pretty well, though it could be improved. However, MD has no support for creating or editing MonoDoc documentation. So the project could consist of any combination of the following: * a documentation project type, for creating and compiling MonoDoc docs * the pad you mentioned, for editing MonoDoc docs * nicer editing support for XML doc comments * a pad for displaying and browsing docs, regardless of source * some integration/unification between MonoDoc and XML docs Rough workplan: * Observe MonoDoc and MonoDevelop parsing interfaces, maybe fix some bugs (5-7 days) * Observe MonoDevelop addin architectures and design general Documentation Addin architecture (7-12 days) * Coding * Tests and bugfix (18 days) * Prepare Documentation (5 days) FWIW, I'm wary of any project proposal that begins with periods of planning/design/research - ideally, such stuff should be done when creating the proposal, so we have a good idea of what you'll be doing. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] PDB native support in C from C# open source project
On Mon, Mar 7, 2011 at 9:41 AM, David Marsh dmars...@hotmail.com wrote: Ref :- http://www.mono-project.com/StudentProjects#Native_support_for_PDB I'd be interested in contributing in this area, is it still an open item ? I believe so, yes. It would be particularly interesting to add full support for the local mappings that pdb has for nested scopes and iterator scopes, and propagate that information into the soft debugger, since Mono's mdb format doesn't currently support those. That would help to fix a few problems we have right now in the debugger - inspecting captured variables in anonymous delegates and iterators, and inspecting multiple variables with the same name in sub-scopes of a single method. We could then either propagate those features back into the mdb format, or switch to pdb entirely. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Git line-ending issues
On Fri, Jan 7, 2011 at 2:17 AM, st...@free.fr wrote: Alright. But my main question was about what I should do specifically about the commit I mentioned. Should I restore the line endings to what they were, or leave things as is? Or does it not matter either way? Thanks. I don't know that I can make the call which way it should go. Reverting it won't help history now it's in the main repo, so maybe it makes sense to leave it as it is... but either way it should match the .gitattributes settings. Of course, that means you could either change the .gitattributes to match the file, or revert the file. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Git line-ending issues
On Thu, Jan 6, 2011 at 2:02 PM, Stifu st...@free.fr wrote: Hi guys, I'm having issues with a commit I did (d'oh :(), and would like help to clean up my mess. The commit can be seen here: https://github.com/mono/mono/commit/4d5451a61ce63769083ebad3b1a5d9055a27b6df I only removed a few lines in the file, but the whole file shows up as changed. From what I understand, this is due to a difference in line-ending encoding. Looking at the .gitattributes file in the same folder, I see certain files (including the one I modified) are specified as having a certain line-ending encoding (CRLF). The .gitattributes format is rather unintuitive. crlf means the file is stored as lf in the repo, but converted to/from crlf on windows. -crlf explicitly disables conversions, in case the user has autoconversion enabled for all files. Are you perhaps using a git tools that ignores these attributes? -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Git line-ending issues
On Thu, Jan 6, 2011 at 3:38 PM, st...@free.fr wrote: No, shamefully I thought I could get away with directly editing the file from the GitHub web interface (which actually works fine with files that aren't -crlf). I'll refrain from doing so in the future, as I guess it's not recommended (can't even preview). Do you have an opinion about how I should fix this issue (if there is actually anything to fix)? Don't use tools that autoconvert and ignore .gitattributes. And aren't all those files defined in the .gitattributes file only there for historical reasons, rather than being something desirable? I wouldn't mind going through files (WinForms only, in my case) to convert them all to the same format, if it's something that sounds any good. Conversion without a good reason is bad because it adds a ton of noise to history, for example annotation.becomes ~useless. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Where should I install my pkg-config files on OS X?
On Tue, Oct 19, 2010 at 11:31 AM, Jackson Harper jack...@novell.com wrote:
On Mon, 2010-10-18 at 18:04 -0400, Michael Hutchinson wrote:
On Mon, Oct 18, 2010 at 10:58 AM, Jackson Harper jack...@novell.com wrote:
For libev-sharp I'm trying to follow the developer guidelines for
unstable API. Basically I create install my dll in
prefix/lib/libev-sharp/
Then to use libev-sharp projects should do:
cp `pkg-config --variable=Libraries Thing` build/.
The problem is on OS X I have no idea where libev-sharp should install
the libev-sharp.pc file. Using
pkg-config --variable=pc_path pkg-config | awk -F: '{print $1}'
doesn't really help, I get a garbage directory like /tmp/pkg-config
Should I just hardcode it to
'/Library/Frameworks/Mono.framework/Versions/Current/lib/pkgconfig/'
Beware that this whole directory will get replaced when you upgrade Mono.
For this reason, MonoDevelop 2.4.1 (and master) looks in
/Library/Frameworks/Mono.framework/External/pkgconfig and I'd like to
fix a future version of Mono to have its pkgconfig look there too.
I've added similar directories for MSBuild extensions and MonoDoc
docs called xbuild and monodoc, unsurprisingly. A gac would
probably be useful too.
Awesome! But just so I am clear, xbuild in mono 2.8 does not support
this feature yet, right?
Correct, not unless you do as MD does:
export
PKG_CONFIG_PATH=/Library/Frameworks/Mono.framework/External/pkgconfig:$PKG_CONFIG_PATH
--
Michael Hutchinson
http://mjhutchinson.com
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Where should I install my pkg-config files on OS X?
On Mon, Oct 18, 2010 at 10:58 AM, Jackson Harper jack...@novell.com wrote:
For libev-sharp I'm trying to follow the developer guidelines for
unstable API. Basically I create install my dll in
prefix/lib/libev-sharp/
Then to use libev-sharp projects should do:
cp `pkg-config --variable=Libraries Thing` build/.
The problem is on OS X I have no idea where libev-sharp should install
the libev-sharp.pc file. Using
pkg-config --variable=pc_path pkg-config | awk -F: '{print $1}'
doesn't really help, I get a garbage directory like /tmp/pkg-config
Should I just hardcode it to
'/Library/Frameworks/Mono.framework/Versions/Current/lib/pkgconfig/'
Beware that this whole directory will get replaced when you upgrade Mono.
For this reason, MonoDevelop 2.4.1 (and master) looks in
/Library/Frameworks/Mono.framework/External/pkgconfig and I'd like to
fix a future version of Mono to have its pkgconfig look there too.
I've added similar directories for MSBuild extensions and MonoDoc
docs called xbuild and monodoc, unsurprisingly. A gac would
probably be useful too.
--
Michael Hutchinson
http://mjhutchinson.com
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Process SIGSEGV on Mono 2.8p6
On Tue, Oct 5, 2010 at 2:12 AM, Chuck Esterbrook chuck.esterbr...@gmail.com wrote: On Tue, Sep 28, 2010 at 2:00 PM, Miguel de Icaza mig...@novell.com wrote: Hello Chuck, Could you make a simple test case from this program? Something is calling Process to run a program, and this is where the problem is, a test case would be very useful. I totally agree, but have not been able to create a standalone test case. If I come up with something, I'll post again. This issue should have been fixed by a couple of recent commits: http://github.com/mono/mono/commit/579a0ca72b996d11a50ddf6ddb4f67e59995072d http://github.com/mono/mono/commit/3b6f5c33088c53280980218f82168e3cba00a25b -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] IL-based regex engine
On Tue, Aug 24, 2010 at 1:54 AM, Eddy Zavaleta e...@mictlanix.org wrote: Hi, My name is Eddy Zavaleta I'm currently a senior in college at Instituto Politécnico Nacional in Mexico. I need to make a final project to gradute and I'm looking for something to work on. I have been an floss enthusiast for many years especially for GNOME/Mono projects so I would like to make some contribution to Mono. I just check the ToDo list in the mono-project site and I'm interested in the regular expression engine. Anyone can give me additional information about this task, some recomendations about what path I should take. I would appreciate any help with this. Hi, Unfortunately the ToDo list is out of date - the IL Regex engine exists now, though it has bugs. What kinds of things are you interested in working on? -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] debug embedded mono
On Fri, Aug 6, 2010 at 9:54 AM, marcus julius marcus...@yahoo.com wrote: I have a C++ application that uses C sharp classes which also use C++ functions. Thus, both C++ and C sharp call each other, but main project that I run is C++. The question is how to debug this project? I tried to create a dummy start up C sharp project and call my C sharp code from there. The mono debugger works for the C sharp code, but it does not find the C++ functions that are called from within C sharp. MethodNotImplemented exception is thrown. The mono debugger does not work on C++ and regular debugger cannot access to the Mono code in C sharp. So, any information on how to do it? It's not possible to do mixed-mode debugging with Mono, i.e debug C# and C++ simultaneously. However, you can debug C# code within an embedding host. To do so, the host must initialize the Mono Soft Debugger. This causes the debugger in the Mono runtime to make a TCP connection to an IDE. You can create a simple addin in MonoDevelop to cause it to listen for a debuggee and start a debugging session. For some examples, check the mono-osx list archives. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Make mono_dl_register_library into a fallback
On Tue, Jul 13, 2010 at 9:51 AM, Paolo Molaro lu...@ximian.com wrote: On 07/02/10 Michael Hutchinson wrote: This interface is not suitable as a fallback mechanism, it would be too cumbersome to use and it's probably not ideal even for its intended purpose. What about a callback registration system instead? The intended purpose, AFAIK, is to expose statically linked libraries to P/Invoke. That's what I'm using it for, and it's very straightforward to use this way. I have a trivial C# tool that reflects over the library with the P/Invokes and dumps the mappings to source files. The interface was just a quick hack from Miguel, in fact is has never been exposed as public API as you found out (it was only possible to use it in a custom mono build for consoles). If you have a tool generating the table now, changing it to generate the function needed by the new interface should be trivial, anyway. It was published in the 2.6 headers, though the actual functionality did not work in normal builds. My patch isn't intended to provide a generic dynamic linker fallback. But it does change the code to fallback and you want to publish the API, so then we're stuck with an unsuitable API for a new feature. It's meant to provide an easy way to P/Invoke statically linked libraries for all embedders, not just those on platforms without dynamic linkers. If you have a working dynamic linker using DllImport (__Internal) is the way to go. Only if your dynamic linker supports looking up symbols in __Internal (NULL). The Android one does not, and if you have non-PIC static libraries the Windows one does not either. That's certainly more flexible, but I'm not convinced it's necessary at this time without concrete use cases. If we're going to include the If you don't have concrete cases, why are you expanding the functionality of the quick and dirty (and non-public) API? I did describe a concrete use case for my solution - being able to P/Invoke static libraries on the aforementioned major platforms. Without my patch this is currently impossible. I have been using it for this just fine. Your solution is a more cumbersome solution for my problem, and does not solve other concrete use cases. old interface anyway - else we make embedders responsible for reimplementing its functionality - then why not go this path for now, and reimplement it on top of the callbacks later? Because it means exposing an API and attaching to it functionality it's not suited for. The tricks you mention could be much more useful if callbacks could intercept lookups for individual symbols, rather than acting as a fallback for handling whole libraries. But this would require much more substantial changes to the dynamic linker code. A separate API entry point could be added for that. To recap: *) that API was never public. *) I'm not comfortable with publishing that API and supporting it with the fallback functionality. *) if we need a fallback mechanism something like my proposed interface is much better and I think is suitable for publishing (maybe with an additional flags value to give a priority vs the existing lookups). Maybe, but my patch exists, and cleanly repurposes existing functionality to fix an existing limitation. Implementing your proposed solution properly (especially with symbol granularity rather than library granularity) would require a much more substantial amount of work. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Make mono_dl_register_library into a fallback
On Fri, Jul 2, 2010 at 12:38 PM, Michael Hutchinson m.j.hutchin...@gmail.com wrote: On Fri, Jul 2, 2010 at 6:18 AM, Paolo Molaro lu...@ximian.com wrote: On 07/01/10 Michael Hutchinson wrote: The mono_dl_register_library function can currently be used to register P/Invoke mappings for platforms that do not have a dynamic linker. The attached patch makes it also function as a fallback when the system's dynamic linker cannot resolve the library, so that it is always available to embedders. I'll also need to restore mono/utils/mono-embed.h to the public headers in the autotools build (but this patch was created using MSVC on Windows). OK to commit to trunk? This interface is not suitable as a fallback mechanism, it would be too cumbersome to use and it's probably not ideal even for its intended purpose. What about a callback registration system instead? The intended purpose, AFAIK, is to expose statically linked libraries to P/Invoke. That's what I'm using it for, and it's very straightforward to use this way. I have a trivial C# tool that reflects over the library with the P/Invokes and dumps the mappings to source files. My patch isn't intended to provide a generic dynamic linker fallback. It's meant to provide an easy way to P/Invoke statically linked libraries for all embedders, not just those on platforms without dynamic linkers. It is more flexible as a fallback since it doesn't require to register upfront all the possible names and load the all functions at startup. It's likely better also for the original purpose when, for example, even if dynamic linking is not possible it is possible to lookup a symbol at runtime. It opens up the possibility of also generating the code at runtime (for redirecting some win32 p/invokes to winforms for example, or other tricks). Something along these lines: typedef void* (*MonoDlFallbackLoad) (const char *name, int flags, char **err, void *user_data); typedef void* (*MonoDlFallbackSymbol) (void *handle, const char *name, char **err, void *user_data); typedef void* (*MonoDlFallbackClose) (void *handle, void *user_data); void mono_dl_register_fallback (MonoDlFallbackLoad load_func, MonoDlFallbackSymbol symbol_func, MonoDlFallbackClose close_func, void *user_data); The old interface could be easily implemented on top of this new one (though we likely could drop it as well). That's certainly more flexible, but I'm not convinced it's necessary at this time without concrete use cases. If we're going to include the old interface anyway - else we make embedders responsible for reimplementing its functionality - then why not go this path for now, and reimplement it on top of the callbacks later? Any comment on this? I'd really like to get this functionality merged ASAP, as other people depend on it, and the patch is getting stale. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] base call hoisting (error) and MonoDevelop w/Moonlight
On Fri, Jul 9, 2010 at 5:31 PM, ted leslie tles...@tcn.net wrote: I have built a successful gtk-sharp-2-12-branch mcs mono mono-addins mono-basic moon from:: co svn://anonsvn.mono-project.com/source/trunk/ but on the monodevelop I get errors: This error: ./MonoDevelop.AspNet.Gui/AspProjectDom.cs(91,50): error CS0584: Internal compiler error: base call hoisting ./MonoDevelop.AspNet.Gui/AspProjectDom.cs(91,25): error CS1579: foreach statement cannot operate on variables of type `object' because it does not contain a definition for `GetEnumerator' or is not accessible [trimmed] Since the hoist error effects the GetToolsPath in Moonlight (in MD), it may be the reason for my MD moonlight build issue. If not, then there seems to be two seperate issues. The fact that MD errors once, then not the next time, and appears to generate a successful moonlight app, only to have to give a blank plugin (in browser), probably isn't correct behavior, even if I somehow F'd up my install? (check for empty *.g.resources file?) (but I like to think I did the install like anyone else would have). The root of the problem is a C# compiler bug (Internal error) in mcs trunk. It's likely there other issues are knock-on effects - maybe your workaround is returning bad values. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Make mono_dl_register_library into a fallback
On Fri, Jul 2, 2010 at 6:18 AM, Paolo Molaro lu...@ximian.com wrote: On 07/01/10 Michael Hutchinson wrote: The mono_dl_register_library function can currently be used to register P/Invoke mappings for platforms that do not have a dynamic linker. The attached patch makes it also function as a fallback when the system's dynamic linker cannot resolve the library, so that it is always available to embedders. I'll also need to restore mono/utils/mono-embed.h to the public headers in the autotools build (but this patch was created using MSVC on Windows). OK to commit to trunk? This interface is not suitable as a fallback mechanism, it would be too cumbersome to use and it's probably not ideal even for its intended purpose. What about a callback registration system instead? The intended purpose, AFAIK, is to expose statically linked libraries to P/Invoke. That's what I'm using it for, and it's very straightforward to use this way. I have a trivial C# tool that reflects over the library with the P/Invokes and dumps the mappings to source files. My patch isn't intended to provide a generic dynamic linker fallback. It's meant to provide an easy way to P/Invoke statically linked libraries for all embedders, not just those on platforms without dynamic linkers. It is more flexible as a fallback since it doesn't require to register upfront all the possible names and load the all functions at startup. It's likely better also for the original purpose when, for example, even if dynamic linking is not possible it is possible to lookup a symbol at runtime. It opens up the possibility of also generating the code at runtime (for redirecting some win32 p/invokes to winforms for example, or other tricks). Something along these lines: typedef void* (*MonoDlFallbackLoad) (const char *name, int flags, char **err, void *user_data); typedef void* (*MonoDlFallbackSymbol) (void *handle, const char *name, char **err, void *user_data); typedef void* (*MonoDlFallbackClose) (void *handle, void *user_data); void mono_dl_register_fallback (MonoDlFallbackLoad load_func, MonoDlFallbackSymbol symbol_func, MonoDlFallbackClose close_func, void *user_data); The old interface could be easily implemented on top of this new one (though we likely could drop it as well). That's certainly more flexible, but I'm not convinced it's necessary at this time without concrete use cases. If we're going to include the old interface anyway - else we make embedders responsible for reimplementing its functionality - then why not go this path for now, and reimplement it on top of the callbacks later? The tricks you mention could be much more useful if callbacks could intercept lookups for individual symbols, rather than acting as a fallback for handling whole libraries. But this would require much more substantial changes to the dynamic linker code. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Extract mono_exception_get_message_string from mono_print_exception
On Fri, Jul 2, 2010 at 6:28 AM, Paolo Molaro lu...@ximian.com wrote: On 07/01/10 Michael Hutchinson wrote: The attached patch adds a new mono_exception_get_message_string function to the Mono public API, extracted from mono_print_exception. This makes it possible for embedders easily to convert exceptions to strings without printing them and without using private API. It is already possible to use the embedding API to get the same result without using any private API, of course. My bad, I hadn't found mono_get_exception_class. Anyway, we can certainly add an helper method, but it should be more general: MonoString *mono_object_to_string (MonoObject *obj, MonoObject **exc); Note that it works for any object and that it allows the user to handle exceptions thrown from the implict method invocation. The result can be used as is or mono_string_to_utf8 () can be called on Implemented - new patch attached. I also made mono_string_to_utf8_checked public, as mono_string_to_utf8 is marked deprecated. -- Michael Hutchinson http://mjhutchinson.com mono-print-exception.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Extract mono_exception_get_message_string from mono_print_exception
On Fri, Jul 2, 2010 at 3:13 PM, Michael Hutchinson m.j.hutchin...@gmail.com wrote: On Fri, Jul 2, 2010 at 6:28 AM, Paolo Molaro lu...@ximian.com wrote: ... Anyway, we can certainly add an helper method, but it should be more general: MonoString *mono_object_to_string (MonoObject *obj, MonoObject **exc); Note that it works for any object and that it allows the user to handle exceptions thrown from the implict method invocation. The result can be used as is or mono_string_to_utf8 () can be called on Implemented - new patch attached. I also made mono_string_to_utf8_checked public, as mono_string_to_utf8 is marked deprecated. I just noticed that the definition in object.h should be mono_object_to_string, not mono_object_get_string. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Extract mono_exception_get_message_string from mono_print_exception
On Fri, Jul 2, 2010 at 3:43 PM, Robert Jordan robe...@gmx.net wrote:
You can get rid of the loop and optimize it further by caching
System.Object's ToString method:
MonoString *
mono_object_to_string (MonoObject *obj, MonoObject **exc)
{
static MonoMethod *to_string = NULL;
MonoMethod *method;
g_assert (obj);
if (!to_string)
to_string = mono_class_get_method_from_name_flags
(mono_get_object_class (), ToString, 0, METHOD_ATTRIBUTE_VIRTUAL |
METHOD_ATTRIBUTE_PUBLIC);
method = mono_object_get_virtual_method (obj, method);
return (MonoString *) mono_runtime_invoke (method, obj, NULL, exc);
}
Makes sense - I'm not familiar with Mono runtime API, and I'd just
lifted code directly from mono_print_exception.
I've folded this into my patch (with the to_string fix), added
Changelogs, and updated the utils Makefile.am to install mono-error.h.
OK to commit now?
--
Michael Hutchinson
http://mjhutchinson.com
mono-print-exception.diff
Description: Binary data
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Extract mono_exception_get_message_string from mono_print_exception
The attached patch adds a new mono_exception_get_message_string function to the Mono public API, extracted from mono_print_exception. This makes it possible for embedders easily to convert exceptions to strings without printing them and without using private API. OK to commit to trunk? -- Michael Hutchinson http://mjhutchinson.com mono-print-exception.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Make mono_dl_register_library into a fallback
The mono_dl_register_library function can currently be used to register P/Invoke mappings for platforms that do not have a dynamic linker. The attached patch makes it also function as a fallback when the system's dynamic linker cannot resolve the library, so that it is always available to embedders. I'll also need to restore mono/utils/mono-embed.h to the public headers in the autotools build (but this patch was created using MSVC on Windows). OK to commit to trunk? -- Michael Hutchinson http://mjhutchinson.com mono-dl-map.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Extract mono_exception_get_message_string from mono_print_exception
On Thu, Jul 1, 2010 at 3:44 PM, Michael Hutchinson m.j.hutchin...@gmail.com wrote: The attached patch adds a new mono_exception_get_message_string function to the Mono public API, extracted from mono_print_exception. This makes it possible for embedders easily to convert exceptions to strings without printing them and without using private API. OK to commit to trunk? On second thoughts, mono_exception_to_string is a better name. Also, mono_free, as defined in mono-publib.h, does not seem to exist, so as an embedder it's currently not possible to free the returned string. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Extract mono_exception_get_message_string from mono_print_exception
On Thu, Jul 1, 2010 at 8:06 PM, Michael Hutchinson m.j.hutchin...@gmail.com wrote: Also, mono_free, as defined in mono-publib.h, does not seem to exist, so as an embedder it's currently not possible to free the returned string. Oh, false alarm, it seems the problem is that mono-publib.c isn't included in the MSVC project. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Standard name for mcs
On Sun, Jun 27, 2010 at 4:29 PM, Russell Wallace russell.wall...@gmail.com wrote: On Sun, Jun 27, 2010 at 9:22 PM, Mark de Bruijn | Dykam kram...@gmail.com wrote: The problem is that not all version of C# are completely backwards compatible themselves. I was under the impression Microsoft were being very careful about maintaining backward compatibility in both the language and the library. If that fails, it's basically going to be a choice between going back to Java (which I'd rather not do) or back to C++ (which I'd really rather not do). What backward compatibility bugs do you know of? And for some reason I am still missing the point. Mono going to 4.0 just means dmcs is available. Well, as of 2.4.4, gmcs is available but now mcs is _not_ available in the standard distribution. I infer from that, that once dmcs becomes available, gmcs will likewise stop being available in the standard distribution. Is that not the case? I.e. is there going to be a change of policy in this regard? If so, that would be an adequate solution. No, mcs has been included in *all* released versions of Mono to date. It will only be removed in 2.8, about 5-6 years after the addition of gmcs. I suspect your problem is the fact that Debian/Ubuntu breaks up Mono into many tiny packages in order to minimize install size of applications for end-users, and this unfortunately means that developers often don't find things that they'd expect to be in a normal Mono installation. You likely need to install the mcs package (no idea what the package name is though). -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gstreamer-sharp problems
On Mon, May 31, 2010 at 5:28 PM, rasive ras...@gmail.com wrote: Could someone at least point me in the right direction? A working example would be sufficient, i have tried a lot of ways, but none seems to work. What version are you using? There was an unfinished gstreamer-sharp floating around for several years, and only relatively recently was the effort resumed. I would recommend building the latest from source and trying the included samples. http://gstreamer.freedesktop.org/modules/gstreamer-sharp.html -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Cannot compile monodebugger with mono from svn trunk
On Sat, May 29, 2010 at 3:10 PM, xplicit s...@ngs.ru wrote: In monodevelop 2.2 I don't see 'Run With Mono Soft Debugger' only 'Run With Mono Debugger'. In prefered debuggers I see: Mono Debugger, Mono Debugger for ASP.NET, GNU Debugger (GDB). Monodevelop 2.2 was installed from Ubuntu 10.04 repository and runs under mono 2.4. The soft debugger commands are only be enabled when you target Mono 2.6 or later, because the soft debugger was only added in Mono 2.6. However, you can target a Mono 2.6+ from a MD that's running on Mono 2.4 using MD's support for multiple target runtimes. However, Ubuntu removed the soft debugger addin from their MonoDevelop 2.2 build, because it includes a binary dll copied from Mono 2.6 :/ Also I have two parallel mono environment (mono 2.6.4 and mono 2.7) and tried to debug my applications with debugger from md 2.2 with no success. I did not try to recompile MD 2.2 from sources yet (shoud I recompile or maybe there is the way to add Soft Debugger to MD 2.2 without recompilation?) An unmodified MD 2.2 build has the soft debugger addin. You could try extracting the soft debugger addin dlls from the 2.2.2 rpms and manually installing them. But I tried to check out MD from trunk, recompiled it under mono 2.6.4 and software debbuger appeared in the list and I now can debug my app under 'Soft Debugger' both in the 2.6.4 and 2.7 mono environment. Generic mono debugger does not work with MD2.4 under mono 2.6.4 environment, throwing 'MissingMethod' exception when evaluating watch (DeclaringType in Mono.Debugger.Method). I don't know why this happens, I examined assembly, which monodevelop tries to load (Mono.Debugger.dll from /opt/mono26) and it seems, that the assembly has this method (if I understood right the output of monodis) I really don't know much about the MDB addin or whether it can work with multiple target Monos. You could try filing a bug or asking on the MD list. But if you have the soft debugger working, it's much more reliable anyway :) -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Cannot compile monodebugger with mono from svn trunk
On Tue, May 25, 2010 at 10:31 AM, xplicit s...@ngs.ru wrote: For me it does not matter, which debbuger to use. I just want to have the ablity to debug my applications in monodevelop with the latest mono. I tried to debug mono 2.7 application in monodevelop 2.2 without compiling and installing debugger, but I got the error: System.Runtime.Remoting.RemotingException: Tcp transport error. Server stack trace: at System.Runtime.Remoting.Channels.Tcp.TcpMessageIO.ReceiveMessageStatus (System.IO.Stream networkStream, System.Byte[] buffer) [0x0] at System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.ProcessMessage (IMessage msg, ITransportHeaders requestHeaders, System.IO.Stream requestStream, ITransportHeaders responseHeaders, System.IO.Stream responseStream) [0x0] at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage (IMessage msg) [0x0] Exception rethrown at [0]: --- System.Runtime.Remoting.RemotingException: Connection closed at System.Runtime.Remoting.Channels.Tcp.TcpMessageIO.StreamRead (System.IO.Stream networkStream, System.Byte[] buffer, Int32 count) [0x0] at System.Runtime.Remoting.Channels.Tcp.TcpMessageIO.ReceiveMessageStatus (System.IO.Stream networkStream, System.Byte[] buffer) [0x0] --- End of inner exception stack trace --- at System.Runtime.Remoting.Channels.Tcp.TcpMessageIO.ReceiveMessageStatus (System.IO.Stream networkStream, System.Byte[] buffer) [0x0] at System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.ProcessMessage (IMessage msg, ITransportHeaders requestHeaders, System.IO.Stream requestStream, ITransportHeaders responseHeaders, System.IO.Stream responseStream) [0x0] at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage (IMessage msg) [0x0] this is was the reason why I try to compile debugger with mono 2.7 You got this message from running the debugger? I can see how something like that could happen if you used an old version of MDB with MD... but it shouldn't happen with the soft debugger. Do you have the menu option Run-Run with-Mono Soft Debugger? -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Cannot compile monodebugger with mono from svn trunk
On Mon, May 24, 2010 at 2:56 PM, xplicit s...@ngs.ru wrote: I tried to compile monodebugger with mono from trunk and could not. FWIW, are you sure you want MDB? Since Mono 2.6 there's a new SDB debugger built into the Mono runtime by default, which MonoDevelop 2.2 supports by default without any extra addins. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono debugger
On Wed, May 12, 2010 at 2:03 PM, sberryman sh...@golfsigma.com wrote: I don't have a parallel environment though. The trunk build is the only copy of mono running on the box. Alan's point about not mixing version still stands. And are you sure you want the MDB debugger? Mono 2.6+ has the SDB debugger built into the runtime. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Garbage Collection Issue?
On Thu, May 13, 2010 at 2:59 PM, Bryan Murphy bmurphy1...@gmail.com wrote: On Thu, May 13, 2010 at 12:07 PM, Matt Dargavel m...@shout-telecoms.com wrote: Finally, does anyone have any other suggestions on where else I should look / other diagnostics to try? You might want to try heap-buddy, although it's been quite some time since I've been able to get it to compile. http://www.mono-project.com/HeapBuddy There's also heap-shot, which works fine with 2.6, as long as you use a SVN revision from around the time 2.6 was branched. Heap-shot can be used to snapshot the heap and examine the objects that are there, what objects they reference, and what objects reference them. It can also show the difference between heap snapshots. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] MonoDevelop MoonLight debugger
On Tue, Apr 20, 2010 at 6:37 PM, Timothy Graupmann tgraupm...@yahoo.comwrote: I found a video on using the MonoDeveloper debugger with Moonlight. http://www.youtube.com/watch?v=GSUZRZWzTQM Apparently this works on Linux. I didn't have the same success on the mac. It requires Moonlight, not Silverlight. We don't have any way to access the SL debugger APIs. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] monodevelop from trunk compile error - error CS0006: cannot find metadata file `Mono.Cecil.dll'
On Wed, Feb 24, 2010 at 5:31 AM, Tomasz Kubacki tomasz.kuba...@gmail.com wrote: hello, I use mono from trunk with parallel env (http://www.mono-project.com/Parallel_Mono_Environments) You seem to be using a Mono in /usr/local, which can cause confusing build problems due to pkgconfig behaviour http://www.mono-project.com/Parallel_Mono_Environments#BEWARE:_pkgconfig_fallback_behaviour -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Testing Compatibility
On Sun, Feb 21, 2010 at 7:47 AM, Stifu st...@free.fr wrote: If I'm not mistaken, Mono can't build C++, but it should be able to run .NET C++ apps. Only if they're pure CIL. If they're mixed-mode, i.e. contain both native and CIL code in the dll/exe, then Mono can only run them on Windows or Wine. Unfortunately most C++/CLI is mixed-mode; although it's possible to run C++/CLI in CIL-only mode, that not very common, as managed/native interop is the main reason to use it. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Language of message errors in monodevelop
On Tue, Feb 9, 2010 at 8:20 AM, jav...@crowsoft.com.ar wrote: Hi, Someone knows how to set the language of message errors in MonoDevelop? I'm using mono in my work. My pc have windows XP in spanish (I can't change this) This kind of message (plus my horrible English) makes difficult for me ask for help about these errors. c:\Dev\proyectos.mono\CSDataBase\Codigo\CSDataBase\fCancelQuery.cs(14,14): Error CS1061: 'CSDataBase.fCancelQuery' no contiene una definici¢n de 'lbDescript' ni se encontr¢ ning£n m‚todo de extensi¢n 'lbDescript' que acepte un primer argumento de tipo 'CSDataBase.fCancelQuery' (¨falta una directiva using o una referencia de ensamblado?) (CS1061) (CSDataBase) Please file a bug against MonoDevelop.. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Advice on porting Windows app
On Thu, Feb 4, 2010 at 1:19 PM, Peter Shoebridge pe...@blueyondergaming.com wrote: I want to port our gaming client to Linux and would like to solicit possible approaches. The client consists of several separate applications, the first, is a background executable (with no UI) that starts and communicates with several others. This one should not pose any issues, other than it does have some code to communicate with some serial and usb peripherals. The UI apps are written for Silverlight 2.0 and hosted within a web browser control within windows forms applications. The silverlight UI code communicates with the host windows forms app using the ObjectForScripting method of the web browser control and calling javascript from the SL code. How would I best implement this feature in Mono and Moonlight? Basically, I need to host the Moonlight application which needs to perform some operations on the application, such as resize the window, change it to top most etc. which obviously can't be performed from the Moonlight environment directly. I want to avoid opening a socket as there are limited ports available and I am already using some of them. I believe Moonlight can be used out-of-browser in full trust with access to all framework APIs. You could also use the GTK# Moonlight widget to embed your GUI in a GTK window directly. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono embedded : segfault when jit_cleanup
On Wed, Dec 23, 2009 at 5:35 AM, Damien maitred...@gmail.com wrote: Hi, I'm coding a plugin for valve source servers (half-life 2, orangebox...), and I try to embed Mono. All is working well, until I try to call mono_jit_cleanup : I have a segfault. In my code, when I don't call any Mono functions at all, all is working well. When I call Mono related functions, all is working well (init, assembly loading, type instanciation, function calling, type marshalling...), but cleanup = segfault. Event with only mono_jit_init with mono_jit_cleanup I have a segfault. How can I see if it is related to Mono or server ? I'm using Mono 2.4.2.3 (ubuntu 9.10 x86 distrib package). Check that you only call mono_jit_init once. Also, the track trace from the segfault would be useful in diagnosing the issue. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Is this by design?
On Wed, Dec 23, 2009 at 2:53 PM, Charlie Poole char...@nunit.com wrote: Hi All, The NUnit source contains separate solutions for VS2005, 2008, etc. Each solution contains multiple projects and each project contains multiple source folders under it. The actual source files are linked from each folder and show up under them in Solution Explorer. When I open these projects with MonoDevelop, they are all grouped as External Files and the individual folders don't show in the IDE. I see that MonoDevelop does support folders for source files that are actually contained under the directory containing the project and that files added in this way appear under their respective folders. Is the feature not supported for external files by design? If that's the case, can you suggest alternate structure that will allow me to support multiple solutions? MonoDevelop doesn't currently support MSBuild file links properly, as it ignores the target relative path. This is on my list to fix for MD 2.4. FYI, monodevelop-list would have been a more appropriate place to ask this. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] StyleCop incompatibility
On Tue, Dec 8, 2009 at 6:27 AM, Andrew Mikhailov and...@vitche.com wrote: The MS defines a code-style rule for the order in which the “usings” must be sorted: http://www.thewayithink.co.uk/stylecop/sa1208.htm The MonoDevelop application’s “Sort Usings” functionality simply sorts using in the alphabetical order but does not consider this rule. I would suggest filing this as an enhancement request for MD's C# code style options. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announcing the release of Mono 2.4.3
On Wed, Dec 9, 2009 at 10:40 PM, Kris Ray k...@landmarkdigital.com wrote: The release notes say that debugging works on OSX now when logged in as root. I just installed mono 2.4.3 and the latest monodevelop 2.2 rc on OSX 10.6.2. I enabled the root account, then logged in as root. I then created a console app in monodevelop and put in breakpoints. The menu under run has the debug option grayed out. What else do I need to do to enable this? This appears to have been an error in th 2.4.3 release notes. AFAIK mdb only works in Mono 2.6. Even then, Monodevelop for MacOS does not include the mdb addin. I suggest waiting for Mono 2.6 which should be out soon. It has the new soft debugger built in, and MonoDevelop 2.2 also has built-in support for the soft debugger. SDB is much more portable, and works very well on MacOS -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WaitAny does not consistently return when waiting on more than one WaitHandle
On Wed, Nov 25, 2009 at 6:59 PM, Tom Philpot tom.phil...@logos.com wrote: Zoltan, Would it help if I created a Mac OS specific bugzilla? Is there someone else that can test this on Mac? (Geoff N, perhaps)? This behavior is the same (i.e., consistently inconsistent) on 10.5 and 10.6 for what it’s worth. FWIW, I've noticed something like this affecting MD on Mac: https://bugzilla.novell.com/show_bug.cgi?id=558273 -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono and the 4.0 profile
On Fri, Nov 20, 2009 at 2:05 AM, Miguel de Icaza mig...@novell.com wrote: One small follow up: Pending an audit to verify that no APIs were dropped or renamed, perhaps we could also remove the 2.0 assemblies as well and modify the runtime to remap all 2.0 assembly references to 4.0 to reduce both the install size and the compilation time. The only downside to dropping the 2.0 profile would be that Mono could not be used to target the 2.0/3.5 runtimes. Maybe packagers could ship the 2.4.x or 2.6.x versions of the 2.0/3.5 assemblies in a devel package. Not sure if it's worth the effort though. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [MonoDevelop] feedback and suggestions for GTK#
To add to this, another advantage of using naming similar to the GTK+ naming is that it is usually very straightforward to translate GTK+ code, documentation and tutorials to GTK#. Translating Winforms knowledge to GTK# would be hard no matter what naming was used; the naming is a minor issue compared to the other differences. On Oct 24, 2009 11:16 PM, Jon Cosby j...@jcosby.com wrote: On Sat, 2009-10-24 at 11:18 +0530, Sharique uddin Ahmed Farooqui wrote: Hi, I'm writting a a ... GTK# is not the same as winforms and some gtk widgets behave differently than their winforms counterpart. Renaming them to the familiar winforms names could lead new developers to expect the old behavior and cause a lot of frustration. Jon ___ Monodevelop-list mailing list monodevelop-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monodevelop-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] correct tail call optimization in mono
On Sun, Aug 23, 2009 at 5:02 PM, Rodrigo Kumperakump...@gmail.com wrote: Mono doesn't really needs to support tail call on all valid positions, doing as well as MS is enough for F# workloads. Thou I have no idea on what are the restrictions for TCO on dotnet. I've run across a pretty detailed post on this in the past: http://blogs.msdn.com/davbr/pages/tail-call-jit-conditions.aspx I also just found this post detailing changes in .NET 4: http://blogs.msdn.com/clrcodegeneration/archive/2009/05/11/tail-call-improvements-in-net-framework-4.aspx -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Moving *.Design to package mono-design
On Sun, Aug 9, 2009 at 6:30 AM, Ivan Zlatevcont...@i-nz.net wrote: Unfortunately that leaves you with no option of avoiding aspnet pulling winforms through System.Design. :( There's still the option of a mono-web-designtime package... -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Array and IEnumerable
On Wed, Jul 1, 2009 at 1:13 AM, Trouve Antoinetrouve.anto...@mac.com wrote:
This is incorrect. ListSubclass cannot be cast to ListSuperclass on
.NET.
Some examples like this can be solved by generic
covariance/contravariance in .NET 4.0. See
http://themonkeysgrinder.blogspot.com/2009/02/c-4-is-now.html for some
explanations. However, since System.Generic.Collections.ListT both
accepts and returns objects of type T, I don't believe it could be
made variant.
Ho, you're right. I think this behaviour has changed since .NET 2.0.
I've just checked and one of my old project do not compile anymore.
... or I might have missed something.
I have missed something and written too fast: this projects works in the
case I use my old interfaces (e.g. IList instead of List)
It the point explained in your link as variance right ? By the way I
remember it was not supported by Mono 1.3 or something.
I tested and it works with gmcs 2.4 (and 1.9 since I've just tested).
What I said is true for normal (nonvariant) generic types.
However, arrays aren't really generic types. They are treated
specially by the runtime, so that they can be cast to IListT /
ICollectionT / IEnumerableT, where T is the array element type or
any supertype. Presumably your problem was a bug in this feature, in
an older version of Mono.
This is demonstrated by the following sample.
using System;
using System.Collections.Generic;
class Program
{
class A {}
class B : A {}
static void Main (string[] args)
{
B[] foo = new B[0];
Console.WriteLine (foo is IListB); // true
Console.WriteLine (foo is IListA); // true
ListB bar = new ListB ();
Console.WriteLine (bar is IListB); // true
Console.WriteLine (bar is IListA); // FALSE
}
}
Covariance and contravariance are interesting because they make this
kind of casting possible for generic types. They're in .NET 4.0, which
is not yet released, and hence are not yet supported by Mono either.
There are plenty of explanations on the web, so I won't got into
details here.
--
Michael Hutchinson
http://mjhutchinson.com
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Array and IEnumerable
On Tue, Jun 30, 2009 at 12:45 PM, Elise Langhami-ell...@microsoft.com wrote: I'm running Mono 2.4 on Windows and am getting a similar error - is there any solution to this bug ? System.Array.InternalEnumeratorSystem.String[] doesn't imple ment interface System.Collections.Generic.IEnumeratorSystem.Array ** ERROR:mini-trampolines.c:67:mono_convert_imt_slot_to_vtable_slot: code should no t be reached Can you please construct a minimal test case to reproduce this error and file a bug against the runtime? -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Array and IEnumerable
On Tue, Jun 30, 2009 at 10:30 PM, Yopmastertrouve.anto...@mac.com wrote:
I think your issue is due to another huge difference between Mono and .NET
which leads to this kind of error. Here is an example:
Let us consider Human and Child so that Child is derived from Human:
class Child : Human {}
If now you create the List of type
ListChild children;
In .NET, children will also implement the type ListHuman:
children is ListChild
true
children is ListHuman
true
This is incorrect. ListSubclass cannot be cast to ListSuperclass on .NET.
Some examples like this can be solved by generic
covariance/contravariance in .NET 4.0. See
http://themonkeysgrinder.blogspot.com/2009/02/c-4-is-now.html for some
explanations. However, since System.Generic.Collections.ListT both
accepts and returns objects of type T, I don't believe it could be
made variant.
--
Michael Hutchinson
http://mjhutchinson.com
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] monodev and debugging on mac os x ( linux as well)
On Thu, May 14, 2009 at 9:05 AM, Félix.RVA f.ruiz-valdepe...@premavals.com wrote: You can use the integrated Debugger on Monodevelop only on the 2.0 version or higher. I don't know how it works on the Mac version but on Linux distributions you must install the monodevelop-debugger packages (gdb and mdb) ... then the debugger options will be available on the monodevelop IDE. The Mono debugger only works on Linux x86/x86_64 at this time. There are porting efforts underway for Windows and Mac, but no ETA yet. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Usage of construct properties in a wrapped GObject library
On Sun, Apr 26, 2009 at 11:38 AM, mardy.tardi ma...@users.sourceforge.net wrote: I guess that by modifying the C library by adding more _new() methods I can get more constructors in the C# API, but is there some other way around it, without modifying the C API? Use .custom files to add custom constructors into the C# wrapper. http://mono-project.com/GAPI#.custom_files -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [MonoDevelop] Announcing Unofficial Fedora 10 mono/monodevelop packages
On Tue, Apr 21, 2009 at 11:40 AM, buhochil...@gmail.com buhochil...@gmail.com wrote: Hi guys, I want to announce an unofficial support for mono/monodevelop packages for Fedora 10, currently those packages are under review on bugzilla, but I can tell you that are currently working just fine on several machines here at my Univ. Good things included are: Monodevelop 2.0 final release. Mono 2.4 release Monodevelop Integrated GDB debugger addin Monodevelop Integrated MDB debugger addin Mono and Monodevelop dependencies updated for the mono stack... We also have the database integration addin for monodevelop and java/ikvm and vala support to if someone need it (currently not in the repo). Great news! Assuming the packages will be in the official repos soon, I won't add the URL to the MD wiki, but I'll be sure to point anyone who asks for packages towards your instructions :-) -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [BUG] Unhandled Exception; object reference not set to an instance of an object....
On Sun, Apr 19, 2009 at 6:41 AM, Robert Jordan robe...@gmx.net wrote:
but when i run it under windows, without mono being installed, it works
fine... so im not sure whats going on; here is the code snippit
while (Running) {
string input=Console.ReadLine();
if (input.StartsWith(/)) {
MD does not support terminal input, thus your input string will
be null.
You must run apps depending on Console.Read* outside MD.
Note that there's a run in external console option in the project
options in MD.
--
Michael Hutchinson
http://mjhutchinson.com
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VB code completion
It will be implemented when someone contributes it - the MD team already has more than enough other work planned to fill the foreseeable future. On Mar 29, 2009 12:04 PM, Chris LaFond claf...@prowestgis.com wrote: Anyone know when VB .net code completion is slatted to be implemented in monodevelop? Just wondering .. I do a fare amount of VB, and i hate windows ... thanks Chris LaFond Programmer Pro-West Associates Inc. 8239 State 371 NW PO Box 812 Walker, MN 56484 www.prowestgis.com claf...@prowestgis.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list pwalogo.gif___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Unhandled Exception: System.Resources.MissingManifestResourceException:
On Mon, Mar 23, 2009 at 12:11 AM, SuperAfton23 superafto...@mt2009.com wrote: I suggest MonoDevelop 2. It should be able to build your sln file fine -- either open and build it in the IDE, or use mdtool build from the command line. It also outputs the commands that it uses for the build, if you're curious. $ mdtool build MonoDevelop Build Tool VS2003 solutions are not supported natively. OK, you have a VS2003 solution. You can import it to MD, you just can't open it directly. I suppose this means I can't use mono on this project. No, it doesn't mean that at all. As I said before, you can use the same binaries you built on Windows. Alternatively you can convert your solution to a VS2005/2008 solution, which is the project format also used by MonoDevelop 2. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Where does System.Collections.Generic.HashSet hide?
System.Core.dll On Mar 22, 2009 11:57 AM, LCID Fire lcid-f...@gmx.net wrote: Could anyone tell me where to find the HashSet class? I cannot find it in the libraries on my ubuntu machine and neither in svn trunk. ___ 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] Using Mono on Windows to use .NET 3.0+ classes
On Sat, Mar 14, 2009 at 7:04 PM, Stifu st...@free.fr wrote: I simply tried adding this to my project: using System.Core.dll; And here's the compilation error I get: The type or namespace name `Core' does not exist in the namespace `System'. Are you missing an assembly reference? (CS0234) - C:\Documents and Settings\Thomas\Mes documents\SharpDevelop Projects\test\MainForm.cs:14,14 What am I missing? Importing a namespace with a using statement is very different from adding a reference. Use the context menu on the References folder in the project to reference the dll. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] inherited event
2009/2/25 Vladimir Giszpenc vgiszp...@dsci.com:
Hi,
I was wondering why events have to be in local scope to be called. If the
event is in a base class, shouldn’t I be able to invoke it?
This is not a bug in Mono as the behavior is the same on MS.Net, but I was
hoping for some insight.
http://msdn.microsoft.com/en-us/library/hy3sefw3.aspx
The protected virtual On{Event} invoker pattern is useful because it
allows derived classes to handle the event with an override, and
control the emission of the event.
--
Michael Hutchinson
http://mjhutchinson.com
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Develop native menus on Mac OS X
On Sun, Feb 22, 2009 at 9:53 AM, Andreas Färber andreas.faer...@web.de wrote: Am 20.02.2009 um 01:12 schrieb Michael Hutchinson: [...] * menu item sensitivity is not respected, so items are always sensitive even when they cannot be used IIUC, this is standard Mac behavior, not a major issue. Disabled menu items cannot be selected, but clicking closes the menu without doing anything. So there is no way to indicate that a command is not currently valid? My quick google image search disagrees. * menu item images are not shown Menu items don't have images on the Mac. Just like on Windows, originally. I didn't consider this a major issue compared to the other problems anyway :) [...] IMO we need to generate the menus from the command tree completely differently for Mac. If someone would like to volunteer, I'll tell them how... It might even be viable to do it with Cocoa#. Please try to avoid the 5+ ObjC bridges. There is an official Gtk+ project for Mac OS X menu integration: http://live.gnome.org/GTK%2B/OSX/Integration This is the library I was using, and it is not suitable for MonoDevelop's menu integration. The GTK# menus MonoDevelop generates are simply too complex to be converted cleanly by a generic bridge. Please see the discussions on the monodevelop lists if you'd like more details. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Develop native menus on Mac OS X
On Thu, Feb 19, 2009 at 6:43 PM, marc hoffman m...@elitedev.com wrote: Sandy, yesno. ;). it works for the editor itself (first thing i did when i tried MD ;), but not in other areas of the UI, where you still need Ctrl+CXV (which makes it even more annoying, if anything). Really? My version of MD on Linux lets you specify custom key commands for everything in the File, Edit, etc menus, too. yes. what i meant was that if i remapped, say Ctrl+C to Cmd+c, then that shortcut works in the code editor. but if i open a dialog and - say - configure project options such as, i don't know, output path, those edit boxes in the dialogs still responded to Ctrl+C, but not to Cmd+C. that said, this was a few months ago, when i last tried. things might have changed since then. Ctrl-X/V/C shortcuts for text widgets are a GTK thing. The only way we could fix that in MD would be do add a command handler to every single text entry widget, which would be extremely messy. This needs to be handled by the Mac GTK. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Develop native menus on Mac OS X
On Wed, Feb 18, 2009 at 11:23 AM, Geoff Norton gnor...@novell.com wrote: On Wed, 2009-02-18 at 06:35 -0800, Sandy Armstrong wrote: On 02/18/2009 06:28 AM, Joachim Ante wrote: Hi, Are you guys planning to switch to Mac OS X native menus and hotkeys that fit existing Mac applications for Mono Develop 2.0? (bug 367030) I can't speak for the MonoDevelop guys, but I can say that this would not be hard for a new contributor to do, given the examples available in Banshee, Tomboy, Tasque, etc. Well, I don't think anybody has done hotkeys yet, but I don't think it would be *that* hard. I have a patch somewhere or other for the menu (its 2 lines of code). The hotkeys I havn't looked into yet tho. We should probably move this discussion to the monodevelop-list tho. Unfortunately it's nowhere near as easy is this. I cleanly patched in the main menu support, but it has *major* problems. * the custom labels we use for displaying the accelerators are not shown * menu item sensitivity is not respected, so items are always sensitive even when they cannot be used * menu item images are not shown * menu items with checkboxes or radio boxes are invisible This is so broken that I've disabled my changes. IMO we need to generate the menus from the command tree completely differently for Mac. If someone would like to volunteer, I'll tell them how... It might even be viable to do it with Cocoa#. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Develop native menus on Mac OS X
On Thu, Feb 19, 2009 at 10:13 AM, Sandy Armstrong sanfordarmstr...@gmail.com wrote: On 02/19/2009 03:06 AM, marc hoffman wrote: Sandy, On 02/18/2009 01:05 PM, Joachim Ante wrote: just really difficult to make the mental switch for all the hotkeys like cmd-c / ctrl-c for copy paste etc. So the faster this one gets fixed, the faster / easier I can convince people to use Mono Develop instead of what ever text editor they are using now. Is it possible to work around this by editing Keybindings in the preferences dialog, and distributing a default MD config directory to your users? I haven't tried, yet... yesno. ;). it works for the editor itself (first thing i did when i tried MD ;), but not in other areas of the UI, where you still need Ctrl+CXV (which makes it even more annoying, if anything). Really? My version of MD on Linux lets you specify custom key commands for everything in the File, Edit, etc menus, too. The Mac Gdk key mappings are really odd, so it's impossible to bind Command cleanly right now. I'm taking a look at fixing this, but it might require changes to the Mac Gdk. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] idea summary: Swing in Mono?...
On Sun, Feb 8, 2009 at 1:06 AM, BGB cr88...@hotmail.com wrote: yes, this is a workable option, but there is a minor drawback: certain operations, in particular, uploading textures (glTexImage2D), dumping graphics to screen (glWritePixels), getting graphics from screen (glReadPixels), ... all tend to be fairly expensive (far more than drawing native primitives in GL). so, yes, using an offscreen pixmap for a GUI, and streaming this into GL would work, just it would be a little bit of a threat to the performance... You can accelerate the rendering using the GPU: http://www.ogre3d.org/forums/viewtopic.php?t=46348 snip oddly, I can't seem to find any evidence of there being OpenGL bindings in mono, hmm... There are two available that I'm aware of: Tao and OpenTK. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Coolite 0.7 CssClassPropertyAttribute
2009/1/6 Joshua Martin josmar52...@endeavorcorp.com: Is this class, System.Web.UI.CssClassPropertyAttribute, part of the Mono 2.0.1 release? No, it was added on 2008-09-13: http://lists.ximian.com/pipermail/mono-patches/2008-September/127775.html AFAICT .NET 3.5 SP1 was released in mid-August, a month after Mono branched for 2.0. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] MD not packaging binaries correctly though it could be mono at fault
2008/11/30 Paul [EMAIL PROTECTED]: Hi, I hit this issue a long enough time ago, so I don't remember the specifics really. It'd be worth filing a bug report on this if this really is the issue. Filed - BZ 450341 This is a MonoDevelop issue, not a mcs issue, and it's fixed post-1.0 (well before 1.9.1 anyway). VS uses the parent directory as a namespace for the resource by default. Note that even in MD 1.0, you can override the resource name using the property pad. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] xbuild
2008/11/13 Rafael Teixeira [EMAIL PROTECTED]: AFAIR, Monodevelop reads csprojs which are msbuild files but with specific semantics, and deals with the needed tasks. Actually, MD can *read and edit* arbitrary MSBuild files, but can only build certain targets that we have specifically added support for, e.g. C#, VB, Web app projects, etc. Monodevelop doesn't try to implement all msbuild functionality and specially it's extensibility features, which are used by VS.NET. What VS does is to call out to MSBuild for the actual build. MD does have support for reading/writing things like arbitrary build targets, it just can't /build/ them without a functional xbuild. It may be feasible to evolve Monodevelop to use xbuild but probably it would impact the support for the other buildings tasks Monodevelop and its addins currently support. The main reason is that msbuild (and therefore xbuild) doesn't use Mono.Addins for its extensibility and doesn't consume/expose the extension points in/to MD/MD-addins, but those of VS.NET/msbuild-addins. MSBuild is independent of VS, and Mono.Addins has little (if anything) to do with it. The main impediment is that xbuild is not sufficiently functional yet. Our long term plan, when xbuild is functional, is to use xbuild for building in MD. To this end, Ankit has been working on xbuild. Obviously we'll have to port the MD-specific build steps to xbuild tasks, at which point it will be possible to build your projects without having all of MD installed. There some threads in monodevelop-list that explain more about how and why we are doing this. Hope I didn't confuse things and this message can be of some help, It was mostly right :-) -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] xbuild
2008/10/27 Jonathan Chambers [EMAIL PROTECTED]: Hello, I am looking to work on xbuild a bit, and so I started by looking at the the current tests and planned on writing some more. Cool! I really think that xbuild is important, so I'm glad you're looking at this. It looks like there are a substantial number of tests (18) marked NotDotNet. Is there a reason we'd have this many tests that don't work on .Net? Also, some other tests not marked with NotDotNet are failing on .Net? Can I assume the tests are wrong if they are failing on .Net? That's an interesting point, and I really don't know. Looking at these tests, it seems that they're mostly checking argument error checking. Given that most people won't be Microsoft.Build.* XBuild APIs directly, perfect compatibility may not matter, and more stringent checking might be useful. OTOH, compatibility is also good. The documentation for MSBuild on MSDN is a bit sparse. Is there any other source of information other than writing tests? I'm only aware of one MSBuild book, unfortunately, and I don't know if it's any good. Finally, I am trying to work on this in VS and MonoDevelop. Does anyone have any guidlines on setting up projects for mcs/class type assemblies? My goal is to be able to have projects for MSBuild.* and the xbuild assemblies in a solution, and be able to build run them. However, I believe when I run my locally built xbuild it will load the MSBuild.* assemblies out of the GAC, rather than my locally built ones. Also, xbuild locates Task files based upon a mono install layout structure. Any advice for working around these issues? I basically am looking for make run type functionality like MonoDevelop has. In this particular case it might be ok to use MONO_PATH. Probably Ankit can answer these xbuild questions better than I can... -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] What is the state of mono interpreter ?
On Mon, Sep 29, 2008 at 2:39 PM, James Mansion [EMAIL PROTECTED] wrote: Rodrigo Kumpera wrote: These are shortcomings of the current AOT implementation of mono that are easier to fix than implement a fast interpreter. Who said anything about fast? I would value an interpreter not as a replacement for JIT in a full mono stack, but as a way to create a very small footprint runner for CLR code, with a really cut-down runtime. This would be competing more with a Lua usecase than anything else. Which is, I think, what the original author of the thread meant by referring to the Micro Framework... http://en.wikipedia.org/wiki/.NET_Micro_Framework -- runs in 300kb, 70 classes, 420 methods, doesn't need an OS or a MMU... -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] How to: Run tar command from c# app
On Thu, Sep 25, 2008 at 2:05 PM, ebonnett [EMAIL PROTECTED] wrote: Hi all, How would I run a tar command from a c# app on mono (1.9.1) on Debian? Would I use the Process and ProcessStartInfo object? Yes, you would. There are a number of examples floating around the net, including the mailing list archives. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Question about JIT performance
2008/8/14 Bojan Rajkovic [EMAIL PROTECTED]: snip The thing that immediately struck me as odd was: how is the inlined BoxApproximation that HAS a switch() call to check whether it's doing left, right or midpoint faster than everything else. It's not just a little faster, it's a lot faster. The machine running all of these tests is running Mono trunk as of a few days ago, x86 processor with a 2.0 GHz clock speed and 512 MB of RAM (it's a VMware server virtual machine). Running the same thing on Mono 1.9.1 outside of VMware yields similar results. What intrigued me in our discussion is that on .NET, there is very little difference between the four methods. The only statistically significant difference I could measure is that the inlined versions are about 3-4% slower than the versions with the method call -- which is in itself interesting. (For reference, it's about 21 cycles per loop iteration on a Core 2 in 64-bit mode.) -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Source for mono(ICSharpCode.NRefactory)?
2008/8/10 Paul [EMAIL PROTECTED]: Hi, Do I need to grab the sharpdevelop source and pull out the source for ICSharpCode.NRefactory then compile under mono to get this dll or is there a source package with just that code in it? There isn't one AFAIK. MonoDevelop include a copy, but #develop is the official version. Depending on what you need it for, MCS might be better. MD is switching to mcs for C# parsing. What's the use-case? -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [MonoDevelop] Some questions about the debugger/debugger add-in
On Tue, Jul 15, 2008 at 8:34 PM, Casey Marshall [EMAIL PROTECTED] What key is L1? It's bound to the step commands, but I have no idea what key that corresponds to. It's F11. The Gdk.Key enum has two names for the same integer value, and the L1 is being resolved first. F11 *works* fine, it just displays oddly. We've had similar issues with they keybinding addin before, and I have a local patch for this that I'll commit on Friday. (sorry, your other questions are outside my area) -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Catch keys outside the Window?
On Tue, Jun 24, 2008 at 6:48 PM, Xeon06 [EMAIL PROTECTED] wrote: Hey all, I'm trying to make a keybinding application in C# using Mono. However, I have no experience whatsoever in programming under Linux (more specifically I'm under Ubuntu and GNOME). I need to be able to detect keypresses outside the window of my application. I also want the application to be in the tray (left of the clock, however thats called in Linux). In Windows I would just hook the user32.dll but under Linux I am well... Stuck. Is there something in the Mono library that allows this? Or can I hook some Linux binary? I read a bit and I'd need to use the X server but I'm not even sure if I can do this with Mono. You may find this useful: http://svn.gnome.org/viewvc/tomboy/trunk/Tomboy/XKeybinder.cs?view=markup According to the COPYING file, the license seems to be LGPL, so you won't have to worry about the license as long as you keep it in a separate library. Note that it's P/Invoking libtomboy (http://svn.gnome.org/viewvc/tomboy/trunk/libtomboy/) so you'd need to use that too. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] system.diagnostics (tracesource/traceeventtype) support in mono
On Mon, Jun 23, 2008 at 7:15 AM, sabbadin [EMAIL PROTECTED] wrote: Hi, I'm getting an error while running a simple console app that uses System.Diagnostics.TraceSource class or System.Diagnostics.TraceEventType. It says the class cannot be loaded. I was told that 1.1.17 mono version is installed (how can i check it) .. mono --version What version of mono support this stuff ? I don't know offhand, but 1.1.17 is almost two years old. I strongly recommend upgrading to 1.9.1. Generally speaking where I can find info aboput the implementation status of a class ? , when it was introduced ? what features are present in a specific mono version ? .. http://www.mono-project.com/Class_Status has the current status. You can find the release notes (which list important changes) here: http://www.mono-project.com/OldReleases -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Small fix for CSharpCodegenerator
On Fri, Jun 20, 2008 at 3:18 AM, Gert Driesen [EMAIL PROTECTED] wrote: Hey Ankit, Are you using the 2.0 profile version of CodeDom? In that case we could just introduce an option for specifying whether the CodeDomProvider is used in MD-mode, and generate code accordingly. See http://msdn.microsoft.com/en-us/library/bb537926.aspx for more info. That's an excellent idea, but we may need to run on .NET too. Also, MD doesn't depend on Mono trunk -- we still claim our users can get by with 1.1.10. It's for the latter reason that we have out won copy of the VB CodeDOM generator already :) Those options looks like a neat way to keep a CodeDOM interface while implementing other features that we might like, such as other formatting options (Mono coding style). I also wonder if we could hack in a way to generate explicit event implementations -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Small fix for CSharpCodegenerator
On Thu, Jun 19, 2008 at 2:41 PM, Gert Driesen [EMAIL PROTECTED] wrote: Antik, I know the generated code does not look good, but it actually matches the output of MS. In general, the formatting of generated code it not much of interest since one does not tend to change it anyway. Having our generated code exactly match that MS makes our it easier to create tests, so I'd prefer to keep it this way. I suspect the problem here is that MonoDevelop uses CodeDOM to generate code for inserting into user code, so it does matter to us how the output looks However, we could maintain a C# CodeDOM generator fork in our tree, as we do for VB.NET. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] excute linux command under mono C#
On Tue, Jun 10, 2008 at 6:21 PM, Alan_Chun [EMAIL PROTECTED] wrote: Hi, any one know how to execute a command, e.g, stty 9600 -F /dev/ttyS0 under mono C#? string cmd = stty 9600 -F /dev/ttyS0 ; System.Diagnostics.Process proc = new System.Diagnostics.Process(); proc.StartInfo.FileName = ??? //here proc.StartInfo.Arguments = cmd; ?? proc.StartInfo.UseShellExecute = false; /// proc.StartInfo.RedirectStandardOutput = true; proc.Start(); Pass your shell command to a shell such as sh or bash: Filename: sh (or bash) Arguments: -c ' + your_escaped_command + ' -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gstreamer-sharp Question
2008/5/5 Jonathan Thomas [EMAIL PROTECTED]: I am very interested in using the gstreamer bindings in a mono project, but I could really use some advice. I can't seem to find the gstreamer-sharp assembly anywhere. The only luck I've had so far is some development notes back in 2006. Do any mono up-to-date bindings exist for the gstreamer framework? Is there a better multi-media framework I should use? Sadly, the GStreamer# bindings were never completed, and have been unmaintianed for some time. I don't know how hard it'd be to get it off the ground, though this would certainly be nice to see. Ultimately, I would like to create a non-linear video editing application using C# and the mono framework. I have been told that gstreamer is the most powerful media framework in linux (at least that's what I was told). GStreamer is arguably the most powerful modular media framework on Linux, yes, and works on other platforms too. Banshee (Mono-powered media app) uses Gstreamer via P/Invoking a C wrapper library. There was some debate over whether gstreamer in its current state it's suitable for editing: http://www.mdk.org.pl/2006/12/07/state-of-diva http://blogs.gnome.org/uraeus/2006/12/08/comment-on-diva/ However, that was some time ago, and I'm pretty sure that any such issues can be fixed. I'd suggest taking a look at resurrecting Diva, a Mono based nonlinear video editing app which was widely praised, but stalled a while ago from lack of contibutions. AFAIK it also used a C library to implement the core editing features. Sadly the website seems to be down right now, but I suspect other people on this list can direct you to mirrors. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gstreamer-sharp Question
On Tue, May 6, 2008 at 3:06 AM, Michael Hutchinson [EMAIL PROTECTED] wrote: ... I'd suggest taking a look at resurrecting Diva, a Mono based nonlinear video editing app which was widely praised, but stalled a while ago from lack of contibutions. AFAIK it also used a C library to implement the core editing features. Sadly the website seems to be down right now, but I suspect other people on this list can direct you to mirrors. While the website's down, SVN is still up: http://svn.diva-project.org/diva/ -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gstreamer-sharp Question
2008/5/6 Jae Stutzman [EMAIL PROTECTED]: I believe the missing gstreamer# is a huge hole in the development stack. We also p/invoke the c lib in our apps. It would be nice to see this project revived and become a first-class citizen like gtk#. Maybe we can garner some folks together! GSoc Mono.Media is another option, perhaps. We have picked students for this year already. You want to wait till Sept 2009? :) The fundamental problems with Mono.Media at the moment are: (a) no-one spec'ed concrete use cases and requirements -- it's still a very nebulous idea (b) the are no applications that want to consume it -- people have suggested Banshee, but it has no problems with its GStreamer/C player engine, and you'd need to present a very solid case to change this (c) developing a good and sufficiently generic library from scratch like this will take a lot of time and effort IMO a good GStreamer# binding will be more useful than Mono.Media. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gstreamer-sharp Question
On Tue, May 6, 2008 at 2:25 PM, stapostol [EMAIL PROTECTED] wrote: Michael Hutchinson wrote: (b) the are no applications that want to consume it -- people have suggested Banshee, but it has no problems with its GStreamer/C player engine, and you'd need to present a very solid case to change this Regarding (b), and depending on its architecture, Mono.Media might be very useful as a decoding frontend to applications using the Open Toolkit or the Tao framework (the backend would then be OpenAL). There's a potentially significant market here, if Mono.Media comes to fruition. I don't think anyone had brought up 3D games as a possible market for GStreamer yet :) I suspect that the use cases are different enough from desktop apps that they'd be best served by a specialised API. IMO a good GStreamer# binding will be more useful than Mono.Media. This is quite interesting, too. Does GStreamer# use an intermediate C library, like Banshee? How portable is it? According to their features page, GStreamer works on Linux on i86,PPC, ARM using GCC. Solaris on x86 and SPARC using both GCC and Forte, MacOSX, Microsoft Windows using MS Visual Developer and IBM OS/400. AFAIK Banshee's C library does all the pipeline/element-building work and exposes a minimal media player engine C API. I think Banshee's Windows and Mac ports will be using GStreamer. I'd be surprised if the GStreamer# library doesn't have some C glue code, but it should be as crossplatform as GStreamer itself. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Gtk# 2.8.4 runtime for windows?
On Wed, Apr 16, 2008 at 5:39 PM, Alan McGovern [EMAIL PROTECTED] wrote: Hi, You can work around it by using reflection to test whether that event exists, and if it does you can then register a handler to it. That way you can use the new feature without having to lose compatibility with 2.8. E.g. http://anonsvn.mono-project.com/viewcvs/trunk/monodevelop/main/src/core/MonoDevelop.Core.Gui/MonoDevelop.Core.Gui/GLibLogging.cs?view=markup (that also has some other cool GTK.GDK/GLib logging stuff for generating managed traces when they emit warnings and criticals) -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono on wine redux
On Wed, Apr 9, 2008 at 3:54 AM, Dan Kegel [EMAIL PROTECTED] wrote: snip For the moment, Wine is happy to let people choose between Mono and MS .Net. Since most .net apps are built with Microsoft tools, they're nearly universally mixed- mode assemblies, so people will of neccessity load MS .net runtimes onto Wine. Eventually, though, we'd Actually, only managed C++ produces mixed mode assemblies, and only if it's not running in pure mode. Today, Mono can directly run a very large subset of .NET apps that were built on Windows with no or very few modifications. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [MonoDevelop] Soc 2008 idea: Universal graphical Framwork
On Mon, Mar 24, 2008 at 3:00 PM, Sharique uddin Ahmed Farooqui [EMAIL PROTECTED] wrote: Hi, We need different types of graphical designers like, xml designer, class designer, xaml designer, moonlight designer, etc. I think we should have a base framework, which will provide basic features like canvas and few controls and Monodevelop addin api. So that one can easily add there desired designer in monodevelop (a PCB designer for example). What are ur views friends? There is no realistic way to provide a unified framework for many of these things. However, flow-type designers (class visualiser, database designer, workflow designer etc) could certainly share a canvas, ideally based on Moonlight, and a student has already been discussing this with us. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [MonoDevelop] Typed dataset issue
On Sat, Feb 23, 2008 at 12:39 PM, Sharique uddin Ahmed Farooqui [EMAIL PROTECTED] wrote: hi, I'm aware abt drawbacks of Typed datasets. It is really small application, I have written few months back and don't want to rewrite it. Thanks for suggestions. If you just want to compile it in MD and don't care too much about maintaining the generated code, you could bring the generated files over too and add them to the project directly. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] I18n and ASP.Net (Rolando Martíne z)
2008/2/7 Rolando Martinez [EMAIL PROTECTED]: Hi, Thanks for your answers, I'm working on a application for online translation of po files (something like a online editor of po files ) . Then I would know if I can use something like this (http://www.mono-project.com/Internationalization) and not the typical localization features (resources files). Would you be interested in sharing code with MonoDevelop's translation addin? We already have code to parse/edit/save po files, at trunk/monodevelop/main/src/addins/MonoDevelop.Gettext/ (MIT/X11 license), and would be interested in a web based editor too :) Using gettext from an ASP.NET app would get complicated because libintl gets the language from the LANG environment variable, which would obviously cause problems trying to use multiple languages within a single process, i.e. a threaded web server. However, there's no reason in principle why you could not hack the libintl library to allow different 'instances' to be used from different threads, or even port it to C# and use the current thread's .NET culture. Once these problems were solved, you could use expressions like %# GettextCatalog.GetString (Translate me) %. You'd also need a scanner for find extracting translatable strings, but MonoDevelop's gettext scanner could do that with a couple of regexes. FWIW, the ASP.NET quickstart page claims that the localisation model in 2.0 can be swapped out, but there doesn't seem to be much info on this. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs crashing
2008/2/6 Arno Rehn [EMAIL PROTECTED]: Hi, when I try to compile the KDE-Mono bindings, gmcs crashes with the following: $ /opt/mono-1.9/bin/mono --debug /opt/mono-1.9/lib/mono/2.0/gmcs.exe -r:/usr/lib/mono/2.0/qt-dotnet.dll *.cs -warn:0 It looks like you're mixing a couple of Mono environments. Are the properly separated? See http://www.mono-project.com/Parallel_Mono_Environments for info on the various env vars. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Multiply-defined symbols with F#
On Feb 6, 2008 6:02 PM, Casey Marshall [EMAIL PROTECTED] wrote: Now, this makes sense: both System.Core.dll and FSharp.Core.dll define 'System.Action' types. But, is there any way to work around this? If you want to use C# 2 (and hence avoid referencing System.Core), pass the /langversion:ISO-2 argument to the gmcs compiler. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] App using gecko-sharp won't start.
On Jan 25, 2008 11:47 AM, Jakub Skoczen [EMAIL PROTECTED] wrote: Hey Guys, I am using the MonoDevelop IDE to build a GTK# application that embeds Gecko. When run from within MD, the app starts up and works fine. However, when I try to run it from the command line it won't work. Running: mono gecko-experiments.exe ended with: System.TypeInitializationException: An exception was thrown by the type initializer for Gecko.WebControl --- System.DllNotFoundException: /usr/lib/firefox/libgtkembedmoz.so This is weird. Ubuntu/Debian does strange stuff here; the dllmap should only map dll names, not full paths. so I've set the LD_LIBRARY_PATH=/usr/lib/firefox and I got what can be seen below. I tried enabling launch script generation in MD (0.14) but I cannot see it generating any scripts. I'm running Ubuntu 7.10. Any ideas on what's wrong with that? Stacktrace: at (wrapper managed-to-native) Gtk.Container.gtk_container_add (intptr,intptr) 0x4 at (wrapper managed-to-native) Gtk.Container.gtk_container_add (intptr,intptr) 0x at Gtk.Container.Add (Gtk.Widget) 0x00034 at geckoexperiments.MainWindow..ctor (Gecko.WebControl) 0x000b9 at geckoexperiments.MainClass.Main (string[]) 0x0005b at (wrapper runtime-invoke) System.Object.runtime_invoke_void_string[] (object,intptr,intptr,intptr) 0x I'm not certain, but I think that GtkMozEmbed may require you to set MOZILLA_FIVE_HOME to your Firefox directory too. MonoDevelop certainly does this, which would propagate to child apps (e.g. when you run your app from within MD). -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
