Frodo: What are we holding on to Sam?
Sam: That there's some good in this world, Mr. Frodo... and it's worth fighting for.

My blog just crossed 10 thousand unique visitors. Yippie!

With unknown consciousness, I possessed in my grip

A magnificent mantelpiece, though its heart being chipped,

Noticing not that I'd already slipped

To a sin of love's false security.

From silhouetted anger to manufactured peace,

Answers of emptiness, voice vacancies,

Till the tombstones of damage read me no questions but, "Please,

What's wrong and what's exactly the matter?"

And so it did happen like it could have been foreseen,

The timeless explosion of fantasy's dream.

At the peak of the night, the king and the queen

Tumbled all down into pieces.

Listening to Dylan again

Ah, my friends from the prison, they ask unto me,

"How good, how good does it feel to be free?"

And I answer them most mysteriously,

"Are birds free from the chains of the skyway?"

                        Bob Dylan, Ballad in Plain D, 1964

Common Larceny

Common Larceny is a Scheme runtime implementation on the Common Language Runtime.  One more chip in the usage of dynamic languages on the CLR. More details of the project here -

http://www.ccs.neu.edu/home/will/Larceny/

Robotics4.Net

Robotics for .Net is run by a bunch of geeks who have robots and API that run on .Net. I had been out of touch with Antonio Cisternino for while after our discussions on implementation of closures in C# and further… It looks like Antonio has been making brilliant use of his time since then. Among other goodies on the site you would find Antonio’s Annotated C# language and something that said that its VC++ API for controlling Robosapien that runs on a WinCE box.

http://robotics4.net/default.aspx

Spamming the Spammer

This actually sounded nice. Worth a look - discusses a screen saver from Lycos that discourages spammers by spamming their servers using unused bandwidth.

http://news.bbc.co.uk/1/hi/technology/4051553.stm

Here is another command line tool. Strangely, a couple of quick web searches could not come up with a command line tool for resizing images – so I wrote my own. If you have photographs from a digital camera that you want to mail out and the images are too large for email then most of the time it involves taking each image to some sort of image editing software and resizing them and such.

Image Manipulation Utility v0.1

(c) Roshan James, Dec 1 2004

 Img v0.1 is built on the .Net 2.0 GDI+ API and supports only creation

 of JPG image files. Exif/Iptc metadata are lost during convertions.

Syntax:

     imgmanip [/S] < filepattern> [additional patterns] < image size>

         /S               - recurse subdirs

         < filepattern>    - any wildcard combination

         < image size>     - format < Width>x< Height>, Ex: 800x600

(Don’t tell me it looks cheesy – I know it does – but it solves the problem)

A part of this source I found on the web, so appropriate mention is given to the original article.

Here are a few usage examples

> img *.jpg 800x600

File1.800x600.jpg

File2.800x600.jpg

This basically converts all jpf files to images of 800 * 600 resolution.

To recursively change

> img /S *.jpg 800x600

File1.800x600.jpg

File2.800x600.jpg

Simple?

If the original images have any metadata information then they are not retained in the new ones. What is this? Well most cameras insert information about the camera into the image file. You can also add your custom information like a title or description or comments to the image. To see this information (on a WinXP) simple right click the image file and take a look at the properties -> summary tab. Also if you tinker around with the column settings of explorer in detail view you can display some of this info directly in explorer.

I can think of a bunch of simple useful things to add – format conversions, cropping, borders, grayscale etc. Lets see…

The code is simple usage of .Net GDI+ API. The download exe is compiled to .Net 2.0 – but you can recompile from source to the version you want. For compilation run the following from a .Net SDK 2.0 command line –

>csc img.cs

Download

Speaking of image metadata, if you are a Ruby programmer, take a look at the exif library available. EXIF is a metadata tagging standard for image files.

http://raa.ruby-lang.org/list.rhtml?name=rexif

Digressing from the past couple of posts - I just wrote this little utility for myself that will do file encryption/decryption from the command line. I figured that some of you might also find this useful so I am sharing it out here.

This is no rocket science – simple usage of the API - but gives you reasonably good locking and a handy tool. The 256 bit Rijndael encryption implies that you can provide a password that is upto 16 chars in length. The encryption algorithm is a symmetric one – which means that you use the same password to decrypt the file.

This is also very rudimentary – no error checks and blah done: just enough code to get the job done.

Usage:

This is how you encrypt a file

> enc +password foobar.txt

Creating:2004-12-01--1206711.enc (foobar.txt)

It creates a new file called ‘2004-12-01--1206711.enc’ using the current date-time. This file is always a few bytes larger than the original. To extract the foobar.txt again you would say –

>enc -password 2004-12-01--1206711.enc

If you did not wish to extract the contents of an enc file, but you just what to see what file it contains, you say –

>enc ?password 2004-12-01--1206711.enc

2004-12-01--1206711.enc ==> foobar.txt

The exe here is a .Net 2.0 executable. The source is also there, so you can compile under your pet version of the runtime.  To compile

> csc enc.cs

And of course, it can encrypt any kind of file.

Download

Let me know if you want some simple switches/features added.

Over the months I had slowly lost touch with Scheme, with so much happening in life. Today I saw some scheme code again and somehow just looking at it made me happy. Some kind of inherent simplicity in seeing those brackets and that indentation style – something vague familiarity of old friendship. It was weird.

No no, I am not cracking up and I am still a good old pure imperative languages programmer at heart and yes (Small talk guys please stand to the corner), I believe that C++ is a OO language and I still like .Net and C#. But all said and done, I think I like scheme – need to get back to some old scheming as soon as time allows.

