Disclaimer: this is an automatic aggregator which pulls feeds and comments from many blogs of contributors that have contributed to the Mono project. The contents of these blog entries do not necessarily reflect Xamarin's position.

May 16

Touch.Unit vs NUnitLite 0.7

Last week Charlie Poole released NUnitLite 0.7. This new release greatly reduce the feature gap between the older 0.6 release and the upcoming NUnit 3.

I know people will rejoice having Assert.AreEqual(x,y) back as it is simpler than the Assert.That (x, Is.EqualTo (y)) syntax. Personally I’m more happy about Assert.Throw as I really like this one over the [ExpectedException] attribute. There’s a lot of new features / attributes, many I never used (since the Mono-shipped version of NUnit did not have them), that should prove useful.

At this stage the only missing piece, IMHO (but shared with others too), is the lack of async testing – which I grown fond of during Moonlight‘s development.

Anyway this post is to announce that Touch.Unit was updated to use this new 0.7 version of NUnitLite. Existing (old) features should be working fine (MonoTouch bots seems quite happy with it) but I have not yet used (tested ?) most of the new features. If you find anything wrong please fill a bug report !

Availability: The next version of MonoTouch 5.3.x will provide the updated Touch.Unit runner but if you can’t wait (or update) then pull the update from github and “test” it away :-)


May 15

Calling all social coders: Xamarin is hiring Developer Evangelists

As we continue to rapidly grow at Xamarin, we’ve reached a point where we are looking to spread the word about MonoTouch and Mono for Android to even more developers around the world. To do this we’re creating a new team of social coders to represent us to the community as Developer Evangelists.

What is a Developer Evangelist? The job of an evangelist (sometimes called a Developer Advocate) is to raise awareness for our products in developer communities online and off. This means doing things like speaking at events, creating blog posts and screencasts, answering questions on Stack Overflow or anything else that helps our customers be successful.

Maybe you’ve never considered being an Evangelist because it’s “too sales-y” or “not technical enough”. At Xamarin, that’s not the case. The Evangelist’s job is to build relationships with developers and be a technical ally to our customers. That means you can get your hands as dirty as you want and you can leave the selling up to our excellent sales team.

Here are a few other reasons why you should consider it:

Work with Some of the Best Engineers in the World

We’ve taken great care to hire the best talent we can find. They’ve created a set of tools that are enabling developers all over the world to build great apps. The biggest injustice to a product is for the customer that needs it to never know it exists. Your job is to bring our engineer’s hard work out into the world and get it into the right hands. And when those customers need someone to advocate for them on the inside, you represent them back to the company.

Mobile is the Future Present

The mobile industry is relatively young, but it’s clearly the direction the computing world is heading. Xamarin is situated right in the heart of the mobile movement and committed to making the best cross-platform mobile development tools in the industry.

Satisfaction From Enabling Others

Much of the work you’ll be doing is helping customers be more successful at whatever it is they’re trying to accomplish. You’ll help startups build the prototypes that help them get funded. You’ll help giant companies save millions of dollars. You’ll help developers learn new skills that help them get a better job. I can’t overstate how satisfying is to watch someone you helped become successful, but I’ll try anyway. It’s infinitely satisfying. And you’ll be doing it every day.

Autonomy and Variety of Work

We’re growing fast, so we have a lot of work to do, and evangelists will always have way more work than they could reasonably finish. It’s up to them to decide what exactly they should be working on at any time.

In order to be autonomous you need to be good at doing a lot of different things. If the most important thing you could be doing right now is writing a blog post, you need to be a good writer. If it’s writing a utility or helping a customer with a prototype, you better be a good coder. Evangelists tend to be a combination of engineer, support, marketing, sales, business development, and product. Having the ability to shift roles quickly goes a long way to satisfying all of those needs. If you thrive on constantly taking on different kinds of problems, you’ll find a lot of satisfaction in finishing all of the different kinds of tasks presented to you.

If you’re good at just a few of those things, the time constraints of the job will likely force you to get stronger in your weak areas very quickly. Having a wide variety of work can also help you get over hurdles (like writer’s block) by letting you shift modes for a little while. After some time in the role you’re almost guaranteed to be a much more well-rounded overall employee.

Travel the World (or Not)

You’re probably thinking one of two things: “I love seeing new places, that sounds cool” or “traveling is the WORST”. Good news, traveling gets better the more you do it (the airlines treat you a lot better if you fly a lot) but if that’s still not your thing, we’re also hiring evangelists to focus their efforts on online communities and activities. If you do like to travel, you’ll rack up a ton of frequent flyer miles that are yours to keep and you’ll get to spend time at all the conferences you’ve always wanted to attend.

Are you ready?

If this sounds exciting to you, we want to hear from you! We’re looking for multiple evangelists based in San Francisco, CA or Cambridge, MA with relocation assistance available if you’re willing to move. We’ll also consider remote employees if you’re located in a major metropolitan area and don’t mind traveling to the office occasionally. We have competitive salary and benefits. We’re growing fast and are cash-flow positive.

Join us.

Migrate from Mercurial

Here it comes: A new entry about how to migrate your existing repository into Plastic SCM! This time, the unwitting subject of our inquiry is .... Mercurial!

Things we need:
  • An Hg repository
  • Git installed
  • Plastic SCM


Hg-Fast-Export Tool

Download the hg-fast-export tool from HERE. This Python tool will allow us to migrate the Hg repository to a Git repository. Download and decompress the tool, then issue the following commands to migrate the repository into Git.

$ ...
$ mkdir hg_migrated_repository
$ cd hg_migrated_repository
$ git init
$ /path/to/hg-fast-export.sh -r /path/to/hg_repo
$ ...

I know this seems a bit roundabout, so let me explain. The hg-fast-export tool creates an import package that's in the old standard "inline" format. Plastic SCM does not support that format yet (though we plan on it soon!), instead opting to support Git's newer and more efficient import package format. Git is then the logical go-between to get from Hg to our very own Plastic SCM.

Import to Plastic SCM

As you know from previous blog posts, you only need to fast-export the Git repository and finally fast-import it into Plastic SCM. Here's a refresher:

$ ...
$ git fast-export --all -C --tag-of-filtered-object=drop --signed-tags=strip > repo.fe
$ cm fast-import myHgrepo@localhost:8087 repo.fe
$ ...

And that's all! Easy, right?

Creative Assembly Developer Profile

The Creative Assembly is a veteran game studio celebrating its 25th birthday this year. Known for the Total War game series, they have recently brought the series to a whole new audience of gamers in the form of iOS title ‘Total War Battles: Shogun’. Available on the App Store now, the game brings a mix of turn-based, real time strategy and puzzle gaming to iOS, and the studio plans to bring it to Google Android devices soon.

