Friday, August 28, 2009

Groovy and Processing.org!


Processing.org is a cool little thing; you can't look at two or three of the demos on their site before you realize it's really neat.  Not to mention it's designed as a compliment to Wiring, the language used to program the Arduino and a number of other DIY hardware platforms. 

So suffice to say, Processing is a compelling alternative to Flash for at least a handful of usage scenarios.  So what if you're a Java/ Groovy programmer who wants access to Processing's coolness, without using their cute IDE?  We're Java programmers after all; if I can't use Eclipse and integrate it with Hibernate and Spring -- well, that would be overkill.  But let's just get to the point: you can use Processing.org straight from your Java environment.  In fact, here's their JavaDoc.


But, the Processing language is actually kinda nice!  And if you look at all of those functions that Processing provides, they're all in the PApplet class.  Well that's a pain in the ass.  Never fear -- that's where Groovy steps in.  You can use Groovy's language features to Make Processing's API at least as easy to use, and you get all of the cool features of the Groovy language as well!

Enough rambling -- here's an example:

import processing.core.*

/**
 * A group of dots appear and then shrink in size.
 * This sketch uses the Groovy List and uses a second class SpriteEllipse.
 * This main extends PApplet so it can create the window.
 */
class CirclesDemo extends PApplet {

    // setup vars
    def sprites = []
    def renderer = JAVA2D // P2D

    // state
    int nCount = -1
    def animating = true
    int clickX, clickY = 0
    
    void setup() {
        ellipseMode CENTER
        size 400, 400, renderer
        frameRate 20
        smooth()
        textFont loadFont("TrebuchetMS-20.vlw"), 14
    }
    
    void draw() {
        background 120
        
        nCount++
        nCount %= 90  // add additional sprites every so often:
        if ( ! nCount ) (1..20).each {
            sprites << new SpriteEllipse( this ) 
        }

        def clicked
        sprites.each { s ->
            s.update()
            if ( s.dead ) s.init()
            else if ( clickX && s.isOver( clickX, clickY ) ) clicked = s
            s.render()
        }
        if ( clicked ) sprites.remove clicked
        clickX = 0
        
        fill 255 // set text color
        text sprites.size(), 5, height-5 // update sprite count display
    }
    
    void keyPressed() {
        if ( key == ' ' && animating ) { noLoop(); animating = false }
        else { loop(); animating = true }
    }
    
    void mouseClicked() { // get mouse click pos for next draw() call.
        this.clickX = mouseX
        this.clickY = mouseY
//        println " $clickX $clickY"
    }
    
    static void main(args) {
        PApplet.main( [ "CirclesDemo" ] as String[] );
    }    
}


Now the 'SpriteEllipse' class really could just be rolled up into the above
class -- since its functionality all comes from the PApplet anyway.  But in Groovy
you can easily separate the functionality into a separate class and use Groovy's @Delegate to make it appear that SpriteEllipse extends PApplet.


import processing.core.PApplet

class SpriteEllipse {
    private Float x = 0
    private Float y = 0
    private Float rad = 75
    private Integer color = 20
    private @Delegate PApplet pApplet
    
    SpriteEllipse(PApplet pApplet) {
        this.pApplet = pApplet // must be set first since it is delegate
        this.init()
    }
    
    void init() {    /* Initialize fields to random vals */
        this.x = random( 0, width )
        this.y = random( 0, height )
        this.rad = random( (int)( height*0.05 ), (int)( height*0.225 ) )
        this.color = random( 0, 255 )        
    }
    
    void update() { if ( this.rad ) rad-- }
    
    void render() {
        fill color
        ellipse x, y, rad, rad
    }

    boolean isOver(int mx, int my) {
        (mx-x)*(mx-x) + (my-y)*(my-y) < rad*rad;
    }
    
    boolean isDead() { return rad < 1 }
}


The full code is up on GitHub.  This is a modified version of this guy's work, so he deserves most of the credit. Actually now that I look back at his example, about the only thing I did was make use of the @Delegate feature :)


Monday, August 24, 2009

Hardware Console Monitoring without HyperTerminal

Although I'm a software engineer, I do, occasionally *gasp* have to interact with hardware. Of course that's an oxymoron, but what I mean is there are of course, a large number of programmers work on mainly client-server software that runs on commodity hardware (i.e. UNIX,Linux/Windows) and their biggest worry is which direction the directory slash faces - windows\ or linux/ - Aah!

So, let me share with you my experience of hooking one of these guys up to my laptop via a serial cable. Crazy, I know. Now on Windows, standard procedure is to fire up HyperTerminal -- seemingly the only application in Windows that hasn't been updated since Windows 3.x. It makes Minesweeper look like a 3D interface out of 'Minority Report.'

Getting to the point -- I thought "there's got to be something better than the compuing equivalent of smashing rocks together." Now, I'm perfectly comfortable with a real console window, so I went about trying to see if good ol' Cygwin can help me out here.

I found this link, which isn't exactly a step-by-step tutorial, but it was enough to help me figure it out. Given the following settings in HyperTerminal:
  • Connect Using: COM1
  • Baud rate: 9600
  • Parity: none
  • Stop bits: 1
  • Flow Control: Hardware
This translates (roughly) to the following TTY settings:
$ stty -F /dev/ttyS0 9600 crtscts clocal


And after you've done that... Nothing happens! Now what? Ok, now I can do this:
$ cat /dev/ttyS0

and see the console output from the device in my local console! Sweet.

Now it's not perfect -- for some reason, 'less' didn't quite work; to get around it I did this:
$ cat /dev/ttyS0 >> ilon.console.log
$ less ilon.console.log
..  [ then press 'F' to tail that log ]

So this worked fairly well. I'm not sure if this would work if the console
needed to accept input, but this is still an improvement over HyperTerminal :)

EDIT: More info on general Linux serial support.

Sunday, August 16, 2009

First Post

Trying out Blogger to see if it's a suitable platform for tech-related posts. TiddlyWiki, as cool as it is, doesn't make a good blogging platform because it requires manually syncing the local and web version.

First order of business: figure out how to get good code snippet support.

TODO: try out TwitBlogs.