Digressing - been musing about dynamic languages a bit more. The real reason I have not been writing too much about it is because of the feeling that I am going to sound stupid because I don’t know enough. I think I am going to let go of that and take the risk of looking foolish for a bit and start writing down things as I go ahead.

Here is a bunch of things that could/would fall under the general umbrella of the lose term – dynamic languages –

1)       closures

2)       iterators

3)       coroutines

4)       continuations

5)       mutable types

6)       typeless variables

7)       dynamic method dispatch

8)       eval

I don’t want to get into method dispatch and sub-classing mechanisms here, but I think the above is a general list. Any biggies I have missed? Lets see if there are any appropriate mappings we can find in the CLR and such.

The iterators and closures are solved problems – or atleast are largely solved problems in C# 2.0 (yes I know we can’t do ref variables – I think that’s ok for now – I will be happy if you have an answer)

There are solutions to most of the others lying around in one way or the other in Jim’s IronPython and the lesser loved Jscript.Net compiler that ships in source form with Rotor.

Does anyone know where I can find a readable description of how a scheme compiler (not interpreter) would work?

Dynamic Languages on the CLR – Part 1

Today I came across a paper written in 1996 at MIT that spoke of Dynamic Languages implementation on the JVM. The paper is an interesting read and pleasant because it isn’t dotted with arcane notational jing-bang and actually talks about real implementation issues.

The paper is written by Olin Shivers of MIT, interesting person – ha ha, actually this is the real link.

The first section address the issues of optimization of small scalar data types like integers which cannot actually afford to have dynamic lookup. The solution he proposes entails an assumption to be imposed on pointer types – so that small values can be held immediately rather than via indirection. For this purpose he recommends the addition of a type called an ImmediateDescriptor. I could not help smiling because this seems so much like a solved problem in the CLR of today – value types.

The second big issue that the paper brings is one of custom operations that a particular language may require that the runtime may not support. I don’t really have an answer for this. The paper goes onto compare this as being the inherent contradiction between RISC and CISC systems and adds the angle of safety of the end programming construct. This is by far a brilliant piece of thinking and these are the two suggestions primarily

1)       Build it up in API

2)       Enable the VM to have an extendable instruction set – similar to micrcodes in a processor

a.       Enable compilability of such new instructions by compiling to a lower level more RISC instruction set than the high level instruction set of the runtime…

I am hoping to offset this second part by not affording extensibility in the runtime and instead believing in some magical set of primitives. I don’t know about work that is actually being planned by the CLR team in this regard, I wonder what they are planning.

It has been on my mind for a long time, to write about this – supporting dynamic languages on the most advanced runtime on the planet. I have been having this pet project on the back of my mind, and figured that I should probably write about it now. I was wondering how hard it would be to extend the CLR in a fundamental way to support dynamic languages – the idea here is not to add a whole bloat of features to the CLR, but to try and identify a set of primitive or simple rules/abstractions which when added to the CLR would enable implementation of dynamic languages efficiently on the CLR.

Why the CLR? Because the CLR is one of the fastest runtimes/VMs out there; it was inherently designed to run multiple languages; runs on a whole bunch of hardware and software platforms and has a very wide acceptance in the industry; it is an open standard that is not owned by any company; and there are atleast two publicly available implementations in source form – which means that it enables a language that previously had to lug along its own VM/interpreter to boldly go where no previous version has gone before.

Some smart languages like Groovy are doing this with the JVM. I was hoping for a while that Ruby would – but it turns out, after several mails on the Ruby mailing list that Matz the creator of Ruby, has other plans. Matz is writing his own VM for Ruby.

It looks like it’s a season for writing multi-language runtimes – head of the pack being Parrot, the new VM for Perl 6. There is of date, little or no information available about the actual architecture of Rite – ruby’s VM that Matz is working on.

What makes a runtime that supports dynamic languages different from runtimes that are built to support statically typed OO languages – I don’t have enough of a formal education or personal experience to answer that straight out. That is one of the things that I hope to teach myself in coming time. I can throw terms like dynamic method dispatch at you… but essentially I don’t know if I can nail it down to a set of fundamental primitives that make all the difference.

This is a blog entry about some of my early ramblings on the topic. I am hoping to teach myself some of the difference by looking at the opcode design for Parrot. I am expecting that there would be opcodes for runtime type lookup, runtime method invocation etc etc – does that solve the problem, I don’t know. It provides features that can be used to mitigate the problem, yes. In conjunction with studying the architecture of Parrot, I am hoping to compare and contrast that with what the CLR supports and see what is missing in the CLR. Again I am not expecting much to be missing – what I am expecting to be seeing be seeing is that a lot of what Parrot provides as opcodes, the CLR would not natively provide, but would instead be available as framework API.

There is another source – Jim Hugunin’s IronPython. Sometime early this year Jim Hugunin shocked the Python community and a large part of the dynamic languages world by implementing a python version that ran on the CLR – it was faster that the classical C Python. Jim previously was known for his Jython – a Python that ran on the JVM – but was a rather slow implementation. What Jim has essentially done is that he has written a bunch of libraries to augment what the framework provides and has used these liberally along with regular IL. Jim now works for the CLR team at Microsoft.

Once I think I have an understanding of how the Parrot opcodes makes it a better runtime for dynamic languages, looking at Jims work (which is openly available) should give me a good idea of what primitives can be derived and can be pushed into the CLR. That should be a good fun project to work on.

A lot of what I have typed would be plain common sense for someone who was actually following the field. A whole bunch of things are getting in the way of getting started, else I would have already.