Published: Thu, 28 Jul 2016 18:18:00 -0500Copyright: Miguel de Icaza
Thu, 28 Jul 2016 22:18:00 -0500
Mobile developers are working with all kinds of graphics assets and until now, to preview them, we would use an external tool to browse them.
We have developed a plug-in for both Visual Studio and Xamarin Studio that will provide live previews of various assets right into the IDE. It works particularly well for UrhoSharp projects.
The previewer can display in the IDE previews of the
following asset types.
For Visual Studio, just download the previwer from the Visual Studio Gallery.
For Xamarin Studio, go to Xamarin Studio > Add-ins go to the "Gallery" tab, and search for "Graphics asset previewer" and install.
Wed, 17 Feb 2016 20:51:00 -0500The Early Days Years ago, in 2008 we introduced an interactive C# shell, at the time a challenge was to adjust the syntax to be suitable for interactive use, to provide a usable decent command line editing API for .NET and to turn our compiler as a service into a tool that could provide code completion. A few months later, we added a UI shell for this on Linux and used Gtk's text widget to add support for embedding rich content into the responses. It was able to render images inline with the responses: This was inspired at the time by the work that Owen Taylor at Red Hat had done on Re-interact. You can still watch a screencast of what it looked like. Like Owen, I added a plot command: At the time, Re-interact took some ideas from IPython and it seems like they are both inspired to some extent by Mathematica's interactive window. Re-interact in particular introduced a brilliant idea, which was that users could go back in history, edit the previous expressions and the entire buffer would be re-evaluated. This idea lives on in Apple's Playgrounds for Swift. In the meantime, the IPython project grew and they added one of my favorite features: it was now possible to blend text, explanations and code into workbooks. You can see a sample of this here. For years, I have desired an IPython for C#. The Xamarin Years In the meantime, at Xamarin, we experimented with the idea of bringing sometehing like Re-interact/Playgrounds to Xamarin Studio and we shipped Sketches: But while these were interesting for trying out ideas and learning C#, they are not very useful for day to day work. We found that what our developers needed was a full C# REPL that was connected to the application they were running on, so they could experiment with their UI live. This is when we introduced Xamarin's Inspector. We took the existing engine and changed the way you interacted with C#. The inspector was originally planned as a debugging aid, one that you could use to attach to a live Android/iOS/WPF process and use to examine: We wrote several backends to provide some visual representation of the running app: While Sketches used the IDE editing surface and a custom renderer view for results, with the Inspector we took a different route. Our interactive surface was an HTML canvas, and our results are rendered using HTML. This allowed us to do some pretty visualizations for results. We have only started to explore what is possible in this space, and our last release included various data renderers. In particular, we added support for pretty printing collections and a handful of native Android and iOS results. Up until now, we had been powered by Mono's C# compiler and while it has served us well for many years, it pales in comparison with the services that we could get out of Microsoft's Roslyn. Our code completion and error reporting were limited and the model did not translate too well to F#. We recently switched the inspector to use Roslyn: With this release, we ended up with an Inspector that can now be used either to debug/analyze a running app (very much like a web inspector), or one that can be used to experiment with APIs in the same spirit as other shells. Continuous In the meantime, Frank Krueger took the iOS support that we introduced for the compiler as a service, and wrote Continuous, a plug-in for Xamarin Studio and Visual Studio that allowed developers to live-code. That is, instead of using this as a separate tool, you can modify your classes and methods live and have your application update as you change the code: Frank also added support for evaluating values immediately, and showing some values in comments, similar in spirit to his Calca app for iOS: The Glorious Future But now that we have a powerful HTML rendering engine to display our results and we upgraded our compiler engine, we are ready to take our next step[...]
Fri, 22 Jan 2016 16:49:00 -0500
My colleague Jason Smith has shared his views on what developers should use when trying to share code between projects. Should you go with a Shared Project or a Portable Class Library (PCL) in the world of Xamarin.Forms?
He hastily concludes that you should go with PCLs (pronounced Pickles).
For me, the PCL is just too cumbersome for most uses. It is like using a canon to kill a fly. It imposes too many limitations (limited API surface), forces you to jump through hoops to achieve some very basic tasks.
PCLs when paired with Nugets are unmatched. Frameworks and library authors should continue to deliver these, because they have a low adoption barrier and in general bring smiles and delight to their users.
But for application developers, I stand firmly on the opposite side of Jason.
I am a fan of simplicity. The simpler the technology, the easier it is for you to change things. And when you are building mobile applications chances are, you will want to make sweeping changes, make changes continously and these are just not compatible with the higher bar required by PCLs.
Jason does not like #if statements on his shared code. But this is not the norm, it is an exception. Not only it is an exception, but careful use of partial classes in C# make this a non issue.
Plugging a platform specific feature does not to use an #if block, all you have to do is isolate the functioanlity into a single method, and have each platform that consumes the code implement that one method. This elegant idea is the same elegant idea that makes the Linux kernel source code such a pleasure to use - specific features are plugged, not #ifdefed.
If you are an application developer, go with Shared Projects for your shared code. And now that we support this for F#, there is no reason to not adopt them.
Thu, 14 Jan 2016 14:27:00 -0500
Back in 2008, I wrote about getline.cs, a single-file command line editor for shell application. It included Emacs key bindings, history, customizable completion and incremental search. It is equivalent to GNU's readline library, except it is implemented in a single C# file.
I recently updated getline.cs to add a popup-based completion and C# heuristics for when to automatically trigger code completion. This is what it looks like when using in Mono's C# REPL in the command line: (image)
Tue, 22 Dec 2015 18:57:00 -0500Mono's master tree now contains support for a new mode of operation for our garbage collector, we call this the cooperative mode. This is in contrast with the default mode of operation, the preemptive mode. This mode is currently enabled by setting the MONO_ENABLE_COOP environment variable. We implemented this new mode of operation to make it simpler to debug our GC, to have access to more data on the runtime during GC times and also to support certain platforms that do not provide the APIs that our preemptive system needed. Behind Preemptive Mode When we started building Mono back in 2001, we wanted to get something up and running very quickly. The idea was to have enough of a system running on Linux that we could have a fully self-hosting C# environment in a short period of time, and we managed to do this within eight months. We were very lucky when it came to garbage collection that the fabulous Boehm GC existed. We were able to quickly add garbage collection to Mono, without having to think much about the problem. Boehm is fabulous because it does not really require the cooperation of the runtime to work. It is a garbage collector that was originally designed to add garbage collection capabilities to programs written in C or C++. It performs garbage collection without much developer intervention. And it achieves this for existing code: multi-threaded, assembly-loving, low-level code. Boehm GC is a thing of beauty. Boehm achieves its magic by pulling some very sophisticated low-level tricks. For example, when it needs to perform a garbage collection it relies on various operating system facilities to stop all running threads, examine the stacks for all these threads to gather roots from the stack, perform the actual GC job then resume the operation of the program. While Boehm is fantastic, in Mono, we had needs that would be better served with a custom garbage collector. One that was generational and reduced collection times. One fit more closely with .NET. It was then that we built the current GC for Mono: SGen. SGen has grown by leaps and bounds and has been key in supporting many advanced scenarios on Android and iOS as well as being a higher performance and lower latency GC for Mono. When we implemented SGen, we had to make some substantial changes to Mono's code generator. This was the first time that Mono's code generator had to coordinate with the GC. SGen kept a key feature of Boehm: most running code was blissfully unaware that it could be stopped and resumed at any point. This meant that we did not have to do too much work to integrate SGen into Mono . There are two main downsides with this. The first downside is that we still required the host platform to support some mechanism to stop, resume and inspect threads. This alone is pretty obnoxious and caused much grief to developers porting Mono to strange platforms. The second downside is that code that runs during the collection is not really allowed to use many of the runtime APIs or primitives, because the collector might be running in parallel to the regular code. You can only use reentrant code. This is a major handicap for development and debugging of the collector. One that is just too obnoxious to deal with and one that has wasted too much of our time. Cooperative Mode In the new cooperative mode, the generated code is instrumented to support voluntarily stopping execution Conceptually, you can think of the generated code as one that basically checks on every back-branch, or every call site that the collector has requested for the thread to stop. The supporting Mono runtime has been instrumented as well to deal with this scenario. This means that every API that is implemented in the C runtime has been audited to determine whether it can run in a finite amount of time, or if it is a blocking operation and adjusted to parti[...]
Mon, 19 Oct 2015 17:01:00 -0500I first heard about David Brooks' article criticizing Most Likely to Succeed from a Mom at school that told me it was a rebuttal to the movie, and I should check it out. I nodded, but did not really expect the article to change my mind. David Brooks is an all-terrain commentator which dispenses platitudes and opinions on a wide range of topics, usually with little depth or understanding. In my book, anyone that supported and amplified the very fishy evidence for going to war with Iraq has to go an extra mile to prove their worth - and he was specially gross when it came to it. Considering that the best part about David Brook's writing is that they often prompt beautiful take downs from Matt Taibbi and that his columns have given rise to a cottage industry of bloggers that routinely point out just how wrong he is, my expectations were low. Anyways, I did read the article. While the tone of the article is a general disagreement with novel approaches to education, his prescription is bland and generic: you need some basic facts before you can build upon those facts and by doing this, you will become a wise person. The question of course is just how many facts? Because it is one thing to know basic facts about our world like the fact that there are countries, and another one to memorize every date and place of a historic event. But you won't find an answer to that on Brooks piece. If there is a case to be made to continue our traditional education and continue relying on tests to raise great kids, you will not find it here. The only thing that transpires from the article is that he has not researched the subject - he is shooting from the hip. An action necessitated by the need to fill eight hundred words a short hour before lunch. His contribution to the future of education brings as much intellectual curiosity as washing the dishes. I rather not shove useless information into our kids. Instead we should fill their most previous years with joy and passion, and give them the tools to plot their own destinies. Raise curious, critical and confident kids. Ones that when faced with a new problem opt for the more rewarding in-depth problem solving, one that will have them research, reach out to primary sources, and help us invent the future. Hopefully we can change education and raise a happier, kinder and better generation of humans. The road to get there will be hard, and we need to empower the teachers and schools that want to bring this change. "Most Likely to Succeed" represends Forward Motion, and helps us start this discussion, and David's opinions should be dismissed for what they are: a case of sloppy stop energy. Do not miss Ted Dintersmith's response to the article, my favorite part: I agree with Brooks that some, perhaps even many, gain knowledge and wisdom over time. We just don’t gain it in school. It comes when we’re fully immersed in our careers, when we do things, face setbacks, apply our learning, and evolve and progress. But that almost always comes after our formal education is over. I interview a LOT of recent college graduates and I’m not finding lots of knowledge and wisdom. Instead, I find lots of student debt, fear of failure, and formulaic thinking. And what do I rarely see? Passion, purpose, creativity, and audacity. So, game on, David Brooks and others defending the 19th Century model of education. [...]
Mon, 21 Sep 2015 21:50:00 -0500
When we did the port we found various leaks in the IDE that were made worse by Roslyn, so we decided to take the time and fix those leaks, and optimize our use of Roslyn.
We want to get your feedback on how well it works and to let us know what problems you are running into. Once we feel that there are no regressions, we will make this part of the default IDE.
While Roslyn is very powerful, this power comes with a memory consumption price tag. The Roslyn edition of Xamarin Studio will use more memory.
We are working to reduce Roslyn's and Xamarin Studio memory usage in future versions.
Wed, 02 Sep 2015 21:41:00 -0500
This past June, Apple announced that WatchOS 2 applications would have to be submitted using LLVM BitCode. The idea being that Apple could optimize your code as new optimizations are developed or new CPU features are introduced, and users would reap the benefits without requiring the developer to resubmit their applications.
BitCode is a serialized version of the low-level intermediate representation used by LLVM.
WatchOS 2 requires pure BitCode to be submitted. That is, BitCode that does not contain any machine code blobs. iOS supports mixed mode BitCode, that is, BitCode that contains both the LLVM intermediate representation code, and blobs of machine code.
While Mono has had an LLVM backend for a long time, generating pure BitCode posed a couple of challenges for us.
First, Mono's LLVM backend does not cover all the generated code. There were some corner cases that we handled with Mono's old code generator. Also, Mono uses hand-written assembly language code in various places (lots of small optimizations involving generics code sharing, method dispatch and other things like that). This poses a problem for WatchOS.
Secondly, Mono uses a modified version of LLVM that adds support for many .NET idioms. In particular, our changes to LLVM produce the necessary information to support .NET-style exception handling .
We spent the summer adapting Mono to produce Vanilla LLVM bitcode support. This includes the removal of our hand-tuned machine code, as well as devising a new system for exception handling that works in this context. Sadly, the exception handling is not as efficient as the one that we got with our modified LLVM.
 Vanilla LLVM exception support requires exceptions to be explicit. In .NET some exceptions happen implicitly, for example, when dereferencing a null pointer, or dividing by zero.
Tue, 01 Sep 2015 14:47:00 -0500
There are four major components of Xamarin's platform product: the Android SDK, the iOS SDK, our Xamarin Studio IDE and our Visual Studio extension.
In the past, we used to release each component independently, but last year we realized that developing and testing each component against the other ones was getting too expensive, too slow and introduced gratuitous errors.
So we switched to a new style of releases where all the components ship together at the same time. We call these cycles.
We have been tuning the cycle releases. We started with time-based releases on a monthly basis, with the idea that any part of the platform that wanted to be released could catch one of these cycles, or wait for the next cycle if they did not have anything ready.
While the theory was great, the internal dependencies of these components was difficult to break, so our cycles started taking longer and longer.
On top of the cycles, we would always prepare builds for new versions of Android and iOS, so we could do same-day releases of the stacks. These are developed against our current stable cycle release, and shipped when we need to.
We are now switching to feature-based releases. This means that we are now waiting for features to be stable, with long preview periods to ensure that no regressions are introduced.
Because feature based releases can take as long as it is needed to ship a feature, we have introduced Service Releases on top of our cycles.
To illustrate this scenario, let me show what our current platform looks like.
We released our Cycle 5 to coincide with the Build conference, back in April 29th. This was our last timed release (we call this C5).
Since then we have shipped three service releases which contain important bug fixes and minor features (C5-SR1, SR2 and SR3), with a fourth being cooked in the oven right now (C5-SR4)
During this time, we have issued parallel previews of Android M and iOS 9 support, those are always built on top of the latest stable cycle. Our next iOS 9 preview for example, will be based on the C5-SR4.
We just branched all of our products for the next upgrade to the platform, Cycle 6.
This is the cycle that is based on Mono 4.2.0 and which contains a major upgrade to our Visual Studio support for iOS and plenty of improvements to Xamarin Studio. I will cover some of my favorite features in Cycle 6 in future posts.
Thu, 27 Aug 2015 16:07:00 -0500This is an update on our efforts to upgrade the TLS stack in Mono. You can skip to the summary at the end if you do not care about the sausage making details. Currently, TLS is surfaced in a few places in the .NET APIs: By the SslStream class, which is a general purpose class that can be used to turn any bidirectional stream into an TLS-powered stream. This class is what currently powers the web client in Mono. By the HttpWebRequest class, which provides .NET's HTTP client. This in turn is the foundation for the modern HttpClient, both the WCF and WebServices stacks as well as the quick and dirty WebClient API. HttpClient is in particular interesting, as it allows for different transports to be provided for it. The default implementation in .NET 4.5 and Mono today is to use an HttpWebRequest-based implementation. But on Windows 10, the implementation is replaced with one that uses WinRT's HTTP client. Microsoft is encouraging developers to abandon HttpWebRequest and instead adopt HttpClient as it both async-friendly and can use the best available transport given on a specific platform. More on this in a second. Mono's Managed TLS Mono currently only supports TLS 1.0. This is the stack that powers SslStream and HttpWebRequest. Last year we started an effort to bring managed implementations of TLS 1.2 and TLS 1.1. Given how serious security has become and how many holes have been found in existing implementation, we built this with an extensive test suite to check for conformance and to avoid common exploits found in implementation mistakes of TLS. This effort is currently under development and you can see where it currently lives at mono-tls module. This will give us complete TLS support for the entire stack, but this work is still going to take a few months to audit. Platform Specific HttpClients Most of the uses for TLS today is via the HTTP protocol, and not over custom TLS streams. This means that it is more important to get an HTTP client that supports a brand new TLS stack, than it is to provide the SslStream code. We want to provide native HttpClient handlers for all of Mono's supported platforms: Android, iOS, Mac, Linux, BSD, Unix and Windows. On iOS: Today Xamarin.iOS already ships a native handler, the CFNetworkHandler. This one is powered by Apple's CFNetwork stack. In recent years, Apple has improved their networking stack, and we now I strongly recommend using Paul Bett's fantastic ModernHttpClient which uses iOS' brand new NSUrlSession and uses OkHttp on Android. On Android: in the short term, we recommend adopting ModernHttpClient from Paul Betts (bonus points: the same component works on iOS with no changes). In the long term, we will change the default handler to use the Android Java client. In both cases, you end up with HTTP 2.0 capable clients for free. But this still leaves Linux, Windows and other assorted operating systems without a regular transport. For those platforms, we will be adopting the CoreFX handlers, which on Unix are powered by the libcurl library. This still leaves HttpWebRequest and everything built on top of it running on top of our TLS stack. Bringing Microsoft's SslStream and HttpWebRequest to Mono While this is not really TLS related, we wanted to bring Microsoft's implementations of those two classes to Mono, as they would fix many odd corner cases in the API, and address limitations in our stack that do not exist in Microsoft's implementation. But the code is tightly coupled to native Windows APIs which makes the adoption of this code difficult. We have built an adaptation layer that will allow us to bring Microsoft's code and use Mono's Managed TLS implementation. SslStream backends O[...]
Tue, 21 Jul 2015 15:53:00 -0500Hello Internet! I wanted to share some updates of Roslyn and Mono. We have been working towards using Roslyn in two scenarios. As the compiler you get when you use Mono, and as the engine that powers code completion and refactoring in the IDE. This post is a status update on the work that we have been doing here. Roslyn on MonoDevelop/XamarinStudio For the past year, we have been working on replacing the IDE's engine that gives us code completion, refactoring capabilities and formatting capabilities with one powered by Roslyn. The current engine is powered by a combination of NRefactory and the Mono C# compiler. It is not as powerful, comprehensive or reliable as Roslyn. Feature-wise, we completed the effort, and we now have a Roslyn-powered branch that uses Roslyn for code completion, refactoring, suggestions and code formatting. In addition, we ported most of the refactoring capabilities from NRefactory to work on top of Roslyn. These were quite significant. Visual Studio users can try them out by installing the Refactoring Essentials for Visual Studio extension. While our Roslyn branch is working great and is a pleasure to use, it also consumes more memory and by extension, runs a little slower. This is not Roslyn's fault, but the side effects of leaks and limitations in our code. Our original plan was to release this for our September release (what we internally call "Cycle 6"), but we decided to pull the feature out from the release to give us time to fix the leaks that affected the Roslyn engine and tune the performance of Roslyn running on Mono. Our revisited plan is to ship an update to our tooling in Cycle 6 (the regular feature update) but without Roslyn. In parallel, we will ship a Roslyn-enabled preview of MonoDevelop/XamarinStudio. This will give us time to collect your feedback on performance and memory usage regressions, and time to fix the issues before we make Roslyn the default. Roslyn as a Compiler in Mono One of the major roadblocks for the adoption of Roslyn in Mono was the requirement to generate debugging information that Mono could consume on Unix (the other one is that our C# batch compiler is still faster than Roslyn). The initial Roslyn release only had support for generating debug information through a proprietary/native library on Windows, which meant that while Roslyn could be used to compile code on Unix, the result would not contain any debug information - this prevented Roslyn from being useful for most compilation uses. Recently, Roslyn got support for Portable Program Database (PPDB) files. This is a fully documented, open, compact and efficient format for storing debug information. Mono's master release contains now support for using PPDB files as its debug information. This means that Roslyn can produce debug information that Mono can consume. That said, we still need more work in the Mono ecosystem to fully support PPDB files. The Cecil library is used extensively to manipulate IL images as well as their associated debug information. Our Reflection.Emit implementation will need to get a backend to generate PPDBs (for third party compilers, dynamic code generators) and support in IKVM to produce PPDB files (this is used by Mono's C# compiler and other third party compilers). Additionally, many features in Roslyn surfaced bloat and bugs in Mono's class libraries. We have been fixing those bugs (and in many cases, the bugs have gone away by replacing Mono's implementation with implementations from Microsoft's Reference Source). [...]
Fri, 23 Jan 2015 00:07:00 -0500
From the sophisticated opinion of the trendsetters to Forbes, the Selfie Stick is the recipient of scorn and ridicule.
One of the popular arguments against the Selfie Stick is that you should build the courage to ask a stranger to take a picture of you or your group.
This poses three problems.
First, the courage/imposition problem. Asking a stranger in the street assumes that you will find such a volunteer.
Further, it assumes that the volunteer will have the patience to wait for the perfect shot ("wait, I want the waves breaking" or "Try to get the sign, just on top of me"). And that the volunteer will have the patience to show you the result and take another picture.
Often, the selfista that has amassed the courage to approach a stranger on the street, out of politeness, will just accept the shot as taken. Good or bad.
Except for a few of you (I am looking at you Patrick), most people feel uncomfortable imposing something out of the blue on a stranger.
And out of shyness, will not ask a second stranger for a better shot as long as the first one is within earshot.
I know this.
Second, you might fear for the stranger to either take your precious iPhone 6+ and run, or even worse, that he might sweat all over your beautiful phone and you might need to disinfect it.
Do not pretend like you do not care about this, because I know you do.
Third, and most important, we have the legal aspect.
When you ask someone to take a picture of you, technically, they are the photographer, and they own the copyright of your picture.
This means that they own the rights to the picture and are entitled to copyright protection. The photographer, and, not you, gets to decide on the terms to distribute, redistribute, publish or share the picture with others. Including making copies of it, or most every other thing that you might want to do with those pictures.
You need to explicitly get a license from them, or purchase the rights. Otherwise, ten years from now, you may find yourself facing a copyright lawsuit.
All of a sudden, your backpacking adventure in Europe requires you to pack a stack of legal contracts.
Now your exchange goes from "Can you take a picture of us?" to "Can you take a picture of us, making sure that the church is on the top right corner, and also, I am going to need you to sign this paper".
Using a Selfie Stick may feel awkward, but just like a condom, when properly used, it is the best protection against unwanted surprises.
Mon, 01 Dec 2014 22:47:00 -0500
Do you know of someone that would like to participate in the .NET foundation, as part of the .NET Foundation Advisory Council?
Check the discussion where we are discussing the role of the Advisory Council.
Wed, 12 Nov 2014 15:44:00 -0500Today, Scott Guthrie announced that Microsoft is open sourcing .NET. This is a momentous occasion, and one that I have advocated for many years. .NET is being open sourced under the MIT license. Not only is the code being released under this very permissive license, but Microsoft is providing a patent promise to ensure that .NET will get the adoption it deserves. The code is being hosted at the .NET Foundation's github repository. This patent promise addresses the historical concerns that the open source, Unix and free software communities have raised over the years. .NET Components There are three components being open sourced: the .NET Framework Libraries, .NET Core Framework Libraries and the RyuJit VM. More details below. .NET Framework Class Libraries These are the class libraries that power the .NET framework as it ships on windows. The ones that Mono has historically implemented in an open source fashion. The code is available today from http://github.com/Microsoft/referencesource. Mono will be able to use as much a it wants from this project. We have a project underway that already does this. We are replacing chunks of Mono code that was either incomplete, buggy, or not as fully featured as it should be with Microsoft's code. We will be checking the code into github.com/mono by the end of the week (I am currently in NY celebrating :-) Microsoft has stated that they do not currently plan on taking patches back or engaging into a full open source community style development of this code base, as the requirements for backwards compatibility on Windows are very high. .NET Core The .NET Core is a redesigned version of .NET that is based on the simplified version of the class libraries as well as a design that allows for .NET to be incorporated into applications. Those of you familiar with the PCL 2.0 contract assemblies have a good idea of what these assemblies will look like. This effort is being hosted at https://github.com/dotnet/corefx and is an effort where Microsoft will fully engage with the community to evolve, develop and improve the class libraries. Today, they released the first few components to github; the plan is for the rest of the redesigned frameworks to be checked in here in the next few months. Xamarin and the Mono project will be contributing to the efforts to bring .NET to Mac, Unix, Linux and other platforms. We will do this as Microsoft open sources more pieces of .NET Core, including RyuJIT. Next Steps Like we did in the past with .NET code that Microsoft open sourced, and like we did with Roslyn, we are going to be integrating this code into Mono and Xamarin's products. Later this week, expect updated versions of the Mono project roadmap and a list of tasks that need to be completed to integrate the Microsoft .NET Framework code into Mono. Longer term, we will make the Mono virtual machine support the new .NET Core deployment model as well as the new VM/class library interface We are going to be moving the .NET Core discussions over to the .NET Foundation Forums. With the Mono project, we have spent 14 years working on open source .NET. Having Microsoft release .NET and issue a patent covenant will ensure that we can all cooperate and build a more vibrant, richer, and larger .NET community. [...]
Thu, 23 Oct 2014 21:18:00 -0500
(image) Earlier this year, both Epic Games and CryTech made their Unreal Engine and CryEngine available under an affordable subscription model. These are both very sophisticated game engines that power some high end and popular games.
We had previously helped Unity bring Mono as the scripting language used in their engine and we now had a chance to do this over again.
Today I am happy to introduce Mono for Unreal Engine.
This is a project that allows Unreal Engine users to build their game code in C# or F#.
Take a look at this video for a quick overview of what we did:
width="720" height="405" src="//www.youtube.com/embed/5hAahXahUVU" frameborder="0" allowfullscreen>
This is a taste of what you get out of the box:
This is not a supported product by Xamarin. It is currently delivered as a source code package with patches that must be applied to a precise version of Unreal Engine before you can use it. If you want to use higher versions, or lower versions, you will likely need to adjust the patches on your own.
We have set up a mailing list that you can use to join the conversation about this project.
Visit the site for Mono for Unreal Engine to learn more.
(I no longer have time to manage comments on the blog, please use the mailing list to discuss).
Tue, 14 Oct 2014 15:20:00 -0500
Today, I want to share some news from the .NET Foundation.
Forums: We are launching the official .NET Foundation forums to engage with the larger .NET community and to start the flow of ideas on the future of .NET, the community of users of .NET, and the community of contributors to the .NET ecosystem.
Please join us at forums.dotnetfoundation.org. We are using the powerful Discourse platform. Come join us!
Advisory Council: We want to make the .NET Foundation open and transparent. To achieve that goal, we decided to create an advisory council. But we need your help in shaping the advisory council: its role, its reach, its obligations and its influence on the foundation itself.
To bootstrap the discussion, we have a baseline proposal that was contributed by Shaun Walker. We want to invite the larger .NET community to a conversation about this proposal and help us shape the advisory council.
Wed, 01 Oct 2014 01:53:00 -0500Markdown is as a file format for easily producing text that can be pleasantly read both on the web and while using command line tools, or plain text editors. Recently, a crop of tools have emerged that deliver some form of WYSIWYG or side-by-side authoring tools to assist writers to visualize the final output as they work. Authors are turning to these tools to produce documentation that looks good when authoring the document, yet the tools are not true to the spirit and goals of markdown. And in some cases, authors are not familiar with the essence of what makes markdown great, nor the philosophy behind it: Readability, however, is emphasized above all else. A Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. Using these editors is the modern equivalent of using Microsoft Word to produce HTML documentation. The generated markdown files very easy to produce, but are not suitable for human consumption. They likely violate a number of international treaties and probably will be banned by the EU. This short post is a set of simple rules to improve your markdown. They will help you deliver delight to all of your users, not just those using a web browser, but also those casually reading your documentation with a file manager, their console, and most importantly, potential contributors and copy editors that have to interact with your text. Wrap Your Text The ideal reading length for reading prose with a monospaced font is somewhere between 72 and 78 characters. This is text snippet is from Mark Twain's Adventures of Tom Sawyer, with text wrapped around column 72, when reading in an 80x25 console: It wont matter if you are using a larger console, the text will still be pleasant to read. But if you use some of these markdown editors that do not bother wrapping your text, this is what the user would get: And this is what is more likely to happen, with big consoles on big displays: There is a reason why most web sites set a maximum width for the places where text will be displayed. It is just too obnoxious to read otherwise. Many text editors have the ability of reformatting text your text when you make changes. This is how you can fill your text in some common editors: Emacs: Alt-Q will reformat your paragraph. Vim: "V" (to start selection) then "gq" will reformat your selection. TextMate: Control-Q. Considering Using Two Spaces After a Period When reading text on the console, using two spaces after a period makes it easier to see where phrases end and start. While there is some debate as to the righteouness of one vs two spaces in the word of advanced typography these do not apply to markdown text. When markdown is rendered into HTML, the browser will ignore the two spaces and turn it into one, but you will give your users the extra visual cues that they need when reading text. If you are interested in the topic, check these posts by Heraclitean River and DitchWalk. Sample Code For small code snippets, it is best if you just indent your code with spaces, as this will make your console experience more pleasant to use. Recently many tools started delimiting code with the "```". While this has its place in large chunks of text, for small snippets, it is the visual equivalent of being punched in the face. Try to punch your readers in the face only when absolutely necessary. Headers Unless you have plans to use multiple-nested level of headers, use the u[...]
Wed, 20 Aug 2014 16:26:00 -0500
I wanted to share three tricks that I use a lot in Xamarin Studio/MonoDevelop.
Xamarin Studio's code completion for members of an object defaults to showing all the members sorted by name.
But if you press Control-space, it toggles the rendering and organizes the results. For example, for this object of type UIWindow, it first lists the methods available for UIWindow sorted by name, and then the cluster for its base class UIView: (image)
This is what happens if you scroll to the end of the UIWindow members: (image)
Use the Command-. shortcut to activate the universal search, once you do this and start typing it will find matches for both members and types in your solution, as well as IDE commands and the option to perform a full text search: (image)
This is a feature that we took from Emacs's Dynamic Abbrevs.
If you type Control-/ when you type some text, the editor will try to complete the text you are typing based on strings found in your project that start with the same prefix.
Hit control-/ repeatedly to cycle over possible completions. (image)
Wed, 23 Jul 2014 14:28:00 -0500
For many years a major focus of Mono has been to be compatible-enough with .NET and to support the popular features that developers use.
We have always believed that it is better to be slow and correct than to be fast and wrong.
That said, over the years we have embarked on some multi-year projects to address some of the major performance bottlenecks: from implementing a precise GC and fine tuning it for a number of different workloads to having implemented now four versions of the code generator as well as the LLVM backend for additional speed and things like Mono.SIMD.
But these optimizations have been mostly reactive: we wait for someone to identify or spot a problem, and then we start working on a solution.
We are now taking a proactive approach.
A few months ago, Mark Probst started the new Mono performance team. The goal of the team is to improve the performance of the Mono runtime and treat performance improvements as a feature that is continously being developed, fine-tuned and monitored.
The team is working both on ways to track performance of Mono over time, implemented support for getting better insights into what happens inside the runtime and has implemented several optimizations that have been landing into Mono for the last few months.
We are actively hiring for developers to join the Mono performance team (ideally in San Francisco, where Mark is based).
Most recently, the team added a new and sophisticated new stack for performance counters which allows us to monitor what is happening on the runtime, and we are now able to export to our profiler (a joint effort between our performance team and our feature team and implemented by Ludovic). We also unified both the runtime and user-defined performance counters and will soon be sharing a new profiler UI.
Wed, 21 May 2014 19:03:00 -0500Snowden is quoted on Greenwald's new book "No Place to Hide" as wanting to both spark a debate over the use of surveillance and to get software developers to adopt and create better encryption: While I pray that public awareness and debate will lead to reform, bear in mind that the policies of men change in time, and even the Constitution is subverted when the appetites of power demand it. In words from history: Let us speak no more of faith in man, but bind him down from mischief by the chains of cryptography. [...] The shock of this initial period [after the first revelations] will provide the support needed to build a more equal internet, but this will not work to the advantage of the average person unless science outpaces law. By understanding the mechanisms through which our privacy is violated, we can win here. We can guarantee for all people equal protection against unreasonable search through universal laws, but only if the technical community is willing to face the threat and commit to implementing over-engineered solutions. Last week Matthew Green asked: So has Snowden succeeded? Have developers 'created better encryption' since his leaks?— Matthew Green (@matthew_d_green) May 14, 2014 Only time will be able to answer whether as a community the tech world can devise better and simpler tools for normal users to have their privacy protected by default. Snowden has succeeded in starting an important discussion and having software developers and their patrons react to the news. At Xamarin we build developer tools for Android and iOS developers. It is our job to provide tools that developers use on a day to day basis to build their applications, and we help them build these mobile applications. In the last year, we have noticed several changes in our developer userbase. Our customers are requesting both features and guidance on a number of areas. Developers are reaching to us both because there is a new understanding about what is happening to our electronic communications and also response to rapidly changing requirements from the public and private sectors. Among the things we have noticed: Using Trusted Roots Respectfully: For years, we tried to educate our users on what they should do when dealing with X509 certificates. Two years ago, most users would just pick the first option "Ignore the problem". Today this is no longer what developers do by default. Certificate Pinning: more than ever, developers are using certificate pinning to ensure that their mobile applications are only talking to the exact party they want to. Ciphersuite Selection: We recently had to extend the .NET API to allow developers to force our networking stack to control which cipher suites the underlying SSL/TLS stack uses. This is used to prevent weak or suspected ciphersuites to be used for the communications. Request for more CipherSuites: Our Mono runtime implements its own SSL/TLS and crypto stacks entirely in C#. Our customers have asked us to support new cipher suites on newer versions of the standards. Sometimes developers can use the native APIs we provide to achieve the above goals, but sometimes the native APIs on Android and iOS make this very hard or do not expose the new desired functionality, so we need to step in. [...]
Mon, 12 May 2014 21:48:00 -0500
Some great announcements today from the Microsoft world.
The first one is that Microsoft's next generation web stack (ASP.NET vNext) is open source from the ground up, and runs on Mono on both Linux and Mac.
There are plenty of other design principles in this new version of ASP.NET. I provide a translation from Microsoft speak into Unix speak in parenthesis:
Update: And the software is live at http://github.com/aspnet
They are shipping a number of new components to talk to their online services, and they all have a license suitable for being used from platforms other than Windows.
Mon, 28 Apr 2014 21:41:00 -0500
As promised, we are now tracking the Unix-friendly Roslyn port on Mono's GitHub Organization.
We implemented a few C# 6.0 features in Mono's C# compiler to simplify the set of patches required to compile Roslyn.
So you will need a fresh Mono (from git).
Mon, 14 Apr 2014 14:53:00 -0500
The team has put together some beautiful getting started documentation for our iOS User Interface Designer.
In particular, check a couple of hot features on it:
Mon, 14 Apr 2014 14:50:00 -0500
We have been working with a few PlayStation 4 C# lovers for the last few months. The first PS4 powered by Mono and MonoGame was TowerFall:
We are very excited about the upcoming Transistor, by the makers of Bastion, coming out on May 20th:
Mono on the PS4 is based on a special branch of Mono that was originally designed to support static compilation for Windows's WinStore applications .
 Kind of not very useful anymore, since Microsoft just shipped static compilation of .NET at BUILD. Still, there is no wasted effort in Mono land!
Wed, 09 Apr 2014 17:03:00 -0500Last week, Microsoft open sourced Roslyn, the .NET Compiler Platform for C# and VB. Roslyn is an effort to create a new generation of compilers written in managed code. In addition to the standard batch compiler, it contains a compiler API that can be used by all kinds of tools that want to understand and manipulate C# source code. Roslyn is the foundation that powers the new smarts in Visual Studio and can also be used for static analysis, code refactoring or even to smartly navigate your source code. It is a great foundation that tool developers will be able to build on. I had the honor of sharing the stage with Anders Hejlsberg when he published the source code, and showed both Roslyn working on a Mac with Mono, as well as showing the very same patch that he demoed on stage running on Mono. Roslyn on Mono At BUILD, we showed Roslyn running on Mono. If you want to run your own copy of Roslyn today, you need to use both a fresh version of Mono, and apply a handful of patches to Roslyn . The source code as released contains some C# 6.0 features so the patches add a bootstrapping phase, allowing Roslyn to be built with a C# 5.0 compiler from sources. There are also a couple of patches to deal with paths (Windows vs Unix paths) as well as a Unix Makefile to build the result. Sadly, Roslyn's build script depends on a number of features of MSBuild that neither Mono or MonoDevelop/XamarinStudio support currently , but we hope we can address in the future. For now, we will have to maintain a Makefile-based system to use Roslyn. Our patches no longer apply to the tip of Roslyn master, as Roslyn is under very active development. We will be updating the patches and track Roslyn master on our fork moving forward. Currently Roslyn generates debug information using a Visual Studio native library. So the /debug switch does not work. We will be providing an alternative implementation that uses Mono's symbol writer. Adopting Roslyn: Mono SDK Our goal is to keep track of Roslyn as it is being developed, and when it is officially released, to bundle Roslyn's compilers with Mono . But in addition, this will provide an up-to-date and compliant Visual Basic.NET compiler to Unix platforms. Our plans currently are to keep both compilers around, and we will implement the various C# 6.0 features into Mono's C# compiler. There are a couple of reasons for this. Our batch compiler has been fine tuned over the years, and for day-to-day compilation it is currently faster than the Roslyn compiler. The second one is that our compiler powers our Interactive C# Shell and we are about to launch something very interesting with it. This functionality is not currently available on the open sourced Roslyn stack. In addition, we plan on distributing the various Roslyn assemblies to Mono users, so they can build their own tools on top of Roslyn out of the box. Adopting Roslyn: MonoDevelop/Xamarin Studio Roslyn really shines for use in IDEs. We have started an effort to adopt Roslyn in MonoDevelop/Xamarin Studio. This means that the underlying NRefactory engine will also adopt Roslyn. This is going to be a gradual process, and during the migration the goal is to keep using both Mono's C# compiler as a service engine and bit by bit, replace with the Roslyn co[...]
Sat, 04 Jan 2014 11:52:00 -0500
Herb Sutter from the ISO C++ group, reached out to the Cairo folks:
We are actively looking at the potential standardization of a basic 2D drawing library for ISO C++, and would like to base it on (or outright adopt, possibly as a binding) solid prior art in the form of an existing library.
we are focused on current Cairo as a starting point, even though it's not C++ -- we believe Cairo itself it is very well written C (already in an OO style, already const-correct, etc.).
Congratulations to the Cairo guys for designing such a pleasant to use 2D API.
But this would not be a Saturday blog post without pointing out that Cairo's C-based API is easier and simpler to use than many of those C++ libraries out there. The more sophisticated the use of the C++ language to get some performance benefit, the more unpleasant the API is to use.
The incredibly powerful Antigrain sports an insanely fast software renderer and also a quite hostile template-based API.
We got to compare Antigrain and Cairo back when we worked on Moonlight. Cairo was the clear winner.
We built Moonlight in C++ for all the wrong reasons ("better performance", "memory usage") and was a decision we came to regret. Not only were the reasons wrong, it is not clear we got any performance benefit and it is clear that we did worse with memory usage.
But that is a story for another time.
Tue, 29 Oct 2013 19:35:00 -0500
Few guys have approached us recently about doing remote debugging of a Mono process. Typically this involves an underpowered system, or some kind of embedded system running Mono, and a fancy Mac or PC on the other end.
These are the instructions that Michael Hutchinson kindly provided on how to remotely debug your process using either Xamarin Studio or MonoDevelop:
Remote debugging is actually really easy with the Mono soft debugger. The IDE sends commands over TCP/IP to the Mono Soft Debugger agent inside the runtime. Depending how you launch the debuggee, you can either have it connect to the IDE over TCP, or have it open a port and wait for the IDE to connect to it.
For simple prototyping purposes, you can just set the
MONODEVELOP_SDB_TESTenv var, and a new "Run->Run With->Custom Soft Debugger" command will show up in Xamarin Studio / MonoDevelop, and you can specify an arbitrary IP and port or connect or or listen on, and optionally a command to run. Then you just have to start the debuggee with the correct
--debugger-agentarguments (see the Mono manpage for details), start the connection, and start debugging.
For a production workflow, you'd typically create a MonoDevelop addin with a debugger engine and session subclassing the soft debugger classes, and overriding how to launch the app and set up the connection parameters. You'd typically have a custom project type too subclassing the DotNetProject, so you could override how the project was built and executed, and so that the new debugger engine could be the primary debugger for projects of that type. You'd get all the default .NET/Mono project and debugger functionality "for free".
You can get some inspiration on how to build your own add-in from the old MeeGo add-in. It has bitrotted, since MeeGo is no more, but it is good enough as a starting point.
Thu, 22 Aug 2013 23:41:00 -0500
I am hiring software developers.
We are growing our Xamarin Studio/MonoDevelop, Visual Studio, iOS and Android teams.
Ideally, you are a C# programmer and ideally, you relocate to Boston, MA. But we can work with remote employees
Tue, 20 Aug 2013 20:17:00 -0500
Check their home page on GitHub with cute videos!
PlayScript is a superset of ActionScript and it was based on Mono's C# 5.0 compiler. PlayScript is ActionScript augmented with C# 5.0 features.
Zynga's PlayScript allows developers that have some ActionScript/Flash code to bring their code to any platform that supports the ECMA Intermediate Language (Microsoft .NET and Mono) and blend it with other .NET languages.
But the PlayScript has a fabulous feature, it allows mixing code in both C# and PlayScript in the same compilation unit. For example, you can use the compiler like this:
# Compile the C# source foo.cs into foo.exe $ mcs foo.cs # Compile the Playscript source bar.play into bar.exe $ mcs bar.play # Compile both C# and Playscript into a single executable $ mcs foo.cs bar.play
On a larger scale, you can see this in action in the pscorlib library. This library contains a blend of PlayScript and C# source code compiled into a single binary.
They have also an add-on for Xamarin Studio that you can use to get IDE support for it.
Just like Unity's UnityScript, developers will be encouraged to use strong types to improve the performance of their applications.
Update: Some background on Playscript.