Ruby is now ludicrously fast.
Ludicrious JIT is a Ruby 1.8 JIT which uses the libjit library that was written for dotgnu pnet's JIT core, very similar to what rubydium was trying to do. But libjit's come a long way in the last 3 (!) years, so if you're a Ruboi I suggest you try this out anyway.
It is a testament to the efforts of Rhys, Aleskey and Klaus to keep the library truly modular, reusable and independent of pnet's internals.
--The biggest difference between time and space is that you can't reuse time.
-- Merrick Furst
So it has finally happened - a stable release of dotgnu's Portable.NET and Libjit, after nearly a year and a bit more. The critical thing about this release is that Rhys doesn't yet know about this yet. This is the first release we've done without rhysw's involvement - he's been last sighted in Greephone land. So rather than the usual place, you can get the packages from the savannah download area.
This is by far the most revolutionary release dotgnu has had. The entire x86 engine is now fully native JITted. The windows.forms has taken quite a lot of work. My special congratulations to Aleksey Demakov and Klaus Triechel - who have worked especially hard of late to get libJIT into the shape it is today.
And in other news, we've put up a couple of Google SoC ideas at gnu.org. I'm very much interested in people picking up the AMD64/ARMv4 libjit core, either individually or as a team (does GOOG allow that ?). Also great strides being made in WinForms land, Radek has just managed to get the SharpDevelop editor to run.
The SD code uses a fair bit of PInvoke code bits to draw the caret and such, which is totally disabled in this rebuild. But it is quite an achievement at this point to be able to run a GUI component of this complexity.
Awesome work all around folks !
--Time is the most valuable thing a man can spend.
-- Theophrastus
*DRUMROLL* I'm proud to announce the first commercial product to use dotgnu Portable.NET in a big way. Trumpf.de have brought out a pulse laser cutting tool which uses dotgnu. The embedded control device runs linux and uses dotgnu to power its control UI, running a Windows.Forms application on the touch screen. Here's how the embedded appliance looks like - isn't it purty ?
It is one of those days that you live for - when you can stand back and marvel at what has become of bits you twiddled. And congratulations to klausT, avd and radekp for supporting Trumpf. Of course, much heartier thanks to Trumpf for believing in our code, being a good customer and investing a good ten thousand dollars or more into the project, even more when you consider the number of patches from them directly. That kind of customer focus has essentially revived pnet from the ashes of its past into a new good groove of embedded goodness.
If want, you can take a look at the official brochure, but which doesn't mention anything about linux or dotgnu, sadly. There's more related stuff upcoming - I'm trying to get ARM support resurrected with the help of Pengutronix folks.
A solid year's worth of work has gone into pnet thanks to this and the next stable release is only four days away. This is the first release to include libjit support - adding a full x86 JIT to the engine core. The twin team of Klaus and Alesky have reworked the engine so much that I've been having trouble jumping back into the project without asking too many stupid questions. So, look out world, here comes 0.8.0.
Been a good five years - looking back.
--You know, I have one simple request. And that is to have sharks with frickin' laser beams attached to their heads!
-- Dr Evil, Austin Powers
On a cold dark day in November 2005, Trumpf took a risk and bet 9000 USD on dotgnu. These were two grants of 4500 USD each, one for libjit (i686) and the other for the corresponding JIT coder in Portable.net, which I've jokingly referred to as the Southern "Summer of Code" (update: skwashd reminded me that he coined the phrase).
As of October 1st 2006, the work is considered to be complete. Congratulations to klausT, aleksey and kirill, who will all receive an equal cut of the pie. But it is not really about the money here, it is about the true spirit of FOSS - how people stand up to be counted, are put to the test and come out winners. I've been there, done that and still miss the rush.
Moving onto the bad news section of things, I'd like to take advantage of this occasion to formalize my sabbatical in DotGNU land. I've been promising to huff and puff for a while, but nothing's been blow away so far, other than the odd one-liner somewhere. So at least for a couple of months, I'll just stop promising stuff and go into "do & commit" mode of operations.
If that doesn't work out, I'll just have to be promoted to management or taken out back & shot.
--The reward of a thing well done is to have done it.
-- Emerson
Last october, Radek Polak suddenly announced that now dotgnu has a debugger. As much as that was good news, it still didn't fit in easily with the current design where the debugger works over the wire. On wire debug protocols are all the rage these days and for good reason, except that a few too many exist in some places. The new debugger backend is checked into Portable Studio SVN for those interested in the nitty gritty details. Here's a sample debug session.
The server is running at port 4571
Waiting for a connection...
Connection accepted
--------------------------------------
Shortcuts for recently used commands
0. watch_method PrintFn
1. unwatch_method PrintFn
2. list_threads
3. unwatch_all
4. stack_trace
5. print_locals
6. dasm
7. watch_location simple.cs 2
8. watch_all
9. watch_method Main
--------------------------------------
> l
<DebuggerResponse>
<Breakpoint Offset="-1">
<Location Linenum="0" Col="0"><SourceFile Filename="" /></Location>
<Member MemberName=".ctor" Owner="$Synthetic.$164">
<MemberSignature Language="ILASM"
Value="public hidebysig specialname rtspecialname
instance void .ctor(int32) runtime managed "/>
<MemberType>Constructor</MemberType>
</Member>
</Breakpoint>
</DebuggerResponse>
> print_locals
<DebuggerResponse>
<LocalVariables>
<LocalVariable Value="10" />
<LocalVariable Value="0" />
<LocalVariable Value="0" />
</LocalVariables>
</DebuggerResponse>
That is the raw debugger protocol dump, now I'll just wait for Radek (or someone else) to slap a pretty UI on top of that. In all probabilty, Portable Studio will let me debug dotgnu code without all the hassles we've been going through for the past few years.
Developer tools are the crack cocaine of the software world. One try and you're hooked.
--Debugging is over when people get tired of doing it.
Tom Tromey has put up information about a function GCJ backend interpreter using libjit. He's not put up the code as such, but here's the blog entry explaining what he's done. But a little digging found me this gcj-jit/jit.cc which could be the Real McCoy.
This is all really awesome for libjit because it adds another good use as well as a lot more test cases. More news later.
--Your motives for doing whatever good deed you may have in mind will be misinterpreted by somebody.
Finally, Rich333 appeared back on #dotgnu - of course, while I was away.
<scandium> and a few days ago I think t3rmin4t0r said that he's going to look at it to get
the interpreted mode of libjit right
<Rich333> so the chances of him helping with libCrayons instead of making smug blog comments
about it are zero... perfect
<Rich333> thank the gods
So let me make yet another smug comment about libCrayons while I'm at it. Heh, just kidding. I've been slacking for a while lately, I've been working on XPath which nobody around really needs that badly. Richard has been hacking away like mad on the crayons code. I just did a diff of the commit he made yesterday.
libCrayons/ 2006-03-06 +6774 -2673
I'm sure that he's been under-appreciated for all the effort he has put into pnet. Praise, where praise is due... [in other words - w00t, Rich333 r0cks]
Also if anyone's interested in helping (come on !), just give #dotgnu a raise and see if you're any good at low level graphics magic. You'd probably learn more about how UI systems work in two months than years in a classroom. And that's a promise.
--The trouble with opportunity is that it always comes disguised as hard work.
-- Herbert V. Prochnow
While the blug meet was in full flow on saturday, my dev box at work was building a clean copy of firefox off CVS. I just started to build it out of curiousity, but soon I realized that the world of web programming is going to be taken by storm when people start writing code for deerpark. Though it revolts my sense of propriety when browser specific hacks are introduced, this one's a pretty corking feature.
For a few years now, we've been using Applets to display dynamic data from the server side. At that point they were the only real way to actually fetch data from the server without refreshing the page. With the advent of Ajax, that no longer limits writing apps in javascript rather than in java. But still the only way to show dynamic charts and graphs was still to use an applet - No More .
HTML Canvas: This is a new standard from the WHATWG to do procedural graphics. Canvas is different from SVG in that this has context operations like rotation or other transoformation and resemble OpenGL or Postscript rather than SVG. In fact, Mozilla has built its canvas so that SVG is a data model which is rendered on a canvas view.
Since I am too lazy to actually do any graphics work, I'll point you to some excellent examples. Here's the classical tiger sample which keeps popping up whenever someone wants to show off graphics - tiger.xml. For those who still don't believe in the power of this new widget, I present you the graph charts on liquidx. Or the ultimate sample - a wolfenstein model first person shooter written in javascript. Pretty decent game, if you could play one at 8 FPS.
Believe me it is certainly worth downloading one of the nightly tarball if you are averse to building it yourself. Go get it, try it and see it work. I'm surprised that not too many people are blowing hot & cold over this particular feature.
--Never invest your money in anything that eats or needs repainting.
Even though libCrayons is taking its sweet time, the drawing library on top of it is actually moving along pretty nicely recently. Brubbel has been working quite hard on the path handling (as the changelog shows). He checked in an absolutely brilliant sample which should show off what pnet's graphics drawing is actually capable of. I've pulled out the code out of the FormsTest for the sake of those who just want to play around with it - TigerPath.cs.
The anti-aliasing and fill curve patches just rock, just take a look at the state the codebase was in before. Three patches in CVS and it is all smooth as silk - *sweet*.
It isn't often a huge patch hits pnetlib - but 600 odd lines in one week sort of makes me happy to just sit back and look at the pretty pictures :)
Now, I'm headed deep to investigate what XmlNodeReader really does...
--These are merely lines to me, but they paint a picture for you.
Halfway through debugging APC last night, I started to get seriously bored with the complete lack of success I was having. So I just kicked back and implemented a new feature for pnet. So far pnet's System.IO.Ports implementation has support for regular serial ports, USB ports and Infrared ports - I wanted it to work with bluetooth. For no good reason, the thought popped into my head - backup my phone numbers with a program.
So I started to recall all the AT commands I'd studied so hard while doing mobile phone testing in Wipro. I didn't have a document for GSM AT commands, neither was I sure how to set up a serial simulation via bluetooth. I cheated a bit by doing a strings libgnokii.so | grep "^AT" but I knew what those commands did. After starting the bluetooth daemon, I discovered that hciconfig/hciattach is *NOT* the tool to attach stuff to hci0. The point to note is that you need to know the bdaddr of the phone you want to hook into.
[root@phoenix ~]# rfcomm -i hci0 connect rfcomm0 00:13:70:C3:AA:7A Connected /dev/rfcomm0 to 00:13:70:C3:AA:7A on channel 1 Press CTRL-C for hangup
Now this is what happens when I give rfcomm0 as the resource in pnet's System.IO.Ports implementation.
Uncaught exception: System.ArgumentException: Arg_PortName
Parameter name: value
at System.IO.Ports.SerialPort.set_PortName(String) in ./IO/Ports/SerialPort.cs:574
at System.IO.Ports.SerialPort..ctor(String, Int32, Parity, Int32, StopBits)
at System.IO.Ports.SerialPort..ctor(String, Int32)
at Phonebooker..ctor(String) in phonebooker.cs:52
at Driver.Main(String[]) in phonebooker.cs:22
Because the terminal I/O device should work with the same API no matter whether it is USB, bluetooth or regular serial ports, there was no real change to the entire code to make it work. Let's just say that it just works and leave it at that.
Then it was smooth sailing to write a small app which would read/write data from the serial port. Essentially the code looks something like the following.
port.Write(command+"\r");
while(port.BytesToRead > 0)
{
String line = port.ReadLine();
if(line.StartsWith("ERROR") ||
line.StartsWith("OK"))
{
break;
}
}
With these four AT commands
- AT+CSCS='8859-1'
- AT+CPBS
- AT+CPBR?
- AT+CPBR=n
Just a quick reminder, you need the latest CVS head code of pnet and pnetlib to test this toy out :)
--If you find a solution and become attached to it, the solution may become your next problem.
Since all other text editors suck (emacs is good for a scheduler application or as a visual shell, but its editing leaves much to be desired), radekp decided to find a way to embed VIM into a windows.forms application. And to my astonishment (well, yeah), he managed to get it working.
Quite amazing things people do with simple tools.
--It's difficult to see the picture when you are inside the frame.
Actually, it happened before 2006 dawned. I was too busy to sit down and write about it. But it is official folks, the first peice of C# code has been run using the libjit x86 JIT. Here is the announcement.
If you would like to help out dotgnu - by talking about it, by testing it - any way you can, contact me (t3rmin4t0r on #dotgnu!irc.freenode.net). I really need someone who can fix up the XML parts of dotgnu. So if you want to help, be sure to talk me to me. Or talk to _Simon, he'll probably tell you what all bugs that I am slacking on.
--All one has to do is hit the right keys at the right time and the instrument plays itself.
-- J.S Bach
There was this thesis that SuperIlu was doing. The general aim was to study if we could freeze a virtual machine on one machine/cpu and migrate it to another - and now we understand a lot more about acorn nut burying squirrel migration patterns than we ever did before. Did you know that evil squirrels say we own your nuts just before they ship you off to the nut mines ? Amazing things they can do these days ...
The jokes aside, it is an excellent example of how Portable.net can be made to do things which it wasn't designed for - in a sort of Model-T driving a flour mill sense. The engine can be stopped ,moved to another machine and the whole thing will keep ticktocking as if nothing happened at all.
If you can read German, you can look at the real thesis. Or if you are like me you can read his implementation notes, which are thankfully in English. for the
--Hackers are just a migratory lifeform with a tropism for computers.