Today I implemented the Method Group Conversions finally,
after getting some clarity of mind. The patch was relatively
short, mostly shuffling existing code around. So it is now
possible to write:
Button b = new Button ("Hello");
b.Clicked += handle_click;
...
void handle_click (object o, EventArgs e)
{
}
Specially interesting to Gtk# developers, since the plan is
to move the delegate signatures from the GtkSharp namespace
into the class that defines the delegate, so people will be
saved from writing:
// What they would have to write:
b.SizeAllocated += new Widget.SizeAllocatedHandler (handler);
// What they can write:
b.SizeAllocated += handler;
void handler (object o, SizeAllocatedArgs args)
{
}
I talked to Martin today for a while about the debugger.
It is finally back in shape: it can debug managed an
unmanaged, so people can use it to debug the JIT. The bad
news is that it requires an NPTL threading system, which is
only available on Red Hat 9 or with 2.6 kernel installations.
One of the limitations of the debugger is its current
command line language is yacc-based and grew organically. It
is not really great for interactive work.
I have been pondering what to do about this: an option was
to use JScript, but its not ready. Another was to use
something like IronPython, but that is also far away, and
another is to roll-a-tiny-command-line-system.
Am leaning towards rolling our own command line language,
my struggle is between a few models:
- TCL model
- Extrapolate variables first, then parse into
strings, implement statements as commands. Ultra
simple.
- The shell model
- extrapolate variables first, perform language
parsing, use ; and \n as separators parse chunks as
string vectors; use reserved keywords. More
complex
- The Perl model
- The parser drives the process, extrapolation
happens at the language level, and is not a input
hack. Use semicolons to delimit-statements, and
braces for grouping. Not clear if the interactivity
will feel right
Each model has its beauty, and it is hard to make a
decision. Will roll the dice next week.
On top of that, I want the command line processor to
perform some parsing for us, so we can type:
(mdb) b -thread 4 Main
In C#, the "break" command would be implemented like this:
class Break : Command {
[Argument] public int thread { get {} set {} }
public Break (string [] args)
{
}
}
So the thread property would be set to "4", and
the Break command would receive { "Main" } as an
argument.
Mono and MacOS X
I installed Mono on MacOS X. This is the first time that I
use a Mac for doing development. A few impressions: The Mac
UI is incredibly pretty, am glad the Gnome folks are using
this as a model to follow. After using the Mac, Longhorn and
XP feel cheesy, and Gnome feels rather professional, but not
as complete.
Now, the big downside of the MacOS is their kernel. This
is on a machine that is faster than my laptop, and still takes
three times as much to build the Mono C sources.
The problem can be tracked down to their Mach kernel. In a
way its good, because it makes us look much better for server
and heavy duty use. On the other hand, if they did not have
Avi from the Mach team running their decisions, that kernel
would have been long gone and Linux or FreeBSD kernel would be
used instead.
A few years ago, I looked into implementing the Mach-O file
format, its a primitive beast, it should not be hard to
implement that and implement the few things in Linux that
MacOS needs to get their UI tools running on a decent kernel.
The new alpha
GC from Hans Boehm works on MacOS with Mono, which
addresses one of the big problems people had. Mono-wise:
there are a few JIT failures with OS 10.3 though while things
work on 10.2.
To assist in the debugging, I started learning about the
PowerPC architecture. So far I have only seen two nice things
about its design (the conditional register files, and the
summary overflow bit,) but the choice of opcode names is the
worst I have ever seen. Psychologically it has the effect
of making me think `This instruction set sucks'. I might be
wrong, it might be just a perception thing, but having used
the SPARC and the MIPS in the past, which are pretty beautiful
designs, you are left wondering about chips designed outside
of universities.
Other updates
Jordi Mas is joining the Mono team on Monday. He will be
working on GDI+ and System.Drawing, that will be a good first
task for him. In the meantime, Peter Bartok is taking over
the gargantuan effort to make Wine-current work as a library,
and make it use Cairo in the X11 backend to solve the fight we
had between those two.
Lluis has checked-in th esupport to th eweb srevice page to
render a sample seesion of what a request to the webserver
looks like. Gonzalo got the FileSystemWatcher interface
implemented on Windows and Linux (using FAM, and falling back
to polling) which is pretty cool and Jackson has been working
in our tracing support for ASP.NET, all very nice, new toys
for the weekend.