Historically, the Creative Assembly have worked purely on PC and Consoles, writing their own engine tech for the Total War series, we visited the studio to ask them about their experience of using Unity to take the series to mobile platforms.

Check out Total War Battles: Shogun on the App Store -
http://itunes.apple.com/us/app/total-war-battles/id499885330?mt=8

May 14

Xamarin Designer for Android available for Visual Studio and MonoDevelop

Today, we’re thrilled to announce the arrival of the Xamarin Designer for Android, which makes it incredibly easy for Android developers to visually create beautiful layouts for their applications from directly within Visual Studio and MonoDevelop.

The biggest single complaint we’ve heard about Android development from Mono for Android developers has been the absence of a great Android layout designer. With Xamarin Designer for Android, we’ve delivered the kind of design experience C# developers expect from their favorite IDE. To learn more about the Xamarin Designer, check out our Designer Overview and Designer Walkthrough

Along with Xamarin Designer for Android, we’re also releasing Mono for Android 4.2 and MonoDevelop 3.0 – both monumental releases in their own right.

Mono for Android 4.2

Beyond Xamarin Designer support, Mono for Android sports many delicious improvements.

Android Java Binding Library project and tool

This release introduces a new project type that enables consumption of Android Java libraries (.jar) from C# assemblies (.dll). For a more in-depth explanation, see the Java Binding Library tutorial.

Graceful Degradation of UI

Mono for Android 4.2 includes bindings to Android’s Support Package, enabling developers to use a selection of Honeycomb APIs on devices running Android Level 4 and greater. Learn more about how to integrate this into your application with our Android Fragments Walkthrough.

x86 Support

Android x86 installs are fully supported by Mono for Android, including support for debugging official Android x86 emulator images from a Mono for Android trial installation. Debugging an app deployed against an x86 image offers much better performance compared to ARM emulator deployments. We also have an article to walk you through Configuring the x86 Emulator.

Much more

Additional Mono for Android 4.2 features include a 50% smaller shared runtime, a new device toolbar, non-modal deployment, and integrated logcat for Visual Studio. Even more details can be found in the Mono for Android 4.2 Release Notes

MonoDevelop 3.0

The major focus of MonoDevelop 3.0 is a new C# code completion engine, which provides more accurate and reliable code completion and navigation, semantic highlighting for C# files, and a reliable on-the-fly code formatter.

Other improvements include a revamped Assembly Browser, preliminary support for Portable Library Projects, better handling of large projects, and virtual indenting in the source editor. You can read more about all the new improvements in our complete write-up of What’s new in MonoDevelop 3.0.

AnDevCon III

If you’re in California this week for AnDevCon III, you can come check out demos of all of this and more by coming by the Xamarin booth (401).

May 13

Catch Bryan Costanich at AnDevCon and DevTeach

Bryan Costanich, Xamarin’s Director of Education, will be speaking about mobile development and the state of the mobile industry at AnDevCon and DevTeach this May.

Bryan’s first talk will be at AnDevCon in the San Francisco Bay Area, where Bryan will cover cross-platform development in C# using the Mobile World Congress 2012 app as a case study. He will focus on architectural best practices, and touch on some of the design considerations that come up when building cross-platform apps. Bryan will also deliver a version of this talk at DevTeach in Vancouver on May 30th.

The DevTeach session will be preceded by an in-depth discussion of the mobile industry, where Bryan will introduce the mobile ecosystem and the four major platforms that fuel it. This separate talk is meant to give developers and entrepreneurs alike a solid grounding in the workings of the mobile economy. You don’t want to miss it!


Cross-Platform Mobile Development with Xamarin

Using C# to Build Native Apps That Share Code Across Android, iOS and Windows Devices

AnDevCon, Wednesday, May 16th at 3:30pm
DevTeach, Wednesday May 30 at 9:30am in room Tiffany A

Native apps have many performance, functionality and usability benefits over HTML5-based apps, but maintaining OS-specific codebases is time consuming and expensive. Using a real–world conference scheduling app built for Mobile World Congress 2012, this case study will outline how to use C# and .NET to design and develop native apps that share code across Android, iOS and Windows. This session will cover how to:

  • Use a fully layered architecture adhering to Object Oriented principles
  • Leverage a unified cross-platform data layer
  • Share the business layer across all platforms
  • Use the native control toolkit on each platform to ensure device-specific user-experiences
  • Run as a native application to avoid performance sacrifices
  • Minimize the amount of code written by using existing frameworks

We will also discuss how leveraging things like the ORM for data access, .NET framework for Web calls, and MonoTouch.Dialog for iOS UI, and other bits, can significantly reduce the amount of code you need to write.

Register for AnDevCon    Register for DevTeach

The Business of Mobile Development

DevTeach only, Wednesday May 30, 2012 at 8am in room Tiffany A

Everyone has heard stories about developers making money with Apple’s App Store, but that’s just a small piece of the pie in the enormous mobile ecosystem. In this eye-opening session, we’re going to first look at the overall market and importance of the mobile space, and then we’re going to jump into market shares of the four big mobile platforms; iOS, Android, Windows Phone 7, and Blackberry. In doing so, we’re going to examine the value chain and ecosystem that has built up around each of these platforms and see where money is being spent, and where money is to be made. This session offers some surprising insights and is a must for both existing mobile developers and people considering breaking into mobile development.

Register for DevTeach

May 11

Using MethodRental.SwapMethodBody to do Method Level JIT Compilation

IKVM.NET has always had a class granularity JIT. Whenever a type is first "used" the CLR fires the AppDomain.TypeResolve event and at that point the IKVM.NET runtime compiles the Java bytecode to CIL for all of the methods in the class.

I don't recall my exact thought process, but I assume that when I started on IKVM.NET I looked at MethodRental.SwapMethodBody and was scared away by the lack of documentation and the fact that it requires full trust and manually constructing a method body blob.

Later on, I focussed more on static compilation and didn't care too deeply about dynamic performance. So I never revisited this decision. However, recently I have been thinking about dynamic performance, triggered by potential invokedynamic optimizations.

To get reacquainted with MethodRental.SwapMethodBody I wrote a small program that dynamically creates the following class:

class Frob {
public Frob(int i) { Console.WriteLine(i); } public static void M(int i) { Console.WriteLine(); Console.WriteLine(new Frob(i)); } }

The code is available here: MethodRentalDemo.cs

When the constructor and the M method are first created, the method body is defined, using MethodBuilder.CreateMethodBody, as a simple trampoline that calls Program.JIT to just-in-time generate the actual CIL for the method.

Here's the managed JIT trampoline CIL code for Frob.M:

ldtoken    method void Frob::M(int32))
call       void Program::JIT(valuetype System.RuntimeMethodHandle)
jmp        void Frob::M(int32)

