unethical blogger - Mono

IronWatin; mind the gap

R. Tyler Croy — Tue, 13 Oct 2009 21:57:49 +0000

Last week @admc, despite being a big proponent of Windmill, needed to use WatiN for a change. WatiN has the distinct capability of being able to work with Internet Explorer's HTTPS support as well as frames, a requirement for the task at hand. As adorable as it was to watch @admc, a child of the dynamic language revolution, struggle with writing in C# with Visual Studio and the daunting "Windows development stack," the prospect of a language shift at Slide towards C# on Windows is almost laughable. Since Slide is a Python shop, IronPython became the obvious choice.

Out of an hour or so of "extreme programming" which mostly entailed Adam watching as I wrote IronPython in his Windows VM, IronWatin was born. IronWatin itself is a very simple test runner that hooks into Python's "unittest" for creating integration tests with WatiN in a familiar environment.

I intended IronWatin to be as easy as possible for "native Python" developers, by abstracting out updates to sys.path to include the Python standard lib (adds the standard locations for Python 2.5/2.6 on Windows) as well as adding WatiN.Core.dll via clr.AddReference() so developers can simply import IronWatin; import WatiN.Core and they're ready to start writing integration tests. When using IronWatin, you create test classes that subclass from IronWatin.BrowserTest which takes care of setting up a browser (WatiN.Core.IE/WatiN.Core.FireFox) instance to a specified URL, this leaves your runTest() method to actually execute the core of your test case.

Another "feature"/design choice with IronWatin, was to implement a main() method specifically for running the tests on a per-file basis (similar to unittest.main()). This main method allows for passing in an optparse.OptionParser instance to add arguments to the script such as "--server" which are passed into your test classes themselves and exposed as "self.server" (for example). Which leaves you with a fairly straight-forward framework with which to start writing tests for the browser itself:

#!/usr/bin/env ipy
 
# The import of IronWatin will add a reference to WatiN.Core.dll
# and update `sys.path` to include C:\Python25\Lib and C:\Python26\Lib
# so you can import from the Python standard library
import IronWatin
 
import WatiN.Core as Watin
import optparse
 
class OptionTest(IronWatin.BrowserTest):
    url = 'http://www.github.com'
 
    def runTest(self):
        # Run some Watin commands
        assert self.testval
 
if __name__ == '__main__':
    opts = optparse.OptionParser()
    opts.add_option('--testval', dest='testval', help='Specify a value')
    IronWatin.main(options=opts)

Thanks to IronPython, we can make use of our developers' and QA engineers' Python knowledge to get the up and running with writing integration tests using WatiN rapidly instead of trying to overcome the hump of teaching/training with a new language.

Deployment Notes: We're using IronPython 2.6rc1 and building WatiN from trunk in order to take advantage of some recent advances in their Firefox/frame support. We've not tested IronWatin, or WatiN at all for that matter, anywhere other than Windows XP.

Crazysnake; IronPython and Java, just monkeying around

R. Tyler Croy — Mon, 05 Oct 2009 06:00:59 +0000

This weekend I finally got around to downloading IronPython 2.6rc1 to test it against the upcoming builds of Mono 2.6 preview 1 (the version numbers matched, it felt right). Additionally in the land of Mono, I've been toying around with the IKVM project as of late, as a means of bringing some legacy Java code that I'm familiar with onto the CLR. As I poked in one xterm (urxvt actually) with IKVM and with IronPython in another, a lightbulb went off. What if I could mix different languages in the same runtime; wouldn't that just be cool as a cucumber? Turns out, it is.

After grabbing a recent release (0.40.0.1) of IKVM, I whipped up a simple Test.java file:

I compiled Test.java to Test.class then to Test.dll with ikvmc (note: this is using JDK 1.6); in short, Java was compiled to Java bytecode and then to CIL:

javac Test.java
mono ikvm-0.40.0.1/bin/ikvmc.exe -target:library -out:Test.dll Test.class

Once you have a DLL, it is fairly simple to import that into an IronPython script thanks to the clr module IronPython provides. It is important to note however, that IKVM generated DLLs will try to load other DLLs at runtime (IKVM.Runtime.dll for example) so these either need to be installed in the GAC or available in the directory your IronPython script is running in.

Here's my sample test IronPython file, using the unittest module to verify that the compiled Java code is doing what I expect it to:

When I run the IronPython script, everything "just works":

% mono IronPython-2.6/ipy.exe IkvmTest.py  
.
----------------------------------------------------------------------
Ran 1 test in 0.040s

OK
%

While my Test.java is a fairly tame example of what is going on here, the underlying lesson is an important one. Thanks to the Mono project's CLR and the advent of the DLR on top of that we are getting closer to where "language" and "runtime" are separated enough to not be interdependent (as it is with CPython), allowing me (or you) to compile or otherwise execute code written in multiple languages on a common (language) runtime.

That just feels good.

Toying around with ASP.NET MVC and NAnt

R. Tyler Croy — Mon, 24 Aug 2009 07:17:12 +0000

I recently found myself toying around with a number of web frameworks (like Seaside) to get a good read on who's doing what in the web world outside of Python and Django, when I stumbled across the ASP.NET MVC Add-in for MonoDevelop. Though the new Vim keybindings are sweet, I still can't effectively get work done in MonoDevelop yet. What MonoDevelop does do however is support generating Makefiles for any given project, which allowed me to create some Makefiles for an ASP.NET MVC project I had created in MonoDevelop, and port those Makefiles over to fit my NAnt and Vim-based workflow.

Along with building the necessary DLLs, I prefer to use my NAnt scripts to fire up the NUnit console and fire up a development instance of XSP to test my web applications out. All said and done this fairly basic script does the job; I typically run it with:

nant test run

Not much else to say, hope you find it useful.

Lazily loading attributes.

R. Tyler Croy — Mon, 15 Sep 2008 07:27:41 +0000

I found myself talking to Jason today about the virtues of getattr(), setattr(), and hasattr() in Python and "abusing" the dynamic nature of the language which reminded me of some lazy-loading code I wrote a while back. In February I found the need to have portions of the logic behind one of our web applications fetch data once per-request. The nature of the web applications we're building on top of the MySpace, Hi5 and Facebook platforms require some level of network data-access (traditionally via REST-like APIs). This breaks our data access model into the following tiers:

Working with network-centric data resources is difficult in any scenario (desktop, mobile, web) but the particularly difficult thing about network data access in the mod_python-driven request model is that it will be synchronous (mod_python doesn't support "asynchronous pages" like ASP.NET does). This means every REST call to Facebook, for example, is going to block execution of the request handler until the REST request to Facebook's API tier completes.

 def request_handler(self, *args, **kwargs):
    fb_uid = kwargs.get('fb_sig_user')
    print "Fetching the name for %s" % fb_uid
    print time.time()
    name = facebook.users.getInfo(uid=fb_uid) 
    ### WAIT-WAIT-WAIT-WAIT-WAIT
    print time.time()      
    ### Continue generating the page...

There is also a network hit (albeit minor) for accessing cached data or data stored in databases. The general idea is that we'll need to have some level of data resident in memory through-out a request that can differ widely from request-to-request.

Lazy loading in Python

To help avoid unnecessary database access or network access I wrote a bit of class-sugar to make this a bit easier and more fail-proof:

class LazyProgrammer(object):
    ''' 
        LazyProgrammer allows for lazily-loaded attributes on the subclasses 
        of this object. In order to enable lazily-loaded attributes define
        "_X_attr_init()" for the attribute "obj.X"
    '''
    def __getattr__(self, name):
        rc = object.__getattribute__(self, '_%s_attr_init')()
        setattr(self, name, rc) 
        return rc

This makes developing with network-centric web applications a bit easier, for example, if I have a "friends" lazily-loading attribute off the base "FacebookRequest" class, all developers writing code subclassing FacebookRequest can simply refer to self.friends and feel confident they aren't incurring unnecessary bandwidth hits, and the friends-list fetching code is located in once spot. If one-per-request starts to become too resource intensive as well, it'd be trivial to override the _friends_attr_init() method to hit a caching server instead of the REST servers first, without needing to change any code "downstream."

Lazy loading in C#

Since C# is not a dynamically-typed language like Python or JavaScript, you can't implement lazily-loaded attributes in the same fashion (calling something like setattr()) but you can "abuse" properties in a manner similar to the C# singleton pattern, to get the desired effect:

using System;
using System.Collections.Generic;
 
public class LazySharp
{
	#region "Lazy Members"
	private Dictionary<int, string> _names = null;
	#endregion
 
	#region "Lazy Properties"
	public Dictionary<int, string> Names
	{
		get {
			if (this._names == null)
				this._names = this.SomeExpensiveCall();
			return this._names;
		}
	}
	#endregion
}

Admittedly I don't find myself writing Facebook/MySpace/Hi5 applications these days on top of ASP.NET so I cannot say I actually use the class above in production, but conceptually it makes sense.

Lazy loading attributes I find useful in the more hodge-podge situations, where code and feature-sets have both grown organically over time, they're not for everybody but I figured I'd share anyways.

Resurgange of the shell.

R. Tyler Croy — Thu, 11 Sep 2008 07:57:36 +0000

Two things happened in such short proximity time-wise that I can't help but thing they're somehow related to the larger shift to interpreters. Earlier this week Miguel introduced csharp shell which forced me to dust off my shoddy Mono 1.9 build and rebuild Mono from Subversion just because this is too interesting to pass up on.

One of my favorite aspects of using IronPyhton, or Python for that matter is the interpreter which allows for prototyping that doesn't involve creating little test apps that I have to build to prove a point. For example, I can work through fetching a web page in the csharp shell really easily, instead of creating a silly little application, compiling, fixing errors, and recompiling:

tyler@pineapple:~/source/mono-project/mono> csharp
Mono C# Shell, type "help;" for help
 
Enter statements below.
csharp> using System;
csharp> Console.WriteLine("This changes everything.");
This changes everything.
csharp> String url = "http://tycho.usno.navy.mil/cgi-bin/timer.pl";
csharp> using System.Web;
csharp> using System.Net;
csharp> using System.IO;
csharp> using System.Text;
csharp> HttpWebRequest req = HttpWebRequest.Create(url);
<interactive>(1,17): error CS0266: Cannot implicitly convert type `System.Net.WebRequest' to `System.Net.HttpWebRequest'. An explicit conversion exists (are you missing a cast?)
csharp> HttpWebRequest req = HttpWebRequest.Create(url) as HttpWebRequest;
csharp> HttpWebResponse response = req.GetResponse() as HttpWebResponse;
csharp> StreamReader reader = new StreamReader(req.GetResponseStream() as Stream, Encoding.UTF8);
<interactive>(1,45): error CS1061: Type `System.Net.HttpWebRequest' does not contain a definition for `GetResponseStream' and no extension method `GetResponseStream' of type `System.Net.HttpWebRequest' could be found (are you missing a using directive or an assembly reference?)
csharp> StreamReader reader = new StreamReader(response.GetResponseStream() as Stream, Encoding.UTF8);
csharp> String result = reader.ReadToEnd();
csharp> Console.WriteLine(result);
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final"//EN>
<html>
<body>
<TITLE>What time is it?</TITLE>
<H2> US Naval Observatory Master Clock Time</H2> <H3>
<BR>Sep. 11, 07:29:02 UTC
<BR>Sep. 11, 03:29:02 AM EDT
<BR>Sep. 11, 02:29:02 AM CDT
<BR>Sep. 11, 01:29:02 AM MDT
<BR>Sep. 11, 12:29:02 AM PDT
<BR>Sep. 10, 11:29:02 PM AKDT
<BR>Sep. 10, 09:29:02 PM HAST
</H3><P><A HREF="http://tycho.usno.navy.mil">Time Service Department, US Naval Observatory</A>
 
</body></html>
csharp> reader.Close();
csharp> response.Close();
csharp>

I really think Miguel and Co. have adding something infinitely more useful in this Hackweek project than anything I've seen come out of recent hackweeks at Novell. The only feature request that I'd add along to the csharp shell would be "recording", i.e.:

tyler@pineapple:~/source/mono-project/mono> csharp
Mono C# Shell, type "help;" for help
 
Enter statements below.
csharp> Shell.record("public void Main(string[] args)");
recording...
csharp> using System;
csharp> Console.WriteLien("I prototyped this in csharp shell!");
<interactive>(1,10): error CS0117: `System.Console' does not contain a definition for `WriteLien'
/home/tyler/basket/lib/mono/2.0/mscorlib.dll (Location of the symbol related to previous error)
csharp> Console.WriteLine("I prototyped this in csharp shell!");
csharp> Shell.save_record("Hello.cs");
recording saved to "Hello.cs"

Which could conceptually generate the following file:

using System;
 
public class Hello
{
   public void Main(string[] args)
   {
     Console.WriteLine("I prototyped this in csharp shell!");
   }
}

JavaScript Shell

In addition to the C# shell, I've been playing with v8, the JavaScript engine that powers Google Chrome. The V8 engine is capable of being embedded easily, or running standalone, one of the examples they ship with is a JavaScript shell. I've created a little wrapper script to give me the ability to load jQuery into the V8 shell to prototype jQuery code without requiring a browser to be up and running:

tyler@pineapple:~/source/v8> ./shell
V8 version 0.3.0
> load("window-compat.js");
> load("jquery.js");
> $ = window.$
function (selector,context){return new jQuery.fn.init(selector,context);}
> x = [1, 5, 6, 12, 42];
1,5,6,12,42
> $.each(x, function(index) { print("x[" + index + "] = " + this); });
x[0] = 1
x[1] = 5
x[2] = 6
x[3] = 12
x[4] = 42
1,5,6,12,42
>

The contents of "window-compat.js" being:

/*
 * Providing stub "window" objects for jQuery
 */
 
if (typeof(window) == 'undefined') {
        window = new Object();
        document = window;
        self = window;
 
        navigator = new Object();
        navigator.userAgent = navigator.userAgent || 'Chrome v8 Shell';
 
        location = new Object();
        location.href = 'file:///dev/null';
        location.protocol = 'file:';
        location.host = ''; 
};

In general I don't really have anything insightful or especially interesting to add, but I wanted to put out my "+1" in support of both of these projects. Making any language or API more easily accessible through these shells/interpreters can really help developers double-check syntax, expected API behavior etc. Thanks Novell/Google, interpreters rock!

NAnt and ASP.NET on Mono

R. Tyler Croy — Sun, 04 May 2008 12:26:08 +0000

Most of my personal projects are built on top of ASP.NET, Mono and Lighttpd. One of the benefits of keeping them all running on the same stack (as opposed to mixing Python, Mono and PHP together) is that I don't need to maintain different infrastructure bits to keep them all up and running. Two key pieces that keep it easy to dive back into the the side-project whenever I have some (spurious) free time are my NAnt scripts and my push scripts.

NAnt
I use my NAnt script for a bit more than just building my web projects, more often than not I use it to build, deploy and test everything related to the site. My projects are typically laid out like:

bin/ Built DLLs, not in Subversion
configs/ Web.config files per-development machine
libraries/ External libraries, such as Memcached.Client.dll, etc.
schemas/ Files containing the SQL for rebuilding my database
site/ Fully built web project, including Web.config and .aspx files
sources/ Actual code, .aspx.cs and web folder (htdocs/ containing styles, javascript, etc)

Executing "nant run" will build the entire project and construct the full version of the web application in the site/ and finally fire up xsp2 on localhost for testing. The following NAnt file is what I've been carrying from project to project.

<?xml version="1.0"?>
<project name="MyProject" default="library" basedir=".">
  <property name="debug" value="true" overwrite="false" />
  <property name="project.name" value="MyProject"/>
  <property name="project.version" value="1.0.0"/>
  <property name="library" value="MyProject.dll"/>
  <tstamp property="build.date" pattern="yyyyMMdd" verbose="true" />
 
  <!-- These are being definde for posterity's sake, as they may change in the future -->
  <property name="bin_dir" value="bin"/>
  <property name="src_dir" value="sources"/>
  <property name="lib_dir" value="libraries"/>
  <property name="site_dir" value="site"/>
  <property name="deps_dir" value="deps/"/>
  <property name="contrib_dir" value="contrib/"/>
 
  <!-- xsp specific properties -->
  <property name="xsp_port" value="8088"/>
  <property name="xsp_root" value="${site_dir}"/>
  <property name="xsp_apps" value="/:../${bin_dir}"/>
  <!--//  End properties -->
 
  <target name="library" description="Basic MyProject build task" >
    <echo message="Building ${project.name}-${project.version}"/>    
    <csc target="library" output="${bin_dir}/${library}">
      <sources>
        <include name="${src_dir}/**.cs"/>
      </sources>
      <references>
        <include name="Npgsql.dll"/>
      </references>   
    </csc>  
  </target>
  <target name="clean" description="Clean up MyProject">
    <echo message="Cleaning ${project.name}"/>
    <delete>
      <fileset>
        <include name="${bin_dir}/**.dll"/>
        <include name="${site_dir}/**.dll"/>
        <include name="${site_dir}/**.aspx"/>
      </fileset>
    </delete>
  </target>
  <target name="site" description="Populate the site/ directory">
    <copy todir="${site_dir}">
      <fileset basedir="${src_dir}/htdocs">
        <include name="**"/>
      </fileset>
    </copy>
    <copy todir="${site_dir}/contrib">
      <fileset basedir="${contrib_dir}">
        <include name="**"/>
      </fileset>
    </copy>
    <copy todir="${bin_dir}">
      <fileset basedir="${lib_dir}">
        <include name="*"/>
      </fileset>
    </copy> 
      <!-- Copying bin/ into the site/ directory sucks, but xsp2 is buggy
        with the applications parameter
      -->
    <copy todir="${site_dir}">
      <fileset>
        <include name="bin/*.dll"/>
      </fileset>
    </copy> 
  </target>       
  <target name="run" description="Runs the xsp2 web server on the port cited above" depends="library, site">
    <echo message="Starting the xsp2 web server running on port ${xsp_port}"/>
    <exec program="xsp2" failonerror="true" commandline="--port ${xsp_port} --root ${xsp_root}"/>
  </target>
</project>

The Push Script
Since I usually build and deploy on the same machine, I use a simple script called "push.sh" to handle rsyncing data from the development part of my machine into the live directories.

#!/bin/bash
###############################
##      Push script variables
export NANT='/usr/bin/nant'
export STAGE=`hostname`
export SOURCE='site/'
export LIVE_TARGET='/serv/www/domains/myproject.com/htdocs/'
export BETA_TARGET='/serv/www/domains/beta.myproject.com/htdocs/'
export TARGET=$BETA_TARGET
###############################
 
###############################
##      Internal functions
function output {
        echo "===> $1"
}
function build { 
        ${NANT}|> && ${NANT}|> site
}
###############################
 
###############################
##      Build the site first
output "Building the site..."
build
if [ $? -ne 0 ]; then
        output "Looks like there was an error building! abort!"
        exit 1
fi
 
###############################
##      Start actual pushing
if [ "${1}" = 'live' ]; then 
        output " ** PUSHING THE LIVE SITE ***"
        export TARGET=$LIVE_TARGET
else
        output "Pushing the beta site"
fi
 
output "Using Web.config-${STAGE}"
output "Pushing to: ${TARGET}"
 
cp config/Web.config-${STAGE}|> site/Web.config
rsync --exclude *.swp --exclude .svn/ -av ${SOURCE}|> ${TARGET}|>

Depending on the complexity of the web application I might change the scripts up on a case-by-case basis, but for the most part I have about 5-6 projects out "in the ether" that are built and deployed with a derivative of the NAnt script and push.sh listed above. In general though, they provide a good starting point for the tedious bits of non-Visual Studio-based web development (especially if you're in an entirely Linux-based environment).

Hope you find them helpful :)

SXSWi and Me

R. Tyler Croy — Mon, 31 Dec 2007 13:11:08 +0000

I spoke with Tammy (our PR mastermind) about whether or not Slide was going to let me out of my cage to go to South by Southwest Interactive this coming March and it seems like they might actually let me! (I'm just as surprised as you are)

Unfortunately things with Facebook were at such a ridiculous pace when SXSWi was accepting panel submissions, that I never got a chance to submit my panel idea: "Slide is awesome, now let's talk about how great Slide is." This leaves me in a slightly awkward position, I cannot remember the last conference or event that I went to where I wasn't speaking or talking or dancing with a baboon in front of a live studio audience. Even at the last SXSWi I was there for about 36 hours and most of that time was spent setting up and then helping run BarCamp Austin². Ideally I'd like to get on stage with some of the guys from Twitter, Facebook, Bebo, Google and maybe even Myspace to discuss the more open social web that we seem to be moving towards and a bit about how awesome Slide is. It's probably nothing more than a pipe-dream however, since the panels seem to be quite locked down at the moment.

Of course, if nobody will have me, then I might be relegated to slumming up and down 6th street in Austin hanging out with the usual drunkards that I know in Austin (you know who you are) and getting into trouble. Mmm, trouble.

Regardless, if you're going to be in Austin for SXSWi let me know, I've got a stack of swanky new business cards I want to get rid of :)

Comparing IronPython and CPython

R. Tyler Croy — Wed, 19 Dec 2007 05:44:20 +0000

First a little background to help explain some of the terms, etc. "Python" is a language, similar to how "Java" is a language; unlike Java wherein the language is also relatively synonymous with the actual implementation of that language, Python has multiple implementations. If you've run python(1) from the command line, you're most likely running the CPython implementation of the Python language, in effect, Python implemented in C. Other implementations of Python exist, like Jython (implemented on top of the Java virtual machine), PyPy (Python implemented in Python), and IronPython (Python implemented on top of the .NET CLR).

I was talking with some of the guys from the #mono channel on GIMPNet about IronPython versus CPython as far as performance is concerned and I decided that I would refine my testing (using pybench) for more similar versions of the respective implementations, in as controlled of an environment as possible.

I ran pybench.py on a "quiet" (i.e. not-busy) machine sitting in a remote datacenter not too far from Novell, the machine is a Pentium III (i386) based machine running openSUSE 10.3. Since IronPython reports it's "implementation version" as Python 2.4.0, I decided to build and run CPython 2.4 against it. IronPython is running on top of the recently released Mono 1.2.6 which I also built from source (I got IronPython from the IPCE package in YaST however). pybench reported the various implementation details for both as such:

CPython

       Implementation: 2.4.4
       Executable:     /home/tyler/basket/bin/python
       Version:        2.4.4
       Compiler:       GCC 4.2.1 (SUSE Linux)
       Bits:           32bit
       Build:          Dec 18 2007 23:00:48 (#1)
       Unicode:        UCS2

IronPython

       Implementation: 2.4.0
       Executable:     /usr/lib/IPCE/ipy.exe
       Version:        2.4.0
       Compiler:       .NET 2.0.50727.42
       Bits:           32bit
       Build:           (#)
       Unicode:        UCS2

IronPython did alright, but it got pretty thrashed on a lot of the benchmarks. Unfortunately it's hard to tell whether it's Mono getting beaten up, or whether it's IronPython itself that's losing the battle here, running similar tests on the .NET 2.0 CLR would be beneficial but not something I am curious enough to boot a Windows virtual machine for. Regardless, here are the results, I've highlighed the rows where IronPython performs better than CPython.

Test	Minimum Run-time			Average Run-time
	CPython	IronPython	Diff	CPython	IronPython	Diff
BuiltinFunctionCalls:	448ms	357ms	+25.4%	450ms	405ms	+11.0%
BuiltinMethodLookup:	530ms	1329ms	-60.1%	536ms	1390ms	-61.4%
CompareFloats:	380ms	129ms	+194.3%	381ms	132ms	+187.7%
CompareFloatsIntegers:	377ms	93ms	+306.1%	378ms	97ms	+291.2%
CompareIntegers:	436ms	160ms	+172.5%	437ms	161ms	+170.6%
CompareInternedStrings:	425ms	443ms	-4.1%	426ms	445ms	-4.3%
CompareLongs:	360ms	292ms	+23.3%	361ms	293ms	+23.0%
CompareStrings:	423ms	330ms	+28.0%	423ms	337ms	+25.6%
CompareUnicode:	377ms	243ms	+54.7%	377ms	245ms	+54.2%
ConcatStrings:	726ms	9452ms	-92.3%	823ms	10071ms	-91.8%
ConcatUnicode:	711ms	5687ms	-87.5%	756ms	6039ms	-87.5%
CreateInstances:	508ms	761ms	-33.2%	518ms	815ms	-36.4%
CreateNewInstances:	451ms	3475ms	-87.0%	458ms	3581ms	-87.2%
CreateStringsWithConcat:	473ms	2650ms	-82.1%	475ms	2833ms	-83.2%
CreateUnicodeWithConcat:	482ms	1008ms	-52.1%	508ms	1092ms	-53.4%
DictCreation:	405ms	2944ms	-86.2%	407ms	3057ms	-86.7%
DictWithFloatKeys:	552ms	934ms	-40.9%	553ms	944ms	-41.5%
DictWithIntegerKeys:	423ms	1118ms	-62.2%	426ms	1137ms	-62.5%
DictWithStringKeys:	413ms	1186ms	-65.1%	414ms	1317ms	-68.6%
ForLoops:	412ms	189ms	+118.5%	413ms	217ms	+90.7%
IfThenElse:	372ms	128ms	+191.8%	374ms	141ms	+165.8%
ListSlicing:	311ms	4033ms	-92.3%	315ms	4230ms	-92.6%
NestedForLoops:	488ms	349ms	+39.7%	489ms	382ms	+28.1%
NormalClassAttribute:	430ms	1080ms	-60.2%	432ms	1104ms	-60.9%
NormalInstanceAttribute:	401ms	427ms	-6.1%	404ms	442ms	-8.7%
PythonFunctionCalls:	393ms	302ms	+30.1%	402ms	352ms	+14.3%
PythonMethodCalls:	478ms	643ms	-25.7%	536ms	673ms	-20.3%
Recursion:	547ms	158ms	+245.9%	659ms	159ms	+313.6%
SecondImport:	476ms	1383ms	-65.6%	481ms	1432ms	-66.4%
SecondPackageImport:	501ms	1425ms	-64.8%	503ms	1482ms	-66.1%
SecondSubmoduleImport:	589ms	1916ms	-69.3%	592ms	1990ms	-70.2%
SimpleComplexArithmetic:	475ms	729ms	-34.9%	476ms	758ms	-37.3%
SimpleDictManipulation:	424ms	1009ms	-58.0%	427ms	1020ms	-58.2%
SimpleFloatArithmetic:	416ms	455ms	-8.7%	422ms	480ms	-12.0%
SimpleIntFloatArithmetic:	345ms	161ms	+113.8%	346ms	162ms	+112.9%
SimpleIntegerArithmetic:	345ms	161ms	+114.7%	345ms	161ms	+113.9%
SimpleListManipulation:	346ms	497ms	-30.4%	350ms	501ms	-30.1%
SimpleLongArithmetic:	402ms	1120ms	-64.1%	403ms	1130ms	-64.3%
SmallLists:	417ms	1693ms	-75.4%	421ms	1717ms	-75.5%
SmallTuples:	450ms	3839ms	-88.3%	453ms	3915ms	-88.4%
SpecialClassAttribute:	431ms	1104ms	-60.9%	432ms	1133ms	-61.8%
SpecialInstanceAttribute:	608ms	423ms	+43.8%	610ms	437ms	+39.5%
StringMappings:	443ms	2255ms	-80.3%	448ms	2311ms	-80.6%
StringPredicates:	503ms	1058ms	-52.5%	504ms	1066ms	-52.7%
StringSlicing:	527ms	2880ms	-81.7%	562ms	3008ms	-81.3%
TryExcept:	418ms	21ms	+1905.2%	418ms	39ms	+985.6%
TryRaiseExcept:	587ms	6670ms	-91.2%	591ms	6733ms	-91.2%
TupleSlicing:	390ms	1817ms	-78.5%	397ms	1863ms	-78.7%
UnicodeMappings:	362ms	1323ms	-72.7%	365ms	1347ms	-72.9%
UnicodePredicates:	438ms	860ms	-49.0%	439ms	912ms	-51.8%
UnicodeProperties:	400ms	0ms	n/a	401ms	0ms	n/a
UnicodeSlicing:	624ms	2491ms	-75.0%	666ms	2638ms	-74.7%

The results are disappointing but not all that surprising, especially with regards to string manipulation. I attempted to run the same pybench.py tool on top of Jython but Jython doesn't appear to support the "platform" module, so I don't have a really good baseline for "managed/virtual machine-based Python implementations" right now. However, given the lack of evidence otherwise, I'll just go ahead and assume IronPython blew the doors off of Jython :). In general though this isn't the be-all end-all benchmark for IronPython, especially on Mono, but it does give a nice hint of where some improvements could be made both in the Mono runtime and IronPython. I'll have to run the benchmarks again with the newer versions of both implementations of Python to see where they're improving or degrading but by all means don't let this deter you from checking out IronPython! I'll be writing up a few code samples over the next couple weeks that I hope will be helpful to those "unenlightened" among us; dynamic languages on the CLR, what has the world come to.

Mono and FastCGI. An awkward relationship.

R. Tyler Croy — Sun, 16 Dec 2007 10:36:10 +0000

I've spent the week tweaking and adjusting my lighttpd configuration to where it cooperates better with Mono's FastCGI server, and I finally feel confident enough with the configuration to share.

Around thursday morning or so (maybe it was wednesday) the site was spewing so many 500 errors that somebody who I'm not sure I know where I know them from, emailed me saying "dude, site's broke." After checking the error logs, I found a lot of errors that were all like this:

fcgi-server re-enabled:  0 /tmp/fastcgi-mono-server
backend is overloaded; we'll disable it for 2 seconds and 
send the request to another backend instead: reconnects: 0 load: 130

fcgi-server re-enabled:  0 /tmp/fastcgi-mono-server
backend is overloaded; we'll disable it for 2 seconds and 
send the request to another backend instead: reconnects: 0 load: 130

After diagnosing the problem and kicking the server again, I decided that a couple of tips on the wiki page for Mono's FastCGI & Lighttpd had done me in, the first being about the FastCGI handler's max-procs configuration variable:

"max-procs" specifies the maximum number of servers to spawn. Because ASP.NET stores session specific objects, I am unsure of how applications would react if switching from one server to another, or if Lighttpd bonds a single server to a client. As such, I highly recommend keeping this value as "1" to avoid any conflicts.

Fortunately Urlenco.de doesn't really need any session information, so I did what Emeril and Apache admins are both familiar with doing, I kicked it up a notch (to about 10). After kicking the server one more time, this time with "max-procs" > 10 I watched the load on my little 1U server spike up to 30. While every terminal I had became so sluggish I could barely interact with the machine, I managed to open up "top(1)" and see what processses were royally screwing my machine. Turns out it was 10 instances of Mono, all trying to digest an ASP.NET site at once, all competing for the meager resources available. It seems that the Mono FastCGI server will process and compile your entire ASP.NET web application as soon as the FastCGI server is bootstrapped and accepting requests. Fortunately pushing new code to the site gets updated on the next HTTP request, so the number of times you'll have to kick (i.e. restart) the Lighttpd server should be minimal and you won't have to incur the huge performance penalty that often (I've since changed max-procs to 4).

I also went against some of the other advice on the wiki page

To overcome these problems, the recommended method for processing files is to send all requests directly to the FastCGI Mono Server.

By effectively passing every single request off to the Mono FastCGI Server you can avoid exposing some internal ASP.NET resources that should be interpreted and not sent over the wire, this seems to be poor practice as far as Lighttpd and FastCGI are concerned. Lighttpd is a very good, high performance HTTP server and should be allowed to do it's job, whereas FastCGI servers merely serve as a means for executing server-side pages, returning markup, etc. To avoid passing every single request off to the FastCGI server, I merely setup the FastCGI handler for .aspx pages and then mapped other ASP.NET extensions to that handler as was appropriate:

fastcgi.map-extensions = (
        ".asmx"   => ".aspx",
        ".ashx"   => ".aspx",
        ".asax"   => ".aspx",
        ".ascx"   => ".aspx",
        ".soap"   => ".aspx",
        ".rem"    => ".aspx",
        ".axd"    => ".aspx",
        ".cs"     => ".aspx",
        ".config" => ".aspx",
        ".dll"    => ".aspx"
)

The base configuration for one of my virtual hosts (Urlenco.de) turned out something like this:

$HTTP["host"] == "urlenco.de" {
 fastcgi.server = (
  ".aspx" => ((
   "socket" => "/tmp/fastcgi-mono-server",
   "bin-path" => "/usr/local/bin/fastcgi-mono-server2",
   "bin-environment" => (
    "MONO_FCGI_APPLICATIONS" => "/:/serv/www/domains/urlenco.de/htdocs",
    "MONO_FCGI_LOGLEVELS" => "Standard", #All", #Debug",
    "MONO_FCGI_LOGFILE" => "/var/log/lighttpd/mono.log",
   ),      
   "max-procs" => 4,
   "check-local" => "disable"
  ))      
 )               
}

Specifying the "application path" is somewhat of a pain, as now I more or less need a separate FastCGI configuration, which means they'll also need separate FastCGI servers, so another virtual host in the configuration (pineapple.monkeypox.org) has the following setup:

$HTTP["host"] == "pineapple.monkeypox.org" {
 fastcgi.server = ( 
  ".aspx" => ((
   "socket" => "/tmp/fastcgi-mono-server-pineapple",
   "bin-path" => "/usr/local/bin/fastcgi-mono-server2",
   "bin-environment" => (
    "MONO_FCGI_APPLICATIONS" => "/:/serv/www/domains/pineapple.monkeypox.org/htdocs",
    "MONO_FCGI_LOGLEVELS" => "Standard", #All", #Debug",
    "MONO_FCGI_LOGFILE" => "/var/log/lighttpd/mono.log",
   ),  
   "max-procs" => 1,
   "check-local" => "disable"
  ))  
 )   
}

Since the virtual host pineapple.monkeypox.org barely runs any ASP.NET code at all, I decided to only give it one Mono FastCGI process. Also of note is that the "socket" is different from the other FastCGI handler, if you try to use the same socket, the first Mono FastCGI process will take it over and both FastCGI handlers will return the same code, returned from the first handler.

Feel free to bug me with any questions, this is my first foray into using Lighttpd and I'm already pleased as punch with it (compared to Apache) but there are certainly some caveats and bits of black magic involved with Mono, FastCGI and Lighttpd. That said, it still feels less sticky than running Apache 2 and mod_mono (not that they're not great and all). Hopefully web traffic will increase and give me a good test-bed for figuring out "the right stuff" to scale Mono on Lighttpd.

Scary thought isn't it? :)

Urlenco.de: Mono, Lighttpd, and PostgreSQL.

R. Tyler Croy — Wed, 12 Dec 2007 10:45:39 +0000

During the nigh 12 hour break I had between regular work over Thanksgiving, I spent about four hours writing a little utility that I wanted to use instead of TinyURL, and found a fantastic domain name for it too: Urlenco.de. I also wanted to use the opportunity to explore using Npgsql, the .NET connector for PostgreSQL, which was a very pleasant experience after using the MySQL .NET connector (part of the pleasant experience was using PostgreSQL itself, of course). Another new thing to explore was the FastCGI support for Mono/ASP.NET, I'll be sure to jot down my experiences with Mono's FastCGI support in a later post since my brain is too fried to talk about it coherently in detail.

The most important part of the entire project was further refining my rapid-development process for Mono and ASP.NET so I can do quick little projects like this and push them to a live webserver in a matter of hours instead of days (of time I don't have). This mostly consists of boiler-plate project templates for some basic database code, page templates, and a NAnt build script that facilitates the building and testing of the site using xsp2 on localhost. Nothing spectacular, just having a toolkit of necessities to take from one project to the next, especially when time is at such a premium, is a minor but important difference from how I work now as opposed to how I used to work (when I had expendable time).

One of my favorite parts of the entire Urlenco.de project was setting up a Urlenco.de API for both encoding (tiny'ing) and decoding (untiny'ing) URLs to and from Urlenco.de, all in under 10 minutes after a suggestion from my friend Dennis at Palantir. After another suggestion, I also wrote a Urlenco.de stats page using the Google Charts API in about 10 minutes as well.

Hopefully this weekend I'll be able to write more about Mono and FastCGI (look ma! no apache!) and why it rocks, and why it sucks, etc. But for now I just wanted to point the service out, and hopefully get some more folks banging against it so I can evaluate whether Mono and FastCGI is ready for some larger projects I have coming down the pipe that I want to move away Apache 2.

Missed Spain :(

R. Tyler Croy — Sat, 01 Dec 2007 20:59:57 +0000

I hope everybody enjoyed their stay this past week in Madrid for the Mono Summit 2007.

Unfortunately, it's been too hectic a month to take the week off and go to Madrid, so I'm incredibly jealous of all of you. Grumble.

"Why are you awesome?" meet Mono

R. Tyler Croy — Thu, 15 Nov 2007 13:57:12 +0000

When I originally wrote the Facebook demo application "Why are you awesome?" I wrote it in PHP4 in about 3 hours and hated myself for every one of those miserable 180 minutes. Since then however, I've been slowly and methodically working on a new, JSON-based, Facebook client library (Mono.Facebook.Platform) specifically to bring together some of the aspects of pyfacebook, the PHP client, and the Facebook Toolkit that I like (implementation progress can be found in the NOTES). After getting some of the key Facebook calls implemented to support "Why are you awesome?" I figured I might as well give it a whirl and see if a "real" application would work on top of the library (it does).

Thus far, all that were needed as far as library calls were:

feed.publishActionOfUser
notifications.send
fql.query
profile.setFBML

A couple of the things I've found thus far in my work have been, that writing a library that you have to use forces you to think about what you add and what you remove a lot more and focus on simplicity and extensibility; secondly, JSON is much faster, meaning I can do things with the Mono.Facebook.Platform library that I couldn't with the XML-based PHP4/5 library. Operations like fetching the user IDs of all 700 friends of mine complete in a timely fashion under the JSON library, whereas they typically timeout with the XML-based libraries.

The Mono.Facebook.Platform library isn't even alpha, it's in negative greek letters right now, there's not enough of the API implemented, and it doesn't handle errors very well at all, so don't use it. When it's finished however, I intend to support over 90% of the Facebook calls, and offer it up as a faster, viable option, for ASP.NET developers on Windows and on Mono.

Of course if you want to check out "Why are you awesome?", head on over to the application page and install it.

Building Mono on Leopard

R. Tyler Croy — Tue, 06 Nov 2007 09:59:40 +0000

I figured I'd write up a guide to building Mono from Subversion in preparation of the upcoming 1.2.6 release, on a site I've neglected since I set it up, mononews.org (I hope to get back to writing tutorials and "newsy" stuff with the 1.2.6 release).

Anyways, if you've got Leopard installed, Geoff Norton did a great job in helping me track down the remaining Leopard/i386 bugs earlier today, so now you can build and run Mono relatively easily from Subversion on your fancy smancy new OS.

Building Mono on Leopard

Any Unemployed .NET Developers in NYC?

R. Tyler Croy — Sat, 20 Oct 2007 11:01:11 +0000

Last week at the Widget Summit speakers dinner I met an executive from DoubleClick, you know, that gigantic ad company that recently got acquired by Google, Inc. While talking about some of the difficulties in developing scalable web products I brought up some of my history in terms of developing .NET web applications and of course, Mono (at least I think that's how we got on the topic).

As it turns out, DoubleClick is really pushing to modernize their internal infrastructure on the .NET platform and really needs some smart folks either willing to move to New York City, or that already live there. If you're looking, feel free to contact me at [email protected] and I'll put you in touch, or hit up their careers page.

If you go to work at DoubleClick, I think you can technically get away with saying you work for Google. You'll also be able to say you are working on truly scalable .NET, which is something I really only think Windows Live and Myspace* developers can say currently.

Of course, if you're on the west-coast or lean more towards Python, Slide is always hiring.

* As it turns out, Myspace runs one of the largest .NET sites on the internet, and lays claim to the largest SQL Server installation on the entire planet.

Remix 07 Boston Wrap-up

R. Tyler Croy — Fri, 12 Oct 2007 08:51:28 +0000

Earlier this week, following CommunityNext and Graphing Social I was lucky enough to have been asked out to Boston for Remix 07 Boston. After receiving the necessary flack from my co-workers at Slide (primarily a Python/Linux shop), I boarded a plane late Sunday night to arrive extremely early on Monday morning (6a.m. isn't my best hour).

Upon arrival to the Hyatt Regency Cambridge, I found out that I had access to the Media Room, which allowed me to recharge my laptop and plug into a hard-wired connection such that I was able to write up a few blog posts from the conference itself. Having such access also allowed me to work on some sample Silverlight applications that I'll write up over the weekend covering Silverlight and IronPython.

While I enjoyed the sessions, such as Miguel's session on Moonlight and Mono and another session on the DLR and dynamic languages, what I enjoyed most was the ability to pick the brains of some of the folks there. Specifically guys like Aaron Brethorst, who works a lot on Microsoft Popfly's interface among other things, who let me question just about everything under the sun with regards to Popfly while still maintaining that I really like the application and its potential.

I also really enjoyed meeting up with Miguel and his crew at Novell (Aaron Bockover and Michael Hutchinson) after Miguel was kind enough to take me to a late lunch and then show me around Novell's Boston office. I also think Miguel successfully guilted me into contributing more code that I've been putting off for so long, like my Mono.Nat NAT-PMP code, Mono.Facebook.Platform, and some patches for System.Web.Script.Serialization; all of which I have neglected in the difficult search for a good night's rest, or the perfect ping-pong serve against co-workers.

I still look and feel mostly dead from exhaustion, but not dead enough not to continue pounding away on everybody's favorite Facebook app, or working on some of the other really cool things that we work on here at Slide (bubble text!). In the valley, everybody knows who Slide is now, everybody knows what's going on with Facebook, and an extremely small subset of people that matter know who I am; but on the east coast, far fewer understand what's going on right now on "that college social network, right?"

Miguel said he doesn't install Facebook applications citing the near-complete opacity of the security and data-storage policy to the end-user, but maybe now that he's met me, and knows who's behind it, he'll install Top Friends and I'll finally be able to claim that Miguel uses something that I wrote, instead of the usual case of vice versa.

Note to self: Travel back to Boston, soon.

Miguel de Icaza's Remix 07 Boston Keynote Address

R. Tyler Croy — Wed, 10 Oct 2007 04:19:57 +0000

Before I leave Boston, I had to make sure of one more thing, that my fellow Mono bretheren got to see what I got to see, Miguel's keynote. Thanks to lots of hard encoding and video preparation done by G. Andrew Duthie and his crew from Microsoft's Media Room at Remix 07 Boston, the videos from the keynote have already been posted in their entirety to Channel 9.

Unfortunately they didn't clip the videos on a per-speaker basis, so you'll probably want to fast-forward in the video to about the 11 minute marker to watch our fearless leader question the manhood of 400 Microsoft developers as I had previously mentioned. Talking with Miguel after the fact he mentioned that some of his more witty quips were mostly due to him worrying about things breaking on stage and going impromptu with some of the things he was talking about. Overall though I think Miguel did a great job exhibiting Moonlight and the Gnome desktop in general, so I hope you enjoy the video (again, fast-forward to the 11 minute marker).

Watch Miguel on stage at Remix 07 Boston (direct link)
(Download VLC to watch on Linux/Mac OS X)

Miguel questions the manhood of 400 Microsoft Developers. Awesome.

R. Tyler Croy — Mon, 08 Oct 2007 15:07:25 +0000

Miguel de Icaza, one of my own personal geek heroes, just gave his brief "keynote" as part of Microsoft's partner talks component of the overall Remix Boston 07 keynote speech.

After previous demos being proudly shown for "working in Safari on Mac OS X, and oh by the way, it's PC compatible too", Miguel showed everybody up by pulling up the still very development version of Moonlight and dazzled a room full of hardened .NET/ASP.NET developers and designers with Mono's progress on the Moonlight project in a scant 4 months since the original "Mix Vegas" conference earlier this year.

If you hang around Miguel enough, you'll know how much he loves Compiz, which he used gratuitously during his demonstrations. The mixture of a good looking Gnome skin and Compiz really helped convey that "yes, Linux is here, Gnome is a fully-featured desktop environment, and check out this AWESOME CUBE EFFECT!" As a developer who's participated in the open source community for almost five years now, it was very inspiring to see a room full of Microsoft's battle-tempered third party developers pine to have some of the cool features that Linux has!

Some of the Silverlight applications Miguel demonstrated were Metaliq's Top Banana which ran surprisingly well, then Silverlight Chess followed by the Halo 3 trailer running (not streaming) on Miguel's Linux laptop. To invite further jealousy from the room of developers, Miguel fired up Firefox, running Moonlight, running the Halo 3 Trailer, on the edge of a "cube" workspace (such as this). Applause ensued.

Coming back to the topic of developing Silverlight/Moonlight applications on top of Linux, Miguel fired up MonoDevelop claiming that "we have one, I just don't use it; I have an allergy to IDEs." Much to my surprise, he then fired up Emacs to edit his local copy of Silverlight Chess, updating a property such that it returned "Mono" instead of ".NET" in the interface, dropped back into his X terminal and ran "make" like, quote, "real men do" (to which some of the crowd applauded and the rest laughed). Miguel then ran the ~~Silverlight~~Moonlight Chess application and closed his keynote speech stating that:

"Your designers can use Expression Blend on Windows, but your real developers can use Linux to develop Silverlight."

Overall the keynote was very well done but it really seemed like Miguel stole the show after so much emphasis was placed on "Silverlight's portability" by really showing what the Mono Project is capable of, and that while Silverlight may work on Mac and Windows, Moonlight runs on the corner of a wicked cool cube.

In Boston, At Remix. Phew.

R. Tyler Croy — Mon, 08 Oct 2007 11:42:14 +0000

After a grueling flight that started with a full-on sprint from the TSA security checkpoint and ended about a quarter mile through the terminal (in socks no less), I have made it across the country to Boston for Remix 07 Boston.

I'm still anxiously awaiting the keynote, and trying to find the Mono guys that are in attendance to try to learn as much as possible about the development and future of Moonlight, while simultaneously trying to learn as much as possible about how other developers are embracing and using Silverlight too.

If you're at Remix, come find me, I'm a San Franciscan in a rainy Boston, and I'm scared ;)

I'm this idiot, rocking my "business attire"

Remix 07 Boston, Woohoo!

R. Tyler Croy — Wed, 03 Oct 2007 07:01:47 +0000

Turns out I'll be attending Remix 07 Boston next week but unfortunately my mega-cool-Silverlight hack won't be finished due to some scheduling complexities involved with working 130% of my time at a start-up in San Francisco (turns out, not too conducive to side-projects). I will be arriving bright and early at 6:30a.m. pounding down a gigantic (and expensive) airport coffee, and then heading to the Hyatt Regency Cambridge, so I apologize in advance if I look exceedingly tired Monday morning.

It'll be a great opportunity to get a feel for where Microsoft thinks that Silverlight is going, and how they intend to get there. It's a long hard road to even become near where Flash is in terms of market entrenchment, but Microsoft is one of three companies I believe currently capable of acheiving it (the other two being Adobe itself [bought Macromedia, they cheated], and Apple).

I would also like to give those Popfly guys an earful but I may spare them depending on how busy I am trying to find some fellow Facebook developers that live in the Boston area, or Miguel, who I'm pretty sure doesn't exist, but is merely a robotic creation of some wacky laboratory in Mexico.

If you'd like to meetup and have lunch, or a beer in the evening Monday or Tuesday, feel free to send me at email ([email protected]) or track me down during the actual conference (i'm this guy).

Special thanks to Anand for what us young-folk call "the hook-ups" and I look forward to seeing both of my blog readers in Boston next week ;)

Popfly. How to lose the buzz.

R. Tyler Croy — Thu, 27 Sep 2007 10:43:54 +0000

I remember watching a Channel 9 interview about Popfly with my coworker and former landlord David Young just after the original Facebook F8 Platform Launch back in May, laughing hysterically at a user-interface that used grass as an interface element, but at the same time thinking it was a very cool use of Silverlight as an application platform, instead of a Microsoft reply to Flash. Since that fateful day in May when a Microsoft Vice President of Business Development unveiled Popfly (exactly who should be unveiling a developer tool), I've heard close to absolutely nothing about Popfly, but loads about Silverlight.

Waiting to build a new version of Mono from trunk, I figured I'd check it out again, hoping their ludicrous "private beta" period would have passed, and I could finally use the technology that was unveiled almost 5 whole months ago. Alas, despite having the Silverlight plugin for Safari, popfly.com doesn't support Safari (I thought people wrote cross-platform web pages these days). Admitting my defeat, I popped open my VMWare instance of Windows XP, and Internet Exploder 7, only to discover that yes, Popfly is still invite-only or they're having server difficulties? Despite their about page jokingly referring to themselves as the developers behind products like Microsoft Bob, I'm starting to wonder if they weren't joking, as Popfly's introduction at F8 was either woefully premature or Microsoft decided that a developer environment where you draw lasers in-between boxes that represent stuff is too silly.

All my criticisms aside, the product does look interesting enough for me to be excited about the Popfly session at ReMix Boston '07 in October, if for no other reason than to ask for an invite, and maybe even wtf?

Given the insane amount of buzz around the Facebook Platform, and independent developers struggling to get cool applications into users' hands fast enough, Microsoft screwed up royally on a chance to sow the seeds of the next generation of developers on the web with Microsoft technologies.

Dear 800lb Gorilla,
When you announce something at a tech event that could possibly turn out to be industry changing like the Facebook Platform Launch, actually have the product ready for people to start using, otherwise, why bother?

Contemplating ReMIX 07 in Boston

R. Tyler Croy — Sun, 23 Sep 2007 11:34:12 +0000

While catching up on about 2 weeks of Mono Subversion commit emails (about 1000), building Mono, and writing a new Facebook REST client library, I came across ReMIX 07 in Boston, which certainly looks interesting. I haven't been to Boston yet, and it'd be nice to at the very least, to try to buy Miguel and some of the Boston-based Mono team a beer, maybe to make up for some of my anger that sometimes blurts out into the IRC channel:

05:48 <rtyler> god [expletive-deleted] damnit, I'm going to beat somebody up(Which, in all fairness, usually stems from some idiot mistake on my part)

The sessions on Silverlight by Adam Kinney, who I did this interview with, are definitely looking enticing, as I'm still trying to figure out if it's worth my time and effort, or if Microsoft is going to screw developers again (ActiveX for Mac OS anybody?).

Most of the sessions seem to be targeting web developers, which is a role I find myself increasingly definable by, despite my role being clearly stated on my business card:

Regardless, seeing what developers are doing off in la-la-Microsoft land should be interesting as most of my web development work is either in Python or ASP.NET(Mono).

I am a little disappointed in the lack of sessions on IronPython and where that project is heading; it probably lost out to mega-mind-boggling sessions like "Stop Building PowerPoint Backgrounds & Start Selling High-end Presentations", which means I would have to settle on "Just Glue It! Ruby and the DLR in Silverlight" for my DLR fix.

That said, will it be worth a trip across country and a couple of hundred dollars out of pocket? Any couches available in the Boston are? And of course, are Microsoft conferences that awesome?

Channel9 Silverlight Interview

R. Tyler Croy — Wed, 19 Sep 2007 12:28:23 +0000

At the closing of SilverlightDevCampSF Microsoft Evangelist Adam Kinney did a brief video interview with me about my silly Silverlight hack. I had just started with Silverlight the night before, and didn't even have Moonlight virtual machine up yet, but I did have a Windows XP vm kicking around.

After the, roughly, three hours it took me to get Visual Studio 2008 (Orcas), Expression Blend, and a couple of other tidbits installed on my vm, I finally got to my Silverlight hack. Starting with something I presumed would be exceedingly simply, I created our "collage" transition in Silverlight (you can find a "sample" here).

The hack is relatively simple, a new randomly generated storyboard and canvas are created for each image, then added to the root element; after 15 images have been added the canvas is cleared and repeats. I used Silverlight 1.0, since that's all that is released right now, so everything is in Javascript (argh!), but I intend on revisiting the hack once Silverlight 1.1 is a bit more stable (and rewrite it in IronPython!).

Anyways, here's the interview.

SIlverSurfer, Try out Silverlight on Mac OS X

R. Tyler Croy — Sun, 16 Sep 2007 05:25:48 +0000

At the SilverlightDevCampSF this past couple days, I discovered a couple things while hacking around with both Moonlight, and Silverlight.

The first of which was that I don't know nearly enough about Silverlight, XAML, and WPF in general (crap). The second of which, was that with WebKit on Mac OS X, any application that embeds WebViews inherits plugins that are installed on the system. Extending this idea further, WebKit can inherit plugins that are bundled with a Cocoa application (inside Application.app/Contents/PlugIns), woohoo! What this means, outside of a purely Silverlight-related context, is that you could theoretically bundle a WebKit-plugin with a WebKit-based application and just have that plugin purely application specific, or bundle up a WebKit application with different versions of Flash and Silverlight for testing purposes. Unfortunately, there are some issues with clicking through to the Silverlight canvas in an embedded WebKit view, you can still try it out inside an application, without having to install the Silverlight plugin and restart your instance of Safari.

That said, are you thinking what I'm thinking? Of course not, you're probably sane, but I'm not, so I'd like to introduce SilverSurfer 1.0, an embedded version of WebKit that loads in the Silverlight 1.0 plugin for Mac OS X. It doesn't install anything on your computer, so you don't have to restart Safari, or futz with plug-ins, this is especially useful if you just want to try Silverlight out and see what it's about without installing anything.

Running SilverSurfer

Visiting a Silverlight page in Safari

Visiting the same page in SilverSurfer

Complex Silverlight in SilverSurfer

I think it's a neat trick, the only downside is actually having to bundle up the entire Silverlight.plugin bundle with the application bundle to make sure you don't have to install it, but other than that I hope you can find it useful when trying out Silverlight, or just testing it in Safari!

C'mon down to SilverlightDevCampSF

R. Tyler Croy — Fri, 14 Sep 2007 21:29:20 +0000

A bit late to bring up, but later today and tomorrow here in San Francisco, "we" (using that term loosely) will be holding SilverlightDevCampSF, one of the first BarCamp-styled events that I'll have ever attended where I've not played a part in it's organization.

In case you're unfamiliar with BarCamp events, they're loosely organized meetups/conferences to which geeks flock to normally for the booze included, but sometimes for the technical aspects as well.

I'm showing up particularly for Kevin Marshall's session on "Silverlight Facebook Apps" for obvious reasons, as well as to try my best to enlighten my fellow developers on the joys of Mono and Moonlight (that last part might not work out, time permitting). Overall it should be fun, and I hope if you're in the bay area you can make it down to 1 Market St! (map)

In case you're showing up, here's what I look like:

I'm with stupid ^

IronPython for MacPorts

R. Tyler Croy — Mon, 06 Aug 2007 09:06:12 +0000

What goes better with Sunday evening boredom better than some Tcl scripting and package management? I know! Nearly nothing, my sentiments exactly. After stumbling across a guide or two, I decided I should give creating an IronPython MacPort a try.

I'm not sure on the utility of this minor hack, since the Mono Framework installer includes IronPython 1.1a1. I decided to give it a whirl nonetheless and came up with a pretty simple IronPython Portfile, although there is one thing missing, the IronMath and IronPython DLLs are not properly installed in the GAC. I'm a bit hazy on whether I should be installing the DLLs using gacutil(1) or whether I should just copy things over to the $(PREFIX)/lib/mono/gac and be done with it.. Therefore the crux of my "work" was just creating a sane Makefile, since the IronPython makefile that's distributed on CodePlex uses "csc" and has some pretty nasty syntax.

You can check out my Portfile and copy of IronPython 1.1 from anonymous subversion by:

Clicking over here
or
Checking out the code with:
svn co svn://svn.geekisp.com/bleep/trunk/IronPython

I'm debating whether or not I should submit the port to MacPorts for inclusion in their next release, mostly because I'm not completely sure if the Mono port includes IronPython or not. If you've got the Mono port installed, feel free to let me know if it installed IronPython, or if you feel like offering up a Makefile.mono patch that properly installs the assemblies into the GAC. I'm a bit new to packaging up open source projects for Mac OS X properly, so any tips would be helpful.

Hacking with IronPython

R. Tyler Croy — Mon, 30 Jul 2007 13:24:08 +0000

I've been wanting to play with IronPython for a very long time, but never really got around to it since most of my days are either consumed with Python or Mono to some capacity, but never both.

Despite my initial instinct to flee in terror after looking over some of the IronPython examples I found on various blogs, I decided it would at the very least be worth an install just to check out the interpreter, and to see how well it performs on top of Mono.

ccnet% ipy
IronPython 1.0.2467 on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
>>>

Scary! But familiar, so I forged ahead undaunted, wanting to start hashing some strings, I figured I'd import the md5 module and get to work.

ccnet% ipy
IronPython 1.0.2467 on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import md5
Traceback (most recent call last):
  File md5, line unknown, in Initialize
  File hashlib, line unknown, in Initialize
  File hashlib, line unknown, in __get_builtin_constructor
ImportError: No module named _md5
>>>

Alright, so there are still some holes in the IronPython bridge into Python, but this is fine by me, I can call into .NET code! One other thing that seemed to be missing was the 'select' built-in module, which in turn made my little 'telnetlib' based project fall on it's head.

I run an icecast2 server on my workstation, so I can just tune in with my MacBook Pro, and get whatever stream is being served up by the server. The source for the icecast2 server is a script using Liquidsoap which allows for shuffling, bumps, and a couple of other things to make my music-listening experience better. One of the nice things about Liquidsoap is that it has a telnet interface, so I can glean meta-data about what's playing, or control the playlist through the telnet interface. With this telnet interface in tow, I set out to hack up a Windows Forms and IronPython-based controller for already scripted radio station. And thus, my little IronRadio Controller was born:

Unfortunately, I couldn't use Python's native "telnetlib" so I rolled my own IronTelnet class that would permit basic reads and writes to the telnet server, but other than that, the IronRadio Controller is mostly WIndows Forms code and some events cobbled together. The interface is unfortunately poor, as I don't have an Interface Builder for WIndows Forms, let alone IronPython-based Forms (not to mention I could care less about spit-and-polish for anything in X11.app).

The source for the script can be found here, and will require IronPython and Mono to run (or .NET if you're on a Windows machine).

I'm still trying to figure out if I can use IronPython with mod_mono to replace fighting with mod_python, but there are no guarantees as to whether that will work or be worth the trouble.

IronRu..OOH SHINEY!

R. Tyler Croy — Mon, 23 Jul 2007 15:20:42 +0000

While debating which set of bugs to squash next, I popped open Vienna and started catching up on monologue and came across Jb Evains' post regarding IronRuby which John Lam from Microsoft posted as just being "released" (pre-mega-alpha).

While I don't use Ruby, or even IronPython on a day to day basis, I have done a lot of work in Cocoa (Objective-C) and to a greater extent, Python. Watching hackers get dynamic languages up and running on top of the CLR is almost like watching Neil Armstrong walk on the moon, you were hoping that it could be done, but up until you actually saw it, you weren't really sure if it could actually be acheived.

Unfortunately, I don't care for Ruby's syntax in comparision to Python's, but that still doesn't mean I can't get excited about dynamic languages on top of the CLR, wahoo!

New Email, etc

R. Tyler Croy — Sun, 22 Jul 2007 06:52:19 +0000

Digging through my repository of domain names i rent, I finally found one I felt like using for some of my open source hacking; specifically my dealings with Mono, OpenMoko and Mac OS Forge. I finally setup monkeypox.org for both email, general web servitude, and moved most (if not all) of my related mailing list subscriptions over to tyler(at)monkeypox.org.

You can find me at that mailing address for all things Mono, and most things non-work related. I'm fine with giving out a few email address @monkeypox.org to some of my Mono compadres, provided they're super-cool and pass a 42km long obstacle course.

Mono, meet Facebook

R. Tyler Croy — Wed, 04 Jul 2007 17:48:15 +0000

Recently I've been developing Facebook applications on behalf of Slide (my employer) using our killer internal frameworks. While this has resulted in an extremely fast turn around from the whiteboard to release and 8 of the most used applications on Facebook with well over 15 million users, it's all in Python, about 100 miles and a "tabs vs. spaces" flamewar away from what I "used" to do, Mono.

Believe it or not, Mono has full ASP.NET 1.1, and a near-complete ASP.NET 2.0 class compatibility (check it out!). Not only that, there's two different ways of hosting a Mono/ASP.NET application, via xsp2 (for development) or with Apache 2 and mod_mono (for production). The only logical progression for a hacker such as myself, was to write a Mono-based Facebook application, and thus Weather# was born.

Development
Fortunately the pervasiveness of Facebook client libraries is approaching the commonality of Twitter client libraries, mostly because it's a simple REST API, and it's cool. Since somebody already wrote the code, and weaseled it into the Mono Subversion repository (facebook-sharp) I decided to use it instead of rolling my mini API. The code was a bit old, and obtuse to deal with, so I simply incorporated all of the classes into my project, building everything into my web application. Using one of the many SOAP webservices available on xmethods.net, I used the wsdl.exe app to generate my SOAP client stubs (which are always subclasses of System.Web.Services.Protocols.SoapHttpClientProtocol), which left me with only about 150 lines of interface and basic glue code to bring these components together such that on page load:

The user location information is fetched from Facebook
A SOAP request to the weather web service is made per zip code or city
The return data is parsed and fed into the page for display

The entire project was built in MonoDevelop which has pre-built ASP.NET templates which include customizable build, run and deploy settings for the MonoDevelop build system. When you click "Run" from inside MonoDevelop IDE, it will rebuld the solution, launch your project inside of xsp2 and then open up a new tab in Firefox to the web application. Building/Testing/Deploying is definitely the easiest part of the road to ASP.NET on Mono.

While the ASP.NET Visual Designer is not yet ready for prime time, it's only a minor set back in that you can't drag and drop your web interface together a la Visual Studio .NET, but you have to revert to how most of the web builds their interfaces, with templates and by hand. Given the sheer simplicity of the Weather# interface, this wasn't a major hurdle to overcome.

Deployment
The only true problem with this near-perfect development setup is the actual public deployment, there are only a few hosts that provide mod_mono hosting as of yet. One of the most beneficial features of Mono however, is the full binary compatiblility with .NET, meaning you can develop your entire web application using the free and open source Mono tools, and then deploy your web application to an IIS ASP.NET server (which are very common in the hosting biz). If you have a colocated server, or a virtual private server, it's trivial to setup mod_mono on your Apache 2 web server with most of the mainstream Linux OSes and *bSD's. With ubuntu, in my case, there's only a few packages to install via Synaptic and then move the configuration over in the /etc/apache2/mods-enabled directory and make sure your configuration is correct. That said, if you're the proud owner of a colocated server it should be trivial to configure everything properly.

Facebook Integration
Facebook includes a couple key parameters in their calls into your page to present the user your application, such as the fb_sig_user and fb_sig_session_key, both of which you can pass into any Facebook client library to start to have your application querying the Facebook Platform. Weather# only makes this call once to users.getInfo to fetch the location information it needs. You can query for a lot more information if necessary, but for the purposes of this example, fetching the location was as basic as was necessary. The most complex part is setting up your Facebook applications settings in "My Applications", the Weather# information can be found here (opens in a new window). The most important information is in the screenshot, but if you'll note the callback URL settings. They are set to "iframe" for development purposes (and my desire not to open another port in the firewall to my workstation) and are hitting localhost port 8081, which is the local port I configured my MonoDevelop-deployment xsp2 settings to use. If you switch it over to FBML, you will either have to serve up FBML to the canvas page, or an <fb:iframe/>, but both require Facebook being able to contact your callback URL for proxying purposes.

<fb:conclusion/>
Developing with ASP.NET on Mono is essentially no different than developing with ASP.NET on the stock Microsoft .NET assemblies with the key difference being...no Microsoft .NET assemblies, and no IIS. Meaning, that if you're comfortable with C# or Visual Basic, you can very quickly, and very cheaply develop ASP.NET-based web applications (or web services) and serve them from within your existing LAMP infrastructure. In my opinion, this is one of the best options out right now for current web development, right behind Python; the absolute power of the .NET class libraries is unparalleled, from web controls, to web services, to ADO.NET for data storage, the tools available to the overworked and underpaid developer are worth looking into if you're not already "in the know." mod_mono and xsp2 both run on Mac OS X, Linux, and FreeBSD, and are in the package systems across those platforms (MacPorts, APT, or Ports). MonoDevelop works on Linux and FreeBSD, you can get it working on Mac OS X but it's about as painful as a brazilian bikini wax (erm..so I'm told).

Resources

Weather# screenshot
Source: svn co svn://svn.geekisp.com/bleep/trunk/WeatherSharp
Facebook Developers Site
mod_mono

Twitterbot Recap

R. Tyler Croy — Tue, 01 May 2007 23:28:56 +0000

While trudging through some comment spam, I came across some older comments that I felt needed recapping in this post about my Twitterbot. An anonymous poster had asked about some issues with Mono on Mac OS X returning 401 Unauthorized errors when using HTTP authentication within the Twitterbot. The issue was fixed relatively quickly after I brought it to the attention of some of the Mono developers, and the fix will be included in Mono 1.2.4 (preview available).

There shouldn't be any more issues with regards to running the Twitterbot on any platform supported by Mono now. In the future I would also like to add better history and duplicate checking by using either a flat-file datasource or one that feeds on a database, but the latter would probably make the program far more complex and difficult to use. Ideas, as usual, are always welcome.