Blog has moved!

Hey all, I’m discontinuing p5wscala. It was a fun time in my programming career but I have since moved onto other things, and I want an outlet to share my experiences – but this blog doesn’t serve that purpose, since this one is dedicated to that very specific category of programs written in Scala using the Processing library. Thanks to everyone who’s been reading, I hope they’ve been of some help.

I have a new blog at blog.zhangxiaohan.com; I have copied all the posts from this blog over there, and will definitely be picking blogging back up. The topics will be of a more general scope though – less of a specified goal; more just “what am I doing?”

Update: I have no immediate plans for continued blogging and have since disabled that older site. Keep up to date with me at http://www.hellochar.com/! Thanks!


Still Alive

Hey, it’s been a bit since I’ve updated but I’m alive and well; been collaborating with Brendan on an upcoming game. Here’s a screenshot of an early prototype:

 

 

More to come!


I’m on Github!

I’ve uploaded all of the p5wscala source code onto Github. You can find me at https://github.com/hellochar. The source code for these sketches is at the p5wscala repository, but a lot of the code depends on the other two repositories (Scala-lib and Zhang-Camera-etc). Please let me know if there are any problems with the libraries (and I know there will be). Also, I’ve got a new sketch coming up, so stay tuned!


Website down

Sorry guys, my website will be down until next Saturday (8/13/11). Someone is rooming where the server is and the noise is a bit too loud.


Interactive Processing Window from REPL

[Edit 08/09/2011 I’m keeping an updated version here.]

Here’s a little thing I concocted:

import processing.core._; import PApplet._; import PConstants._;
object Test extends PApplet {
	override def setup() { size(500, 500); }
	override def draw() {}
}
PApplet.runSketch(Array("Test"), Test)
import Test._

Assuming you have the processing library in the classpath, you can copy and paste that code into the Scala REPL and you suddenly have an interactive graphical environment:

Welcome to Scala version 2.8.0.final (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_23).
Type in expressions to have them evaluated.
Type :help for more information.

scala> import processing.core._; import PApplet._; import PConstants._; import org.zhang.lib.misc._;
object Test extends PApplet {
	override def setup() { size(500, 500); }
	override def draw() {}
}
PApplet.runSketch(Array("Test"), Test)
import Test._
import processing.core._
import PApplet._
import PConstants._
import org.zhang.lib.misc._

scala>      |      |      | defined module Test

scala>
scala> import Test._

scala> background(255)

scala> var (x, y) = (width/2, height/2):(Float, Float)
x: Float = 250.0
y: Float = 250.0

scala> def newDir = random(4).asInstanceOf[Int] match { case 0 => (x, y+5); case 1 => (x, y-5); case 2 => (x+5, y); case 3 => (x-5, y); }
newDir: (Float, Float)

scala> for(i <- 0 until 1000) {val (nx, ny) = newDir; line(x, y, nx, ny); x = nx; y = ny; }

scala> save("frame1.png")

frame1.png

scala> filter(BLUR, 3)

scala> def randomWalk() {
     | var (x, y) = (width/2, height/2):(Float, Float)
     | def newDir = random(4).asInstanceOf[Int] match { case 0 => (x, y+5); case 1 => (x, y-5); case 2 => (x+5, y); case 3 => (x-5, y); }
     | for(i <- 0 until 1000) {val (nx, ny) = newDir; line(x, y, nx, ny); x = nx; y = ny; }
     | }
randomWalk: ()Unit

scala> randomWalk()

scala> filter(BLUR, 3)

scala> save("frame2.png")

frame2.png

scala> for(i <- 0 until 10) {randomWalk(); filter(BLUR, 3)}

scala> save("frame3.png")

frame3.png

scala> colorMode(HSB)

scala> background(255)

scala> for(i <- 0 until 100) {stroke(i*2.5f, 255, 255); randomWalk(); filter(BLUR, 1); }

scala> save("frame4.png")

frame4.png

Immediate feedback ftw!


Scala Scripting, XML Literals, What the encodings?!

I read recently about how Scala can be used as a scripting language and decided to use it to help streamline my turn-sketch-into-applet process. These first two sketches I put up showed me that there were four basic steps to making a sketch presentable. I fired up MS word and decided that my script should, after taking a file name for input:

1. Create a sketch folder
2. (a) Generate a proguard configuration file suited for the sketch and then (b) run proguard using that configuration file, outputting a jar in the sketch folder (the configuration file should also be saved in the sketch folder)
3. copy the source code of the given sketch into the sketch folder
4. generate an “index.html” file pointing to the applet and referencing the source code
4a. Possibly ask for “mouse and keyboard controls”, and an optional “extra comments”

