Last month I introduced code completion in
Mono's Interactive
C# shell. You can use the TAB key to auto-complete at the
current cursor position. Pressing the TAB key twice will list
all possible completions.

This should make the csharp more pleasurable
to use and for bash junkies like me a more natural fit.

This comes in quite handy for completing namespaces, types
and valid methods. It works with the C# 3.0 initializer
syntax as well, that one is useful in Silverlight for those of
us that can not stand to type XAML instead of C#:

csharp> new TextBlock () { Bac[tab]

Does the nice:

csharp> new TextBlock () { Background

Bonus points: another tab at that point inserts the equal
sign to assign the value.

This will provide possible completions (methods,
properties, fields) that are valid at that point in the
string.

A discussion that details the implementation of how the
compiler supports code completion is in
the mailing
list and
our compiler
documentation has been updated to include a tutorial on
expanding code completion.

A few good news: the entire stack (Gtk+, Cairo and Gtk#)
comes in a nice 8 meg download, it is packaged as an MSI and
it is now signed by Novell's certificate, so you no longer get
a scary "Unknown Publisher" dingus on the screen.

This is the equivalent of the greek god Prometheus giving
fire to humans.

We are giving Windows developers a nice cross-platform
toolkit that is nicely integrated into Visual Studio. To try
a sample application using it, you can
download Tomboy,
load the Tomboy.sln solution, hit F5 and enjoy.

As a follow up
to yesterday's
post I did the "hard work" of cut-and-pasting the VTE
pseudo-terminal support+gnome-pty-helper into an independent
module and wrote a managed binding for the code,
autoconf-ified it and put it on SVN.

This library was developed used internally at Microsoft
some years ago to support some internal projects. This
provides a set of services similar to our
own Cecil
library. Despite this, it is nice to see Microsoft open
source more code.

Cecil, in addition to the low-level APIs for reading and
writing ECMA CIL files has a few niceties layered on top of it
like a Flowanalysis engine (it is used to decompile byte codes
into ASTs) and a full fledged decompiler.

Additionally, Marek is currently replacing the backend in
our C# compiler to move away
from System.Reflection.Emit into using Cecil so
that we can bring our C# REPL to Windows developers.

Mono's C# REPL currently works in a very limited mode in
.NET (no generics, no LINQ) because
.NET's System.Reflection has several limitations
for building full-fleged compilers. To work around this issue
Mono has over the years extended the Reflection stack to
provide the features that were missing. We were never quite
happy with this and we are now dropping it in exchange for
Cecil.

There was a discussion about how to host REPLs in
applications like MonoDevelop recently and some of the
discussion was centered around how to host something like a
shell into a program like MD.

Since I have been thinking about building a
Silverlight-based version of the Midnight Commander (OH NOES!)
I figured I should share some thoughts that I had on this
matter.

Widgets like ZVT and VTE today bundle a number of things in
a single widget:

A Unix Pseudo terminal with login/logout support (Unix
flavor-specific).

A terminal emulator that turns escape sequences generated
by a stream into rendering commands.

A binding to the Gtk+ toolkit to send input events to the
child process and render the terminal results.

I would like to see some nice C# libraries for doing each
one of those tasks independently of each other. Think of it
as the MVC of terminal widgets. Like this:

Reusable Blocks for Terminal Emulation.

Pseudo-terminal support: the functionality to create
pseudo terminals is very OS-specific, it is hard to get right
and getting the more advanced features like registering your
session is even harder. Very few applications get this right
(mc, zvt and vte all use the same code that took me years to
fine tune but has never been made reusable for other
applications).

This can be used beyond terminal emulators, it can be used
to script or control programs expect a real terminal to run.
These are typically interactive Unix console applications.

Those applications either break or refuse to run when their
standard input or standard output are
redirected. Expect is a
system built on top of this functionality

Terminal Emulation: A terminal emulator class that
supports the vt100/xterm command set and render it into some
internal buffer; can take high-level keystrokes and encode
them as byte streams (for example turning Alt-X into ESC-x)
and supports terminal resizing.

This terminal emulator should not be bound to Gtk+ it
should merely render into a text buffer.

Gtk#, Silverlight and Curses Bindings: Once the
underlying terminal emulator exists we will need to write a
handful of bindings to the terminal emulator.

The Gtk# is an obvious choice for embedding terminal
emulators inside things like MonoDevelop.

The Silverlight binding would allow people to create full
fledged SSH clients on the web.

The curses binding could be used to implement an
application
like GNU
Screen or it could be used in an application like the
Midnight Commander (the Midnight Commander plays some Unix
tricks to avoid having to emulate a terminal, and this has
been a small weakness).

Sandy was just saying a few weeks ago that porting Tomboy
to Windows brought new developers to the project. Although
some people have historically been against the idea of making
Linux software available on other platforms, it is nice to see
day-to-day validation that by expanding the scope of our open
source software to other platforms it directly improves the
software in our own platform (as many predicted).

A good friend of mine that has extensive experience with C#
and has written significant portions of
the Banshee media
player, has contributed to our C# 3.0 and C# 4.0 support
and to our runtime is looking for a programming job.

If you want to hire him, drop me an email and I will get
you in touch with him.

Update: I accidentally published an incomplete
version of this blog entry the other day before the actual
content and samples were ready.

As part of our ongoing Embrace and Extend.NET series
(SIMD,
supercomputing),
today I wanted to talk about the Mono.Tasklets library that
has just landed on Mono's repository.

This library will become part of the Mono 2.6 release.

Mono.Tasklets is the Mono-team supported mechanism for
doing continuations, microthreading and coroutines in the ISO
CLI. It is based on Tomi
Valkeinen's excellent work on co-routines for Mono.

Unlike the work that we typically do in Mono which is pure
C# and will work out of the box in .NET (even our Mono.SIMD
code will work on .NET, it will just run a lot slower)
Mono.Tasklets requires changes to the VM that are not portable
to other ISO CLI implementations.

The WaitFor function would yield back to unmanaged code. The
unmanaged code would then simply go on, possibly calling other
C# methods in the same class/instance. After 20 seconds, the
engine would resume the Update method.

The idea here is to have multiple execution paths running
on a single thread using a sort of cooperative multitasking.
GUI programmers are already used to this sort of work by using
callbacks: event callbacks, timer callbacks and idle
callbacks. In Gnome using C or C# 1.0 you use something like:

It is worth pointing out that Joachim and in general the
gaming world were ahead of our time when they requested these
features. This style of threading is commonly referred as
microthreading or coroutines.

At the time, without runtime support,
Rodrigo
suggested that a framework based on a compiler-supported
generator-based system using the yield instruction
would satisfy Joe's needs for coroutines in the gaming space.

This is what Unity uses to this day.

C# Yield Statement in Mono

The yield statement in C# works by building a state machine
into your method. When you write code like this:

The compiler generates a state machine for you. In the
above example there are two states: the initial state that
starts execution at the beginning of the function and the
second state that resumes execution after the yield
statement.

Yield statements can be used to solve this class of
problems, but they become annoying to use when every method
participating in suspending execution needs to become an
iterator. If any part of the pipeline is not built with
explicit support for yield, the system stops working.
Consider this:

Here, even if the WaitForIncomingMessageFromNetwork uses
yield the callers (DoTenThings and Attack) are not
participating, they merely discard the return from yield, so
the execution does not return to the main loop.

Using a yield-based framework is not much of a problem if
you only need to use this every once in a while. For example
we use this in our ASP.NET engine but it is only used in a
handful of places.

Unity used
an approach built on top of the yield framework to suspend
and resume execution. For example this is invoked by
the Update() function on an enemy script:

The same can be done in Unity with C#, but your functions
should be declared as returning an IEnumerable.

Microthreading in SecondLife

In 2006, Jim from
LindenLabs introduced
the work that they had done in SecondLife to support
microthreading.

Jim's work was a lot more ambitious than what both Joe had
requested. SecondLife required that code be suspended at any
point in time and that its entire state be serializable into a
format suitable for storage into a database. Serialized
state could then be restored at a different point in time or
on a different computer (for example while moving from node to
node).

For this to work, they needed a system that would track
precisely the entire call stack chain, local variables and
parameters as well as being able to suspend the code at any
point.

Jim did
this by using a CIL rewriting engine that injected the state
serialization and reincarnation into an existing CIL
instructions stream. He covered the technology in detail in
his Lang.NET talk in 2006.

The technology went in production in 2008 and today this
continuation framework powers 10 million Mono scripts on
SecondLife.

The Stackless
Python on EVE presentation goes through the concepts that
Tomi adopted for his Mono.Microthread library.

Tomi's approach was to modify the Mono runtime to support a
basic construct called a Continuation. The continuation is
able to capture the current stack contents (call stack, local
variables and paramters) and later restore this state.

This extension to the runtime allowed athe entire range of
operations described in the Stackless Python on Eve
presentation to be implemented. It also addresses the needs
of developers like Joachim, but is not able to support the
SecondLife scenarios.

Mono.Tasklet.Continuation

The Mono.Tasklet.Continuation is based on Tomi's
Microthreading library, but it only provides the core
primitive: the continuation. None of the high-level features
from Tomi's library are included.

When you call Store the current state of execution is
recorded and it is possible to go back to this state by
invoking Restore. The caller to Store tells whether it is
the initial store or a restore point based on the result from
Store:

Tomi's patch and library were adopted by various people, in
particular in the gaming space and we have heard from many
people that they were happy with it. Not only they were
happy with it but also Paolo, Mono's VM curator, liked the
approach.

Frameworks

Speaking
with Lucas, one of the
advocates of Tomi's VM extensions, at the
Unite conference it
became clear that although the Mono.Microthreads work from
Tomi was very useful, it was designed with the EVE scenario in
mind.

Lucas was actually not using Mono.Tasklets on the client
code but on the server side. And when used in his game the
Stackless-like primitives were getting on his way. So he
used the basic Continuation framework to create a model that
suited his game. He uses this on his server-side software
to have his server micro-threads wait for network events from
multiple players. The Tomi framework was getting in Lucas'
way so he created a framework on top of the Continuations
framework that suited his needs. He says:

I found however, that what system you build on top of the core
continuations tech, really depends on what kind of application
you're building. For instance, I have a system where I send
serialized "class ProtocolMessage" 's over the network. they have a questionID
and an answerID, which are guids.

the last call will block, and return once a message with
the expected type, and matching answerID has been received.
This is made to work because the
SendMessageAndWaitForAnswer<T>() call adds itself to a
dictionary<GUID,MicroThread> that keeps track of what
microthreads are waiting for which answer. A separate
microthread reads messages of the socket, and reads their
answerID. it then looks to see if we have any "microthreads
in the fridge" that are waiting for this message, by comparing
the guid of the message, to the guid that the microthread said
it was waiting for. If this is it, it reschedules the
microthreads, and provides the message as the return type for
when the microthread wakes up.

This is very specific to my use case, others will have
things specific to their use cases.

Going back to the Joachim sample from 2004, using Tomi's
code ported to Mono.Tasklets, the code then becomes:

The MicroThread.WaitFor will suspend execution, save the
current stack state --which could be arbitrarily nested-- and
transfer control to the scheduler which will pick something
else to do, run some other routine or sleep until some event
happens. Then, when the scheduler is ready to restart this
routine, it will restore the execution just after the WaitFor
call.

The code is written in a linear style, not in a callback or
state machine style. Each one of those methods
WaitForObjectVisible, WalkTo and Kiss might take an arbitrary
amount of time to execute. For example the prince character
might not kick into gear until the princess is visible and
that can take forever. In the meantime, other parts of the
game will continue execution on the same thread.

The Continuation framework will allow folks to try out
different models. From the Microthread/coroutine approach
from Tomi, to Lucas' setup to other systems that we have not
envisioned.

Hopefully we will see different scheduling systems for
different workloads and we will see libraries that work well
with this style of programming, from socket libraries to web
libraries to file IO libraries. This is one of the features
that Lucas would like to see: Networking, File and other IO
classes that take advantage of a Microthreading platform in
Mono.

Last year we did some work in Mono together with
Luis Ortiz to support 64-bit arrays in the VM.

What was interesting about this work is that even though
the ECMA standard allows the index of arrays to be a long .NET
on Windows64 does not support this and Java would require
modifications to the bytecode format. Altering Mono became
the natural choice for those looking to host very large arrays
in an advanced and managed VM.

This means that you can continue to use your existing tools
to build applications, but when running under Mono you will
get to use those arrays without that pesky 2,147,483,648 upper
boundary.

Today Ian Dichkovsky (from N-iX)announced on the mailing
list their work to bring Mono to the MIPS64
from SiCortex. This is
based on the excellent work from Mark Mason that did the
MIPS32 port.

SiCortex has an entry-level desktop computer with 72 MIPS
processors and if you have the budget you can get modules with
5,832 processors. The MIPS
processors helps
them stay eco-friendly.

In my survey I listed the pros and cons to give people a
feeling of what I was up against.

The first couple of votes were not very helpful, I got 2
votes, one said yes, one said no.

Then another twenty or so votes came and the balance
started to shift towards "go". Here is the final result:

And then something very strange happened, the comment
section for the online poll started getting people's opinion
in the form of poems or Haikus.

I copy pasted some of the poems below:

In my heart you will always be now in heaven i cant wait
again to see

When I decided not to roam
I just stayed home
Got a lot done
Enjoyed some time in the sun

Listen to good talks with your friends
Before all the fun ends!

Catch up and learn about Google's V8
--Maybe you'll even get a date!

You should go because it will be a blast
Life is short, so make it last!

a haiku for miguel:

Improve your cv
Boston is lovely right now
Drink with nerdy folks

I can’t make up my mind.
I really am in a bind.
I can go to Lang dot net,
And my day will be set.
Or stay at home and work,
Like a common store clerk.
This choice will be easy.
Lang is where I will be.

Should I stay,
or should I go?
For every con,
there is a pro.

I could see old friends,
and make some new.
Or stay at home,
and get work done too.

I could learn about Second Life,
and Google's V-8.
And actually accruing miles
would really be great.

It would take a whole week.
And delay my work,
But learning something new
Is definitely a perk.

A programmer I am,
and a programmer I will be.
I think this great poem
made my mind up for me.

New friends
Old friends
Learning new things
And when you get back to Boston
You can have some baked beans

destroyer of days seven
bringer of travel expenses
Lang.NET

provider of lectures
connector of colleagues
Lang.NET

delayer of projects
impeder of family time
Lang.NET

programmer of dynamic C#
granter of Second Life
Lang.NET

Why go across the country to have a v8?
Because that's what .NET is 4.
Lang.NET

Kill time
or make new friends?
Lose a little time from work
or catch up with those you've fallen out of touch with?
Work can always wait Miguel
opportunity cannnot.

Another dollar for yet another day,
That is what they all used to say.
For Lang.NET 2009 I pine away
The cost to do it makes me say “Hey!”
Give me Second Life with which to play
If only I could go to the conference that way
I’d program it if C was their programming thang’

Let me help Miguel on what to do.
He's undecided...can't decide between the two.
If he goes to Lang. NET, work at home will pile high.
If he stays home to work, perhaps he'd cry.
He'd miss the chance to learn Second Life,
Or make new friends, maybe even find a wife!

So it costs a few bucks to get to there.
He'd blow it on something else other than air fare!
Make the reservations today and don't delay.
You'll have a good time....that's what I say!

Divided I stand
The opportunity to advance ahead
A week of talks and new friends await me
On my way to Lang.NET 2009.

One week gone,
Trekking across the country.
Putting all tasks aside,
I delay work
On my way to Lang.NET 2009.

In the end,
The journey made
Is better than the journey dreamed.

Oh the choice, to go or to stay
that is Miguel's question of the day!

Should he go, he would have a great time
Should he stay...he might save a dime!

Going he will learn about new things out there
Staying he might...get more work done fair.

The choice looks easy to someone like me
but then again I'm not Miguel....I'm Susie

Once when Miguel was feeling weak,
A conference looked to kill his week.
But opportunity there it seemed was rife:
A chance to master Second Life!

Miguel's Dilemma
Should I stay or should I go
The trip could be for not
But my gut says I should go
Money,work,time and home
Oh, well bye bye I go.....

knowledge is calling me to fill him up
my friends are quite expecting
there are also some guys I don't know that i have to spy on

who cares about work!
who cares if I hitchhike to Lang.Net!

home will always wait
across the country I will enlighten myself

To Lang.NET or not to Lang.NET ... that is the question.
Whether 'tis nobler to learn about great stuff
Like Second Life and dynamic C#,
Or consider it the death of
An entire week away from home,
Thereby missing out on the catching up with old friends.
What value, then, shall be given
This knowledge and friendship?
Is it greater than the cost of transport and per diem?
Only Miguel can truly tell.

Lang.NET
Lang.NET
Oh this decision should not make you fret

Think about the things that are great
Second Life! .NET 4 and Google V8!

These things are worth the week away
your delay in work, and your hit in pay

Think about the old friends you'll greet
And all the new ones that you will meet

The knowledge base you'll gain and learn
will help you back help you back home and what you earn

Lang.NET
Lang.NET
Looks like going is really your best bet.

Haiku:

While traveling sucks
Experience should be worthwhile
Go enjoy Lang.NET

There are times we can't resist
Pondering the things we've missed.
We vow, "Next time I won't be slow.
I'll just pick up myself and go.".
And when we're back, our money spent,
We often think, "I'm glad I went".

Lang.Net
Not a bad gig to get
Sure it's a road trip
And a work skip
A budget breaker
But 'cmon,
Ain't it grand to be a taker?

Lang.Net
Not a bad gig to get
Sure it's a road trip
And a work skip
A budget breaker
But 'cmon,
Ain't it grand to be a taker?

Miguel should fly cross country,
And not worry about the money.
The trip will be great,
You must learn about Google V8.

Leaving home for a week,
Does sound rather bleak,
But you'll chat with old pals,
And may meet some gals.

There is much to learn,
but conferences return.
If you stick to your guns,
keep your money in your pocket,

you'll have more in store
when next year rolls around.
So stand on solid ground!,
and in 2010 launch rocket.

Not quite sure why I got so many replies in the form of
poems, and Google surveys do not track the IP address of the
submissions, so I have no idea if these were all submitted by
the same person or not.

Telerik is one of the
most famous provider of controls for .NET. We have been
working for the past few months with Telerik to make sure that
their RadControls
for ASP.NET AJAX product worked out of the box with Mono:

Today Telerik announced the availability of their product
officially for Mono-based customers on Linux systems. From
their press
release:

Telerik, the leading vendor of development tools and
components for the Microsoft .NET platform announced that
RadControls for ASP.NET AJAX fully supports the Mono runtime
environment, an open source .NET framework sponsored by
Novell, tailored for development of Linux applications. The
Telerik AJAX UI components is the first major commercial user
interface (UI) suite to go cross-platform and allows
developers to build rich .NET applications in a Linux
environment.
“This has been a long-awaited feature, which we have been
quietly working on for quite some time. Over the past few
months, we have been actively testing the compatibility of our
RadControls for ASP.NET AJAX offering with Mono", said Hristo
Kosev, Telerik CTO. "We are extremely happy that our joint
work with Novell will allow customers to build compelling
high-performance ASP.NET AJAX-based applications and run them
on Linux using Mono 2.4.”
The decision to work with Novell to extend the capabilities of
RadControls over other platforms is in direct response to
customer feedback and interest in Mono. Telerik and Novell are
optimistic about the effect their partnership will have on the
industry and the benefits it will bring to .NET developers.

Telerik is a major player in the control space in the .NET
world and many developers turn to them for ready to use
controls for their applications. Developers that were
previously using Telerik products can now host their products
on Linux servers.

Special thanks go to Marek Habersack in the Mono
team who worked tirelessly to fix Mono's ASP.NET stack.
Working with the Telerik folks was a pleasure. Telerik helped
us by providing us access to their source code, their test
suite and their QA team that made sure that their thousands of
tests ran equally well on Mono as they did on Microsoft's
.NET.

Microsoft's ASP.NET
MVC is an extension built on the core of ASP.NET that
brings some of the popular practices and ease of development
that were popularized by Ruby on Rails and Django to the .NET
developers.

Scott Guthrie
---the inventor of
ASP.NET--- just
announced that Microsoft is open sourcing the ASP.NET MVC
stack under the MS-PL license:

I’m excited today to announce that we are also releasing the
ASP.NET MVC source code under the Microsoft Public License
(MS-PL). MS-PL is an OSI-approved open source license. The
MS-PL contains no platform restrictions and provides broad
rights to modify and redistribute the source code. You can
read the text of the MS-PL at: http://www.opensource.org/licenses/ms-pl.html

These are incredibly good news. Worth dancing for!

I know that a lot of developers inside Microsoft worked to
get this important piece of code released under the MS-PL to
ensure that the users of ASP.NET could benefit from the code
being open source. I know that at least Phil Haack, Scott
Guthrie, Scott Hanselman, Dimitry Robsman, Rob Conery and
Brian Goldfarb pushed for this.

I am psyched, not only because ASP.NET MVC is usable in
Mono and the code is licensed under open source terms, but
also because I strongly believe that the same innovation,
rapid adoption and experimentation that has happened with
the new wave of web stacks will come to ASP.NET MVC across all
platforms.

The source code is
available for
download and we are hoping to integrate this into Mono
shortly. Scott
Hanselman has
a nice blog entry on how ASP.NET MVC went from price-free
to open-source free.

In
Scott's PDF
tutorial he discussed how to build applications with
ASP.NET MVC using Visual Studio and how the Rails practices of
not repeating yourself and convention over configuration are
used by ASP.NET MVC.

We have developed
a MonoDevelop add-in
that provides a set of templates, dialog boxes and the tooling
necessary to take advantage of ASP.NET MVC on Linux and MacOS
X as well. Hopefully the experience will be very similar to
Visual Studio.

It was only two weeks ago that we were sipping virgin pina
coladas at Mix09: