Adrian Lamo’s Neighborhood

Johnny Lee's Wii Head Tracking

Johnny Lee (link) has done some really neat research. One of his projects is head tracking using off the shelf parts, specifically a Wiimote and light bar thingie, which I became aware of a few weeks ago. Check it out here. Basically it changes the image on the screen of your TV to make it look like you're looking through a window into the virtual world, as it would look through an actual window from that point of view.

Messin' with Mars

I was bored today and decided to envision Mars with water and an urban population:

Mars_2_day_small

Mars_2_night_small

Thievery! Oh nonsense.

I happened across an interesting little project today. A project to create a Javascript GUI framework by one Greg Houston who, by an amazing coincidence has decided to design it in a way that's similar to my own framework. And by another stunning coincidence he has chosen to name it... Mocha. How peculiar. How peculiar indeed. Is this a case of blatant theft of an idea? I'm flattered if it is, for two reasons: 1) It validates the idea, and 2) It means people know who I am. Shocked, tho I am, I'm also not angry. I'd like to be. It's been my concern that my stupid dilly-dallying on this project would find me outpaced by the less visionary but more diligent and organized and until now I had every reason to believe that that concern was merely my imagination, but it seems I was right, at least to some extent. Well again I'm vindicate in my views, tho this vindication is perhaps less desirable. However, it doesn't matter. The framework I'm (not-so-often-ly) working on was always going to be open source anyway, given the obvious inability to hide JS code from prying eyes. However I'm saddened no one thought to even mention this alternate project to me. Perhaps Greg doesn't even know who I am, and merely came up with this in parallel, but the similarities are too great. Perhaps we share a mutual friend and without realizing was informed of the idea I had and set out on his own to create what he thought was a good idea, not realizing the idea was actually a memory of something. Either way, it is what it is. To that end I feel I might as well open up what little I have so far to the world. I warn you: it's not pretty -- I don't pretend to be a great programmer, or even a good programmer -- it's horrendously slow (I'm working on a new way to implement class-based inheritance in JS so that it runs faster than what I've currently got, which will obviously be rendered pointless in JS2 but such is life, ey?), and it's far from being done, but it is everything I have worked on so far. So here it is, the original Moka, not yet complete but in its current entirety:

Moka

I should probably set up some sort of website for it at the domain I have for the project, but I'm no good with that sort of thing. It's necessary now, tho, I suppose. At the very least to keep me working on it and to build a community for it. Eh. Quick note: I'm not releasing this, as such. This is still copyright me, that's obvious. However I don't care if you mess with it right now. Just understand, it's not ready to be used in anything serious, nor is it ready for official release. The official versions (if they should ever exist) will be better and will be licensed probably under the LGPL.

Augury.

PsygnisFive
Nov 11, 2007

I just watched the three most important TED2007 talks. They all talk about related (albeit abstractly so) concepts that all tie in to what I think will be a very important technological achievement in the coming decades: the development of an abstract theory of self-organization.

Neil Gershenfeld: The beckoning promise of personal fabrication — Fabricators and the ability to "print" whole objects. (Once we have this technology, the entire social, economic, and political landscape will change. Watch out!)
Saul Griffith: Hardware solutions to everyday problems — Self organizing structures and their application to current problems.
Paul Rothemund: Casting spells with DNA — An exploration of the way in which chains of amino acids and other molecules can be coerced into specific shapes simply by programming them.
Hod Lipson: Robots that are "self-aware" — Designing robots that can determine their own body configuration and learn how to achieve tasks, without any outside guidance.
Vilayanur Ramachandran: A journey to the center of your mind — How brain damage can provide insight into the functioning of the brain.

Also worth listening to:
On Intelligence by Jeff Hawkins — Hawkins' magnum opus sketching out a view of the design of cognitive structures.
Futures in Biotech 10 — Carla Shatz on self-organizing brain structures.
Futures in Biotech 20 — Eric Kandel on the mechanisms of memory and learning.

Abstractly defined values

This one's going to be short.

I was reading some stuff on Ruby and was perplexed by this stuff that looks like

:name

so I looked into it and it turns out that it's a sort of object that doesn't really represent anything other than a sort of unique abstract value. And any two symbols with the same name after the colon there are considered the same. I think this is quite interesting because it means you can use these as variables for objects that have a property that can take one of a small number of values, without having to rigidly define exactly what those values are.

Obviously you can get sort-of similar activity just by using a string

"name"

since any two strings with the same text will be equal, so I'm not entirely sure why you'd use symbols, but I thought I'd think of some way of doing this in Javascript. I figure you can have a special function, like just $("name") that returns a globally defined symbol object, maybe like

function $(name){

return window[name] || (window[name] = { "id2name": name, "inspect": "$"+name, ... });

which works exactly as you want it too, but is really just ugly and nowhere near as elegant as the Ruby solution. Shame you can't just do

$name

or something.

The curious case of Javascript functions

I recently discovered this thing called Functional Javascript, which contains a number of quite sexy modifications to Javascript's base classes to add extra, more functional things. While I was browsing Oliver Steel's blog, I came across his Javascript memoizer.

The idea behind memoization is that you don't have to perform a complex computation over and over to access a value that stays the same. His example is the length of a given bezier, unchanging curve. Calculating the length is processor expensive, even tho the length is constant.

So, along the way, he describes a method of doing this by modifying an object method on the fly. Instead of simply defining it like so:

foo.bar = function(){ ... }

You would define it like:

foo.bar = function(){ ... }.memoize();

And that got me thinking, because for a while I had been looking for a way to "monitor" a function, so that every time it get's called, you can notified via a callback. Now, I didn't want to have to do this by including the callback info in the function, I wanted to be able to just decide, "Oh, I'd like to start monitoring this function", whenever I wanted.

So I started experimenting, inspired by Function.prototype.memoize, and I discovered something quite fascinating and curious about Javascript.

x = function(){ ... }.method();

is completely valid Javascript, but

function(){ ... }. method();

is not. Calling a function on a function literal will only work when assigning that function to a value. Now, I understand why this should be the case: function(){ ... } is "special", in quotes, because just doing

function(){ ... }

doesn't work, so you obviously can't call a method on that because it breaks before it even gets to the method. But then why does

(function(){ ... })

work without any problems? Curiouser and curiouser.

Anyway, I like to think that the method of calling methods on functions during assignment like that is quite an elegant solution to the problem of memoizing and call monitoring as you create these functions. I never would've thought to do something like that, and I wonder how many other people also thought of it. And how many other things in Javascript are there like this? Little quirks that have a certain elegance to them.

That makes me wonder what sort of sublime programming language we could design. I have the odd sense that it might be named after a red colored precious gem.. :P

(This method of memoization, btw, was only mentioned on Oliver Steele's blog, which is where I saw it. It was apparently created by Keith Gaughan.)

New name!

So after talking with Brian about what we should call the framework, now that it's clear we can't use Jade, we've settled on Moka, as a short form of Mocha. We decided to go with an alternative spelling to avoid potential confusing with MochiKit. We also figure that since the framework is going to have two primary skins, one light and one dark, we can come up with cute little coffee-based names for each skin.

Naming, Preparation, URLS

Naming Issues
Brian, the guy I'm going to be doing this whole startup thing with, pointed out to me that theres already a framework named Jade, for Java. My instinctual reaction was to discount it. I mean, it's JAVA, c'mon. Evil language. But once reason returned I had to concede that a new name would be needed. This means I'll have to change all the code for my framework, since all Jade classes have "Jade" as a prefix (e.g., "JadePanel"), which is a direct inspiration from the NS prefixing in OpenStep.

Progress and Preparation
Jade (or whatever .. *grumble*) is now really rather close to being ready to go into alpha testing, which Brian points out is going to require a site and all the accoutrements that go along with having a project like this. So far it seems like we'll need at LEAST info about the project, some sort of blog or forum or similar for building a community, documentation for the framework, and of course site design, server space, and a domain name. Oh boy.

Pretend file systems, URLs, and XHR
Obviously if you're gonna have apps, you're going to want to upload and use files so you need some sort of file system. Also, since it's web based, there's going to be significant use of URL manipulation and XMLHttpRequest usage. But these are all kind of the same on the web, aren't they? URL's reference files on a server, XHR allows you to perform HTTP requests for files, and a file system is just a way of handling files. So I've made the decision to collapse functionality into a single URL class that will let you perform URL manipulation and XHR interactions with the server seamlessly.

JavaScript's untyped function arguments, or: Try...Catch?

PsygnisFive
Mar 9, 2007
3 comments

Ok, so for a while now I've been woefully undereducated on the uses of try...catch. I know, I know, how can I claim to know JavaScript beyond even a basic level without knowing try...catch. Ok fine, sue me, denounce me as a poser, MEA CULPA. :P

Why is this relevant to the title? Well for a while now I've been manually checking argument type like so:

function doSomething( aJadeObject ){ if( aJadeObject == undefined ){ return; } if( typeof(aJadeObject.isKindOfClass) != "function" ){ return; } if( !aJadeObject.isKindOfClass(NecessaryClass) ){ return; }

//blah blah blah... }

The first line verifies that the argument is defined, because if it's not the second line will destroy the script. The second verifies that the object responds to the JadeObject method that's used to test descent from a particular class. The third actually verifies that descent. I did this for obvious type-checking purposes. I don't want to sent JadeArray query messages to a number or to null and kill the program, do it? No. Instead it would be better if bad messages just returned some default or null value or something, so that in such a case, the program would still function but there would just be a minor, localized, and likely unnoticeable, fault, instead of taking the entire thing down.

This whole convoluted system came up in a discussion with the ever patient Emmanuel Zephyr, my Cocoa devver friend person. I asked him his opinion on what sort of values should be returned when the function by default is supposed to return some none-void value. His suggestion was that i shouldn't even bother with all of that but instead should just use try...catch, which would simply try to perform the necessary operations without crashing the script. If the objects in question respond to the necessary messages then the try block will work successfully, which means that as far as the script cares, the arguments were the right type, otherwise it would fail and no bad things would happen.

So instead of all of that junk above, it would reduce to...

function doSomething( aJadeObject ){ try { //blah blah blah... } catch(e){ //maybe log the error? } }

without any type checking at all, and with a potential area for handling these type errors, possibly with some sort of logging for later debugging. I can't really believe that I allowed such a useful tool as try...catch slip past my dradis, but that's life, ey?

My only concern is this:

var x = 0; try { x = 5; y++; // throws an exception because y is undefined } alert(x); // alerts 5, because the x = 5 assignment works, despite the try block containing exception-throwing code.

This is potentially problematic because there might be cases where something is added to an array or whatever on the assumption that it's a certain type of object, and then it gets sent a message that it doesn't know how to respond to because it's not that type of object. So now the try fails but the object is still in the array, which is probably not a good thing. Now, this might not be a huge issue, and any problems that it might cause probably won't be too hard to fix, but it's definitely not perfect. Oh JS2, where art thou?