The jmp instruction is interesting, it transfers control to a method that takes the same arguments as the current method and passes the current argument values. Here it is used to jump to a new version the same method, where the method body has been replaced with the actual CIL code.

The native code that is generated for the trampoline is:

  x86 x64
 
push   ebp 
mov    ebp,esp 
sub    esp,8 
xor    eax,eax 
mov    dword ptr [ebp-8],eax 
mov    dword ptr [ebp-4],ecx 
lea    ecx,[ebp-8] 
mov    edx,6231A0h 
call   680065F0 
lea    eax,[ebp-8] 
push   dword ptr [eax] 
call   FFE39B70 
mov    ecx,dword ptr [ebp-4] 
mov    esp,ebp 
pop    ebp 
jmp    dword ptr ds:[006231A8h] 
 
push   rbx 
sub    rsp,20h 
mov    ebx,ecx 
lea    rcx,[00257330h] 
call   FFFFFFFFF35036D0 
mov    rcx,rax 
call   00000000001C84C0 
mov    ecx,ebx 
lea    rax,[00247D80h] 
add    rsp,20h 
pop    rbx 
jmp    rax
add
            rsp,20h pop rbx ret 

(Note that the x64 JIT generates three unreachable instructions at the end. Shown in gray.)

When this code is invoked, it loads the method handle and calls the Program.JIT method. After that returns, it invokes the new method body that the JIT method installed using MethodRental.SwapMethodBody.

When run on the CLR* this all appears to work as you'd hope, but unfortunately that's no guarantee that it will work in the real world. Googling (and experience) suggests that there aren't many** users of MethodRental.SwapMethodBody, so it is quite possible that there are some showstoppers lurking somewhere.

* It does not work on Mono at the moment.
** I found one reference to it in a paper on RubySharp from 2004.

Want to switch from ClearCase, this is what Plastic has to offer

Okay, today instead of a deeply technical merging speech, I'll be on the "value proposition side".

Since I'd like to be as practical as possible, what I'm going to do is to copy, the reasons that one CC user sent me a few weeks ago. I think they're the best possible marketing speech.

Here it goes: We already use branch per task in ClearCase, and I see clear advantages in Plastic:

I think it is quite important to highlight that teams using ClearCase UCM tend to hate the whole thing, while it is taking longer for hard-core CC users to run away...

