Antlr

So I have started playing a little bit with Antlr, specifically using antlrworks. I was originally going to learn MPS, however Antlr seems like a possibly better choice. It seems that it can generate python as well as java parsers. Obviously I am most interested in the python ones.

http://www.dalkescientific.com/writings/diary/archive/2007/10/30/antlr_mw.html

This seems to be a good article that I am starting to work through.

http://www.antlr.org/wiki/display/ANTLR3/ANTLR+Cheat+Sheet


Some notes:
need the python library from http://antlr.org/download/Python/
- requires 3.1.3 version of antlr, will not work with the newest version of antlrworks
name of file must match the grammar name
the language can be specified like(defaults to java):
options{
language=python;
}

Well, havent posted anything in a while. I have been too busy with school and work and all of that normal stuff. But I did pick up a 8-bit AVR based game console/dev kit. I am hoping in a few weeks to dive into that. I also want to use the n-gon code I wrote to help implement astroids on the arduino. I think that would be fairly cool, and will learn a great many things. Just have to get through some school stuff first.

n-gon

So this weekend I wanted to use the ST7565 display with the arduino to draw a rotating cube, but decided to start in 2D first. So I did a rotating n-gon, which just showed how distracted and out of practice I am with C. None the less, it works, for the most part. Here is the source, pictures to follow later.

point.h:

typedef struct{
int x;
int y;
} Point;


arduino sketch:

#include
#include
#include "point.h"

#define BACKLIGHT 10
#define n 4
//n as in n-gon

ST7565 glcd(9, 8, 7, 6, 5);

static Point p[n];
static Point center;
float theta=30;
//due to error the smallest usable theta appears to be
//10 degrees, 15 is even better. anything lower and the steps are uneven due to
//rounding.
float c_t; //cos of theta
float s_t; //sin theta
boolean persist = true;
float distance;


void setup(){
Serial.begin(9600);
pinMode(BACKLIGHT, OUTPUT);
digitalWrite(BACKLIGHT, HIGH);
p[0]= (Point) {40, 10};
p[1]= (Point) {80, 10};
p[2]= (Point) {80, 50};
p[3]= (Point) {40, 50};
center= (Point) {60, 30};

glcd.st7565_init();
glcd.st7565_command(CMD_DISPLAY_ON);
glcd.st7565_command(CMD_SET_ALLPTS_NORMAL);
glcd.st7565_set_brightness(0x18);
theta = theta*(3.1415/180);
s_t=sin(theta);
c_t=cos(theta);

glcd.clear();
}

void loop(){
distance = sqrt(pow(p[1].x-p[0].x, 2)+pow(p[1].y-p[0].y, 2));
Serial.println(distance);

if(persist==false){
glcd.clear();
}
for(int i=0; i glcd.drawline(p[i].x, p[i].y,
p[i+1].x, p[i+1].y, BLACK);
}
glcd.drawline(p[n-1].x, p[n-1].y,
round(p[0].x), p[0].y, BLACK);
glcd.display();

for(int i=0; i p[i]=rotate_point(p[i], true);
}
delay(500);
}

Point rotate_point(Point _p, boolean clockwise){
//c_t is cos(theta) as a global to reduce computation
//s_t is sin(theat) as a global to reduce computation
//center is a Point, which represents the local origin the point
// will rotate around
float x = _p.x-center.x;
float y = _p.y-center.y;
if(clockwise==true){
_p.x = round((c_t*x)-(s_t*y)+center.x);
_p.y = round((s_t*x)+(c_t*y)+center.y);
}else{
_p.x = round((c_t*x)+(s_t*y)+center.x);
_p.y = round((c_t*y)-(s_t*x)+center.y);
}

return _p;
}

Well, I created a simple block shooting game using the arduino, wii nunchuck, and LoL shield. This is one of the first times doing multiple tabs of arduino code, and learned that the prototypes are only created for the original one, not all the rest. It is a pretty nifty but simple game. I am thinking though, that after I show it to some of the devs at work I will try rewriting it for the ST7565 LCD display that I got. I think that will allow me to make some more complex scenes and maybe make a space invader like game.

I may also try to do a version of pong for the LoL shield sometime. That could be nifty.

Well, my NXT needed some repairs today. The display was acting funny, as in not working. After some research it turned out that some of the caps needed to be resoldered. Wasn't too bad even though they were SMDs.

And I found what might be the perfect board for a biped robot. The leaf lab maple, with an arm cortex cpu instead of an 8 bit avr. And it has a modified arduino environment. I think that might be perfect for some of the more complex stuff that I will do with a biped. So may order that and the lynxmotion BRAT sometime in the next month or two.

Randomness

This is real randomness.... Matt and I today built a pendulum system based on the instructions from Make Magazine. This allows for both a double pendulum and a Rott's pendulum to be configured. Here are some cool pictures from the pendulum.

Languages

A talk with my boss yesterday about programming languages got me thinking a bit more. Why is it that some languages become mainstream while others remain obscure or academic? Part of this is languages have to be 'cool enough' to be worth while. By that I mean by the nature of programmers they want to either work on something very cool, or use a very interesting tool. Most have a domain that they are passionate about; for me that is computational biology and artificial life. However many of us don't work within their domain of specialty. (like for me I don't have a PhD, so the jobs are very rare) So if a programmer is working on problems that are not in themselves exciting what gives them drive?

I think that the answer is the tools and techniques that they can apply to the problem. As an example, I do not find web technology in itself to be particularly thrilling. I recognize that it is one of the most important technologies around currently, and changes the whole way client server interactions take place (REST interfaces are beautiful). However, something happens when I am using an interesting tool like Python, and test driven development. I get excited when I get each test to pass. It is no longer a matter of focusing on the web technology, but now I focus on the tests, and it becomes a game where my score is the number of unit tests I can get to pass. I think many people who program are the same way. They want to play with cool technology, but also don't want to relearn everything.

Since they become productive with one set of tools, they are reluctant to move out of that unless they really have to. If a developer is a java expert, and is given some problem that is more amenable to a perl or python script, and they do not know perl or python already, they will likely solve the problem in java instead of taking this as a chance to learn a new tool. In many cases they will just 'get it done' with the tool that they know and are comfortable with. However over time this leads to situations where the tool that they are expert with is no longer the current industry fad, and they have passed up all these small chances to delve into a new tool. For an individual developer this doesn't mean too much, but as an industry it means that fewer developers are willing to adopt some other tool at any given time point. Thus leading to a problem of how to find enough developers proficient in a new technology to actually use it.

The other side of the coin I think is managements perception of 'academic'. Software companies exist to produce a product, and to make money with that product. To do so the product has to work well enough that users actually want to buy it. This leads to the importance of code quality and maintainability and long term service. However to most managers it seems that academic means more whimsical programming, code that is all throw away, and does not have strict quality standards. This very well might be true in the language design labs, or OS labs, where things are proof of concept. However, outside of these areas things change very much. Go to a physics/engineering/genomics/applied math group and likely the situation is very different.

For one investments in equipment are taken seriously, and in many cases specialized instrumentation that interfaces with computers may be kept for decades in use because of prohibitive costs in obtaining new equipment. In such cases any custom code written for that instrument must work, and must be maintained over a long lifetime by different people. Additionally there are high stakes if there are errors in the system, as it could invalidate all the research done with that equipment. Costs of reagents are high, and rerunning experiments could be a huge financial drain on a research group. However such systems are generally on the smaller side of programming projects in academia.

Consider the case however of the code base used for working on grand challenge type problems. Here code quality is probably more important than in most companies. A team might spend months writing code for their scheduled run on a supercomputer. If their code doesn't work they have to essentially buy more time and wait again for their run to come up. This is not the time to find a null pointer exception. So these things have to be written by teams quickly, robustly, and in a manner that is is maintainable, just like commercial software. However, because of the huge complexity of many of the problems the overhead in learning a new language for a project is just not that big of a deal if it means that the problem goes from impossible to just barely possible.

Thus I think commercial software houses should look not to the CS departments for what is up and coming in languages, but to applied math, physics, bioinformations/computational biology groups. Right now this seems to point to Python, Scheme, and R.