Creating a folder is very easy with java.io.File, so that one was a no-brainer. #1 Check.

I hadn’t really looked into Scala’s IO. I decided to go with Apache Commons IO to do most of my file copying/writing, since their FileUtils class has basically exactly what I needed. Writing the configuration file was as simple as FileUtils.write(configFile, configString), and copying the source code similarly also only took one line. #2a and #3 check.

I haven’t yet touched Scala’s process capabilities either. Scala 2.9.0 has a new process library taken from Akka, but I’m still running 2.8.0 so I just went with java.lang.Process. My original attempts revolved around Runtime.getRuntime().exec(""), but exec seemed unable to send arguments to the command (e.g. exec("java -version") won’t give you anything in the process.getInputStream). ProcessBuilder seemed to have better infrastructure so I looked at that instead; of particular interest was the redirectErrorStream(boolean) method, which helped me out a lot. It turns out that the reason I wasn’t getting any messages back from the Processes is because the programs I was testing outputted to the error stream instead of just the output stream. I probably should have considered that, but hindsight is 20/20. #2b check.

Generating index.html was threw me for a loop; since Scala has XML literals, I copied the HTML directly into the script. There is javascript code within the HTML, and javascript happens to use curly braces to denote map literals. Scala interpreted those curly braces to represent escape blocks. I ended up re-writing the map literal curly braces within the escape blocks, like so: var parameters = {"{ };"}. Again, hindsight steps in and says something like “You should’ve just written a raw string literal instead of using XML; then you wouldn’t be having this problem!”. But hindsight really enjoys telling you how much better HE could have done it. You can learn a lot from him but he sure acts like an ass sometimes :)

There’s a gotcha when writing Scala code to specify attributes. Curly braces will NOT be interpreted as a Scala escape block if it’s within quotes:

scala> val name = "Xiaohan Zhang"
name: java.lang.String = Xiaohan Zhang

scala> <object name="{name}"/>
res0: scala.xml.Elem = <object name="{name}"></object>
//Tautological attribute is a tautology. AND it's an attribute!

The way to do it is to just let Scala put in the quotation marks for you:

scala> <object name={name}/>
res1: scala.xml.Elem = <object name="Xiaohan Zhang"></object>

#4 check. Now, I didn’t expect the script to run the first time I fired it up; I was dealing with unfamiliar terrain and regardless, programming is very difficult to do right the first time. But the error I got completely caught me off guard:

IO error while decoding C:\Users\hellochar\Documents\dev\NetBeansIntelliJ\Daily\Script.scala with UTF-8
Please try specifying another one using the -encoding option

… What? Like most people, I haven’t really taken the time to learn about my encodings. I figured it was probably just some weird character in my index.html file that I copied over. Removing that code didn’t work. (Originally I tried just commenting it out but I realized that the problem was not in the logic of the code; it was in the compiler’s attempt to even READ my code).

But then I took out ALL of my code and tried running the program, and it still didn’t work.

I decided that my best route of action was to actually figure out WHAT the error code meant (my hindsight gave me a slightly condescending clap for this). Fortunately, I ran into this article very early on in my search. This is a blessing, because I really enjoy Joel’s writing. He reminds me of my high school physics teacher and FIRST robotics mentor; there’s a no-bullshit air about him and mixes in his ideologies with his teachings, which makes for both an interesting read and something to think about afterwards. The article was a prime example. After reading it I figured the problem probably lay in some weird character I was using within my code. I kind of just stared at this screen for a while:
Where are you hiding?
AND THERE IT WAS.
Getting closer...

Closer...

CLOSER!


FUCK

FUCK. YOU. MS WORD. The problem was that I had copied and pasted the description of what my script should do from Word, which put in those “smart” quotes. The particularly annoying thing is that UTF-8 supports those types of quotes (because it supports every character), but I guess MS Word uses a different encoding from the rest of the world. On the upside, it’s an easy fix; just copy the text into Notepad, “save as” in UTF-8 encoding, and then copy/paste the text into the script. You won’t notice any difference, except for that the code will actually run. The problem is that the scala spec requires you to only use a specific subset of Unicode to construct tokens (the smart quotes are not in that set). Originally I thought that the interpreter just ignored all characters inside a comment block, but then I realized that the interpreter wouldn’t be able to tell when the block ends. You just have to get rid of the character.

After I had the basics down, I tried to go a little further by attempting to extract the size of the applet from within the source code. e.g. I wanted to extract “800” and “600” from “size(800, 600);”. Regex combined with scala.io.Source class made this pretty straightforward:

val Size = """size\((\d+), (\d+)\);?""".r //trying to find size(400, 400);
val (width:String, height:String) = try { scala.io.Source.fromFile(sourceFile).getLines.map(_.trim).filterNot(_.startsWith("//")).find(_.startsWith("size(")) match {
  case Some(string) => string match { case Size(w, h) => (w, h) }
  } //nonmatching cases will throw matcherror and get catch-ed
} catch {
  case _ => ("900", "500") //default to that
}

I grab each line from the source file, take out the whitespace, get rid of comments (it won’t catch /**/ but that’s much too complicated for me to care about right now), and find the first line that starts with “size(“. If one exists, I try matching it against my size regex to extract the digits for width and height, respectively. If anything fails, just default to 900 by 500. I can then feed those numbers into the width and height parameters of index.html.

All in all, I’m pleased with the scripting aspect of Scala; the only downside is that the script takes a while to start up each time you want to run it.


Beware of the default implementations of Stackable Traits

I have been plagued with the strangest code problem tonight. One type of sketch I’ve been doing lately is interesting visuals with my name, similar to the title bar at http://roberthodgin.com/; if you visit my website you’ll see the first one I did. It makes sense to write a subclass of PApplet to hold common code related to this type of sketch. I’ve also fallen quite deeply in love with Scala’s stackable trait pattern, and it makes sense to make my subclass into a stackable trait, since the code mostly gave me convenience methods for creating an RShape out of my name (I…
scala> println(res3);
I have been plagued with the strangest code problem tonight. One type of sketch I’ve been doing lately is interesting visuals with my name, similar to the title bar at http://roberthodgin.com/; if you visit my website you’ll see the first one I did. It makes sense to write a subclass of PApplet to hold common code related to this type of sketch. I’ve also fallen quite deeply in love with Scala’s stackable trait pattern, and it makes sense to make my subclass into a stackable trait, since the code mostly gave me convenience methods for creating an RShape out of my name (I’m using geomerative in order to turn my name into a collection of shapes). The basic code goes like this:

trait NameApplet extends PApplet {
    ... //stuff

    abstract override def draw() {
      super.draw();
      ... //other stuff
    }

    ... //stuff other than the other stuff
}

Harmless enough, right? For those of you who don’t want to read the article, the basic idea behind the stackable trait is that I’ll create some concrete subclass and mix-in the NameApplet, e.g. class MySketch extends PApplet with NameApplet. The “abstract override” modifier for the draw method simply means that super will refer to the first concrete implementation of draw that comes before the mix-in, so calling “super.draw()” in this case will call PApplet’s draw method. That wasn’t the best explanation so you should probably just read the article :P. Anyways, I wanted a grid of particles whose size depended on how close they were to my name, so today’s sketch mixed in NameApplet. (I actually extended NameApplet, since I had no other mixins so super was bound to PApplet anyways).

object Jun30 extends NameApplet {
...
    override def draw() {
       ...
       super.draw(); //I call super.draw in order to get the "other stuff"
    }
...
}

(Tangent: as I learned very recently, it’s actually an awful idea to declare a Scala object that is a subclass of Applet since nothing will be able to instantiate it, meaning you can’t put it online)
After I had the basics down, I did a preliminary run to see what it looked like. My draw() method ran ONCE, and then everything stopped. I put in debugs to no avail; it looked like everything ran fine for exactly one frame, and then just decided to stop. It was very frustrating to debug something so seemingly straightforward. (But we’ve all been there, right?)

Long story short, I discovered that the call to super.draw() in Jun30 was causing the problem. At this point the “other stuff” in NameApplet’s draw() was a single if statement that always evaluated to false, so the problem must’ve been the call to super.draw() in NameApplet’s draw method. Taking a look at the source code for PApplet, the default implementation of the draw method was indeed the culprit:

public void draw() {
    // if no draw method, then shut things down
    //System.out.println("no draw method, goodbye");
    finished = true;
  }

FFFUUUUUUU

In retrospect, this is something I should’ve checked at the very beginning. The default draw method stops the applet so as to allow for Basic Mode in the PDE. Of course, I wasn’t thinking about the PApplet implementation of draw() when writing NameApplet’s draw(). But if we learn from anything, it’s going to be our mistakes and frustrations. I’m certainly going to think about what super.xxxx is doing when writing stackable traits from now on.

P.S. Sorry for being gone these past few days; I’ll try to post daily and hopefully put up some finished sketches w/ source code on xzhang.no-ip.org soon.