Let's now go through the main reasons to consider Plastic instead of CC:

  • No messy config specs anymore: (component selection is done via Xlinks, just work in the repo and branch at will)
  • Atomic commits (so no broken merges half way through)
  • Branch creation is lightweight, compared to CC, which is not as slow as others but not as fast as Plastic either
  • Can easily and quickly swap workspaces between branches
  • Branch explorer gives simple overview of where work is being done and makes merges much simpler to execute
  • Merges are much faster (as a side note, some of our biggest setups are merging thousands of files that used to last for... hours!)
  • Merges can be backed out (practically impossible with CC)
  • No complicated admin
  • Live backups
  • Support for multi-site with no added cost
  • You can install local servers for distributed development
  • Much faster to load a workspace (compared to CC snapshots – not as fast a CC dynamic views, which is instantaneous, but they're rubbish on Windows once you try to build)
  • Faster to checkin/checkout
  • Unity Earns Top Spot at 2012 American Business Awards

    Today Unity was named a Finalist in The 2012 American Business Awards “Most Innovative Tech Company of the Year– up to 2500 employees” category, and will ultimately be a Gold, Silver, or Bronze Stevie Award winner in the program! We’re honored by this recognition, and now we just have to wait until the tech awards event in San Francisco on September 17 to find out the color of our statue.

    The American Business Awards are the nation’s premier business awards program. More than 3,000 nominations from organizations of all sizes and in virtually every industry were submitted this year for consideration in a wide range of categories. Finalists were chosen by more than 140 business professionals nationwide during preliminary judging in April and May. More than 150 members of 10 specialized judging committees will determine Stevie Award placements from among the Finalists.

    We wanted to share this great news since it is, thanks to you, that Unity continues to grow so rapidly and re-invest for more innovations and services. We’re looking forward to the fall and the final results!

    May 10

    Sleeping with the enemy: my life with Windows Phone

    In my last blog post about smartphones, I urged the universe at large to help maintain a variety of ecosystems, to help foster competition and originality amongst vendors – and the same day I hit publish, WebOS was killed.

    Apparently the universe hates me.

    Since then, a few things have changed. My main phone since the day of its release was the HP Pre 3, running WebOS – and whilst I still have a soft spot for the OS, the Pre 3 was simply too buggy for me to use full time. The main issue is that I use my phone as an MP3 player in the car – but the Pre 3 would pause playback at the end of a track every half dozen tracks or so – making it impossible to drive the 85 miles to work without needing to root around in the armrest and poke a touchscreen. Not something I really want to do whilst moving – and ultimately too big a papercut to deal with.

    So, come the new year, I moved on to my next device, a Nokia N9 running MeeGo Harmattan. Ultimately, this was an even bigger failure for me than the Pre 3 was, and I lasted maybe two weeks with it before giving up and going back to the HP. Beyond massive usability errors in the software (especially the braindead unkillable pop-up demanding Internet access, even when none is available), the worst for me was how it handled the MP3 player task. My usual way of working is to have the phone hooked up to the stereo with a 3.5mm jack, and the car switches to headset Bluetooth profile to handle calls – this is pretty common on cars too old to support A2DP profile (Stereo music-capable headphones). WebOS and Android are fine with this – but not the N9. The N9, instead, will output all audio through the last connected audio device, regardless of how much that might not be helpful. Get in car, start music playing, plug in cable, start engine – and it plays audio for about three seconds before the Bluetooth connects, and it switches to outputting music via the Headset bluetooth profile (not something that my car can do). Unplug and replug the cable, and music works – but incoming calls are silent until I disconnect the 3.5mm jack, as it outputs the headset audio through the headphone socket. I just couldn’t deal with this big a step back from WebOS as far as my workflow goes, and gave up.

    So, where next? Well, a funny thing happened – a co-worker with generally very good instincts regarding consumer electronics usability told me that his housemate had just bought a Nokia Lumia 800 Windows phone (the WP7-based cousin to the N9) and loved it. Enough that said co-worker was considering getting one himself. This was a very strange thing to hear, especially from an iPhone owner, about a Microsoft product. I’d been generally interested in WP7 on an academic level for a while, but to hear that degree of praise of the actual product was interesting. Also interesting, and roughly simultaneous, was seeing Sajid Anwar’s reverse engineering of the proprietary Zune file transfer protocol go from theory into an actual set of libmtp patches.

    So if the capability to use Banshee to transfer music on is here or near… and it can’t be as braindead as Harmattan when it comes to headphone/bluetooth behaviour, then why not jump ship and squeeze a handset out of Orange?

    About a week after my co-worker replaced his iPhone with a Lumia 800, I bought one too.

    So where to begin? Well, I’ll begin at the start: WP7 is a joy to use. It really just is. It’s the first mobile OS to try something radically different in the UI department for years. Everyone else these days (especially Android) builds iPhone rip-offs to varying degrees, and even the iPhone interface has a lot in common with the old old OLD interfaces found on the dumb Nokia phones of the 1990s. WP7 has an interface which provides just the right level of passively visible information and interactivity, and manages to do it with an elegance that no Android home screen filled with widgets will ever manage. The uncluttered screens are easy to read, and the Metro usability paradigms are trivial to pick up and learn. Without a doubt I’d recommend WP7 to friends and family from a usability perspective, and the Microsoft engineers and designers responsible for cooking up the WP7 interface are worthy of praise. And I’m not the only one saying this – Apple co-founder Steve “Woz” Wozniak recently came out with a similar line.

    That’s the good. There’s also some bad, make no mistake. I’m going to cover all the reasons WP7 sucks over several paragraphs. But overall, a smartphone is a device which I expect to suck – the question is how bad the suck is, and whether it gets in the way of me using the device for what I need at the time. Moreso than MeeGo, moreso than Android, and even WebOS (and I’m still a big WebOS fan), WP7 has more good points than bad points. But there’s still some room for improvement, and some room for caution – and since I know there are a few Microsoft folks following me on Twitter, I’m going to go over my prescription for continued platform success.

    Oh, one more thing before I start: I know WP7 isn’t Free Software. As an end user, I really don’t care about that. I just want something that works – something I didn’t get from WebOS and Harmattan, both of which are primarily Free Software stacks. I’m not saying there’s a causal relationship there, or that a mobile OS can’t be both Free Software and good – just that as an end user, my favourite platform right now is non-Free. Take from that whatever you like. It’s also vitally important, as Free Software folks, never to lose sight of what the other players in the market are up to. If you can’t objectively assess why people are using a proprietary option by using it & recognising its good points (i.e. what to steal & what to improve) then you can’t hope to win over users.

    So. WP7′s downsides in detail.

    In-place updates. Seriously guys, even Apple can manage this now. Why can’t Windows Phone? I understand that making backups is smart – and all updates come with a mandatory backup – but I really shouldn’t be tied to a PC to update a post-PC device. Also, those backups are useless, since they cannot be restored onto replacement devices in the case of failure or theft, so fix that too.

    Update all the things. An iPhone sold in June 2009 still has access to the latest iOS releases. Android phones are notorious for shipping with an outdated version of the OS, then getting at most one major update over the phone’s lifetime (usually the device is abandoned by its manufacturer within months of release). Which camp does Microsoft want to align with, there? Every Windows phone 7 device released should receive Windows Phone 8, even with some features disabled. Anything less is punishing every existing customer, in the hope that you’ll attract new ones – not a winning strategy for a fringe platform whose biggest evangelists are its users.

    Fix IMAP. IMAP isn’t hard. Yet WP7 never seems to work properly with a subset of my mail, never showing the message body & just saying “Downloading” forever. Fix it.

    Bing sucks. Bing’s search results are terrible. Either do something to make them bearable, or allow me to pick which search engine I get when I hit the search button. A Google live tile isn’t the same thing.

    Make killing apps easier. I know you stole the WebOS card view for multitasking (hold the back button) – please also steal the WebOS ability to close apps. I don’t want to have to go into an app and bash “back” repeatedly until it quits. This is particularly annoying for Internet Explorer.

    Make reinstalling apps easier. If I want to install every app I previously had installed on a new device, without restoring a backup, this should be easy. There are third party apps which try to plug this gap.

    Find a way to support copyleft. I’d like to port a few C# apps to WP7, but because they’re LGPL, I can’t. The code’s copyright holders would have no issue with their code being on WP7, as long as end users have a mechanism to replace the libraries, so why not find a way to allow this? e.g. when compiling an app, let me mark a library as “user-replaceable”, then allow for some mechanism where an end user can replace those assemblies with their own version.

    Let me use multiple Google calendars. WP7 only lets me add/see appointments on my default Google calendar. I want to add/see things on my wife’s calendar, which is shared with me. WebOS can do this.

    MTP-Z is the devil. I do not need or want encrypted end to end communication between my PC and my camera device, to transfer a photo off. I do not need or want encrypted end to end communication between my PC and my MP3 player to transfer a photo on. Let’s be honest, the only reason for MTP-Z is to enforce DRM on Zune-rented music tracks – and honestly, there’s no good reason to require MTP-Z for *all* communications if all you want to do is protect one folder or file extension. Now, since MTP-Z theoretically forces me to use Zune for many tasks better handled by other apps, now I get to write multiple criticisms of Zune’s desktop app – and as long as MTP-Z is enforced, every Zune failing is a Windows Phone failing too.

    Zune: Support Windows’ codec infrastructure, and transcode where needed. Windows Media Player can play Ogg Vorbis files. No, not out of the box, but if one installs the required codecs. Zune should support the same files as WMP – if you want to ensure people don’t try to copy files to a portable device which are not supported on that device, then you should have an API in place to allow for pluggable seamless transcoding of files as required – Banshee allows me to do this (e.g. to copy files I have as .flac to devices which do not support it).

    Zune: Search my tracks, not the web. Zune’s searching is terrible – it doesn’t do as-you-type searches, and when I hit enter, matches from my collection are given a tiny little space compared to matches from the Zune music store. Let me easily pick the track I feel like listening to, don’t make it a chore

    Zune: Let’s solve metadata together. I absolutely love how nicely the Zune app – on desktop and on phone – shifts as appropriate to the currently playing artist (e.g. changing the lock screen to an image of the artist in question). However, Zune doesn’t make it obvious how to set an album’s metadata to support this, and it’s particularly frustrating when it’s a minor difference of spelling causing a track not to get the “nice” treatment – e.g. “UNKLE” versus “U.N.K.L.E.”. Either start making heavy use of audio fingerprinting services like MusicBrainz to fill in metadata, or allow me to search for “fully supported” artists when filling in track metadata

    Zune: Random playlists are useless on devices. I like smart playlists. In Banshee, I have one to pick 12GB of random tracks, which I can sync to my phone. I can’t do this with Zune. If I try to just sync all my random music to my phone, it errors out due to lack of space. If I have a random playlist, the random selection changes multiple times during a sync – resetting the sync, wiping out half the tracks that were transferred on, and starting again. As a result, the sync goes on for literally hours, never ending up with more than a gig or so of tracks on the phone. Random playlists should be freezable, so I can transfer them to my device in peace, then get a new random selection when I want.

    So, that’s my list of miserable failure – and it’s still a less painful list than any other mobile OS I’ve used. Perhaps one day Android will approach being usable, perhaps Blackberry’s BBX will actually appeal to human beings rather than corporate IT managers, and perhaps Mozilla’s delightfully named “Boot to Gecko” will get some traction. Who knows. All I know is, My Lumia 800 is the best phone I think I’ve ever owned, and it’s important for anyone working in the mobile space to understand why.

    Amazon EC2: Automatic EBS volume snapshots using C#

    Amazon EC2 lets you create snapshots of the EBS volumes using the Amazon Console or the EC2 Java-based command-line tools. The Console works fine until you have to manage a decent amount of volumes or need frequent snapshots. As for the Java-based command-line tools, well, they are Java-based...

    Another alternative is to use the .NET API so you can customize what volumes are backed up and how often, the retention criteria, and anything you want while using your favorite programming language. You have to start by downloading the AWS dll from Amazon. Click on Download the DLL and Samples.

    The following program takes a snapshot of all the volumes that are in use in your account. The snapshot name matches the name of the source volume:

    using System;
    using System.Configuration;
    using System.Collections.Generic;
    using System.Net;
    using System.Linq;
    using Amazon;
    using Amazon.EC2;
    using Amazon.EC2.Model;
    
    namespace AWSBackup {
        class Program {
            static void Main (string [] args)
            {
                // The following line is not needed in .NET.
                // In Mono, it is not needed if you trust the AWS certificate chain
                // See http://stackoverflow.com/questions/3285489/mono-problems-with-cert-and-mozroots
                ServicePointManager.ServerCertificateValidationCallback = (a, b, c, d) => { return true; };
    
                var volumes = GetVolumes ();
                foreach (var v in volumes) {
                    if (String.IsNullOrEmpty (v.VolumeId) || String.CompareOrdinal (v.Status, "in-use") != 0)
                        continue;
                    var name = v.Tag.FirstOrDefault (t => t.Key == "Name").Value;
                    var snapshot = CreateSnapshot (v, name);
                    Console.WriteLine ("Snapshot of {0} initiated at {1}", name, snapshot.StartTime);
                }
            }
    
            static IEnumerable<Volume> GetVolumes ()
            {
                AmazonEC2 ec2 = GetEC2Client ();
                var request = new DescribeVolumesRequest ();
                var response = ec2.DescribeVolumes (request);
                return response.DescribeVolumesResult.Volume;
            }
    
            static Snapshot CreateSnapshot (Volume v, string name)
            {
                AmazonEC2 ec2 = GetEC2Client ();
                var request = new CreateSnapshotRequest ()
                                .WithVolumeId (v.VolumeId)
                                .WithDescription (name);
                var response = ec2.CreateSnapshot (request);
                var snapshot = response.CreateSnapshotResult.Snapshot;
    
                if (!String.IsNullOrEmpty (name)) {
                    ec2.CreateTags (new CreateTagsRequest ()
                                    .WithResourceId (snapshot.SnapshotId)
                                    .WithTag (new Tag { Key = "Name", Value = name })
                    );
                }
                return snapshot;
            }
    
            static AmazonEC2 GetEC2Client ()
            {
                var settings = ConfigurationManager.AppSettings;
                return AWSClientFactory.CreateAmazonEC2Client (settings ["AWSAccessKey"], settings ["AWSSecretKey"]);
            }
        }
    }
    

    ...And that's it! Instead of a shell script that executes several programs per volume, we have a single program that runs on both MS.NET and Mono. Add it to your crontab or the Windows Task Scheduler and you get automatic backups for your volumes. Automatic deletion of old backups is left as an exercise for the reader.

    C# source, application configuration file, and Makefile can be downloaded from here: ec2-backup.zip.

    May 9

    C++ references, continued

    So I got some feedback about my last C++ post. The comment states that references are not pointers, they are just names for another object.

    Sorry for reopening a topic after nearly 6 months. But I cannot stay silent.
    I think you got it wrong. Completely.
    Although a reference might behave like “some sort” of a pointer, it is *not* a pointer. Your statement: “A reference is effectively a pointer, but this is hidden by the language.” is completely wrong.
    To quote the C++ standard: “A reference is an alterantive name for an object.” It is just a new name for something that you’ve defined elsewhere. That’s the very reason why it cannot be null –> You cannot have an alternative name for an object that you do not have yet.

    –Willi Burkhardt

    Great, in theory. Unfortunately, none of the compilers I have used treat references as anything other than pointers. References are, on some level, supposed to guarantee non-null-ness as well as that they reference a valid object. This is not true in any compiler I have ever used.

    Take this example (see it run):

    #include <iostream>
    
    static int const a_const = 5;
    
    int const& A() {
    	return a_const;
    }
    
    static int const* b_ptr = 0;
    
    int const& B() {
    	return *b_ptr;
    }
    
    int main() {
    	int const& a_ref = A();
    
    	std::cout << "Called A()" << std::endl;
    	std::cout << "a_ref: " << a_ref << std::endl;
    
    	int const& b_ref = B();
    
    	std::cout << "Called B()" << std::endl;
    	std::cout << "b_ref: " << b_ref << std::endl;
    
    	return 0;
    }

    If we are to believe that references are simply another name for an object, then converting *b_ptr to a reference should have caused a runtime error. After all, we dereferenced a null pointer, right? The compiler should emit code to prevent this, right?

    In an ideal world, this would cause an error — but it does not. The segmentation fault does not come until b_ref is used; indeed, we see “Called B()” in the program output, indicating that B() successfully returned a reference, which was stored in b_ref. Obviously, at runtime there was a null pointer dereference. But we didn’t use a pointer, I hear you saying. We used a reference!

    Then please explain this behavior to me. On a language level, sure, references are “names for objects.” But this does not change the fact that the implementation is done using memory addresses — which is fundamentally the same thing pointers do. This helps to explain why we see the behavior of this sample. As I mentioned in my last post, when you convert an expression to a reference type, it’s treated exactly as though you had converted it to a pointer type, with an implicit address-of operator (&). So we can rewrite this function:

    int const& B() {
    	return *b_ptr;
    }

    Like this:

    int const* B() {
    	return &*b_ptr;
    }

    And it becomes immediately clear why the segmentation fault did not occur here — taking the address of a dereference expression is the same thing as taking the original expression. The & and * cancel out during compilation, and we just return the pointer. Take a look at this example, which is identical to the above example, except that A() is gone, and B() now returns a pointer, with dereferences added in the appropriate places (see it run):

    #include <iostream>
    
    static int const* b_ptr = 0;
    
    int const* B() {
    	return &*b_ptr;
    }
    
    int main() {
    	int const* b_ptr = B();
    
    	std::cout << "Called B()" << std::endl;
    	std::cout << "b_ref: " << *b_ptr << std::endl;
    
    	return 0;
    }

    Identical behavior.

    So you can throw the spec at me all you want, but every implementation I’ve tried uses pointer-with-automatic-dereference semantics — if you convert every reference to a pointer, add an address-of operator to every assignment to a reference, and a dereference operator to every use of a reference, you will see identical behavior.

    To preempt the “but the compiler can optimize local references” argument, the compiler can do exactly the same with pointers.

    // With a reference
    int A() {
        int a = 5;
        int& b = a;
        return b;
    }
    
    // With a pointer
    int B() {
        int a = 5;
        int* b = &a;
        return *b;
    }

    I’ve heard the argument that the compiler can eliminate the reference in A(). Well, it can also eliminate the pointer in B(). If a local pointer is set to point at another local and the compiler can prove that it will never change, it can optimize it away just as easily as it can optimize away a local reference to a local.

    So, this supports my original argument that references store memory addresses in the same way that pointers do, only with automatic dereferencing. They are effectively nothing more than syntactic sugar, allowing you to forget that you’re operating on an object somewhere else in memory.

    May 8

    Testing Unity

    It’s been a fair while since we wrote a post about testing Unity, so we‘d like to update you on what’s going on in QA. This is the first of two posts from QA. I’ll post the second one soon, which focuses on our tools, cycles and analytics.

    The Product

    I assume you know about Unity if you’re reading our blog. As a developer, you’re intimately familiar with most of the features, but there are a few aspects from a tester’s point of view you might not have thought about before.

    Eyes Wide Open

    Unity is one of the most testable products I have ever worked on. Practically everything in Unity is available for a tester. It consists of a ton of APIs, profilers, logs etc. which enables us to do anything we want from code, including verifying that any action we have taken actually gets us the expected result. On top of that, Unity on the core parts requires only a single installation on a single machine, so the infrastructure required to run automation is very small.

    All those platforms

    There is one caveat though. A core feature of Unity is that it can build your games to many platforms, which naturally requires us to test such functionality. This does complicate a test rig quite a lot and it puts requirements on how our frameworks are built, so we can get the most bang for our testing buck.

    From a more general point of view, we have the problem of covering all those platforms both during a regular test run, but also when you have submitted a bug saying “this and this phone has given us this specific problem”. Or different browser versions on different OS’, or specific graphics cards etc etc. You get the drift.

    The love

    Let’s not forget about the love we get from our community. In so many ways you guys are the backbone of Unity, adding true value through the forums, answers and testing cycles. This is something we take very seriously, something which commits us to be responsive and helpful.

    Our Strategy

    AAA

    No, not the large productions. Automation, automation, automation. We have the testable product, we have the infrastructure and we have the need. Were we to make a single cycle product, and then move on to the next, we would not be taking such a bet on automation, but features in Unity live for years and repeated manual testing on such a product simply doesn’t make sense.

    Use the community

    We have you guys. You’re a great help as it is, but we can do a whole lot more. We can help you with tools which will help you test your own games. Let’s face it; while we believe we’re doing a heroic effort to cover everything, it is practically impossible.

    Tools might include better overviews of bug reports, automated duplicate finders when you submit bugs, integration to answers. Even something like publishing testing suites for you to run on your own games could be an option. Helping you will go a long way in helping us, if we do it in a way where results can be piped back to us in a way so we can take action on it.

    Good internal reporting

    This is about making reports for the Unity development team. We need to assess the quality of different parts of Unity, which parts have good coverage, a high concentration of bugs, or where users are experiencing a lot of pain.

    This point is very easy to say, it’s also conceptually easy to lay out a plan for which type of reporting you want, but the implementation of such a metric based regime is very hard. It requires us to use the same terminology across all of our tools, capture our data consistently and on a regular basis and then build the reporting needed on top of them. We’re currently in the phase of implementing the same terminology across our testing tools right now.

    The People

    Everything starts with the people. We are not stronger than the people we hire, the people we retain and the people who make it all happen. At the time of writing there are 17 engineers and student workers in the Unity QA team, but we are hiring many more.

    Where we are

    Currently, testing in Unity is based in Copenhagen, Vilnius and Brighton. We are also recruiting for a new office in Odessa.

    In Copenhagen we have mostly been focusing on the editor and the core, since this is where most of those developers are placed. Vilnius is mostly about handhelds and consoles and Brighton has been taking care of the Webplayer. I say mostly, because at times everyone is spread across several features, for example, PS3 testing is now in Brighton.

    As you can see, all of Unity is spread across the globe. One of the great things about the QA team is that we are constantly in communication with each other via a big Skype channel. 27 people participating, with regular eavesdropping by the devs and the support team.

    Roles in test

    We have some distinct roles in test, which helps us define our recruiting better, but being in test you often have to have a wider scope on what you do than when you are a developer.

    Software Development Engineers in Test are developers working in test. These guys are working on tools, frameworks and feature automation all at once. Their job is often to figure out ways to improve the overall workflow for everyone involved in the development of Unity, by improving the automation on the build farm, making regression suites to prevent bugs flowing in and also evangelizing the usage of the frameworks for both testers and developers. They are the backbone of the AAA strategy.

    Software Test Engineers are what you would call “manual testers”, but that is not a fair term. Beside figuring out how to actually get proper coverage on a feature, a task which requires a fair amount of technical knowledge, these guys also need to be good at creating an overview of an area . They are also the very first “users” of features, able to provide feedback very early in the lifecycle and ensure that we have as good a first shot as possible for our alpha users. They are the backbone of a good internal reporting strategy.

    QA Student Workers are using their time on looking at the bugs you submit, try to reproduce each and every one of the and then forward the bug to the developers. These guys are doing a heroic effort to respond to your report. If they can’t figure out what is going on, they forward it to a QA within the area or send a reply to you asking for more information. It is a relatively new role in Unity, which we started in the spring 2012 and they are a big part of our effort to be responsive to our community.

    The community

    We have the best community in the world. A bold statement, but I believe it to be true. I have never been in a company where the community has had such a big influence and impact. I’ve said it earlier in this blog post, but it is something we value deeply. We use the community for many things and I’ll highlight a few here.

    Sometimes we assemble alpha groups. The alpha lists are comprised of a small number of people who have a track record of giving us good feedback on features. They are given drops earlier than anyone else and we ask them to take a build (often broken in some areas) and help us make sure we make the right features for the next versions. This feedback is what we use to change any issues we might have with how you guys use it.

    The community also helps us very visibly with reporting bugs to us, both during beta tests and after released versions. Beta tests run for a considerable time, through several releases and we gather tons of bugs from you guys. The beta testers who are really good at finding AND reporting bugs are also given some swag for their efforts (finding them is good, but to make a great beta tester you should consistently deliver easy to reproduce bug reports. More on this in part two).

    Finally I want to mention the willingness to help us when we ask for it in one of our beta groups. I recently called for very large projects from real-life production teams and got a response within one working day. There is no end to how much we appreciate that kind of response and participation.

    Join us!

    I think our lead developer Lucas Meijer articulated all my thoughts about this challenge when he stated that “writing automated tests is very fucking hard”. It is a job which requires you to know a lot about testing techniques, infrastructure, the product, and be a coder who can write extremely solid code. A guy such as Lucas. It is interesting how this task is frowned upon when you look at the challenges it poses. I have met a lot of good developers in my career, but the stars of any dev team were also those that had a great aptitude for testing. I guess this little rant is to say that you should not expect “to start as a developer in test and then grow into a developer”. It’s the other way around.

    It is also a difficult job to be a great software test engineer: you need to possess the correct mix of technical knowledge, and communication and organizational skills. It’s a rare mix, and we continue to look for the right candidates.

    If you’re that guy or girl, if you want to be the one making everything run smoothly in a feature team and if you have a passion for quality you can’t stop preaching about, join us: http://www.unity3d.com/company/jobs .

    May 7

    Linker vs Bindings and IsDirectBinding

    If you looked at my previous entries related to the linker and bindings: NewRefcount, UI thread checks, Runtime.Arch or at MonoTouch‘s generated bindings source code then you likely noticed another common pattern, e.g.

    	[Export ("sizeToFit")]
    	[CompilerGenerated]
    	public virtual void SizeToFit ()
    	{
    		global::MonoTouch.UIKit.UIApplication.EnsureUIThread ();
    		if (IsDirectBinding) {
    			Messaging.void_objc_msgSend (this.Handle, selSizeToFit);
    		} else {
    			Messaging.void_objc_msgSendSuper (this.SuperHandle, selSizeToFit);
    		}
    	}
    

    The use of IsDirectBinding (line #6) is a bit less common in third party bindings, unless the -e option was used with btouch to allow types to safely inherit from your bindings. The fact that such an option exists is a sign that we’d like to get rid of this condition when it’s not required.

    If we knew that a type is never subclassed then we could remove the IsDirectBinding (line #6) as its value would be constant, true, and that would also allow the removal of the false branch (line #9).

    Along with some previous optimizations that can remove [CompilerGenerated] (line #2) and EnsureUIThread (line #5), we would end up with a smaller, branchless method that simply calls the right selector, like this:

    	[Export ("sizeToFit")]
    	public virtual void SizeToFit ()
    	{
    		Messaging.void_objc_msgSend (this.Handle, selSizeToFit);
    	}
    

    Now that’s something the linker can find out since it must analyze the application’s code. Furthermore it also knows, since runtime code generation is impossible on iOS, that the application cannot be extended, unless it’s re-compiled (and re-linked). That’s turning a disadvantage into an advantage! and, starting with MonoTouch 5.3.3, the linker gives you this (small) consolation ;-)

    This optimization saves 22 kb on a release build of TweetStation but, like most other linker-bindings changes, the real goal was not to save space (it’s still nice) but to reduce the number of conditions and branching in the code to allow faster execution.


    May 5

    Super Hyperpolyglot

    A few years ago nearly all the code I wrote was in C++, but increasingly I’m finding myself writing in a variety of mostly C-style languages and having to perform crunching mental gear changes as I switch between them.

    In the interests of making these language switches less painful I thought about listing the commonly used features of the languages I commonly use in a side-by-side format. Luckily I’m a lazy programmer, the web is large and there’s nothing new under the sun, so I quickly found Hyperpolyglot which provides commonly used programming language features in a side-by-side format, which is what I wanted. Nearly.

    Hyperpolyglot organizes it’s language comparisons in to several catagories: scripting languages, C++ family languages, embeddable languages and so on. In my case (and I suspect in many cases) the languages I wanted to compare were spread across several pages.

    After briefly considering some cut and paste to get what I wanted I started playing with Google Spreadsheets, which has a very nifty importHtml function which allowed me to pull the Hyperpolyglot data in to several sheets which can be combined to produce arbitrary language comparisons.

    It’s not perfect as different languages have different features and in some cases the Hyperpolyglot data doesn’t use exactly the same terms across tables (“version used” vs “versions used”) and I’m not a spreadsheet ninja, but it’s good enough to generate PDFs like this JavaScript Python Java C++ Comparision. As a Hyperpolyglot derivative work, The Super Hyperpolyglot Spreadsheet is licensed under the Creative Commons Attribution-ShareAlike 3.0 License, please let me know if you improve it.

    Google Summer Of Code 2012

    My name is Piotr Dowgiałło. I was accepted into Google Summer of Code 2012 with a project ‘Support for ASP .NET MVC in MonoDevelop’, and Michael Hutchinson is my mentor. This blog is a place where I’m going to report my job, present ideas and encountered problems, and write about features that will be implemented.

    The goal of my project is to improve the existing support for ASP .NET MVC in MD. More information about the project and what exactly I’m going to do can be seen on http://google-melange.appspot.com/gsoc/project/google/gsoc2012/sparek/9001. If you’d like to see the whole detailed application, it’s available on http://pdowgiallo.pl/application.pdf.

     

     

    C#/Mono: Playing with Pointers

    I haven’t blogged in a while. Let’s fix that!

    So, I’ve been programming a lot in D lately, which means systems programming, which means pointers! Pointers are amazing. You can do all sorts of crazy and awesome hacks with them. C# and the .NET Framework try to abstract pointers away from us. But fear not, for there are ways around this safety nonsense!

    It turns out that on Mono, you can pin an object even if it contains managed data. This makes it safe to modify an object’s internal layout even in the presence of a moving GC (well, kinda, sorta). You can’t take the address of the object, however, which means we must resort to some IL hackery.

    Thus, the code:

    using System;
    using System.Reflection.Emit;
    using System.Runtime.InteropServices;
    
    public unsafe delegate void PointerAction(byte* pointer);
    
    public static class ObjectExtensions
    {
        private static object _lock = new object();
        private static Func _addrOf;
    
        private static IntPtr AddressOf(object obj)
        {
            lock (_lock)
            {
                if (_addrOf == null)
                {
                    var dm = new DynamicMethod(string.Empty, typeof(IntPtr), new[] { typeof(object) },
                                               typeof(ObjectExtensions), true);
    
                    var il = dm.GetILGenerator();
    
                    il.Emit(OpCodes.Ldarg_0);
                    il.Emit(OpCodes.Conv_I);
                    il.Emit(OpCodes.Ret);
    
                    _addrOf = (Func)dm.CreateDelegate(typeof(Func));
                }
            }
    
            return _addrOf(obj);
        }
    
        public static unsafe byte* ToPointer(this object obj)
        {
            if (obj == null)
                throw new ArgumentNullException("obj");
    
            GCHandle handle;
    
            try
            {
                handle = GCHandle.Alloc(obj, GCHandleType.Pinned);
    
                return (byte*)AddressOf(obj).ToPointer();
            }
            finally
            {
                if (handle.IsAllocated)
                    handle.Free();
            }
        }
    
        public static unsafe void WithPointer(this object obj, PointerAction action)
        {
            if (obj == null)
                throw new ArgumentNullException("obj");
    
            if (action == null)
                throw new ArgumentNullException("action");
    
            GCHandle handle;
    
            try
            {
                handle = GCHandle.Alloc(obj, GCHandleType.Pinned);
    
                action((byte*)AddressOf(obj).ToPointer());
            }
            finally
            {
                if (handle.IsAllocated)
                    handle.Free();
            }
        }
    }

    (Kudos to ki9a on #mono for coming up with the dynamic method IL!)

    Now, don’t try to run that on Microsoft .NET. It will blow up.

    Now that we can get at the internals of objects, let’s try it out:

    static class Program
    {
        static unsafe void Main()
        {
            var str = "foo!";
            object obj = new { foo = 0, bar = (object)null }; // create an object with an int32 field and a reference field
    
            void* vtable = null;
            void* sync = null;
            int length = 0;
            void* chars = null;
    
            str.WithPointer(ptr =>
            {
                vtable = *(void**)ptr;
                sync = *(void**)(ptr + sizeof(void*));
                length = *(int*)(ptr + sizeof(void*) * 2);
                chars = *(void**)(ptr + sizeof(void*) * 2 + sizeof(int));
            });
    
            obj.WithPointer(ptr =>
            {
                *(void**)ptr = vtable;
                *(void**)(ptr + sizeof(void*)) = sync;
                *(int*)(ptr + sizeof(void*) * 2) = length;
                *(void**)(ptr + sizeof(void*) * 2 + sizeof(int)) = chars;
            });
    
            Console.WriteLine((string)obj); // prints "foo!"
        }
    }

    Oh boy. Some explanation is probably in order.

    First of all, let me explain the layout of objects in Mono. Every object has a header consisting of two machine words. The first word points to the object’s VTable, which describes its type, methods, etc. The second word holds the so-called synchronization block, which is used to implement monitors (C# lock). Now, strings have two extra fields: One 32-bit field which holds the string’s length, and one machine word field which points to the raw characters backing the string.

    Now look at this line:

    object obj = new { foo = 0, bar = (object)null }; // create an object with an int32 field and a reference field

    What we’re doing here is creating an anonymous object with a physical structure similar to that of a string. Needless to say, whether it actually is similar is completely implementation-defined. The runtime may decide to reorder fields as it sees fit, and may even make the foo field a 64-bit integer on a 64-bit system. But, what’s important here is that the resulting object has enough space to hold the contents of a string object.

    Now we get to the fun stuff:

    str.WithPointer(ptr =>
    {
        vtable = *(void**)ptr;
        sync = *(void**)(ptr + sizeof(void*));
        length = *(int*)(ptr + sizeof(void*) * 2);
        chars = *(void**)(ptr + sizeof(void*) * 2 + sizeof(int));
    });

    Here, we read out the VTable, synchronization block, length, and character array fields of the “foo!” string object. It is (more or less) safe, since the WithPointer method ensures that the object is pinned while we do our stuff.

    Next:

    obj.WithPointer(ptr =>
    {
        *(void**)ptr = vtable;
        *(void**)(ptr + sizeof(void*)) = sync;
        *(int*)(ptr + sizeof(void*) * 2) = length;
        *(void**)(ptr + sizeof(void*) * 2 + sizeof(int)) = chars;
    });

    Here we assign the values we read out from the string object earlier to the object we created with a similar physical layout to that of string objects. Our anonymously-typed object is now effectively a string.

    Let’s prove that:

    Console.WriteLine((string)obj); // prints "foo!"

    Note two things here: First, the cast succeeded. It would normally have resulted in an InvalidCastException. So far so good. Second, the call actually prints what we expect. This means that we got the physical layout of the string object right.

    Note that all of this was done on an x86 machine running 64-bit Linux with Mono 2.10.8. I have no idea whether it will work with any other Mono version, architecture, bitness, or operating system.

    Will this break the runtime? Possibly! Will the GC explode? Likely! Will it leak memory? Definitely!

    Don’t do this in production code. Like, seriously, don’t.


    May 4

    GUI improvements webinar



    Webinar date: 09/05/2012

    As you may already know, the Plastic SCM 4.1 release has plenty of cool, new GUI features, like a search engine, Branch Explorer improvements, and the revamped History 2D view.

    We’ve newly implemented an image preview in the Items view.  Some file types (like .txt files) work right out of the box, but others take a little ingenuity to set up.  But don’t worry; we’ll show you how!

    We’ve also included lots of keyboard shortcuts to make your work life a little easier.  Tired of clicking through all the menu options to check out and check in your code?  We’ve got the solutions you’re looking for.

    Sign up (and show up!) for our webinar to learn a few tricks!

    Register now!

    New Development Snapshot

    This should hopefully be the last snapshot based on OpenJDK 7 FCS as 7u4 has shipped and the bundle should be available soon. After that I'll start work on integrating 7u4 and working towards the IKVM 7.1 release.

    Changes:

    • Bug fix. When adding certificates to virtual cacerts file make sure that the aliases that are generated from the certificate subject are unique.
    • Bug fix. If a class file UTF-8 string ends with an incomplete multi byte char, we should throw the appropriate exception.
    • IKVM.Reflection: Added ModuleBuilder.__GetAssemblyToken() API.
    • IKVM.Reflection: Removed Mono CryptoConvert code and use .NET 2.0 API instead.
    • IKVM.Reflection: Rewrote StrongNameKeyPair to remove dependency on System.Reflection.StrongNameKeyPair.
    • IKVM.Reflection: Improved assembly title and description.
    • IKVM.Reflection: Metadata is now sorted with a stable sort algorithm.

    Binaries available here: ikvmbin-7.1.4507.zip

    Monologue

    Monologue is a window into the world, work, and lives of the community members and developers that make up the Mono Project, which is a free cross-platform development environment used primarily on Linux.

    If you would rather follow Monologue using a newsreader, we provide the following feed:

    RSS 2.0 Feed

    Monologue is powered by Mono and the Monologue software.

    Bloggers