The following snippet:
<html>
<body>
<script type="text/javascript">
document.write(typeof NaN);
</script>
</body>
</html>
produces:
number
The type of not a number is number... Seriously, what were they thinking!?!
by Noah Gift (noreply@blogger.com) at August 19, 2010 11:57 AM
Today Oracle sued Google over Java patents and copyrights that they claim Google's Android OS infringes. The lawsuit claims that Google knowingly infringed on those patents, and that the continued distribution of Google's Android is harming Oracle's Java Business.
You can read the actual complaint, the patents referenced are:
There is also a copyright lawsuit, but there are not enough details on the complaint to figure out what the claim is. Until there is a trial, we will not really know what is being asked here.
I would like to think that this is going to be solved with a quick settlement where Oracle will shake Google for a few billion dollars and the entire matter will be put behind.
Oracle will likely want to settle with Google under terms that will only cover Google's own use as they want to go shaking other OEM trees for more cash.
An unlikely scenario is for Google to pay the bills for all Android OEMs as they are coming out fast and strong from every corner of the world.
It occurred to me that Oracle could sell all the Java assets to Google. But Google probably passed on this opportunity back when Sun was put on the market.
Sun's Ex-CEO Jonathan Schwartz has recently taken to the blogwaves to blog about the things he could not tell us while he was a CEO of Sun. While he might have found a new voice for gossip from the Sun days, he will not say a word on this matter, because he was likely engaged in shopping the patent lawsuit around.
Sun had created Java, but it turned out to be very difficult for Sun to monetize Java directly after the initial source code license deals that they struck with IBM, Microsoft, Oracle, Netscape and others. They created the J2EE market, just to find that other companies and startups executed better than they did on the systems that they had initially engineered.
Sun was left in the uncomfortable position of being the owner of the technology that everyone was cashing out on, but they themselves had very few revenue streams for Java. Like Clemens Vasters joked on Twitter today:
They had the Microsoft lawsuit cash and they had the embedded licensing business with Java Micro Edition and Java Standard Edition licensing deals.
The open sourcing of Java was also carefully planned. By picking the GPL as their license, they ensured that embedded system OEMs and developers would have to negotiate a different license with Sun if they wanted to use the OpenJDK on their systems.
There is very little public information on the Google/Sun split over Java ME and the creation of Dalvik. The rumors on the grapevine were that Google and Sun could not reach an agreement over the Java Micro Edition licensing. Sun wanted to sit in the middle between Google and the handset OEMs, while Google wanted to create a free-for-all operating system.
When it became clear that they would not be able to reach an agreement, Google started a project to replace Java Micro Edition and they used some clever engineering techniques that blended the best of both worlds.
It is likely that during these negotiations, Google threatened to build their own Java runtime and Sun countered with a list of patents. This would explain why Google went through the trouble of making the Dalvik virtual machine explicitly incompatible with the existing Java virtual machine instructions.
Although Dalvik uses a different set of instructions, Google created a translator that recompiled Java code into Dalvik code, and with this, they worked around whatever licensing technicalities they were aware at the time of the negotiations.
Needless to say, Sun was not happy with Dalvik. Not only because Sun had lost a large licensing deal, but also because it had the potential of becoming the de-facto Java virtual machine that everyone on the embedded space would pick instead of Sun's own Java Micro Edition.
In late 2007 Google announced both Android and the Open Handset Alliance to the public. On the Java front, Sun had delivered on the promise of open sourcing Java, but it had been a rough year for Sun and it would get worse, in the next twelve months after the announcement, Sun stock would lose 80% of its value.
Sun had their plates full, so Sun did not feel the need to react immediately to the Android threat, so they kept their grievances to themselves.
But Jonathan started to shop the company in late 2008. The monetary value of the Java assets had been devaluated due to the open sourcing of the technology under the GPL. I am going to bet that the same careful planning that went into picking the GPL went into pitching the potential for lawsuits.
The world had already witnessed the awesome iPhone and the eyes were on Google to deliver a killer phone. Jonathan must have known this and he must have been pitching this to the potential suitors.
By the time Oracle bought Sun, they knew that they would be going after Google and anyone else with a big, fat checkbook that did not have a licensing deal in place.
And that explains the Exodus of famous Java people from Sun shortly after the acquisition. The wheels of the lawsuit started spinning the moment the sale was done. Those employees are probably under NDA.
Update: I was wrong, apparently Gosling was not under NDA and has confirmed exactly what I said above:
Oracle finally filed a patent lawsuit against Google. Not a big surprise. During the integration meetings between Sun and Oracle where we were being grilled about the patent situation between Sun and Google, we could see the Oracle lawyer's eyes sparkle. Filing patent suits was never in Sun's genetic code. Alas....I hope to avoid getting dragged into the fray: they only picked one of my patents (RE38,104) to sue over.
So now we know that Jonathan shopped Sun with a big "Sue Google" sign. So much for his visionary patent defense against Apple and of course this jewel:
The most egregious of such suits was filed against Sun by Kodak (yes, the film photography people).Egregious, because Kodak had acquired a patent from a defunct computer maker (Wang) for the exclusive purpose of suing Sun over an esoteric technology, Java Remote Method Invocation (“Java RMI” – not exactly the first thing that comes to mind when you hear “Kodak”).
And he was just playing Wang's role a couple of months ago.
Update: this post from the Dalvik announcement era discussed how Dalvik's work around the license-from-Sun challenge.
The Java specification patent grant seems to be only valid as long as you have a fully conformant implementation:
(a) fully implements the Specification including all its required interfaces and functionality;(b) does not modify, subset, superset or otherwise extend the Licensor Name Space, or include any public or protected packages, classes, Java interfaces, fields or methods within the Licensor Name Space other than those required/authorized by the Specification or Specifications being implemented; and
(c) passes the Technology Compatibility Kit (including satisfying the requirements of the applicable TCK Users Guide) for such Specification ("Compliant Implementation").
This is more stringent than the Microsoft Community Promise that applies to .NET as the Community Promise only requires a minimum subset, it does not prevent supersets.
This seems to be what the lawsuit is hinged upon.
I vaguely remember in one of the endless anti-Mono discussions that someone pointed (maybe it was Gosling himself?) that Java had a patent grant for anyone to implement under any conditions.
They pointed to the spec. And I remember seeing this on the spec and thinking that it was a generous patent grant. Perhaps I was confused and the only patent grant is the one in the previous section, but if you know of the other document, please let me know.
By GPLing Java, Sun lost some of the exclusive rights that they used to have, in particular, anyone using the open sourced version of the OpenJDK is given the patent rights to run the software.
The problem is that the rights are only available as long as you are using the GPL version of Java. Any patent grants are not available if you use a third-party licensed version of the Java virtual machine. In that case, it seems like the only option would be to to go back to the Sun licensing terms.
Too many engineering resources are devoted to Android at Google and at their partner companies, but I can not help to think that Google could migrate Android from Java to the ECMA/ISO CIL and C#.
Unlike the Java patent grant, the Microsoft Community Promise for both C#, the core class libraries and the VM only require that you have a full implementation. Supersetting is allowed.
Additionally, Microsoft has placed the .NET Micro Edition entirely under the Microsoft Public License which comes with an even more generous patent grant, and covers a superset of the code covered by ECMA/ISO 335.
We have open source implementations of both, and even more luckily, the ECMA/ISO VM specification allows for different profiles, to allow for ultra-small or server-sized versions of the VM to be created. Ideal for mobile platforms.
Google could settle current damages with Oracle, and switch to the better designed, more pleasant to use, and more open .NET platform.
There is a silver lining in this whole mess, and it is that the tweetosphere came up with a few funny tweets, here are my favorites:
I am very excited to see the first
MonoTouch book published.
by Miguel de Icaza (miguel@gnome.org) at August 13, 2010 11:01 PM
It looks like it's just about time for another major release of NWSGI - the last two Decembers have had major releases, and I see no need to break the trend this year. There are going to be a few major changes this time around, so if anyone has any objections, let me know as soon as possible.
Most importantly, it will only support IronPython 2.7 and thus will require .NET 4.0. Like the IronPython team, I'm not going out of my way to break compatibility with .NET 2.0 (or IronPython 2.6, for that matter), but I won't be distributing anything but IronPython 2.7/.NET 4.0 binaries.
Similarly, I will not be supporting IIS 6 (Windows Server 2003) anymore. Again, I won't go out of my way to break it, but I won't be testing against it either. This means I can get rid of the wildcard handling for good, since IIS 7 has a good URL rewriter available.
The biggest change is that I am decoupling the WSGI processing from the ASP.NET pipeline. All of the functionality is currently part of an IHttpHandler implementation, which restricts it to be used with IIS (and Cassini) only. NWSGI 3.0, on the other hand, will allow NWSGI to be used with HttpListener or other servers such as Kayak by moving all WSGI processing into a separate class with no ASP.NET dependencies. The redesign will also allow me to improve the test coverage from zero to, well, something.
Finally, the licence will change to the Apache Licence 2.0 to match IronPython. The basic terms are identical to the Ms-PL licence that was used previously; the Apache licence is just more explicit and also more widely used.
As with the previous versions, I expect to release the final version shortly after IronPython 2.7 is released.
|
| Blocks | Source Files | Namespaces | Classes | Functions | Block Delta |
[ipy.exe] | Total | 1239 | 2 | 1 | 10 | 90 | 0 |
Hit | 1043 | 2 | 1 | 10 | 82 | 0 | |
Percentage Hit | 84.18 % | 100.00 % | 100.00 % | 100.00 % | 91.11 % | 0 | |
[IronMath.dll] | Total | 1520 | 3 | 1 | 3 | 173 | 0 |
Hit | 1322 | 3 | 1 | 3 | 158 | 0 | |
Percentage Hit | 86.97 % | 100.00 % | 100.00 % | 100.00 % | 91.33 % | 0 | |
[IronPython.dll] | Total | 84661 | 185 | 11 | 579 | 8029 | 0 |
Hit | 70176 | 185 | 11 | 534 | 6311 | +7 | |
Percentage Hit | 82.89 % | 100.00 % | 100.00 % | 92.23 % | 78.60 % | +0.01% | |
[All Components] | Total | 87420 | 190 | 13 | 592 | 8292 | 0 |
Hit | 72541 | 190 | 13 | 547 | 6551 | +7 | |
Percentage Hit | 82.98 % | 100.00 % | 100.00 % | 92.40 % | 79.00 % | +0.01% |
Though Frank Sinatra says it best, “I’m leaving today” isn’t exactly accurate; my last day as a Microsoft employee was July 23rd, 2010. This post is almost two weeks delayed as Felicia and I have been on the road since the 26th, driving cross-country to the east coast; we also decided to leave Seattle in favor of New York, our home state.
Both decisions were extremely difficult to make, as I will miss all the brilliant people I worked with. Just being in their presence made me feel smarter, and we accomplished some amazing things together. Many were also my friends, making this a very heart-wrenching decision too. However, I joined Microsoft to bring Ruby and other open-source programming languages to the .NET framework, as well as to promote open-source practices in general, and I promised myself to ensure the truth of that statement throughout my Microsoft career. So, when my manager asked me, “what else would you want to work on other than Ruby,” I started looking for a new job outside Microsoft.
While Microsoft’s commitment to dynamic languages on .NET has been questioned many times, my tiny team has been excellent at suppressing those fears with quality implementations of Ruby and Python for .NET, compiler services and language embedding API called the Dynamic Language Runtime, and integration with .NET application frameworks like Silverlight and ASP.NET. And most recently the beginnings of IDE support for dynamic languages in Visual Studio. And all this released under an well-known open-source license, the Apache License (Version 2). This was only possible because my team had the freedom to do what we needed to do to counter those fears and run an effective open-source project
However, a year ago the team shrunk by half and our agility was severely limited. I’m omitting the internal reasons for this, as they are the typical big-company middle-management issues every software developer has. In short, the team is now very limited to do anything new, which is why the Visual Studio support for IronPython took so long. IronRuby’s IDE support in Visual Studio hasn’t been released yet for the same reasons. While this is just one example, many other roadblocks have cropped up that made my job not enjoyable anymore.
Overall, I see a serious lack of commitment to IronRuby, and dynamic language on .NET in general. At the time of my leaving Tomas and myself were the only Microsoft employees working on IronRuby. If this direction for dynamic languages on .NET is a path you do not want Microsoft to take, I strongly suggest you provide feedback to the team’s management directly. Also, Jason Zander runs the Visual Studio team, which IronRuby, IronPython, and the DLR happen to be a part of, and is a big proponent of these dynamic languages efforts, so provide him with your thoughts as well.
That being said, I am still interested in implementing dynamic languages on .NET, so I will remain a IronRuby core-team member, ironically making me the first non-Microsoft core contributor. The bad-news is I will no longer be working on IronRuby full-time, but in the near future I’m definitely staying active. Also, Tomas will definitely continue working on IronRuby when he can; we weren’t the last two people left for no reason. :-)
Given that Tomas and I will only be working part-time on IronRuby now, I invite the Ruby and .NET communities to come help us figure out how to continue the IronRuby project, assuming that Microsoft will eventually stop funding it. I’ll start a thread on the IronRuby Mailing List shortly, so keep an eye on that if you’d like to help. [Update: here’s the thread about the next steps for IronRuby. Join the list and discuss.]
While moving to New York is mainly a personal decision, as both my fiancée and I grew up there and our immediate families are still there, it was also for professional reasons; I’ve accepted a new position at Lab49, a financial technology consulting firm in New York City. I chose the financial industry not just because its dominance in New York, but because I see a lot of similarities between financial software and developer tools. Financial software serves a very technical user, much like programmers, but unlike programmers I know nothing these users, making it a challenging new space. It will be familiar as well, as Lab49 has done work with the new Technical Computing team, which many people who once worked on dynamic languages moved to. Lab49 was also very interested in my IronRuby and IronPython background, so it’s a great next step for me.
I’m grateful to have worked on compilers full-time, outside of academia, while still contributing to open-source, especially at a company that hardly showed up on the open-source radar just 4 years ago. And at least one dynamic language at Microsoft is getting love; IE9’s JavaScript engine, and Microsoft has awesome intentions with it. I’m totally a supporter of most things Microsoft is doing, and I look forward to working closely with them on financial problems. I’m just extremely disappointed with their decisions around dynamic languages on .NET. As one former-teammate’s email signature read, “If your ideas are any good, you'll have to ram them down people's throats.”
I’m looking forward to this new chapter in both my life and my career. Not only am I living in the city that never sleeps, but I hope to build upon my dynamic language work and use it in an area completely new to me. While I expect to still be Ruby and .NET oriented, my posts will be about solving new problems, and should make for some good reading. Stay tuned, and thanks for all the support thus far.
by Jimmy Schementi (jschementi@gmail.com) at August 06, 2010 09:40 PM
Help
create
a non-tribal
version of StackOverflow for Unix and Linux questions.
As we know, tribalism makes you stupid. So let us commit to the Linux and Unix Q&A site powered by StackOverflow that will help answer questions for Unix and Linux users of all distributions and blends.
At the time of this writing, only 91 users have committed.
Tell your Solaris, FreeBSD, NetBSD, OpenBSD, Unix, OSX, Linux, Red Hat, Fedora, Ubuntu, Debian, Mandrake, Mint, Arch, Slackware, CentOS, Gentoo, OpenSUSE, friends to commit to it and help create a global community of Unix love.
by Miguel de Icaza (miguel@gnome.org) at August 06, 2010 02:01 AM
We just released Mono Tools for Visual Studio.
There are four main features in MonoTools 2:
Thanks to everyone that participated on our beta program for all of the bug reports and feedback!
MonoTools is the foundation on which we are building the upcoming Mono for Android toolchain.
With the introduction of MonoTools for Visual Studio, we are also moving our long-term maintenance Mono release from the Mono 2.4 release to Mono 2.6, the release that we announced last week.
Download our betas from this page. On Windows, you would install our plugin for either 2008 or 2010 and you need to install Mono 2.6.5 on the target platform (Windows, Linux or MacOS).
On Linux, run `monotools-gui-server' or `monotools-server', this will let Visual Studio connect to your machine. Then proceed from Windows.
On MacOS, double click on the "MonoTools Server" application.
Once you run those, MonoTools will automatically show you the servers on your network that you can deploy to or debug:
ASP.NET debugging with this is a joy!
This release is the first one that uses our new soft debugger. With is a more portable engine to debug that will allow our users to debug targets other than Linux/x86 for example OSX and Windows.
This is the engine that we use on MonoTouch and that we are using for Mono on Android.
Our previous debugger, a hard debugger, worked on Linux/x86 systems but was very hard to port to new platforms and to other operating systems. With our new soft debugger we can debug Mono applications running on Windows, helping developers test before moving to Linux.
When you are developing large applications or web applications, you want your turn around time from the time that you run hit Run to the site running on Linux to be as short as possible.
Cheap Shot Alert: When dealing with large web sites, we used to behave like J2EE: click run and wait for a month for your app to be loaded into the application server.
This is no longer the case. Deployments that used to take 30 seconds now take 2 seconds.
Our plugin now supports the Visual Studio 2010 new features for plugin developers.
This means you get a single .vsix package to install, no system installs, no registry messing around, no dedicated installers, none of that.
The full plugin installs in 3 seconds. And you can remove it just as easily.
Then you can just from VS's Mono menu pick "Run In Mono" and pick whether you want to run locally or remotely.
We now also support multiple profiles, so you can debug from Visual Studio your code running on Linux boxes, Mac boxes or your local system.
MonoTools was our first Windows software and we learned a lot about what Windows developers expected.
We polished hundreds of small usability problems that the community reported in our last few iterations. You can also check our release notes for the meaty details.
And we integrate directly with SuseStudio to create your ready-to-run appliances directly from Visual Studio.
by Miguel de Icaza (miguel@gnome.org) at August 04, 2010 12:21 AM
I'm happy to finally announce that the ASP.NET dynamic language support is now open source:
Download IronPython and ASP.NET integration
For a full IronPython release with the Python standard library, download IronPython 2.7 Alpha 1.
This release contains the source code to Microsoft.Scripting.AspNet.dll, located in the src directory, licensed under the Apache License (Version 2). It will be available in the source repository for IronPython in the very near future, but don't hesitate to start sending in patches. This release is compatible with IronPython 2.7 Alpha 1.
This download enables IronPython as an ASP.NET programming language. To create a new IronPython ASP.NET WebForms project, simply copy examples\web.config and examples\bin, and use examples\hello-webforms.aspx as a reference. A redistributed copy of the IronPython 2.7 Alpha 1 binaries can be found in the examples\bin directory; all files except Microsoft.Scripting.AspNet.dll, the IronPython ASP.NET integration, are from the IronPython 2.7 Alpha 1 release.
For more detail on getting started, here’s a simple walk-through of making the “hello-webforms” app.
Here's what's in the zip file:
/License.html - The Apache License, Version 2. /dlr-aspnet.sln - VS2010 solution for examples /examples - Examples of using IronPython in ASP.NET. /examples/Web*.config - configures ASP.NET to use IronPython /examples/bin - Microsoft.Scripting.AspNet.dll, the ASP.NET integration, and a redistribution of IronPython 2.7A1. /src - C# source code that builds Microsoft.Scripting.AspNet.dll This release renames the main DLL from Microsoft.Web.Scripting.dll to Microsoft.Scripting.AspNet.dll. If upgrading, you'll have to replace all occurrences of Microsoft.Web.Scripting with Microsoft.Scripting.AspNet. This will primarily be at the top of all aspx pages, as well as in your application's web.config. Also note the version number is now 1.1.0.1, which matches all the other Microsoft.Scripting assemblies.
As always, please report issues on the IronPython issue tracker. You can also try to fix any issues yourself and submit a patch. Lastly, you can actually talk to humans on the IronPython mailing list.
by Jimmy Schementi (jschementi@gmail.com) at July 26, 2010 07:07 AM
We have now migrated all of Mono's source code from the Subversion at our Cambridge office over to GitHub.
We are going to be maintaining a migration FAQ and providing help to developers on irc.gnome.org channel #mono for the new setup.
The web site has not been updated yet and we still reference Subversion urls, but this will be fixed in the next few days.
by Miguel de Icaza (miguel@gnome.org) at July 23, 2010 01:19 AM
Mono has an strace-like feature built into the runtime. This is useful to see which methods are being called by your application, just invoke Mono with --trace.
Our upcoming version has a neat new feature, when you use --trace=E:ExceptionName or --trace=E:all you get a stack trace of where the exception was thrown from:
$ gmcs.exe mono$ gmcs missing.cs error CS2001: Source file `missing.cs' could not be found Compilation failed: 1 error(s), 0 warnings
And now with tracing enabled, we do it setting the MONO_ENV_OPTIONS variable:
mono$ MONO_ENV_OPTIONS=--trace=E:all gmcs missing.cs[0xb75136f0:] EXCEPTION handling: System.IO.FileNotFoundException: Could not find file "missing.cs".
"{unnamed thread}" tid=0x0xb75136f0 this=0x0x53f18 thread handle 0x403 state : not waiting owns ()
at System.IO.FileStream..ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare,int,bool,System.IO.FileOptions) {0x00619}
at System.IO.FileStream..ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare) {0x00022}
at (wrapper remoting-invoke-with-check) System.IO.FileStream..ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare) {0x0004f}
at System.IO.File.OpenRead (string) {0x0002c}
at Mono.CSharp.Driver.Parse (Mono.CSharp.CompilationUnit) {0x00016}
at Mono.CSharp.Driver.Parse () {0x00068}
at Mono.CSharp.Driver.Compile () {0x00098}
at Mono.CSharp.Driver.Main (string[]) {0x000a2}
at (wrapper runtime-invoke) {Module}.runtime_invoke_int_object (object,intptr,intptr,intptr) {0x00033}
error CS2001: Source file `missing.cs' could not be found
Compilation failed: 1 error(s), 0 warnings
by Miguel de Icaza (miguel@gnome.org) at July 22, 2010 02:30 AM
Aaron just shipped Banshee 1.7.3 which lets you purchase MP3s from Amazon from the player directly.
Banshee Amazon MP3 Store
Screencast!
Get it fresh!
by Miguel de Icaza (miguel@gnome.org) at July 22, 2010 02:11 AM
While adding Retina Display support to TweetStation I learned a couple of tricks that I figured would help other developers.
Apple's Retina Display conveniently doubles the number of pixels on each dimension, the previous iPhone display had 320x480 pixels while the new new phone has 640x960 pixels.
To make existing applications run out of the box on these new displays Apple changed the units on the display and instead of using pixels they now use points. They are not really typographical points, but iOS "points". Both the old iPhones and the new iPhone have a resolution of 320x480 points.
This means that existing code that absolutely positioned views on the screen will get the views laid out in the same positions regardless of the device that the code is running on.
In UIKit points are interpreted based on the value of the UIView.ContentScaleFactor. If the value is 1.0 each point is mapped to one pixel. If the value is set to 2.0 each point is mapped to four pixels (2x on each dimension).
UIKit layout and CoreGraphics rendering primitives will automatically take this factor into account and position and render accordingly.
The Image loading routines have been extended to load higher-resolution images by default when you use UIImage.FromBundle. On Retina Displays the code will probe for a file@2x.ext filename when you request file.ext to be loaded. For example this loads the background texture you use:
texture = UIImage.FromBundle ("Images/texture.png");
TweetStation's images are here.
All the icons and images on TweetStation were done using Inkscape. When I exported the icons they would invariably look blurry. For example, this is from my first attempt at getting the swipe menu on TweetStation working:
I would just draw my icons on Inkscape and then export them as bitmaps. Inkscape would then anti-alias the result, you can see how the reply icon is not rendered properly:
The Inkscape FAQ contains this bit of information that is very useful if you are drawing small icons:
With the current renderer, it is not possible to completely get rid of antialiasing. However, it is possible to partially suppress it on export. Usually, antialiasing is unwelcome in horizontal and vertical lines which become "blurred". To work around this, make sure your horizontal/vertical edges are snapped on the pixel grid, and all strokes are a whole number of pixels wide. Then, export bitmap at the default 90dpi so that 1 px unit corresponds to 1 bitmap pixel. In the resulting bitmap, snapped color boundaries will be perfectly crisp.
These are the settings that I use now to export the same graphic:
I used guidelines on Inkscape to help me:
This is the new version of the icon before it gets composited with the background
To export the same image at high resolution, set the DPI in the dialog box to 180. Inkscape will automatically change the width and height for you.
The other problem that I had was related to my centering code, this is what the rewteet icon looks like from the menu above:
The blurry sides of the retweet icon were caused by the math code setting the X position of the image at a fraction of a point (0.5).
After fixing both problems and adding a nice backdrop shadow, this is what the menu looks like:
Loading images with more pixels for the background texture and the icons wont do you any good if you are drawing the images yourself.
When you create a graphics context using the pre-iOS 4 APIs you will end up with a context that assumes that you are not aware of the Retina Display and hence will rescale your drawing up. When you create an image context of 100x100 points like this:
UIGraphics.BeginImageContext (new SizeF (100, 100));
You will end up with a context that has 200x200 points, but will automatically double all of your pen widths and will scale any images up. If you had a high-resolution image, it will first be scaled down when rendering to the context, then scaled up when rendering the data.
To take advantage of the retina display you need to call a new method:
UIGraphics.BeginImageContextWithOptions (SizeF size, bool opaque, float scale);
If you set scale to zero, it will pick 1.0 for old display and 2.0 for retina displays. I use this helper method to support both iOS 3.x and iOS 4.0:
void BeginImageContext (SizeF size)
{
if (Graphics.HighRes)
UIGraphics.BeginImageContextWithOptions (size, false, 0);
else
UIGraphics.BeginImageContext (size);
}
This is how the swipe menu is rendered at high resolution:
Apple's Supporting Resolution Independence document has more information.
by Miguel de Icaza (miguel@gnome.org) at July 21, 2010 02:11 AM
Adrian Collier has just blogged about the release of the Solution Navigator extension for VS 2010. One of the things I hate about Visual Studio is the number of tool windows that I have to juggle around. I have two big monitors at work and I still run out of screen real estate every so often. I hate working from home because on my laptop screen, after all the toolwindows, there’s like seven pixels left for actual code. So, anything that promises to reduce the need for multiple toolwindows excites me. Solution navigator, in one fell swoop gets rid of a bunch of toolwindows that I use regularly. There is a solution navigator pane that takes the place of solution explorer and makes it much richer. The tooltips (pinnable!) are the killer feature for me though, hover over any artifact in your code and everything you’d want to know about that is present in a tooltip.
This works for both C# and VB projects. I also happened to write the initial support for VB projects before the Solution Navigator team took over ( It was a very fun week writing the basic plumbing and seeing everything light up!). Check it out and give the team your feedback.
Mono's source code is being migrated to GitHub on July 22nd, starting at 9am Boston time.
We are psyched that Github was kind enough to host Mono's large repositories for free on their system. We are also taking advantage of their new Organizations functionality.
Gonzalo posted the following details about the migration:
We are moving our source code repository to GitHub. On July 22nd ~9am EDT (1300 GMT) the subversion repository at "svn +ssh://mono-cvs.ximian.com/source" will be set to read-only mode and kept that way forever. We estimate that the process of migrating all the projects and moving them to GitHub will take more than 3 and less than 8 hours. Once it is completed we will send an email to this list with URLs to the new repositories, FAQs,...
If you have any questions about the migration, please ask them here and we will add them to our Git Migration FAQ.
by Miguel de Icaza (miguel@gnome.org) at July 20, 2010 09:37 PM
Andrew just announced Mono 2.6.7, the version that is replacing our long-term maintenance release of Mono with plenty of bug fixes as well as the following new features:
Our CentOS/RHEL packages install on /opt/novell/mono, just like our packages for SUSE Linux Enterprise and should not conflict with your own packages of Mono that you might have from some other sources.
by Miguel de Icaza (miguel@gnome.org) at July 20, 2010 09:24 PM
by Angle Bracket Percent : ASP.NET at July 20, 2010 07:28 AM
New releases and announcements from the “Iron” projects have come out over the last couple days, so I wanted to give you an overview of what’s happening, point out the really cool parts, and reiterate some of the motivations.
From a release perspective, both IronRuby and IronPython released new versions of the DLR-based .NET programming language implementations: IronPython 2.7 Alpha and IronRuby 1.1. Click on the respective release name for the full release notes and downloads, but I’ll summarize a bit here:
Install IronPython 2.7 Alpha (includes Visual Studio tooling)
This Alpha release is the first IronPython release working towards Python 2.7 compatibility, and contains a number of bug fixes and performance improvements. It also now requires .NET 4.0 or Silverlight 4; you will need to build from source for down-level frameworks. The installer now includes Visual Studio support for IronPython, rather than being a separate installer, and the source-code for the tools has been open-sourced! Keep reading for licensing information …
Aside from a bunch of bug-fixes, the latest release of IronRuby adds support for .NET extension methods, meaning that .NET programming patterns that are dependent on extension methods, like LINQ, the Reactive framework, Parallel.NET, etc, are now all usable from Ruby code. For example, here’s a simple LINQ example:
For more information see the 101 LINQ samples ported to IronRuby.
Also, since I never announced the IronRuby 1.0 release on my blog … consider this the announcement.
IronRuby, IronPython, and the DLR are now licensed under the Apache License, Version 2. To address all concerns around “why” this is changing, it is solely in reaction to feedback about the licensing terms from users and the .NET/Python/Ruby/dynamic-language communities at-large. The Apache License is a more familiar and popular license to those communities than the Microsoft Public License; using it should lower any license-related barriers people encountered in the past when considering these programming-language implementations.
by Jimmy Schementi (jschementi@gmail.com) at July 20, 2010 03:05 AM
by Angle Bracket Percent : ASP.NET at July 18, 2010 04:30 AM
If you check the latest versions of IronRubyIronPython or the Dynamic Language Runtime you will see that Microsoft has now relicensed the code from the Microsoft Permissive License to the Apache 2 License.
by Miguel de Icaza (miguel@gnome.org) at July 17, 2010 11:52 PM
It has been brought to my attention that the upcoming 200 year celebration of Mexico's independence from Spain on September 15th has lead to office unrest all across the country between teams that have both Mexicans and Spaniards working side-by-side.
Spain might have won the world cup, but Mexico upgraded from being a colony of Spain and being subject to the will of the Kings of Spain, to a democracy subject to the will of drug dealers.
To resolve this animosity, I propose we settle the score this September 15th with a cook-off between Spaniard food and Mexican food.
I propose the cook-off from the Novell/Cambridge team be held at my place the weekend before the festivities to settle the score before the celebrations take place. We will make delicious tacos. Gonzalo will be making a Paella.
by Miguel de Icaza (miguel@gnome.org) at July 17, 2010 11:24 PM
We’re pleased to announce the Alpha release of IronPython 2.7 which can be downloaded at http://ironpython.codeplex.com/releases/view/42434. This is a major new version of IronPython with a number of significant updates. Because this is an Alpha release it is not yet feature complete nor fully compatible with CPython 2.7. Changes thus far include:
- Updates the language to be compatible with CPython 2.7
- Adds integrated Visual Studio support (IronPython Tools for Visual Studio)
- Extends CPython 2.7’s documentation with useful information pertaining to IronPython
- Adds the mmap and signal modules
- Includes a number of performance updates and bug fixes
- Switches the license to Apache License, Version 2.0
- Requires .NET 4.0 and Silverlight 4.0
Python 2.7 includes a number of features backported from the Python 3.0 series. This release implements the new builtin _io module, includes dictionary and set comprehensions, set literals, supports multiple context managers in the with statement, and adds several new functions to the itertools methods, and auto indexing for the new string formatting. There are also numerous updates to the standard library such as ordered dictionaries and the new argparse module.This release also includes a “IronPython Tools for Visual Studio” option within the IronPython installer. This enables one install to get both IronPython and IronPython Visual Studio support assuming you have an existing installation of Visual Studio 2010. This version of IronPython Tools includes a number of bug fixes as well as the start of improved WPF designer support. We discovered very late that the WPF designer support may crash VS when not running under the debugger. If you’d like to try the WPF designer support and give us feedback, just launch another Visual Studio instance and attach to the instance in which you are using the WPF designer support.We’ve also updated the IronPython installer to include documentation based upon the CPython documentation. This new .chm file includes documentation on the Python language and standard library. It’s been extended from the normal Python documentation to include IronPython specific topics such as the DLR hosting APIs and extending IronPython from statically typed .NET languages.We flushed out more support for missing built-in modules which CPython includes. This release includes the mmap and signal modules bringing better support for interoperating with unmanaged code.As usual there are a number of bug fixes and performance improvements. This release includes major performance improvements in cPickle, the sum built-in function, and includes support for fast exceptions which do not use the .NET exception mechanism. There have also been improvements to significantly reduce memory usage of the IronPython ASTs. One of the end results of these numerous improvements is that IronPython’s startup time has decreased by 10% when compared to IronPython 2.6.1.Finally, with this release we have changed the license from the Microsoft Public License to the Apache License, Version 2.0. We’ve made this change based upon continual feedback and questions from the community. The Apache License will be more familiar while remaining an open source license.- The IronPython Team
by Michael Foord (noreply@blogger.com) at July 17, 2010 12:59 PM
With Mono 2.8 we want to make it very easy for developers to use the LLVM powered Mono engine and the new Mono Garbage Collector.
Previously users had to build Mono from source code and choose as part of their build whether they wanted the Mono VM to be powered by LLVM or not and whether they wanted to use the Boehm GC or the new Generational GC. Typically users would have to keep multiple parallel Mono installations.
This is no longer necessary.
Mono 2.8 by default behaves just like any other Mono, by default you get the regular fast Mono JIT with the Boehm GC.
You can then pass the --llvm flag to instruct the Mono runtime to use LLVM for code generation (much slower to JIT, but produces better code for long-running applications or compute intensive applications).
To use the new garbage collector you pass the --gc=sgen command line argument.
We wanted users to try LLVM, SGen or the LLVM/Sgen combination without having to modify all of their launch scripts or existing tools so we introduced a new environment variable that Mono parses on startup, the MONO_ENV_OPTIONS variable.
Mono will parse the contents of the MONO_ENV_OPTIONS variable as if the arguments had been passed in the command line, so you could do a full bootstrap of Mono's class libraries with both by doing:
$ export MONO_ENV_OPTIONS="--llvm --gc=sgen" $ make
Update: Both the --gc=sgen and --llvm options depend on your architecture and operating system being supported by SGen and LLVM and depend on you compiling your runtime with these features.
SGen will be automatically enabled if your OS/architecture is supported when you run configure.
LLVM requires the installation of the LLVM libraries. We strongly recommend that you use our modified version of LLVM that has been extended to support various constructs required by .NET.
For more information on compiling LLVM and building your Mono with it, see our web page
by Miguel de Icaza (miguel@gnome.org) at July 15, 2010 03:47 AM
Visual Basic generally goes out of its way to help out the programmer. Delegate relaxation is a good example of this need to please. Simply put, this feature is about being able to assign to delegates when the signatures don’t exactly match. The canonical example goes like this:
Sub ClickHandler() Handles Button1.Click
Button1.Click takes two parameters whereas ClickHandler takes no parameters. This is quite a convenience if you don’t plan to use the eventargs.
Another example that’s easier to examine is something like:
Dim a As Action = AddressOf String.Empty.ToString
Action is a delegate that takes no parameters and has no return type. We are assigning a function to it which has a return type of String. Here is the code that’s generated for this case.
Dim $VB$Closure_ClosureVariable_14_D As New _Closure$__1 $VB$Closure_ClosureVariable_14_D.$VB$Local_VB$t_string$S1 = String.Empty Dim a As Action = New Action(AddressOf $VB$Closure_ClosureVariable_14_D._Lambda$__1) Public Sub _Lambda$__1() Me.$VB$Local_VB$t_string$S1.ToString End Sub
What is all this messy code doing? What happens is that when the compiler sees a delegate of type <expr>.method it breaks it down into temp = <expr> and temp.Method. The temp var is then hoisted into a closure if needed. The closure class also has a method which has the right signature needed for the target delegate. This function simply calls temp.Method. If there was no relaxation needed (meaning no lambda is generated) then the temp is simply a temp and doesn’t have to be hoisted.
My last post was in September 2008. It’s been close to two years since I posted anything. My rationalization for such unforgivable behaviour is that I started working on a project that wasn’t public at that time. This was an incubation effort and I was part of a very small team of fantastic people that adopted agile practices and is easily one of the best teams for which I’ve worked. After that effort reached it’s conclusion, I, changed roles and moved to the Visual Basic .NET team as a developer and during the Dev10 cycle I owned intellisense, the expression editor and even code model for a while. Recently I’ve started working more with the compiler codebase and there is a quite a bit of blog fodder when you work in the compiler space. So I’m reviving this blog to write about all the corner cases of the language that I’m learning – or atleast that is the reason I give myself for doing something that I should just have been doing all along for the past two years.
TweetStation
is my first native iPhone app (as opposed to my award-winning
HTML5-app iCoaster).
More screenshots can be seen here
Just like Rails, TweetStation is an opinionated Tweeting client, it contains my personal blend of features that I enjoy from other twitter clients, but also tries to do something about changing the world.
TweetStation has been designed to elevate the level of discourse on Twitter.
At a conceptual level, this is achieved by applying the cardinal rule of not taking anything too seriously, specially any interactions you might have online.
At a practical level this is achieved with two features. The first feature plays back chicken noises whenever you request more Tweets (this is bound to the Tweetie-like "Pull to Refresh" feature). These chicken noises have been engineered to remind you that no matter how important an argument appears to be in Twitter, you should not take it too seriously.
Additionally, the chicken-noise-on-refresh serves as a cue to other people talking to you that you rather see what @jacksonh, or @Mickey__Rourke have to say than hear them parrot back the physics of clouds wikipedia page that they just read twenty minutes ago.
When you compose a message with TweetStation music starts playing back in the background. This music was specially selected to elicit in you the desire to write a witty and clever response as opposed to the usual "well, fuck you too" response seen too often on social media sites. The result will be the kind of tweet that your local newspaper would publish in the front page, or in their "Social Media Expert" column.
But there is an elephant in the room, and I want to speak directly about it. Many Twitteristas are concerned about the Tweetpocalypse and Twitter's transition to use some bizarro world non-feature called OAuth.
Tweetstation is feature packed and does not suffer from either problem. You can trust that Tweetstation was developed using the best engineering techniques available today, and that you will never be the victim of the Tweetpocalypse and be left incommunicado due to some silly programming mistake. Not in this 32-bit century, not in the next, and not under my watch. If my years of experience taught me one thing is and one thing only, it is when to use a 32-bit integer data type and when to use a 64-bit one. Do not fear dear user, I also master many other data types, but I digress.
But you might be wondering, why another Twitter client, and why now? As a twitterista you know that there is a special bond, an intimate bond if you will, between the twitterista and his twitter client. This bond can exist as long as both the twitterista and the twitter client grow hand in hand, if they co-develop. And I found myself at odds with the design decisions and paths that other twitter clients were taking. In a metaphorical way, I felt uncomfortable, like a Woody Allen character under pressure. But a character that lacked Woody Allen's command of the language.
And this is how TweetStation was born, it was a labor of love, but mostly of social awkwardness when my friends mocked my Twitter client for lacking a chicken noise, or when they suggested things at dinner like "would it not be cool if...". I decided to change all that, and make sure that other twitteristas in the future did not feel the social scorn that I had gone through, and this is why TweetStation's source code is on github.
You can get TweetStation from iTunes.
By default, the chicken noises are off. To turn on this features, go to "Settings" and in the "Poultry" section set "Chicken Noises" to the "ON" position.
Since this is going to become a FAQ, I wanted to address this here.
I have two sets of keys that I got from Twitter to access the service using OAuth. One set of keys is the regular set of keys that anyone can get, and I attached the name "TrollStation Pro" to that one. This set of keys is what I placed on the public code on GitHub, so anyone can try and anyone can use. I reserve the right to change that name on a day-by-day basis depending on what I consider to be funny that particular day.
The second set of keys are labeled as "TweetStation" and that one is used for the actual application on the AppStore. These keys are special because Twitter was kind enough to give me access to their service using "xAuth" which improves the login experience (no web browser is involved).
TweetStation was submitted to Apple before I could get my hands on an iPhone4, so it is missing the high-resolution artwork. I just submitted a build that contains high-resolution icons for the iPhone4.
by Miguel de Icaza (miguel@gnome.org) at July 10, 2010 08:47 PM
Enthought, Inc., a leading Python and Scientific Computing technology provider announces plans to extend the SciPy and NumPy libraries to IronPython and the .Net Framework. Availability of these libraries on .Net provides advanced technical computing tools to the flexible, fully-featured Microsoft Windows software environment.
"These libraries are fundamental building blocks for technical computing applications, and we are very excited to see them become available to IronPython and the .Net community," said Shahrokh Mortazavi, Architect in Microsoft's High Performance Computing Group.
"It is exciting to witness the impact SciPy and NumPy have had on the technical computing community over the last decade. We are excited to unleash the power of these tools to a whole new group of users on the .Net platform," said Travis Oliphant, president of Enthought, addressing the attendees of the SciPy 2010 conference in Austin, TX.
SciPy and NumPy are a suite of high-performance statistical and numerical tools for the Python programming language. They are used primarily for rapid data processing and analysis in scientific and quantitative applications. Enthought principals, Eric Jones and Travis Oliphant, were the initial authors of SciPy, and Travis was the primary author of NumPy. Both tools are actively maintained and enhanced by a large open-source community, and have been widely adopted by leading researchers, institutions, and commercial enterprises worldwide.
The .Net Framework consists of a Common Language Runtime (CLR) abstraction layer over the operating system, pre-built class libraries for low-level programming tasks, and a range of specialized development frameworks and technologies that enable reusable custom applications. The collaborative effort announced today will enable existing Python applications utilizing NumPy and SciPy to run un-modified on IronPython and to take advantage of the high-performance Just-In-Time (JIT) compiler technology built into the .Net framework.
by Michael Foord (noreply@blogger.com) at July 09, 2010 11:30 PM
We are happy to announce a minor update to the IronPython Tools for Visual Studio. IronPython Tools for Visual Studio (IPyTools) is a set of extensions available for Visual Studio 2010 which supports development of IronPython applications. This release is our 3rd Community Technical Preview (CTP) and builds upon the previous two releases. The release is a minor update which includes bug fixes and a number of small features. You can download the latest release at http://www.ironpython.net/ironpython/tools/
There is also one major change in that the project system is no longer based upon the files which live on disk. Instead we now follow the normal VS project model. This means files must be explicitly added to the project and files which you don’t want in the project won’t automatically show up. We made this change based upon feedback from people using the tool and think it will make it more familiar for normal Visual Studio users. Despite this change there is still support for an “implicit” project when working without a project.
Like the previous release this release includes support for Intellisense including member completion, signature help, find all references, and goto definition. It enables quick browsing of your code using the object browser and the editor navigation bar. It has an interactive (REPL) window that enables the development of applications in an interactive way. IPyTools supports lightweight development without a project as well as working with project files in the tradition of Visual Studio . Opening a .py file causes IronPython Tools to model the code in the containing directory as an implicit project for Intellisense features. There are project templates for console, WPF, WinForms, and Silverlight applications. WPF applications support drag-and-drop UI development. Debugging of Python applications works just like you debug other languages in Visual Studio.
We are still working on our final licensing terms for IronPython Tools, and as such this release is licensed under a temporary limited use license. While we weren’t able to finalize this for this release we expect to have this finalized for the next release.
The full list of changes includes a number of bug fixes:
- Interactive window now respects VS color settings
- Fixed default settings for insert tabs, enter completing options, list of characters to complete to
- Fixed auto-indent inserting extra tabs on a blank line
- Enables usage of VS common settings for smart indentation and tabs and respects those options.
- Escape in REPL cancels both the intellisense session and the current input
- REPL: When a completion item is focused but not selective enter should not complete it
- REPL: We should respect the various intellisense completion options
- REPL: We should be using IronPython’s auto intending
- Fix repl not respecting smart up/down on startup if the window was set to be open
- REPL: Don’t allow history if the current command is still running – instead navigate the buffer
- REPL: Enable syntax highlighting even if a command throws an exception
- REPL: Remove trailing new lines from REPL history so we go back to the last line of input
- REPL: When pasting ensure there’s a new line
- REPL: Auto indent should delete selected lines when pressing enter
There are also a few new features:
- New Fill Comment Paragraph feature
- Implemented auto-dedent so it will backspace # of tabs
- Support for disabling intellisense via normal VS mechanism
- Support for hiding “advanced” members in intellisense (currently defined as __abc__ members)
There is one major change:
- Removes directory based projects in favor of normal VS style projects
- The IronPython Team
by Michael Foord (noreply@blogger.com) at July 09, 2010 11:17 PM
Gonzalo yesterday pointed me to a feature in the HTTP client stack for .NET that I did not know about.
If you want the server to gzip the response before sending it to you, set the AutomaticDecompression flag in your HttpWebRequest:
var request = (HttpWebRequest) WebRequest.Create (uri); request.AutomaticDecompression = DecompressionMethods.GZip;
This will set the Accept-Encoding HTTP header to gzip when you make your connection and automatically decompress this for you when you get the response stream.
Update: on the comments there is a suggestion that Deflate is another option you can use, and you can combine both GZip + Deflate on the flags above.
Update2: Dennis Dietric emailed me to point out an important bit: if the server side does not support GZip or Deflate content, you will could get a 406 return code, so when dealing with third party web sites you need to be prepared to fall back and retry your request without compression in place. The relevant sections of rfc 2616 are 10.4.7, 14.1 and 14.3.
by Miguel de Icaza (miguel@gnome.org) at July 09, 2010 10:46 PM
Over the past couple of years Microsoft has been open sourcing some key .NET libraries under the MS-PL or Apache 2 license.
We are tremendously grateful to Microsoft for making these components open source. This has allowed us to distribute this in the past, and we are going to be bundling a lot more of it with Mono 2.8:
In Mono 2.8, the following assemblies and code come from Microsoft:
With Mono 2.8 we are going to default to the .NET 4.0 profile. So from the list above MEF, the DLR, OData and MVC2 become first class citizens in Mono-land, no longer third-party packages that you needed to install.
Update: as of July 17th 2010, the DLR, IronPython and IronRuby changed their licenses from MS-PL to Apache2.
by Miguel de Icaza (miguel@gnome.org) at July 07, 2010 11:53 PM
by Angle Bracket Percent : ASP.NET at July 07, 2010 07:29 AM
I am very excited to see the first
MonoTouch book published.
You could not ask for a better team of authors to explain the MonoTouch and the iPhone platform. Chris, Craig, Martin, Rory, and Wally.
This book was a team effort by various active members of the MonoTouch community. They nurtured the community from the start by exploring MonoTouch, by reporting bugs and missing functionality in MonoTouch and by guiding .NET developers through the new world of building iPhone applications.
Congratulations on the book release guys!
You can find them here:
by Miguel de Icaza (miguel@gnome.org) at July 06, 2010 10:33 PM
Jonathan Pobst has released a new version of his paint program, Pinta, a lightweight app that runs on Linux, OSX and Windows and is built entirely using Gtk#.
In this version, Jonathan added the MonoDevelop docking library to allow users to reorder the editing tools to match their workflow:
There are ready-to-run packages available for Windows, OSX, Ubuntu and OpenSUSE.
by Miguel de Icaza (miguel@gnome.org) at July 06, 2010 10:00 PM
(See below for Updates).
TweetStation
is my first native iPhone app (as opposed to my award-winning
HTML5-app iCoaster).
More screenshots can be seen here
Just like Rails, TweetStation is an opinionated Tweeting client, it contains my personal blend of features that I enjoy from other twitter clients, but also tries to do something about changing the world.
TweetStation has been designed to elevate the level of discourse on Twitter.
At a conceptual level, this is achieved by applying the cardinal rule of not taking anything too seriously, specially any interactions you might have online.
At a practical level this is achieved with two features. The first feature plays back chicken noises whenever you request more Tweets (this is bound to the Tweetie-like "Pull to Refresh" feature). These chicken noises have been engineered to remind you that no matter how important an argument appears to be in Twitter, you should not take it too seriously.
Additionally, the chicken-noise-on-refresh serves as a cue to other people talking to you that you rather see what @jacksonh, or @Mickey__Rourke have to say than hear them parrot back the physics of clouds wikipedia page that they just read twenty minutes ago.
When you compose a message with TweetStation music starts playing back in the background. This music was specially selected to elicit in you the desire to write a witty and clever response as opposed to the usual "well, fuck you too" response seen too often on social media sites. The result will be the kind of tweet that your local newspaper would publish in the front page, or in their "Social Media Expert" column.
But there is an elephant in the room, and I want to speak directly about it. Many Twitteristas are concerned about the Tweetpocalypse and Twitter's transition to use some bizarro world non-feature called OAuth.
Tweetstation is feature packed and does not suffer from either problem. You can trust that Tweetstation was developed using the best engineering techniques available today, and that you will never be the victim of the Tweetpocalypse and be left incommunicado due to some silly programming mistake. Not in this 32-bit century, not in the next, and not under my watch. If my years of experience taught me one thing is and one thing only, it is when to use a 32-bit integer data type and when to use a 64-bit one. Do not fear dear user, I also master many other data types, but I digress.
But you might be wondering, why another Twitter client, and why now? As a twitterista you know that there is a special bond, an intimate bond if you will, between the twitterista and his twitter client. This bond can exist as long as both the twitterista and the twitter client grow hand in hand, if they co-develop. And I found myself at odds with the design decisions and paths that other twitter clients were taking. In a metaphorical way, I felt uncomfortable, like a Woody Allen character under pressure. But a character that lacked Woody Allen's command of the language.
And this is how TweetStation was born, it was a labor of love, but mostly of social awkwardness when my friends mocked my Twitter client for lacking a chicken noise, or when they suggested things at dinner like "would it not be cool if...". I decided to change all that, and make sure that other twitteristas in the future did not feel the social scorn that I had gone through, and this is why TweetStation's source code is on github.
You can get TweetStation from iTunes.
By default, the chicken noises are off. To turn on this features, go to "Settings" and in the "Poultry" section set "Chicken Noises" to the "ON" position.
Since this is going to become a FAQ, I wanted to address this here.
I have two sets of keys that I got from Twitter to access the service using OAuth. One set of keys is the regular set of keys that anyone can get, and I attached the name "TrollStation Pro" to that one. This set of keys is what I placed on the public code on GitHub, so anyone can try and anyone can use. I reserve the right to change that name on a day-by-day basis depending on what I consider to be funny that particular day.
The second set of keys are labeled as "TweetStation" and that one is used for the actual application on the AppStore. These keys are special because Twitter was kind enough to give me access to their service using "xAuth" which improves the login experience (no web browser is involved).
TweetStation was submitted to Apple before I could get my hands on an iPhone4, so it is missing the high-resolution artwork. I just submitted a build that contains high-resolution icons for the iPhone4.
Login bug: There is a login bug if your password contains any special characters. I have submitted a bug fix to Apple (including the Retina display update). For now you can work around this issue by changing your password to use letters and numbers.
by Miguel de Icaza (miguel@gnome.org) at July 02, 2010 06:01 AM
This year I will be skipping the Guadec conference. Like Ted Gould we are expecting our first baby this year around the same time that Guadec will take place.
The good news is that next year any of you attending my talk at Guadec 2011 will get to enjoy a presentation packed with baby pictures.
I wish a happy Guadec to all the Gnomers attending!
by Miguel de Icaza (miguel@gnome.org) at June 30, 2010 10:46 PM
Apple and its AppStore did for software programmers what Google's AdWord did for bloggers and writers: it provided a mechanism for people to make money while doing what they love.
The AppStore takes a big weight from the shoulders of software developers by taking care of the distribution and billing system.
If I was in charge of the Windows 8 future (or MacOS for that matter), I would try to reproduce that formula on my mainstream operating system. And it seems from the leaked presentations that this is where Microsoft's head is.
The leaked mockups for the AppStore are creative, but the entire slide deck misses the fundamental point that people are scared of installing software on Windows.
Everyone is scared of installing applications on Windows either because they break the system or because you might be accidentally installing malware. In either case, the end result is countless wasted hours backing data up, reinstalling the operating sytem and all the applications.
An AppStore wont fix this.
For a Windows appstore to work, they need to guarantee that installing software wont ever break the system.
They need to produce an appliance that allows users to install and remove software in seconds, and yet, guarantee that installing and removing apps will never break the system. This is not a problem that can be solved by hiring an army of curators and people that just sit all day rejecting apps.
To solve the problem, Microsoft needs to both alter their kernel to ensure the safety of the host OS and come up with a new way of distributing applications. They need:
The Sandboxed Execution System: would prevent applications from touching the registry, installing any drivers, any hooks, any visualizers or any other deep integration features that applications typically use to integrate with the OS.
The sandboxed execution system would prevent applications from looking at the file system, except for locations that have been predetermined for sharing.
The kernel would have to enforce what files they get access to, what devices and what components they get access to. And should be set to a bare minimum.
Self Contained Applications would be required to install software from the network, or from their appstore. These applications would get absolutely no rights to modify anything outside their directory. Any extension points that they could register with the system ("open with") would have to be registered with the public extension point contract.
Public Contract for Extension Points Any extension points like "open with", or handlers for mime-types would be self contained in a manifest in the application directory.
Instead of having every app poking at the system registry and dumping their junk everywhere, applications would list all of their requirements from the operating system on the manifest and the OS would rebuild its internal data from all of the application manifests available from a user.
Limited APIs: File access APIs, display access APIs would have to be altered to give applications limited access to the host operating system, and to give them as little access to anything that most applications do not need.
The above obviously does not apply to frameworks like the .NET framework, Java or Adobe's AIR. But beyond frameworks, there are very few cases where an application really should have legitimate access to all of the features in the OS. Video games certainly do not need it, and even applications like Visual Studio would not need it.
by Miguel de Icaza (miguel@gnome.org) at June 28, 2010 09:17 PM
I've done some work on the builds for both IronPython.SQLite and IronPython.ZLib; with IronPython 2.7 on the way, the number of variants I need to build is going up. IronPython 2.7 will require .NET 4.0, so that saves me having to build a IronPython 2.7/.NET 2.0 version of everything as well.
Still, three variants is too many to build manually through Visual Studio, which is how I've built everything up to this point. The packaging into a zip file was also done manually. To save the effort, I've adopted psake as a build automation tool. It's based on PowerShell, which is a very nice administrative language (I actually prefer to Python for quick & dirty admin tasks – the horror!). The actually builds are still handled by MSBuild so that I can manage the files in Visual Studio; the psake script calls msbuild to build the library. I also have tasks to clean the source tree and build the .zip packages.
The real trick in this is building an .csproj file that can handle being built for both .NET 2.0 and .NET 4.0. The key to it all is the TargetFrameworkVersion property; by default, it is hardcoded to a specific .NET version (v2.0, v3.5, or v4.0) in the .csproj file. To change it during the build, msbuild needs to know that we might provide it on the command line. If you've ever opened a .csproj file, you make recognize these lines:
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration> <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
These lines will set the Configuration and Platform properties if they are not already set from the command line; that's what that Condition attribute does. We just need to do the same thing for the TargetFrameworkVersion property:
<TargetFrameworkVersion Condition=" '$(TargetFrameworkVersion)' == '' ">v2.0</TargetFrameworkVersion>
This allows us to change the TargetFrameworkVersion from the command line. For a little future proofing, I add a property for the IronPython version as well:
<IronPythonVersion Condition=" '$(IronPythonVersion)' == '' ">2.6</IronPythonVersion>
The psake build script is (by convention) default.ps1; I would have preferred build.ps1, but whatever. The core task is the Build task; all it does is call MSBuild:
task Build -Depends GenVersion {
exec {
msbuild /nologo /verbosity:minimal "$ProjectPath" `
/t:Build `
/p:Configuration=$Configuration `
/p:TargetFrameworkVersion=$TargetFrameworkVersion `
/p:OutputPath="..\$OutputPath" `
/p:IronPythonVersion=$IronPythonVersion
}
}
There are also tasks to build the zip files (requires 7-zip on the build system) and run the tests for the given project. All in all, using psake has been a great move, and while I have a few minor issues with it, I highly recommend it.
This is all well and good, but how do you actually use it to build it the library? Switch to the build directory, and, in a PwoerShell window, run:
.\psake
That's it, if a default .NET 2.0 Debug build is what you want; it will also run the tests. To build a Release build for .NET 4:
.\psake build –framework 4.0 –parameters @{config='Release'}
Finally, you can build the zip packages:
.\psake package
It's all much simpler than firing up Visual Studio and building zip files by hand.
I've also upgraded the IronPython.SQLite and IronPython.Zlib solution files to Visual Studio 2010. You can use the free Express editions to build them. Also, none of these changes affect NWSGI, yet.
Iron Web Analyzer is an open source application for web masters to analyze web sites content. Iron Web analyzer employ Iron Python to analyze server responed data. Iron Web Analyzer downloads data from server and dispatches them between Iron Python Analyzer installed on application and collect analyze results produced by Python applications.
In TIBCO Spotfire version 3.1, TIBCO introduces the concept of Script Controls. Scripts Controls provide the ability to add IronPython scripts into a Text Area inside a Spotfire Analysis file. The script has access to the full Client API (from the SDK), and its goal is to perform common automation tasks.
by Michael Foord (noreply@blogger.com) at June 19, 2010 08:21 PM
SharpDevelop 4 has been updated to support running IronPython unit tests that use the unittest2 library.
Make sure unittest2 is on the Python path before running the unit tests.
Out of the box SharpDevelop will actually use the unittest library's test runner. This seems to work however if you actually need to use the unittest2 test runner then you can modify the following two files in the folder: AddIns\AddIns\BackendBindings\PythonBinding\TestRunner.
- sdtest.py
- sdtestrunner.py
by Michael Foord (noreply@blogger.com) at June 19, 2010 07:52 PM
Chris Toshok has just announced our 7th preview of Moonlight 3.0. You can get it from our preview site.
What is new in this release:
by Miguel de Icaza (miguel@gnome.org) at June 19, 2010 04:05 AM
by Mark Rees (noreply@blogger.com) at June 17, 2010 04:32 AM
Today Infragistics announced that their NetAdvantage for ASP.NET will support Mono out of the box.
We loved working with Infragistics on this project, and I am very proud of the work that the Mono team did to get these fabulous controls working with Mono.
You can read more about Infragistics and Mono on Infragistics site where you can also try out some of their sample applications running on Linux with Mono.
From the press release:
"In recent years, our customers have indicated that their organizations are moving to mixed IT environments and require UI tools that enable them to deploy applications in either Windows or open source environments," said Dean Guida, CEO of Infragistics. "With Mono compatibility in our ASP.NET toolkit, we enable developers who have a need for open source development to create UIs that are the basis for Killer Applications and deliver the best user experiences possible."Infragistics ASP.NET toolset excels in top performance, flexibility and usability and enables developers to build rich Web applications for line of business. By providing full compatibility with the Mono runtime, Infragistics extends this functionality to the Mono community.
Coinciding with today's NetAdvantage for .NET 2010 Volume 2 availability, Infragistics highlights the ASP.NET toolkit's Mono compatibility through Sample Showcase hosted on a live Linux Server running Mono: http://mono.infragistics.com/
For us this is a very important milestone as developers building .NET applications need to complement the core framework with packaged components like the ones that Infragistics provides.
It also shows the maturity of the project, as commercial ISVs start supporting more Mono on Linux.
by Miguel de Icaza (miguel@gnome.org) at June 17, 2010 02:02 AM
We have finally released MonoDevelop 2.4. You can read a high-level description of the changes or see screenshots with the details. I would go for the screenshots myself.
We made packages for OpenSUSE, SLES, Windows and MacOS X. For other Linux distributions, you should consult with your favorite package provider or you can build it yourself from sources.
Congratulations to the team. They not only improved the UI and the editing experience, but they support Gtk#, ASP.NET MVC, Silverlight, MonoMac and MonoTouch deployments from the same IDE. We have also added support for WCF references and T4 macro processing.
For the next release we have a couple of big goals in mind for MonoDevelop:
As you can see from our list of MonoDevelop Tasks there are plenty of tasks that currently have nobody assigned to. This includes even popular features like F#, IronPython, IronRuby or PHP support.
We have limited resources and a huge wish-list. If you want to help us take on any of those tasks, please join us on IRC at irc.gnome.org on channel #monodevelop, or join our mailing lists.
by Miguel de Icaza (miguel@gnome.org) at June 16, 2010 09:38 PM
Abstract: The Dynamic Language Runtime (DLR) brings the power of dynamic languages to Microsoft .NET. It provides the plumbing for IronPython and IronRuby, a shared language hosting API, and also enables interoperability with static languages like C# and Visual Basic. Come hear how you can leverage these technologies in your own applications, and learn why dynamic languages deserve a spot in your toolbox!
Abstract: IronPython Tools for Visual Studio is an extension for Microsoft Visual Studio which provides Python programmers with a great development experience inside of Visual Studio. It supports all of the usual Visual Studio features such as editing including rich Intellisense, debugging, light weight Python projects, and participating in Visual Studio solutions. In addition to the usual Visual Studio features it also supports a REPL window for a lightweight development experience which Python developers are accustomed to. Come and see IronPython Tools in action and see some new and exciting ways to work in Visual Studio.
by Michael Foord (noreply@blogger.com) at June 15, 2010 10:53 AM
Perhaps my favorite feature in MonoDevelop 2.4 is the "Navigate To" functionality that we added. This new feature is hooked to Control-comma on Linux and Windows and to Command-. on Mac.
This feature lets you quickly jump to a file, a class or a method:
I used to navigate between my files by opening then from the solution explorer, and then using Control-tab or the tabs. Needless to say, the old way just felt too clumsy for a fast typist like me.
With Navigate-To, I can just hit the hotkey and then like I would in Emacs, type the filename, type or method and jump directly to the method. This is fabulous.
This will also search substrings, so you can either start typing the name of a method or you can fully qualify the method (for example: "Vector.ToString").
But it gets better, you can use abbreviations, so instead of typing "DialogViewController" you can just type "dvc":
BREAKING UPDATE Michael just told me of a cute extra feature: if your match is for a filename, if you type ":NUMBER" it will jump to the selected file to the specified line number.
The result:
by Miguel de Icaza (miguel@gnome.org) at June 15, 2010 03:32 AM
One cute feature of C# 1.0 was the introduction of the Conditional attribute. When you apply the conditional attribute to a method, calls to this method are only included in the resulting code if the appropriate define is set.
For instance, consider:
[Conditional ("DEBUG")]
void Log (string format, params object [] args)
{
Console.WriteLine (String.Format (format, args));
}
Calls to Foo.Log become no-ops unless you pass the -define:DEBUG command line option to the compiler.
What is interesting about this compiler-supported feature is that that the code inside the method Log is checked for errors during compilation as any other regular method. They are first class citizens.
by Miguel de Icaza (miguel@gnome.org) at June 13, 2010 08:30 AM
Ejstembler: A simple WinForm script which can encode or decode HTML and copy it to the clipboard
I was looking some lyrics up online this week, so I wondered how hard to would be to write a simple application to find lyrics to your favourite song. Or to your least favourite song. Or, in fact, to any arbritrary song. Via programmableweb, I found the API to lyricsfly, which looked easy to use. Another IronPython console app beckoned.
Keeping it simple, I decided to use optparse to parse the command-line options and urllib to make the http calls. This way the program can be called with the user_id that lyricsfly requires (head to their website and you can get a temporary weekly key to try this out) along with the artist name and song title. What I decided not to do at this stage was to process the resulting XML. Or handle any errors. Or handle cases where the user_id, artist or title is not supplied. But, although rudimentary, it works. ...
While SaveAs method in Word has Encoding parameter, it wasn’t quite clear, how would I specify it from pywin32.
So, my next attempt was to use IronPython, since it has native .NET interface with Office. The biggest advantage of this approach was the fact that you can do dir() on all objects and methods in IronPython shell.
After some googling on encodings, and IronPython Word scripting, here is the script I came up with. ...
by Michael Foord (noreply@blogger.com) at June 09, 2010 12:29 PM
I am proud to introduce my first iPhone App built entirely using standard HTML5 technologies.
I felt that I had to go with HTML 5 as I did not want to write the app once for the iPhone and once for the Android. I am also open sourcing this application in its entirety, to help future generation of mobile HTML 5 developers learn from my experiences and hopefully help them write solid, cross platform mobile applications using HTML 5.
I use this app every time we go to a pub, or when we are having lunch at the Cambridge Brewing Company.
Before you check it out, my lawyer has advised me that I need to add the following disclaimer:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
I give you: iCoaster.
Stay tuned for my Cheese Table app, coming soon to the iPad.
From my survey on iCoaster for iPad:
"I am currently resorting to use my four iPhones to create one giant iCoaster; this is ridiculous. Need iCoaster HD!!!!""Buying an iPad every time I want to put a drink down is expensive, though it is better than getting those little rings all over my shiny new table."
"Four coasters per iPad would be ideal"
"Please keep up the great work. Not sure what I would do without this app, would at least have a lot of ruined coffee tables."
Sadly, we do have some bugs being reported, and I can assure everyone that I am working around the clock to fix these issues. Ensuring that iCoaster is reliable is my top priority:
"If I put my drink on iCoaster, and then rotate my phone to the landscape orientation, my drink gets spilled onto my lap. Please fix this in the iPad version."
Update: We have confirmation that it works on WebOS and Blackberry as well. HTML5 FTW!
Update 2: Due to popular demand, I am launching an effort to bring iCoaster to the iPad. If you want to participate in the beta for iCoasterHD, please fill in this survey, your feedback will help me prioritize features.
Update 3: iCoaster works on walls too: http://yfrog.com/c9wlkogj.
Update 4: For those of you complaining about the missing DOCTYPE Geoff Norton has done what any honorable open source contributor would have done: he forked iCoaster and made it HTML "compliant": icoaster-fork.
Update 5: After today's brouhaha over Apple's HTML 5, Mike Shaver from Mozilla talks about the elephant in the room.
Update 6: iCoaster's HTML 5 fork has been forked to support full-screen on WebKit and Opera browsers.
Update 7: We have a Silverlight port! This enables iCoaster to run on the upcoming Windows Compact Edition Media 7 Series Phone Embedded Release Plus Pro Advanced.
Update 8: We got a Unity port of iCoaster, and showing true open source spirit, sethillgard open sourced the code.
by Miguel de Icaza (miguel@gnome.org) at June 05, 2010 03:40 AM
Last week we released our first beta for the upcoming MonoTools2.
There are four main features in MonoTools 2:
Download our betas from this page. On Windows, you would install our plugin for either 2008 or 2010 and you need to install Mono 2.6.5 on the target platform (Windows, Linux or MacOS).
On Linux, run `monotools-gui-server' or `monotools-server', this will let Visual Studio connect to your machine. Then proceed from Windows.
On MacOS, double click on the "MonoTools Server" application.
Once you run those, MonoTools will automatically show you the servers on your network that you can deploy to or debug:
ASP.NET debugging with this is a joy!
This release is the first one that uses our new soft debugger. With is a more portable engine to debug that will allow our users to debug targets other than Linux/x86 for example OSX and Windows.
This is the engine that we use on MonoTouch and that we are using for Mono on Android.
Our previous debugger, a hard debugger, worked on Linux/x86 systems but was very hard to port to new platforms and to other operating systems. With our new soft debugger we can debug Mono applications running on Windows, helping developers test before moving to Linux.
When you are developing large applications or web applications, you want your turn around time from the time that you run hit Run to the site running on Linux to be as short as possible.
Cheap Shot Alert: When dealing with large web sites, we used to behave like J2EE: click run and wait for a month for your app to be loaded into the application server.
This is no longer the case. Deployments that used to take 30 seconds now take 2 seconds.
Our plugin now supports the Visual Studio 2010 new features for plugin developers.
This means you get a single .vsix package to install, no system installs, no registry messing around, no dedicated installers, none of that.
The full plugin installs in 3 seconds. And you can remove it just as easily.
Then you can just from VS's Mono menu pick "Run In Mono" and pick whether you want to run locally or remotely.
We now also support multiple profiles, so you can debug from Visual Studio your code running on Linux boxes, Mac boxes or your local system.
MonoTools was our first Windows software and we learned a lot about what Windows developers expected.
We polished hundreds of small usability problems that the community reported in our last few iterations. You can also check our release notes for the meaty details.
And we integrate directly with SuseStudio to create your ready-to-run appliances directly from Visual Studio.
by Miguel de Icaza (miguel@gnome.org) at June 04, 2010 01:56 AM
SharpDevelop 4 has been updated to support unit testing with IronPython.
First you will need to install Python 2.6. SharpDevelop uses the standard Python unit test library (unittest.py) to run the unit tests.
...
Once the project reference is added the unit tests can be run in the normal way by right clicking in the Unit Tests window and selecting Run tests. You can run all the tests in a project, all tests in a class or a single test method.
The output generated when running the unit tests is shown in the Output window.
Test failures are displayed in the Errors window. Clicking an error will open the corresponding code in the editor.
by Michael Foord (noreply@blogger.com) at June 02, 2010 05:02 PM
Excited to see the work happening on the Linux consumer space in the MeeGo Universe. There is now a MeeGo 1.0 download available for everyone to try out.
At Novell we have been contributing code, design and artwork for this new consumer-focused Linux system and today both Michael Meeks and Aaron Bockover blog about the work that they have been doing on MeeGo.
These screenshots are taken directly from Aaron's and Michael's blog posts. Aaron discusses the new UI for the music player Banshee and Michael discusses the new UI for the Email/Calendar program.
Media Panel in MeeGo
You can still get access to the full Banshee UI themed appropriately:
Themed MeeGo UI for Banshee
Check Aaron's blog for the details on the design process and the new features coming out for it.
Then, on the Evolution side of things Michael discusses Evolution Express a renewed effort to make Evolution suitable for netbooks. The work done there is amazing, here are some screenshots:
Evolution Express on MeeGo
Just like Banshee, Evolution now integrates with MeeGo panels, like this:
Summary of your tasks on the MeeGo Panel
This is what the new preferences panel looks like:
Themed MeeGo UI for Banshee
And finally the calendar:
Evolution Express Calendar on MeeGo
You can also run existing Mono applications on MeeGo. I give you the photo management application F-Spot:
F-Spot on MeeGo
And this is Jonathan's Pinta painting program built on Mono with Gtk#:
The Mono-based paint program Pinta
Pinta is fascinating as it shows how much punch can be packed by CIL code. Pinta and all of its effects use 328k of disk space and for distribution it only takes 108k of disk space.
And we are of course very happy to be supporting developers that want to target MeeGo using Windows, Mac or Linux with our MonoDevelop plugin for MeeGo.
If you are more of a Visual Studio developer, our upcoming MonoTools for Visual Studio 2.0 will also support developing applications for MeeGo from Windows.
I am blown away by the way that everyone involved in MeeGo has been able to execute on the vision of bringing Linux to the consumer space by the way of the netbook.
Kudos to everyone involved.
by Miguel de Icaza (miguel@gnome.org) at May 27, 2010 09:38 PM
Pmasiar:
Pmasiar:
Finally I decided to synchronize two separate .XAML files in each of the two different projects, so the challenge was to find the most unobtrusive way of working in both IDE’s and easily syncing the the .XAML files after edits had been made. Given that one of the IDE’s was running a dynamic language with a REPL built in, I thought it shouldn’t prove too difficult.
...
Like I said its far from a perfect solution and to be frank it’s somewhat annoying however my frustration is another thing altogether if I’m faced with doing all my layout and design in Visual Studio – so I will live with it for the moment. Hopefully the IronPython team and or the Expression Blend Team can find a solution that flows changes through more seamlessly in the short term and the perhaps in the long term allow us to open IronPython and IronRuby projects in Blend.
By the way if your wondering about the codename of the project that drove this adventure (PONGO) – the answer is yes if you guessed that it’s something that revolves around IronPython and MongoDB and I will be blogging about that more in the coming weeks.
This tutorial is to show how to use the .NET Selenium 2 with dynamic languages that run on the .NET Common Language Runtime. This tutorial uses IronPython.
To complete this tutorial you will need to have IronPython installed and you will also need to download the .NET Bindings from Google Code
This tutorial will not be using the Remote Driver and it will be using the InternetExplorerDriver as this is the only complete browser at the moment that doesn't need to be built from the Repository.
A requirement I have in an app I am writing is to allow the administrator to set up formulas which can be calculated at runtime. The client app is completely disconnected from Enterprise Core Objects, it uses a (query/command)->response approach so I didn’t want to expose OCL on the client, I also didn’t want to use OCL because I didn’t want arbitrary browsing of the model.
So I have been looking at IronPython – and I like it! I’m not going to go into details of what this code does, I’m just going to paste it so that you may take a look. In short the requirement is for the Admin to be able to retrieve values from the DB by name and perform whatever logic they wish in order to return a decimal result.
by Michael Foord (noreply@blogger.com) at May 25, 2010 06:21 PM
We are hard at work on MonoDroid -- Mono for Android -- and we have created a survey that will help us prioritize our tooling story and our binding story.
by Michael Foord (noreply@blogger.com) at May 22, 2010 01:20 PM
We are hard at work on MonoDroid -- Mono for Android -- and we have created a survey that will help us prioritize our tooling story and our binding story.
If you are interested in Monodroid and in participating on the beta program, please fill out our Monodroid survey.
Here is what you can expect from Mono on Android:
We are still debating a few things like:
We are currently leaning towards using VS2008/2010 for Windows during the beta and later MonoDevelop on Linux/Mac.
Like we did with MonoTouch, we will bring developers into the preview in batches of 150 developers, please enter enough information on the "comments" section if you want to be in the early batches.
by Miguel de Icaza (miguel@gnome.org) at May 21, 2010 11:04 PM
In our Beta for MonoDevelop 2.4 we introduced a new feature designed to help developers better explore a new API.
Many developers use the IDE code-completion as a way of quickly navigate and explore an API. There is no need to flip through the documentation or Google for every possible issue, they start writing code and instantiating classes and the IDE offers completion for possible methods, properties and events to use as well as small text snippets describing what each completion does as well as parameter documentation:
With MonoTouch, we were dealing with a new type hierarchy, with new methods. We found that our users wanted to explore the API through code completion, but they wanted more context than just the full list of possible options at some point.
For example, the UIButton class has this hierarchy:
Looking through the methods, properties and events of this class can be confusing, as for the UIButton class there were some 140 possible completions that came from the complete hierarchy. Sometimes the user knows that the method they want is a button-specific method, and as fascinating as UIResponder, UIView or UIControl might be, the method they are looking for is not going to be there.
With MonoDevelop 2.4 we introduced a new shortcut during code completion that changes the completion order from alphabetic to grouped by type, with completions from the most derived type coming up first:
To switch between the modes you use Control-space when the popup is visible. You can use shift-up and shift-down to quickly move between the groups as well.
I have been using this feature extensively while exploring new APIs.
by Miguel de Icaza (miguel@gnome.org) at May 10, 2010 04:48 AM
MonoDevelop 2.4 was a release in which we focused on improving the ergonomics of the IDE. We did this in dozens of places and we did this by dogfooding the IDE and comparing it to other tools and environments that we have been using.
With MonoDevelop 2.0 and earlier we used a dialog box like most other GUI applications from 2005. The dialog would remain on top of the text and the user would press next, and move the dialog box around as the matches were found.
In the current MonoDevelop (2.2) we adopted a more Firefox-like UI, this is what the search bar looks like:
We have a relatively big bar at the bottom of the screen, big labels, a drop down for picking previously searched items and an options menu that would let users pick manually case sensitivity, whole world matching or toggling regular expressions.
This took too much space, in a prime location of screen real estate. Additionally, the features although present were hard to pick. You would start an incremental search with Control-f but if you wanted to change the settings, you would have to use the mouse to access the options menu. If you later changed your mind, you would have to change the defaults again.
With the new release of MonoDevelop (2.4) we have changed this again, this time adopting the Google Chrome search bar and done a few other usability changes:
The first thing to notice is that instead of taking valuable horizontal space in the form of a full row, we now only take a corner of the screen, and we take it on the top right corner which is less likely to contain the information you are looking for as you search forward.
Case sensitivity searches now use the same model used by Emacs. If you start searching for a term and you type only lowercase letters, the search will be case insensitive.
Searching for "thread" will match "thread", "Thread" or "THREAD". But if at any point during the search you type an uppercase letter, then the search for this particular activation will switch into case-sensitive search. Searching for "Thread" will only match the word "Thread" and not "thread" or "THREAD".
And we also highlight matches like some Mac applications do, all matching words in the screen are highlighted, and the current match gets both a brighter color as well as a bubble that inflates and deflates on every match.
The replace functionality is built into this new UI, and is accessed either with a hotkey (Control-H) or by clicking on the left-side icon:
Just like Google Chrome, we use a watermark to show the number of matches in the document.
MonoDevelop 2.4 is packed with new features, and I hope to blog about some of the design decisions of the new feature as time permits. In the meantime, check out the list of new features in the Beta for MonoDevelop 2.4.
by Miguel de Icaza (miguel@gnome.org) at May 07, 2010 07:26 AM
Jonathan Pobst has announced the release of Pinta 0.3:
Live Preview
Pinta is a lightweight paint application for Linux, OSX and Windows written entirely in C# and using the Gtk# toolkit for its user interface. From the FAQ:
Is Pinta a Port of Paint.NET?Not really, it's more of a clone. The interface is largely based off of Paint.NET, but most of the code is original. The only code directly used by Pinta is for the adjustments and effects, which is basically a straight copy from Paint.NET 3.0.
Regardless, we are very grateful that Paint.NET 3.0 was open sourced under the MIT license so we could use some of their awesome code.
Jonathan further adds that this release is very close to feature parity with the original Paint.NET.
by Miguel de Icaza (miguel@gnome.org) at May 04, 2010 03:50 AM
A Python DB-API 2.0 module that makes it easy to use Microsoft ADO for connecting with databases and other data sources using either CPython or IronPython.
This version is highly refactored following the work of Adam Vandenberg, and also has all of the current user suggested patches. Both the Mercurial tree and the downloadable zip files are updated. (There is no fancy installer, just copy the folder in your site-packages folder.) This has been tested using CPython 2.3, CPython 2.6, IronPython 2.6 (.NET 2) and IronPython 2.6(.NET 4), accessing .mdb, MS-SQL and MySQL databases. There is a separate .zip for Python 3.1.
by Michael Foord (noreply@blogger.com) at May 03, 2010 10:52 AM
IronPython.Zlib implements the zlib module for IronPython using ComponentAce’s zlib.net, which is a purely managed implementation of the zlib library. IronPython.Zlib is entirely managed code and works with both 32-bit and 64-bit IronPython. It passes all of the Python 2.6 zlib and gzip tests and most of the zipfile tests.
IronPython.SQLite is a port of pysqlite to IronPython using C#-SQLite, which, similar to zlib.net, is a managed implementation of SQLite. Thus, IronPython.SQLite is also 100% managed code. It passes about 87% of the Python 2.6 sqlite3 tests; the remaining ones are mostly corner cases or rarely used functionality.
by Michael Foord (noreply@blogger.com) at May 01, 2010 05:04 PM
Wow, it’s been a long time – I wanted to manage at least one post per month, but it’s been three months. Ah well, I’ve been busy working on filling in a couple of holes in the IronPython standard library: sqlite3 and zlib.
IronPython.Zlib implements the zlib module for IronPython using ComponentAce’s zlib.net, which is a purely managed implementation of the zlib library. IronPython.Zlib is entirely managed code and works with both 32-bit and 64-bit IronPython. It passes all of the Python 2.6 zlib and gzip tests and most of the zipfile tests.
IronPython.SQLite is a port of pysqlite to IronPython using C#-SQLite, which, similar to zlib.net, is a managed implementation of SQLite. Thus, IronPython.SQLite is also 100% managed code. It passes about 87% of the Python 2.6 sqlite3 tests; the remaining ones are mostly corner cases or rarely used functionality.
Neither of the above libraries have been built or tested with IronPython for .NET 4.0. I don’t see any reason they shouldn’t work, but they’ve never been tried. If anyone does try, let me know how it goes!
by Michael Foord (noreply@blogger.com) at May 01, 2010 04:25 PM
<script src="http://gestalt.ironruby.net/dlr-latest.js" type="text/javascript">
</script> <script type="text/ruby">
window.alert "Ruby in the browser!"
</script> <script type="text/python">
window.Alert("Python works too!")
</script>Writing Silverlight applications in Ruby, Python, and other DLR-based languages only requires a local web server, a text editor, and a browser which supports Silverlight on Windows or Mac OS, or Moonlight on Linux systems.
by Michael Foord (noreply@blogger.com) at May 01, 2010 04:12 PM
Before April 8th, developers targeting the iPhone had to deal with this section:
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.
The above is a pretty reasonable requirement as it gives Apple the chance to not have to maintain and support internal APIs, temporary APIs or APIs that have not fully matured.
When iPhoneOS 4.0 was announced, the wording was changed to:
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
This spelled disaster for many developers that had chosen to use other programming languages like C#, Delphi, Lua, Python, Javascript, Java, Scheme, ActionScript and a handful of others. It also put a stop to porting efforts for languages like Eiffel and other industrial languages that can be used on the iPhoneOS and the iPad.
Much of the discussion for the rationale of these changes on the blogosphere has centered around personal language preferences. They amount to little more than the usual discussions of Mac vs PC or Emacs vs VI.
When Greg from Tao Effect discussed this with Steve Jobs his reply shed light into the reason. There is a business reason, and possibly a UI reason. Here are my theories.
With the iPhone Apple revolutionized the phone market in a way that nobody had planned for. Microsoft, Nokia, RIM, HTC and everyone else was left to catch up with the user experience and the operating system. One year after the iPhone took the world by surprise, Apple opened up the developer stack, launched the AppStore and leapfrogged every competitor in the field.
Apple had the first mover advantage in a space that they created: the high-end smart phone market.
The problem that Apple faces is that now every competitor has a blueprint of what they need to aim for. Competitors now know what the minimum required user experience and features required are. And they all likely have plans on how they can differentiate themselves and add features that Apple does not have.
And this is where Adobe enters the picture.
Flash and Flex have a huge user base of developers that have been building web and desktop applications for the past few years.
Although Flash applications on the iPhone do not look and act like native iPhone applications they are useful for a certain class of development. It would very likely attract Flash developers to the iPhone, but also Objective-C developers to Flash. Developers that probably are not interested in creating UITableViews or using the low-level APIs, but wanted to focus more on the interactive content creation or exploring new UI ideas or games.
Flash's killer feature would be that the same code that ran on the iPhone would run on many devices with minimal changes. The applications do look alien on every platform, but not every application needs to use native controls. Games, storyboards, marketing tie-ins and a whole new class of ideas do not need a native UI.
Flash would erode some of Apple's first mover advantage in the market they created. So section 3.3.1 was added to protect Apple's shareholder's interests.
Apple being the #1 platform for mobile applications and being the largest distribution channel for those applications probably felt that it would be ok to do.
Eventually, Android, Windows Mobile 7 and Nokia will catch up in terms of UI with Apple. It might take a few years before there is a marketplace as large as Apple's AppStore and a few years before these phones catch up to Apple's dominance in the space.
My prediction is: When those platforms do catch up to Apple in terms of market share and applications Apple will lift the restrictions on section 3.3.1. Apple at that point will have nothing left to lose and everything to gain. Adobe will also bring Flash back to the iPhone as it will be a nice bump in revenues.
As I mentioned before, using cross-platform solutions like Flash or Silverlight would make every application look alien. But also like Steve Jobs alluded to, developers would not have access to new features on the iPhoneOS if they had chosen a technology that did not expose it.
For example, when Apple introduced in iPhoneOS 3.2 the new split views that the iPad uses extensively when rotating your screen, that functionality would have taken too long to bring in a satisfactory way to say Silverlight on iPhone or Flash on iPhone. Or when Apple introduced the UIView that can be used to render maps, it would also have been challenging to embed this control. Or when Apple introduced GameKit, an API to connect iPhones and exchange messages between them.
As a developer, I feel that I should be responsible for my technological choices. If I pick a cross-platform toolkit that looks horrible on the iPhone, it will just leave the space open for a competitor to do a better job. Or if my application does not take advantage of a new API in iPhoneOS, I am also leaving a flank open for a competitor to take over. Apple does not need to intervene with guidelines as the application quality, the AppStore, magazines, reviews and word of mouth are creating the conditions for an all-out darwinian survival of the fittest.
MonoTouch has been misrepresented, initially by Gruber and by most people covering the debate over section 3.3.1. Probably because few of them have actually used MonoTouch or because they are not familiar with .NET. Probably folks think that MonoTouch is .NET, and .NET is Microsoft's Java and draw their own conclusions.
MonoTouch brings the C# language and the core of .NET to the iPhone, but does nothing to provide a cross-platform UI experience or for that matter any sort of mobile device cross-platform APIs.
We bring the C# language, garbage collection, a type safe system that help reduce errors, make programmers happier and more productive on the iPhone while getting access to every single iPhoneOS API that they want to.
We have also been able to expose new APIs that Apple has exposed in record time thanks to the fact that we are not really an abstraction layer over the iPhoneOS, but merely a compiler that talks to the native APIs.
We released the iPad support 24 hours after Apple released the SDK. We released the iPhoneOS 4.0 support within days of the release (mostly because every one of us was pretty bummed out). Our APIs are a 1:1 mapping to the iPhone APIs.
Just like C and C++, if developers want to reuse code between MonoTouch, Windows 7 or MonoDroid, they will have to split their UI and device-specific code from their business logic. MonoTouch does not provide such an abstraction layer.
The "core of .NET" that I refer to previously means: garbage collection, type safety, the platform-invoke bridge, file and networked streaming APIs (contrast with the iPhone ones), XML and Json libraries, Language Integrated Query, access to web services and the ability to reuse hundreds of GUI-less libraries that have been created for .NET.
We believe that MonoTouch does not erode Apple's first mover advange and nourishes the iPhone ecosystem by giving developers and users the native iPhoneOS experience.
by Miguel de Icaza (miguel@gnome.org) at April 28, 2010 08:56 PM
This post is part of the “MIX10 – Pumping Iron on the web” series:
The original post was mistakenly removed, so it’s been reposted with the original post date, 4/27/2010. Sorry if this confuses your blog readers or causes any other inconvenience.
Up until now I've discussed how to use dynamic languages to power both the server-side as well as the client-side of your web-application, but what if you want to apply these methods to solve certain problems in an existing application?
A low-risk, high-benefit use of dynamic languages in your existing applications is for testing. This helps make the act of writing tests simpler, and quite possibly more fun, encouraging your team to actually maintain the test suite.
Before looking at how to test web-apps, let's take a brief look at what a test written with RSpec, a popular Ruby testing framework, looks like:
Note: there are Ruby testing frameworks that look a bit more like what you might be used to. The following is an equivalent test written with test/unit, and this will give you a better idea of the structure of the above example:
The RSpec snippet almost reads like english, making it very clear what the intended behavior of Stack is. Also, it shows the power of Ruby for creating internal DSLs; a "language" built out of the constructs of an existing language. describe and it look like language keywords, but in-fact they are really just methods, because Ruby has optional parameters (as we discovered earlier with Sinatra). Using actual strings as the test name, rather than a method name, allows you to describe the test accurately. Each object has a should method which makes any subsequent calls part of an assertion, making it very obvious which value is the "expected" value and which is the "actual".
The crazy thing is how little code is required to make that work; 24 lines of Ruby. The key points are that yield executes the do-end block passed to a method, and the should method is added to every object, turning any subsequent methods calls into an assertion:
However, please don't use this example as your real testing framework, and then get mad at me when it doesn't have a feature you want; RSpec, Bacon, or test/spec are much more mature testing frameworks that support this same syntax.
See my previous post about using IronRuby to test C# Silverlight applications; it’s still relevant though it’s a fairly old post.
IronRuby and IronPython are built on-top of the Dynamic Language Runtime, which is comprised of many parts, one of which being a .NET Hosting API, allowing you to embed a scripting language in any .NET app.
Now we come to the "ah-ha!" moment of the talk; everything you've seen in the MIX10 posts is made possible by this API. Keep in mind these languages are built on .NET, so their implementations are accessible from any .NET language. C# and VB today are not built on .NET; they just compile programs to run on .NET, which is why you can't easily host those languages today.
Here's the catch; since these language engines are built on .NET, they need to run in a .NET application. So, all Ruby or Python code runs by hosting the languages inside a .NET application. We do things to make this seamless in specific environments: for example, ir.exe and ipy.exe are both .NET programs which host the language and run the code in a command-line, mimicking the behavior of ruby.exe and python.exe. Here are some other popular hosts:
However, we can't provide "runners" for every environment that will spring up, so we allow you to use the same APIs that these runners use in your own apps. These APIs have been kept very simple, as we want any .NET developer to be able to use a DLR scripting language in their applications.
But why embed a scripting language into your application? The main scenario is to scripts as an extensibility mechanism, either internally or as functionality you provide for your end-users. Here are a few concrete examples of what scripts could be used for:
Let's show you how to do the basics, and hopefully that will spark your imagine to think up other cool use-cases:
There are basically three types you need to know; ScriptRuntime, ScriptEngine, and ScriptScope.
ScriptRuntime is a level of encapsulation for your scripts; it represents the DLR scripting runtime, and all script operations go through it.
ScriptEngine is the type that is returned from ScriptRuntime.GetEngine; it represents a DLR-language. In this case, we asked for the language by name, as that's the easiest way to keep it easily configurable, but the downside is you need language configuration info in your App.config. However, if you only want to depend on IronPython, you can use IronPython.Hosting.Python.CreateEngine(), which does all the setup for Python for you.
The ScriptEngine enabled you to execute code in that language, in a variety of ways, from the basic engine.Execute method (essentally eval), or being more fine-grained engine.CreateScriptSourceFromString(code).Compile().Execute(), which parses the file, compiles it, and then executes it. Code can be executed against a ScriptScope to set initial state and share state between executions.
ScriptScope defines the state for your script; like what variables/methods are present. It is a dynamic object, so you can do things like scope.page = this, and that will set the page variable for scripts that execute against the scope. In downlevel .NET frameworks, you'd have to use scope.SetVariable(page, this).
Slight aside: since these APIs are .NET based, the dynamic languages themselves can consume them to run other dynamic languages! For example, here's Ruby executing Python code through the DLR Hosting APIs:
What's also interesting is the dynamic languages can communicate between each-other just as easily; here's Ruby calling Python code:
Anyway, hopefully this sparks some creativity! For more web-related information, also posted about this in relation to Silverlight applications: Scripting C# apps with IronPython.
The next post will show some cool applications of this … (coming soon).
by Jimmy Schementi (jschementi@gmail.com) at April 27, 2010 10:19 AM
This post is part of the “MIX10 – Pumping Iron on the web” series:
The original post was mistakenly removed, so it’s been reposted with the original post date, 4/26/2010. Sorry if this confuses your blog readers or causes any other inconvenience.
IronRuby and IronPython are fully-supported in the browser, thanks to Silverlight. In-fact, they are hands-down the simplest way to develop a Silverlight application. This is not only because of how expressive the programming languages are; the integration with Silverlight doesn't fight how the web works.
For example, here's an entire Silverlight app which just writes a message into the HTML page, written in Python:
DLR-based Silverlight applications let you write HTML script-tags in other languages than JavaScript, but in a way that works cross-browser and cross-platform; the languages work in Moonlight on Linux as well.
Both inline and script-src tags are supported, so your scripts can be separated from the HTML file:
This integration makes writing Silverlight applications just as easy as they were in Silverlight 1, but with the power of .NET and Ruby or Python. DLR-based applications also support a XAP model for anyone familiar with how static Silverlight applications work, so you get to choose which way you prefer to write your applications.
All the specific examples used in this section of the talk were taken from these posts:
Next up, using dynamic languages in your existing web-applications.
by Jimmy Schementi (jschementi@gmail.com) at April 26, 2010 10:18 AM
This post is part of the “MIX10 – Pumping Iron on the web” series:
The original post was mistakenly removed, so it’s been reposted with the original post date, 4/25/2010. Sorry if this confuses your blog readers or causes any other inconvenience.
One reason for embracing dynamic languages is to make your entire web-development experience simpler, be it on ASP.NET enabled web-servers, or on the client through Silverlight. Let's first look at the server.
Both IronPython and IronRuby can run on the same infrastructure as your ASP.NET applications, though in their own ways. Due to historic reasons, IronPython is supported as an ASP.NET language through the ASP.NET Dynamic Language integration, and IronRuby is supported through IronRuby.Rack, which enables Rack-based Ruby web-applications to run on ASP.NET. However, both are open-source, so each one could be ported to the other language.
Since these DLR-based languages run on ASP.NET, deploying them is no different than any other ASP.NET application; they can be run on any ASP.NET enabled web-server like IIS. Keeping that in mind, let’s first look at how simple Ruby web apps can be.
Ruby itself has very expressive syntax, and the Ruby community has built many web-frameworks to make web-development really simple. For example, Sinatra is a web-framework made to minimize the amount of code required to respond to web requests:
The above code does exactly what it says; when a get request happens for '/', show "Hello, World" on the page. This highlights Ruby's domain-specific language abilities; get looks like a keyword, though it's really just a method call with '/' as the first argument (Ruby lets you omit parenthesis from method calls too ... any VB script fans out there?). The do-end block is syntactic sugar for passing a lambda as the last-argument to the get method; all Ruby methods take an arbitrary "block" of code between do-end or {}. Inside that block is what happens on each request, and whatever is returned is written to the response ("Hello, World"); the last statement of any expression (blocks, methods, if-statements, etc) is implicitly the return value of the statement.
For all those C# fans, you can use curly-braces too:
Though these features sound arbitrary by themselves, if I were to write this with only the more-familiar language features found in Ruby, it would lose its character:
This defines a Ruby method verbose, which explicitly returns the string "Hello, World", and then calls the get method directly with the first argument being the URL and the second argument being an explicit pointer to the verbose method. Why does this look so much uglier? While this might be closer to how the programming language actually runs the initial examples, it's not how the programmer thinks.
Not to leave Python out of this love-fest, Python can make this look very pretty as well, but in her own special way. Imagining that a Sinatra-like library exists for Python:
Here the index method is created, which explicitly accepts both the request and the response as arguments; Python's all about being explicit, while Ruby is very implicit. Then the method would be "decorated" with the sinatra.get decorator, which would tell the web-framework that index represents a get-request for "/".
What's a decorator?
A Python decorator is basically a function that accepts a function and returns a function, so this imaginary Sinatra-like framework would define
getsomething like this:Another way of looking at it is without the decorator syntax:
It’s a bit more readable than Ruby, and almost equivalent to the decorator way, except for the order of
getin the code. You'll also see that getting a method pointer is much cleaner than Ruby (indexvs.method(:index)); in Rubyindexwould call the method, since Ruby allows method calls with or without parenthesis, where Python uses parenthesis to indicate a method call.
Point being is that both Ruby and Python are very expressive in their own ways, and makes it really easy to make simple websites on Windows. The IronRuby team takes of advantage of this to power http://ironruby.info, a Ruby-compatibility reporting website. This is the code from the main page:
This renders the index.haml template with the data returned from Stats.get_latest, which is pretty much what the code says. The HTML is generated from the haml templating engine, which makes generating HTML and calling Ruby code extremely easy:
To play around with using HAML, you can use aspnet-haml to support .haml files though ASP.NET.
One of the most popular (or most buzzed) web-frameworks is Ruby on Rails, which is just a collection of Ruby libraries for structuring your web-application. Rails uses the Model-View-Controller pattern, so any ASP.NET MVC people will find it a very-familiar framework. However, Rails really shines when it comes to interacting with the database through it's ActiveRecord library (the “Model” layer). ActiveRecord maps Ruby classes to database tables, and provides an Ruby abstraction for interacting with the database:
This is all the code that is required to map your Ruby classes to the database, as well as create the structure of the database. ActiveRecord dynamically provides getters/setters for the table, as well as sets up foreign-keys and relationships based on conventions (belongs_to :posts assumes that the table has a 'post_id' field).
Interacting with the database is just as easy as calling methods; Post.all translates to the SELECT * from posts SQL query, since the Post object is mapped to the posts database table. Post.find(<id>) does a SELECT * from posts where id=<id>, etc.
Because Rails uses the Rack web-server interface, it will also run on IIS using IronRuby.Rack. See the IronRuby Rails documentation for more info about using Rails on IronRuby, and the Ruby on Rails documentation for general Rails usage.
Those were all Ruby-based web-frameworks, but what about using ASP.NET directly? The IronRuby community has developed an integration with ASP.NET MVC, so you can write your controllers and views in Ruby. Special thanks to Ivan Porto Carrero for single-handedly maintaining it.
Again, to give Python some love, IronPython directly integrates with ASP.NET, letting you write your ASPX code-behind files in Python.
Because of ASP.NET's events-based API (rather than a response-based API like Sinatra/Rails), Python methods can automatically hook events by using the <object>_<event-name> convention, and all server-side controls with "ID"s ends up being a variable available to the Python module. And application-level event hooks can go in global.py. But it's really nice to write Language="IronPython" at the top. =)
Python code can can also interact with the controls:
The <%# %> syntax lets run Python code in the context of the ASP.NET control's data source. The repeater's data-source was set to a list of IMAGETAGS (a python class), which has all those fields on it.
In conclusion, on the server you have many options for using IronRuby and IronPython to simplify your solutions.
Next up, using dynamic languages on the client through Silverlight.
by Jimmy Schementi (jschementi@gmail.com) at April 26, 2010 06:35 AM
by Michael Foord (noreply@blogger.com) at April 25, 2010 01:56 PM
All in all I’ve reached my performance goal with IronJS, now it’s time to finish the runtime to support all statements/expressions/built-ins from the ECMAScript 3 Spec, there will still be changes which affect the performance of the core runtime/compiler, but (hopefully) not by any large amounts.
by Michael Foord (noreply@blogger.com) at April 25, 2010 12:51 PM
This post is part of the “MIX10 – Pumping Iron on the web” series:
The original post was mistakenly removed, so it’s been reposted with the original post date, 4/24/2010. Sorry if this confuses your blog readers or causes any other inconvenience.
This past week I had the pleasure of attending and speaking at MIX10 in Las Vegas about using IronRuby and IronPython on the web. If you’re a TV-person instead of a reading-person, here’s a video of the talk:
As I usually do, this series of posts will be a write-up of my talk … but first …
iron? - Jim Hugunin and John Lam have both been quoted as saying "Iron" stands for different acronyms; "Implementation running on .NET" and "It runs on .NET", respectively. I’m going to put my foot down and officially side with Jim, though really they are bacronyms; neither is actually the original meaning. A StackOverflow post explains more, and I hope that puts the wondering to rest.
This talk is all about the why and how of embrace dynamic languages on Microsoft's web platform - be it on the web-server (IIS) or in the web-browser (Silverlight), and even in existing applications. To start out with, here’s my rational for why we as a developer community should care:
It’s no secret that developers like things to be simple, and the web is pretty simple as far as application models go. While the web’s feature-set is pretty attractive itself (server-client oriented, instant client deployment, and cross-platform clients to name a few), the equally attractive development experience (simple UI mark-up system and a scripting language) still make it easy for people to build amazing websites.
Though the application model is simple, developers continue to evolve it; server and client frameworks are vital tools that make the web-development experience even more productive – it’s very rare that a website has no server side or client side dependencies.
These frameworks provide such innovative features because they stand on the shoulders of powerful and expressive dynamic/scripting languages, giving the frameworks the unique ability to model the "web" as they see fit.
While each web-framework is powerful in its own right, the power really comes from the choice to use whatever tools help get things done. Developers and designers for .NET have the same need to get things done, and if getting things done is essentially the result of programming language choice, what choices are there? Really only C# and VB, which are static programming languages, requiring a compile step before execution and relying on debugging to see code in action. Take a look at the other languages mainly used on the web again -- they're all dynamic languages, running from source code, and providing interactive environments for running code. Why is .NET static while the rest of the web is dynamic? Why can't they exist together? If .NET provided some language choice for developers, all the languages be used together, and the .NET community could benefit from the amazing work being done by dynamic language community, and visa versa.
We in-fact live in this world, and embracing dynamic languages is possible on .NET, but why would you want to do it? I'll discuss this in the following posts (links to posts coming soon):
by Jimmy Schementi (jschementi@gmail.com) at April 24, 2010 07:10 AM
Today we released MonoMac, a new foundation for building Cocoa applications on OSX using Mono.
MonoMac is the result of years of experimentation in blending .NET with Objective-C and is inspired by the same design principles that we used for MonoTouch.
It is also the result of weekend hacking as our day to day work revolves around Mono's efforts on Linux servers, Linux desktops, Visual Studio integration and our mobile efforts. Luckily, it shares some components with MonoTouch.
To get MonoMac, you need to get two modules from our subversion respository: monomac and maccore.
Many years ago Geoff Norton produced CocoaSharp, the first set of .NET bindings to the Cocoa API. CocoaSharp was a fine first binding at the time and it was a good place to start learning about the challenges of binding Objective-C APIs to be consumed by .NET clients.
Over the years three other frameworks were created to integrate the Objective-C world and the Objective-C APIs with C# and other .NET languages. Each one of these new frameworks had its pros and cons, and a year ago we made a call for all three competing frameworks to be merged, but sadly nothing came out of it.
When we created MonoTouch, we wanted a binding for the Cocoa APIs that would fit the patterns and idioms used in the C# and .NET worlds, that would comply with the .NET Framework Design Guidelines and would allow give developers all the tools required to build full Cocoa applications.
We had two main requirements: the binding should just work and the code should be MIT X11 licensed. For the binding to just work, we turned to the .NET Framework Design Guidelines book as it captures years of design decisions, programming idioms and advise that would help C# and .NET developers. By following the Design Guidelines we:
Luckily for us, .NET was designed from the start to be an interoperability framework. A framework that supports the most advanced requirements to make multiple runtimes and frameworks to communicate seamlessly with each other. We used these features to create our bindings.
The above goals turned into the following technical requirements:
More information about our API can be found here: http://monotouch.net/Documentation/API_Design
Cocoa consists of two sets of APIs, one set is an object oriented C-callable API and another one is the Objective-C based API.
C-based APIs were bound using a traditional P/Invoke approach where the C-based API is wrapped in a C# class. This includes APIs like AudioToolbx, CoreGraphics, CoreFoundation and CoreText. There is very little magic in these bindings, they are straight forward bindings, similar in spirit to what you would do if you wrapped those APIs for C++ use. I am in particular very proud of the much simpler AudioToolbox API.
The Objective-C APIs is where the UI heavy lifting takes place and where most of the high-level functionality is found, and this includes APIs like Foundation and AppKit. The Objective-C APIs are bound using a new binding engine (MonoMac.ObjCRuntime) and the btouch binding generator.
The btouch binding generator consumes an API contract in the form of a C# source file and generates a binding that matches the specified contract., for example, this is the API definition for the NSActionCell:
[BaseType (typeof (NSCell))]
interface NSActionCell {
[Export ("initTextCell:")]
IntPtr Constructor (string aString);
[Export ("initImageCell:")]
IntPtr Constructor (NSImage image);
[Export ("target")]
NSObject Target { get; set; }
[Export ("action")]
Selector Action { get; set; }
[Export ("tag")]
int Tag { get; set; }
}
We produced a comprehensive guide to binding Objective-C APIs with MonoTouch that applies directly to MonoMac.
Since a lot of the work of binding an Objective-C API is very repetitive, we have also included a header parser that does most of the heavy lifting in producing the above API from the Objective-C header file. The parser output then needs to be then massaged a bit to produce a binding that satisfies our design requirements. For example, NSArray arguments and return types must be looked up on the documentation and the proper strong typed inserted.
Unlike MonoTouch, MonoMac is not a complete binding for all of the Cocoa APIs at this point. This has been a weekend effort for Geoff and myself but it has reached the point where it can be used for building applications and it has reached the point where we can start taking contributions to the effort.
Currently MonoMac binds:
If you are interested in advancing the state of MonoMac, we are currently looking for contributors to help us bind the other Objective-C frameworks and help us complete AppKit.
MonoMac is merely the library that gives C# developers access to the underlying APIs on OSX, it does not include the tooling necessary to create a full application bundle.
Luckily, MonoDevelop has already most of the code needed in the form of the MonoTouch plugin. We will update this plugin to also support creating full application bundles for OSX.
A new feature that developers will be interested in is the new "Mono bundler" tool that we are hoping we can include in Mono 2.8. This bundler examines your .NET application and generates an application bundle that contains both your application code and any dependencies that it needs from Mono in a self-contained package.
This is the technology being used by Banshee on OSX today. The tool constructs a self-contained application based on your system installed Mono that you can distribute to your users, without requirement them to install Mono in the first place.
But we need your help. There are many small and medium tasks that developers can help us with that will free our already busy weekends and will allow us to have a full MonoMac experience done in a shorter period of time.
The more help we get, the sooner this will be done.
We need contributors in the following areas:
Please join us on the mono-osx mailing list to discuss the future of MonoMac.
Update Currently this requires a preview Mono to work from http://mono.ximian.com/monobuild/preview/download-preview/
by Miguel de Icaza (miguel@gnome.org) at April 20, 2010 01:16 AM
The projects are set to be built against the .NET 4.0.
Hola. En este post vamos a hablar un poco del hermano de Python (ó CPython) para la plataforma de desarrollo de Microsoft .NET, IronPython.
Como he comentado a lo largo de la vida de este blog, alguien que se quiera dedicar a esta bendita profesión no puede estar ajeno a las combulsiones que se originan en este mundo. Si alguien no se había enterado (que creo que no) Microsoft ha lanzado una nueva versión de su archiconocido Visual Studio, versión 2010, junto con la plataforma de desarrollo Framework .NET 4.0. Según parece en esta versión se le empieza a dar una mayor importancia a lenguajes dinámicos, como IronPython. Y es por ello que me he decicido a investigar este territorio, tan inóspito para mí. Y es que aprender nunca pasa de moda.
Decir que IronPython es un lenguaje creado por Microsoft, aunque no hay que pagar ningún tipo de licencia. IronPython es una implementación de CPython (ó Python) escrita en C#.
También he leído (que no probado) que IronPython funciona con la plataforma Mono.
IronPython está ligado a la plataforma .NET en la cual nos encontremos, dándole soporte en su versión 2, y ahora con más fuerza en la versión 4. No es objetivo de este post describir la historia ni características de IronPython en profundidad (¡para eso he puesto los links!)
by Michael Foord (noreply@blogger.com) at April 17, 2010 11:34 PM
Jcao219:
We have just released MonoTouch 3.0.0 with support for iPhoneOS 4.0's new APIs. To try it out, you need to have Apple's iPhone 4.0 SDK installed otherwise MonoTouch 2.0 wont let you download the new toolkit (since it is Apple confidential at this point).
This release is a preview, the final release will be some sort of 3.0.XX number.
This release includes API support for the features that Apple announced last week, in broad terms:
We also sneaked in some new work that is not bound to the iPhoneOS 4.0 API and can be used when building for iPhoneOS 3.1.x and 3.2.x:
by Miguel de Icaza (miguel@gnome.org) at April 16, 2010 11:18 PM
I just posted an article entitled “Custom Extension Types with VSIX” on the Visual Studio Blog.
Check it out if you’re interested in distributing custom content (not necessarily code) as a Visual Studio extension.
We’re pleased to announce the final release of IronPython 2.6.1. This version of IronPython makes great strides in stability and compatibility, including a considerable number of targeted bugfixes. This is our largest servicing release to date, and with your help both before and during the RC phase, along with the simultaneous release of .NET 4.0, this has become a very exciting release for all of us..NET 4.0 includes a new version of the Common Language Runtime and to use the new features you need to use a version of IronPython compiled against .NET 4. This is why IronPython for .NET 4 is a separate download. Surprisingly, this version of IronPython is much faster than IronPython for .NET 2. Dave Fugate blogs about this (and other improvements for working with IronPython under .NET 4):
The IronPython 2.6.1 RC included fixes for well over 50 bugs, large and small. Ctypes has had a number of significant updates, including union support, variant_bool, and wintypes. Another focus has been on sys.settrace, making debugging more reliable. For example, sys.settrace now returns the correct frame, supports tracing through modules, and no longer interferes with “import os”. Other notable fixes include thread-safe importing, and the missing error code in _winreg exception.
In addition, we’ve made a substantial improvement in import time. Not only does this reduce startup time, but it can speed up the importing of large, definition-heavy modules by up to 50%.
Since the RC, we have fixed numerous other issues, as well as adding CPython’s ssl.py to our distribution. We’ve also made some major unicode-related changes in response to your feedback on the mailing list, changes that improve compatibility with certain third-party applications including Django. In particular, invoking unicode() or using unicode string formatting will now call __unicode__() first if it is present on the object. Finally, we’ve included a new code sample that shows how to use __clrtype__ to create custom CLR classes from IronPython. This sample is a sneak preview of what we expect will become a fully supported IronPython module, so we encourage anyone who is so inclined to try it out and let us know how it goes.
Where exactly is this improvement coming from? Well we don't know quite yet. Our first bona fide .NET 2.0 SP1 versus .NET 4.0 IronPython perf suite run occurred less than two weeks ago! An educated guess is that at least a small portion of this improvement stems from the fact that Microsoft.Scripting.Core.dll is actually part of the .NET 4.0 framework. Any ways, you can see more of the performance characteristics of IronPython running under both these .NET releases here.
by Michael Foord (noreply@blogger.com) at April 13, 2010 12:15 PM
By now you’ve probably heard that we launched Visual Studio 2010 and .NET Framework 4.0 today!
Download Visual Studio 2010 (MSDN subscribers only)
Download Visual Studio 2010 SDK
The Visual Studio Industry Partner (VSIP) team has also posted a slew of videos showing off some of the great add-on products that bring additional functionality to the new IDE.
Enjoy, and do please let us know what you think via email, forums, blogs, Twitter, and Microsoft Connect!
We just released our updated version of MonoTools for Visual Studio:
A tool that helps Windows/.NET developers target Linux systems directly from Visual Studio, this release is still intended to be used with Visual Studio 2008 and includes some important improvements:
We are hard at work on our 2.0 release that will include soft-debugging support, MacOS support and will also run with Visual Studio 2010.
by Miguel de Icaza (miguel@gnome.org) at April 05, 2010 10:31 PM
This
year, Michael
Hutchinson is the administrator for
Mono's
involvement in
the Google Summer of
Code.
We are looking for motivated students that would like to either work on one of the ideas that we listed in our Student Projects page like work on MonoDevelop's IDE, Mono's runtime, Mono's class libraries and in Mono-based applications.
Additionally, if you are a student and you have been thinking "The Mono guys really should do...", do not hesitate and propose your idea. Perhaps you get to implement your idea, get paid to do so, and be mentored by our group of awesome C and C# hackers.
If you are a student, you can apply here and Google has a convenient list of frequently asked questions about the program.
Remember: There are only 3 days left.
by Miguel de Icaza (miguel@gnome.org) at April 05, 2010 10:20 PM
Create applications that are more responsive to user needs
IronPython should be an important part of your developer's toolbox and this book will quickly get you up and running with this powerful language. John Paul Mueller clearly shows how IronPython can help you create better desktop or web-based applications in less time and with fewer errors. Throughout the pages, you'll find techniques for extending IronPython and making it a more robust language. In addition, you'll follow advanced steps such as building an IronPython extension that directly accesses the Win32 API. And you'll enhance your skill set as you introduce IronPython into other environments such as Linux® and Mac OS® X.
by Michael Foord (noreply@blogger.com) at April 05, 2010 07:24 PM
From Steve Jobs 1997 presentation when he announced his partnership with Microsoft:
Where we are right now is, we are shepherding some of the greatest assets in the computer industry.If we want to move forward, seeing Apple helping an prospering again.
We have to let go of this notion that for Apple to win, Microsoft has to lose. We have to embrace the notion that for Apple to win, Apple has to do a really good job. And if others are going to help us, that's great. Because we need all the help we can get. And if we screw up and do not do a good job, it is not somebody else's fault, it is our fault.
So I think that is a very important discussion.
If we want Microsoft office on the Mac, we better treat the company that puts it out with a little bit of gratitude. We like their software.
So the era of setting this up as a competition between Apple and Microsoft is over as far as I am concerned. This is about getting Apple healthy and this is about Apple being able to make incredibly great contributions to the industry and get healthy and prosper again.
I feel exactly this way about open source. For open source to win, we do not need Microsoft, Apple or proprietary software to lose. The industry is not a zero-sum game, not only we enrich each other's platforms by exploring different ideas, but it is also incredibly healthy for the industry to have a blend of different approaches to computing.
Open source software leads in some areas in the industry and we as a community are very proud of its success. But when it comes to the areas where open source has not delivered a full solution like our proprietary competitors have, we resort to finger pointing and blaming others.
Some in the open source movement would like all the software in the industry to be open source/free software. Desktops, servers, games, embedded systems and everything that every human touches.
Although it is a noble goal, it has set people up for suffering by making the goal unachievable. It has been 15 years since the rise of the first large open source companies and by now we should know that our dream of a pure open source stack ruling the world is not going to happen any decade now.
Luckily, today, we have a much better understanding of where open source works and where it does not.
It would do us good to ponder Steve's 1997 message:
And if others are going to help us, that's great. Because we need all the help we can get. And if we screw up and do not do a good job, it is not somebody else's fault, it is our fault.
Once again, I want to recommend Ben Zander's The Art of Possibility book, a book with various recipes on how to look at the world through new eyes.
by Miguel de Icaza (miguel@gnome.org) at April 03, 2010 11:44 PM
by Michael Foord (noreply@blogger.com) at March 31, 2010 04:50 PM
Yay! The dlr-languages package has been migrated to testing, which means that it will be included in squeeze, the next release of Debian. Jo has uploaded the -2 version and it is now in sid. This version addresses the issues brought up in the Ubuntu Feature Freeze exception (FFe) bug, so I expect that it will be accepted shortly. Still lots of “ifs”, but this is pretty exciting for me, since this is my first debian package, and I’ve been intending to get it in for over two years.
I’m not just sitting on my hands while this happens. I’ve been working with Ivan, Ankit, Dino and Michael to get the next version of the package put together. I’m currently merging Ivan’s latest branch into the changes I’ve made for DFSG compliance. Dino recommended that the next release include IronRuby 1.0 and IronPython 2.6.1, which should be released by upstream around the middle of April.
Laura and myself will become parents sometime this summer. This will be our first baby.
A friend told me that "Most kids turn ok, despite of their parents" which I interpreted as a green light for raising our daughter with a touch of Dali-like surrealism.
Also, as much as I love the Summer conference circuit, I will be skipping on most travel from May to October and spend some quality time nesting.
by Miguel de Icaza (miguel@gnome.org) at March 23, 2010 03:17 AM
Sorry for the inconvenience folks. I was annoyed by having to mark so many comments as spam, but the plugin interface was so klugy that I had no idea how to find the users who would contribute useful posts. So. Feel free to comment… Nao!
We haven’t done much work on keeping the continuous integration (CI) machines online, and there haven’t been any new builds since November of ’09. I should set Nagios to remind us when things get off track or something. The recent acceptance of the DLR into Debian and our intention to get the next release produced has inspired me (and maybe others) to get things back up.
Ivan and I put a couple of Hudson instances up recently that you can reach via hudson-windows.colliertech.org and hudson-linux.colliertech.org. The linux instance is dropping new builds of IronRuby to http://dlrci.colliertech.org/ironruby/. I expect we can tweak the build script a bit and have it also produce IronPython builds. This would hypothetically drop the builds to http://dlrci.colliertech.org/ironpython/.
Ivan mentioned that we may get CNAME records which would activate the windows-builds.ironruby.net and linux-builds.ironruby.net hosts as well.
Note that these builds are being produced from the linux branch of git://github.com/casualjim/ironruby.git
Thanks for your work on this, Ivan!
You, the Python developer, use Python because you want to, but in the browser you use JavaScript because you think you have to. With IronPython you can write browser code in Python. I’ll only begin to answer "what can the browser bring to Python?" and "what can Python bring to the browser?" in this short overview; examples will be very simple (with the exception of a few flashy ones) to make sure you can get started immediately.
CPython 2.5/2.6/3.1, Jython, IronPython, PyPy, StacklessPython, UnladenSwallow, Cython ... what do we make of all these cool interpreter projects and versions? Where does competition help and where does it hamper?
In this interactive talk I'll highlight the main strengths of each of the Python interpreters. Furthermore, I'll discuss ways to leverage Python interpreters in a co-operative way, discuss challenges, projects and issues ahead and also briefly highlight 'execnet', one my own projects for bridging (Any) Python to (Any) Python.
This talk will cover basics about writing cross-interpreter python programs. What to do and most of all what not to do. This will help you if you want at some point in time to run program on for example Java platform or faster python interpreter, but also if you want to keep it running between CPython releases.
by Michael Foord (noreply@blogger.com) at March 21, 2010 04:08 PM
This guide will explain how to setup and attempt to run the Django test suite on IronPython. Once the test suite runs, it should be much easier to fill in the parts of Django that don't work properly.
by Michael Foord (noreply@blogger.com) at March 21, 2010 01:36 PM
Ivan put up a hudson server on our winders box. Ankit helped me figure out the IronRuby xbuild build problems. I should probably try it on IronPython, too. I sent the ironruby-core list a patch to fix some case sensitivity issues. Some time in the near future, I’m going to get together a bug report for the compiler and send it off to Marek. But I’m tired and Scarlet’s got a friend doing the sleep-over thing tonight.
So. Later ;)
P.S., can you believe that nobody registered a11y.com before now? Crazy talk.
P.P.S., does anyone out there in gnome land have a ruby app they want to test for compatibility with IronRuby?
by Angle Bracket Percent : ASP.NET at March 18, 2010 09:43 PM
We had a visitor on #ironruby today asking for help getting IR running on his mac. I gave him the following directions, and they seemed to work aside from one glitch. I tested them on my wife’s mac, and it worked for me, too.
You can grab the Mono .dmg from go-mono.com. This will install the framework and put the required programs (mono, xbuild) in your PATH.
Since Jim Deville likes macs, I’m sure more recent versions will work, but this is the one we’ve recently packaged up for Debian and tested on Ubuntu. If you want to be certain that the IronRuby code you write on Debian works on OS X, then you should probably build from the same version of the source. You should probably also install version 2.4.3 of Mono, but that may be more effort than it’s worth ;)
http://github.com/mletterle/ironruby/tarball/20090805+git.e6b28d27
Open up a terminal and unpack the thing you just downloaded:
$ mkdir ~/src/ $ cd ~/src/ $ tar xfz ~/Desktop/mletterle-ironruby-e6b28d2.tar.gz $ cd mletterle-ironruby-e6b28d2/
At this point, you should be able to build the IronRuby assemblies using xbuild. I don’t recommend using rake, as it has some dependencies, and I’m not a fan of dependencies.
$ xbuild /p:TreatWarningsAsErrors=false Merlin/Main/Languages/Ruby/Ruby.sln <snip/> Build succeeded. 2817 Warning(s) 0 Error(s) Time Elapsed 00:00:28.8378230
Our guest mentioned that he was using a terminal with a white background. Do note that the font color of the interactive interpreter (aka Read-Eval-Print Loop or REPL) is white, so if you’re using a white background, you might want to change it. IIRC, there is a way to change the font color using a configuration setting. Figuring it out is left as an exercise for the reader.
$ mono Merlin/Main/Bin/Debug/ir.exe IronRuby 0.9.0.0 on 2.6.3 (tarball Wed Mar 10 18:18:12 MST 2010) Copyright (c) Microsoft Corporation. All rights reserved. >>> 1+2 => 3 >>> exit()
The tarball you downloaded also included the source to IronPython. The procedure to build/run IronPython is pretty similar to IronRuby.
Unlike IronRuby’s .sln, this version of IronPython’s .sln does not have a default configuration parameter, so we need to specify it with the /p:Configuration=Debug argument.
$ xbuild /p:TreatWarningsAsErrors=false /p:Configuration=Debug Merlin/Main/Languages/IronPython/IronPython.sln <snip/> 69 Warning(s) 0 Error(s) Time Elapsed 00:00:38.8057450
IronPython has a REPL interface like IronRuby’s. Or is it the other way around? Anyway, here’s an example.
$ mono .//Merlin/Main/Bin/Debug/ipy.exe IronPython 2.6 Beta 2 DEBUG (2.6.0.20) on .NET 2.0.50727.1433 Type "help", "copyright", "credits" or "license" for more information. >>> 1+2 3 >>> ^D
ASP.NET for IronPython
Aaron Marten's WebLog
Akiramei IronPython Section
C. J. Adams-Collier
DLR Hosting and related stuff...
Dave Fugate (Testing IronPython)
Davy Mitchell: IronPython Category
Dino Viehland
Haibo Luo's Weblog
Harry Pierson
Hex Dump
Iron Curt
IronPython Cookbook (New Entries)
IronPython URLs
Jeff Hardy's Blog (NWSGI)
Jim Hugunin
Martin Maly: Dynamic Language Runtime
Miguel de Icaza
Mike Stall
Noah Gift
Official IronPython Blog
Ryan Dawson's Web Log
Seo and the FePy Project
Shri Borde's Weblog
Srivatsn's Blog
The Voidspace Techie Blog
tech-michael
Last updated:
September 02, 2010 02:32 PM
All times are UTC.
Powered by:
