Re: [Mono-dev] Mono Contributors, Action required: Preparing the Subversion to GIT Migration
I did what you asked. What next? Hopefully, the free account at github.com will suffice. I have never used Git nor GitHub before. I use both Windows and Linux. Will Git work on both? --- On Tue, 6/29/10, Miguel de Icaza mig...@novell.com wrote: From: Miguel de Icaza mig...@novell.com Subject: [Mono-dev] Mono Contributors, Action required: Preparing the Subversion to GIT Migration To: mono-devel-list mono-devel-list@lists.ximian.com, Mono Announce mono-announce-l...@lists.ximian.com, mono-l...@lists.ximian.com Date: Tuesday, June 29, 2010, 4:27 PM Hello guys, As part of our migration from Subversion to GIT, we need all Mono contributors to get a GitHub account and provide your Mono SVN account and your new GitHub account name here: http://spreadsheets.google.com/viewform?hl=enformkey=dEdpdTFoNHBwUUI0clVLRFJtTC02N0E6MQ#gid=0 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Contributors, Action required: Preparing the Subversion to GIT Migration
Hello, git works on windows and linux. You'll find git for windows here [1]. A nice AddIn for Visual Studio is available here [2]. Daniel [1] http://code.google.com/p/msysgit/ [2] http://code.google.com/p/gitextensions/ 2010/6/30 Daniel Morgan monodanm...@yahoo.com I did what you asked. What next? Hopefully, the free account at github.com will suffice. I have never used Git nor GitHub before. I use both Windows and Linux. Will Git work on both? --- On Tue, 6/29/10, Miguel de Icaza mig...@novell.com wrote: From: Miguel de Icaza mig...@novell.com Subject: [Mono-dev] Mono Contributors, Action required: Preparing the Subversion to GIT Migration To: mono-devel-list mono-devel-list@lists.ximian.com, Mono Announce mono-announce-l...@lists.ximian.com, mono-l...@lists.ximian.com Date: Tuesday, June 29, 2010, 4:27 PM Hello guys, As part of our migration from Subversion to GIT, we need all Mono contributors to get a GitHub account and provide your Mono SVN account and your new GitHub account name here: http://spreadsheets.google.com/viewform?hl=enformkey=dEdpdTFoNHBwUUI0clVLRFJtTC02N0E6MQ#gid=0 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Porting .NET application (Namespaces)
Hi all, I'm asking myself how to port a C#.NET app to mono. Do i have to replace all the usual namespaces like e.g. System.Data with Mono.Data and so on? Or do I just have to compile using the mono compiler and that's all? If yes, what's the use of e.r. Mono.Data ? Thank you very much in advance for your effort. Best Regards! -- View this message in context: http://mono.1490590.n4.nabble.com/Porting-NET-application-Namespaces-tp2272722p2272722.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting .NET application (Namespaces)
You don't have to do either. Keep your System namespaces. The Mono namespace exists, but it consists of extra classes, not replacements for the core System ones. Also, apps compiled with .NET will work with the Mono runtime, and vice versa, so compiling your app with Mono is not a requirement. djdeveloper wrote: Hi all, I'm asking myself how to port a C#.NET app to mono. Do i have to replace all the usual namespaces like e.g. System.Data with Mono.Data and so on? Or do I just have to compile using the mono compiler and that's all? If yes, what's the use of e.r. Mono.Data ? Thank you very much in advance for your effort. Best Regards! -- View this message in context: http://mono.1490590.n4.nabble.com/Porting-NET-application-Namespaces-tp2272722p2272726.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Standard name for mcs
You would probably need to also distribute a compile script which detects existence of dmcs/smcs/gmcs/mcs in order of decreasing preference, store it in a local var then use it for compilation. Regards Roman On 27 June 2010 19:37, Russell Wallace russell.wall...@gmail.com wrote: I'm trying to distribute a C# program in both binary and source form so that the user can optionally recompile it. According to http://www.mono-project.com/CSharp_Compiler You have to pick one of: mcs: compiler to target 1.1 runtime (to be deprecated with Mono 2.8). gmcs: compiler to target the 2.0 runtime. smcs: compiler to target the 2.1 runtime, to build Moonlight applications. dmcs: Starting with Mono 2.6 this command is the C# 4.0 compiler, and references the 4.0 runtime. And indeed on my Ubuntu 10.04 VM, 'gmcs' works but 'mcs' gives an error message. (dmcs would be nice to have, presumably it just hasn't made it through the pipeline yet -- the Ubuntu version of Mono is 2.4.4 -- which is fair enough.) The problem I'm trying to solve is how to write a reliable makefile. I can have the makefile call gmcs, but then presumably this will start failing as soon as dmcs becomes the standard version. Would it be possible to define a command to run whatever the latest/currently installed C# compiler is? It seems to me that command should be mcs, but it doesn't really matter what it is, as long as it works reliably on all systems. ___ 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] Standard name for mcs
On Sun, 2010-06-27 at 21:29 +0100, Russell Wallace 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. They do, but they only try so hard. For example, the semantics of token evaluation changed from C#1 to C#2 due to generics, e.g. the parsing of F(GA, B(7)); In C#1, that would be a call to F(bool, bool) with `GA` as the first argument, and `B7` as the second argument. In C#2, the semantics are changed so F(T) is looked for, and the generic method GA,B() is invoked with the value 7. Most of the breaking changes between C#1 and C#2 are of this manner. There are other breaking changes between C#3 and C#3 SP1, e.g. http://msdn.microsoft.com/en-us/library/cc713578(VS.90).aspx Most of these could be argued as corner cases where the implementation didn't meet the spec (e.g. fixing double invocation of 'finally' blocks, ensuring that 'params' within indexers matches the interface, etc.). Then there's moving from C#3 to C#4: http://msdn.microsoft.com/en-us/library/ee855831.aspx Most of these are changes due to the new C#4 language features. 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). Java is a stagnant language, which has taken back-compat to such an excess that improving the language is near impossible (which is likely why other JVM languages like Scala are increasingly popular). C++ isn't necessarily any better, either: there are lots of compiler bugs, non-standardized compiler extensions, and the language itself will be changing things (e.g. `auto` is being repurposed in C++-1x, thus changing the semantics of a previously defined (and deprecated) keyword). Also, if we take the above C#3 to C#3 SP1 list as a guide, any compiler fix that is done to better match the spec would be a breaking change, and when we have compilers chasing and/or leading the spec (as is true for most of the C++-1x features), things WILL change to be more conformant with the spec. In short, for ANY language which is actually changing (even minimally), breakage is going to be a possible factor. The only languages where this isn't true is for dead languages which aren't changing anymore (and arguably aren't being used much anymore because they haven't changed). - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Contributors, Action required: Preparing the Subversion to GIT Migration
Hello Daniel, Hopefully, the free account at github.com will suffice. That is correct. I have never used Git nor GitHub before. I am also new with Git, it is not very hard to use, and there are lots of nice tutorials. I use both Windows and Linux. Will Git work on both? Yes, it will. They also have a Subversion bridge that lets you checkout with svn. --- On Tue, 6/29/10, Miguel de Icaza mig...@novell.com wrote: From: Miguel de Icaza mig...@novell.com Subject: [Mono-dev] Mono Contributors, Action required: Preparing the Subversion to GIT Migration To: mono-devel-list mono-devel-list@lists.ximian.com, Mono Announce mono-announce-l...@lists.ximian.com, mono-l...@lists.ximian.com Date: Tuesday, June 29, 2010, 4:27 PM Hello guys, As part of our migration from Subversion to GIT, we need all Mono contributors to get a GitHub account and provide your Mono SVN account and your new GitHub account name here: http://spreadsheets.google.com/viewform?hl=enformkey=dEdpdTFoNHBwUUI0clVLRFJtTC02N0E6MQ#gid=0 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Contributors, Action required: Preparing the Subversion to GIT Migration
On 2010-06-30, at 10:33 AM, Miguel de Icaza wrote: Yes, it will. They also have a Subversion bridge that lets you checkout with svn. And commit now. -g --- On Tue, 6/29/10, Miguel de Icaza mig...@novell.com wrote: From: Miguel de Icaza mig...@novell.com Subject: [Mono-dev] Mono Contributors, Action required: Preparing the Subversion to GIT Migration To: mono-devel-list mono-devel-list@lists.ximian.com, Mono Announce mono-announce-l...@lists.ximian.com, mono-l...@lists.ximian.com Date: Tuesday, June 29, 2010, 4:27 PM Hello guys, As part of our migration from Subversion to GIT, we need all Mono contributors to get a GitHub account and provide your Mono SVN account and your new GitHub account name here: http://spreadsheets.google.com/viewform?hl=enformkey=dEdpdTFoNHBwUUI0clVLRFJtTC02N0E6MQ#gid=0 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting .NET application (Namespaces)
On Wed, 2010-06-30 at 06:40 -0700, djdeveloper wrote: I'm asking myself how to port a C#.NET app to mono. Do i have to replace all the usual namespaces like e.g. System.Data with Mono.Data and so on? No. Mono implements most of the .NET System.* namespaces using the same assembly names, namespace names, and class names. Usually [0], no source code modification is needed. Or do I just have to compile using the mono compiler and that's all? If yes, what's the use of e.r. Mono.Data ? Mono prefixed namespaces and assemblies are for Mono extensions to .NET and internal implementation details. For example, Mono.Posix.dll and the Mono.Unix namespace contain POSIX wrappers which are not present in .NET. There is no Mono.Data.dll, but there is a Mono.Data.Sqlite.dll which contains an ADO.NET provider for SQLite (which .NET doesn't provide). Mono.Simd provides a managed wrapper over SIMD instruction sets such as SSE3; .NET has no equivalent. Other Mono.* directories are used to implement the public .NET classes and namespaces, e.g. the implementation of many System.Xml types are done in mcs/class/System.XML/Mono.Xml*, and mscorlib.dll requires a minimal XML parser contained in mcs/class/corlib/Mono.Xml which isn't exposed publicly. - Jon [0] Modulo use of features Mono doesn't implement. See also MoMA: http://www.mono-project.com/MoMA ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Adding documentation for new namespace
On Wed, 2010-06-30 at 14:58 +0100, Chris Bacon wrote: I would like to add some documentation for the System.Diagnostics.Contracts namespace, for which there is currently no documentation. I cannot see a way to add a new namespace using the Mono Documentation Library. Please could someone let me know how best to do this. cd mcs/class/corlib # or some other assembly directory. make PROFILE=net_4_0 doc-update # generates doc stubs in Documentation/en monodoc --edit Documentation/en # view the 'Mono Documentation/mscorlib' node in the # left-hand pane. [0] You can then edit e.g. mcs/class/corlib/Documentation/en/System.Diagnostics.Contracts/*.xml, `svn add` your XML files and `svn commit` them. I've just committed the doc stubs for mscorlib.dll v4.0, so your first commit won't intermix stubs with content (and be gigantic); r159740. To install the docs: cd mcs/docs rm netdocs{.tree,.zip} make PROFILE=net_4_0 make PROFILE=net_4_0 install The intermediate `rm` is needed to ensure that nedocs.zip is rebuilt, as the make(1) dependencies for rebuilding are inadequate. Once you've `make install`ed, monodoc will show the new documentation. - Jon [0] I can't actually recommend 'monodoc --edit' for editing documentation [1], but it is handy for viewing documentation without assembling and installing it. [1] http://www.jprl.com/Blog/archive/development/mono/mdoc/2010/Jan-10.html ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Moonlight and OSS4 sound ubuntu 9.10 and opensuse11.2
Putting # $HOME/.asoundrc pcm.!default { type oss device /dev/dsp } mixer.!default { type oss device /dev/dsp } fixed the sound issue of moonlight on oss4, however the game now is unresponsive for the first 10 seconds, then runs 1/3 the normal speed (while background music plays), then runs normal speed once background music stops, but action sound play fine still. Seems like the constant streaming of background music in the game causes issue (but cpu/resources of computer were not strained). This may not be a mono/moonlight issue at this point. Just posting this, as a search hit, if anyone else has same issue, they can resolve with above .asoundrc entry. tl On Tue, 29 Jun 2010 22:17:01 -0400 ted leslie tles...@tcn.net wrote: In setting up a new opensuse 11.2 install I installed google chrome and installed the preview moonlight (without even thinking, as I thought moonlight didn't work with normal install with chrome), it worked!! But on the dr. dobbs http://dobbschallenge2.com/ silverlight/moonlight game the sound garbled up. (ran ok for 10 seconds then went all freaky). This was probably do to it running in a vmware instance. Youtube did the same (had sound issue). So I installed oss4 as i really prefer it anyways over pulseAudio/alsa. Youtube now works great, but there is no sound in moonlight. I also tried the same game in my native host os ubuntu 9.10, firefox and chrome (same test as in opensuse11.2), and I also have OSS4 as my sound layer there as well. Also no sound in moonlight (dobbs game), but sound work fine for everything else, flash, and wav, etc.(using this set up for over a year). I can dig further, but perhaps someone in the know on moonlight, can very easily comment on why sound doesn't work on linux with OSS4. Is it only made to work with alsa/pulse? It there a solution? One of the really poor things about linux is no good standard sound layer. I have had set ups were pulseaudio works, other set ups where is pure broken. I have used alsa standalone, but had little luck with multiplexing sounds. I know others swear by Jack. For me OSS4 works perfect. But as I see now, not with moonlight :( I am thinking, if everything else works fine in browser (through to oss4), why not moonlight? -- ted leslie tles...@tcn.net ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- ted leslie tles...@tcn.net ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono and Android: Licensing questions
As the official MonoDroid SDK is getting closer to release (relatively speaking), I have a few questions regarding licensing. What part of the Mono project is covered only under the commercial license and what is covered under the general license, with respect to using Mono for commercial android applications? In other words, would I be required to purchase a MonoDroid license under the following scenarios? My current understanding is that I would not need to do so for the first two scenarios, but I would probably need to purchase a license for the fourth scenario. I'm not sure about the third scenario however. 1. I build mono from source myself, use only the runtime, and write all of my own bindings to the android SDK. 2. I build mono from source using Koush's patches and tools (he uses jni4net to facilitate the android/mono bindings, and he wrote his own MonoDevelop add-in). 3. I build mono from source myself, and the application is written using Moonlight (assuming android support is added to moonlight). Any other Android SDK bindings I would write myself or use Koush's bindings. 4. I use the official MonoDroid SDK, distribute the application for free, but the app has advertisements for which I receive income. Are my assumptions regarding scenarios 1, 2, and 4 correct, and what about the third scenario? Also, another question I have is will there be any sort of staggered licensing? I'd like to write android apps as a hobby in my spare time - I don't expect the apps to draw enough income to buy more than a pizza now and then. Will there be a less expensive hobbyist commercial license in the $50-$100 range? ___ 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 Android: Licensing questions
Hello, 1. I build mono from source myself, use only the runtime, and write all of my own bindings to the android SDK. As long as you ensure that the recipient of the software gets all of the benefits that the LGPL grants them (they should be able to relink their app, replace or upgrade Mono for use in your app), you do not need to purchase any licenses. Apple is very specific that the LGPL is not allowed on their appstore, likely due to the restrictions and implicit patent grants that the redistribution of LGPL or GPL software imposes on Apple. Google does not seem to address that issue so far, most likely it is not a problem in that space.But you would have to ask a lawyer the specifics. It does not seem that Google has a problem like Apple has, but there is some criticism of how they handle copyrighted materials: http://nanocr.eu/2010/06/27/googles-mismanagement-of-the-android-market/ 1. I build mono from source using Koush's patches and tools (he uses jni4net to facilitate the android/mono bindings, and he wrote his own MonoDevelop add-in). It is the same scenario. 1. I build mono from source myself, and the application is written using Moonlight (assuming android support is added to moonlight). Any other Android SDK bindings I would write myself or use Koush's bindings. Same scenario. 1. I use the official MonoDroid SDK, distribute the application for free, but the app has advertisements for which I receive income. The MonoDroid SDK contains a commercial license of Mono, plus proprietary code not found in the open source Mono. Also, another question I have is will there be any sort of staggered licensing? I'd like to write android apps as a hobby in my spare time - I don't expect the apps to draw enough income to buy more than a pizza now and then. Will there be a less expensive hobbyist commercial license in the $50-$100 range? We have not decided on the pricing yet, but it will likely be priced in the same MonoTouch range. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Why GIT?
Hi Miguel, I was wondering if you can elaborate on why/how you chose GIT for future source control of Mono? With a lot of options out there, I'm just wanting a peek at some of your or the Mono team's thoughts when evaluating other VCS. Maybe a post on your blog is due :) Thanks, Amir ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Why GIT?
On Wed, Jun 30, 2010 at 7:56 PM, Amir Ebrahimi a...@unity3d.com wrote: Hi Miguel, I was wondering if you can elaborate on why/how you chose GIT for future source control of Mono? With a lot of options out there, I'm just wanting a peek at some of your or the Mono team's thoughts when evaluating other VCS. Maybe a post on your blog is due :) Thanks, Amir Hi Amir, My guess is that Git was chosen because of its wide acceptance in the FOSS community, and because of Mono developers' familiarity with the system. I'm willing to bet that there are technical reasons too, but I can't speak to those. Regards, Bojan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Why GIT?
Hello Amir, I was wondering if you can elaborate on why/how you chose GIT for future source control of Mono? With a lot of options out there, I'm just wanting a peek at some of your or the Mono team's thoughts when evaluating other VCS. Maybe a post on your blog is due :) I am afraid I do not have a great answer to that question. It was mostly inertia from the rest of the team. I do not mind subversion myself and find it very simple to use. But some members in the team have started using svn2git and keeping their own repositories around, so we kind of gravitated there. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list