Release 0.2

My release 0.2 is complete! I have been working hard on adding and changing code in the Processing.js library for my open source class. Here are some scripts I wrote which demonstrate that the functions I have written work:

PJS Crayon Physics 0.1


0.2 Deliverables


I found that Processing 1.0.8 sorts strings using a case insensitive search while 1.0.9 uses a case sensitive search. I have made this function mimic 1.0.9. I ended up having to throw away a bunch of code which compensated for this. If however I turn out to be wrong (1.0.9 has a bug?) I have the code ready to re-integrate.


The only limitation of this function is the user needs to specify how many bits they want back when passing in a byte primitive. This is because JavaScript does not differentiate between bytes and ints, JavaScript simply has a number type. Because I’m finding this problem in multiple places, I believe the best place to solve this would be in the JavaScript parser itself. However when passing in a char, int or color, there doesn’t seem to be a problem.


I simply modified this function to include an extra static variable parameter, OPENGL. If this is passed in as the third argument, a 3D context will be acquired instead of 2D. I also had to modify bits and pieces of the library to make this work such as changing redraw(), init(), etc. I ran some 2D demos which are present in the Processing.js git repository and I don’t believe I broke anything.


I have two concerns with this function. The first is related to the same problem experienced with binary(). If a hex value is passed into this function background(0x0000FF);, it will create problems. In this case the user wants to set the background color to blue, however by the time the script is parsed, the value has turned to 255 which will be misinterpreted as white. Again to fix this problem, the parser may need to be changed.


Ah yes. I had fun making this variable available since Processing defines a frameRate() function. This obviously creates variable naming issues. I threw in a regular expression to change anything which does not resemble a call to frameRate, such as an assignment to FRAME_RATE. I tested my regular expression well, however there may be a case where it could fail. If this happens, I will update for the next release

For 0.3

I plan to implement the following features:

  • lights()
  • noLights()
  • pointLight()
  • ambientLight()
  • directionalLight()

Merging C3DL into PJS

A few days ago I took my first steps in placing 3D functionality in the Processing.js library. It was confusing and awkward and it led to a demo which is anything but pretty. Not only is the output a joke, the code is quite crude. Regardless, I decided to write a blog post about my small success. As my professor Dave stated I “was brave” in posting it. Looking at it now, I’m very surprise I did, but I guess I get points in releasing early and often. As the blog’s title suggests, it was a bit like force-feeding the Processing.js library C3DL. It was terribly messy, albeit I did succeed. Of course my success lured me to my next challenge: The cube couldn’t move and couldn’t be lit.

After spending some quality debugging time, I did manage to fix those bugs. Here, I can prove it with a JPEG! Without getting into boring technicalities, I’ll just say I needed to make sure the cube model was preloaded before it was instantiated. You’ll have to trust me. The JavaScript evolved to something less messy and a bit more pleasant. It was more like Injecting one library into another. I was getting closer to what I wanted.

So I had both libraries playing nice, but my next problem was packaging this properly so it could be useful to others. I needed to create some sort of architecture which would allow anyone else trying to throw 3D into Processing.js a head start. They could focus on higher level problems rather than diving into WebGL intricacies. I cut out some code, added some code, threw in some comments and made a page with minimal (but existent!) instructions. Chris Tyler helped me minimize the C3DL library so running the demo was slightly faster. The code is getting better. Good enough for me to refer to it as merging one library into another. Harmony is yet to be achieved, don’t worry I’m getting there. : )

Anyway, the files are now up. The screenshot I posted in the beginning of this blog was taken from the running demo. Because C3DL uses WebGL, you’ll need to use Minefield to run the demo. Firefox <3.5 won’t cut it. You can also download the zip with everything packaged up.

Why did I decide to release the code now? It was mostly because I didn’t see the code as Web worthy. Frankly, I see it still as barely Web worthy, but it will have to do for now. The demo has some issues listed on the page in which it renders. I suppose you can decide if it is useful to you or not. If anything I’ll blame the mantra Dave an Chris keep trying to instill: “Release early, release often”.

So, the demo hijacks the Processing.js library since it implicitly places a cube in the scene. How can this useful? Well, my fellow students in the open source course at Seneca College (Yeah, this is a credited course!) can play around with it and see how things are implemented in C3DL then adapt those methods for PJS. They can take a peek into the vertex shaders, the matrix stack, cameras and all sorts of other 3D stuff.

I’m going to keep working on this ‘architecture’, but I’ll shift my focus onto my 0.2 release for my course since it’s due in a couple of days. What I’ll need to do is start removing all the C3DL which will leave me with only WebGL calls for size(), background(), frameRate and similar functions. They aren’t really 3D functions, but still this involves quite a bit of work, I may lose some sleep. But that’s okay, I have a nice proverb posted above my monitor: “Sleep when you die”.

I’d like to thank Cathy and Dave for convincing a silly student to get 3D working in Processing.js the easy way rather than starting from scratch, which I was tempted to do. I believe they saved me a lot of time. Don’t forget: “Good programmers know what to write. Great ones know what to rewrite (and reuse).”

Force-feeding PJS C3DL

Snapshot 2009-11-15 23-40-25
Force-feeding Processing.js C3DL wasn’t so bad, but I did have to play around with the libraries, and I ended up having to write some hacky code to get it done. If you look at the screenshot, you’ll see some hard-coded lines here and there. But it’s working so far! What’s working? Well, what I’m doing is converting this Processing.js line an artist or developer would write:size(400,400,OPENGL);
using this bit of wacky JavaScript.
aCode = aCode.replace(/size\s*\(\s*(\d+)\s*,\s*(\d+)\s*,\s*OPENGL\s*\)\s*;/,"size($1,$2,\"OPENGL\");");
I need to do this because when the user writes OPENGL, it’s not defined! This will cause a JavaScript error. So I convert OPENGL to a string and check the size() function (left window in screenshot) in the Processing.js library. If the user wanted to use OpenGL, I create a 3D context using WebGL with the help of C3DL. The result here is an untextured, unlit, static cube. Pretty boring.But I’m making a 3D context within Processing.js! My next step is to start making some Processing.js functions work with 3D content, maybe setting the background color or similar tasks. Dibs!

Unlearning JavaScript

This week in my DPS909 class, I was required to watch a video: “JavaScript: The Good Parts” presented by Douglas Crockford. His presentation is based on his book by the same title. If you’re starting to learn JavaScript, I urge you to watch it before you get yourself in a mess.

On the Shoes of Giants

Before I get into a little analysis of the presentation I’d like to share a short anecdote about my own interesting experience with JavaScript. About a month ago, I filed a bug in Bugzilla. My build of Minefield was and is having problems when I try to use instanceof on objects which are in a namespace. This problem gave me hell. I had to circumvent it by having my objects return IDs just to check their types. I didn’t think much of my bug until some guy actually replied. I was a bit surprised because most of the bugs I post are ignored because they probably aren’t bugs. It’s just me making mistakes. I was curious who this guy was, so I fired up a search. “Brendan Eich is a computer programmer ..”, uh-huh “..and creator of the JavaScript programming language.” …oh. So the fact that he was nice enough to reply to some lamer’s bug and because he’s a genius somewhat prevents me from slandering JavaScript. So I’ll keep my yucky JS comments to myself.

Thoughts and Surprises

The most important thing I learned is that JavaScript is hugely misunderstood. Not only in the language syntax, but it is often blamed for problems in the DOM or the IEEE floating point standard. For example:

0.1 + 0.2 == 0.3; // is false!

I actually went to check this myself just to be sure. Seems like JavaScript is a bit of scapegoat people like to attack (including myself). JavaScript isn’t perfect, no language is. However, I completely agree with Douglas when he says the language has good parts. I’m still easing my way into it. For a long time I held my strictly-typed languages close. But I’m slowly getting used to letting those go when I fire up Firefox.

I’m glad Dave decided to give us a lesson in closures. It’s something I was having difficultly grasping from a book. Now that I’m understanding the concept, I feel like I’m falling in love. That’s a great feeling. Finding a feature in a language that reminds you why you first started learning programming in the first place.

Another aspect I learned was that JavaScript has some of its roots from Scheme. When I first started learning Scheme scripting in GIMP in my GAM672 class, I felt like I was being force-fed this crazy language. Maybe once I get a better understanding of JavaScript, I can revisit Scheme. Maybe it isn’t so bad.

There are many features of the language which I just can’t understand why they would be present. Here’s an example.

'' == '0'  // false
0 == ''    // true
0 == '0'   // true
false == 'false'   // false
false == '0'       // true
false == undefined // false
false == null      // false
null == undefined  // true

This terrifies me. Should I post this on my wall so I don’t have to learn it? Or on my fridge while I have breakfast so I have it memorized? Well, maybe I don’t have to do either. Douglas insists JavaScript developers should stick to using the triple equals operator (===) which does not do type coercion. I think Douglas knows what he’s talking about. I’ll trust him and start using it everywhere I can. It’s should be easy enough to get in the habit of doing.

Other thoughts

I’m looking forward to trying out some ES3.1 features like object hardening. It definitely sounds like a good idea. I also realize I’ll need to do some unlearning as I play with the language, such as not using (==).

0100 0010?

I need to write the binary function for the Processing.js library for my DPS909 class. I first took on the task simply because I needed some ‘filler’ functions. I wanted to code something small and fun on the side of my larger tasks which for my second assignment include implementing ambient light and directional lights in the library. The problem is binary turned out to be not so easy to implement and I have already written about it once. I got some help from Al and my professor, Dave, yet I’m still having difficulty. I’m at the point where I need some serious help.

Polya Problems

All developers do day-in and day-out is solve problems. We take on large, complex challenges with reassuring nods. “Of course I can do that.” As soon as we get back to our desks, we hope it’s technically possible and pray we can learn it in time. Sometimes the problem is small, in which case we follow all the problem solving steps automatically. Identify the problem, create possible solutions, blah, blah, blah. We don’t even have to think about it, it just happens automatically. And of course sometimes we hit a wall. That’s what I’ve done. I’m so hopelessly lost I actually need to sit down and draw out this problem step-by-step to get a firm handle of the situation. So here I present the steps I haven’t written out since high school.

Define the Problem

Here goes. The Processing.js library is a JavaScript port of the Java-based Processing library written by Casey Reas and Ben Fry. There are a bunch of us in the OSD600 and DPS909 classes at Seneca porting the language to JavaScript. There are also a slew of sketches which Ben Fry and Casey Reas have written which must work identically between the two libraries. Otherwise the sketches won’t be portable. So all the 20 tests I wrote in the Processing PDE for binary() have to return the same results even if they are run from a JS propelled HTML file. Here is the binary signature:

String binary(toConvert, numDigits);

This little guy gives me insomnia. It can either take an byte (8bits), char(16bits), int(32bits) or color(32bits). Depending on the type used, a different amount of bits will be returned in the form of a String. For byte, it will always be 8, for int it will vary depending on the value. For example

binary(5); //returns "101".

If the user wants the padding bits, they can just call:

binary(5,32); //00000000000000000000000000000101

Now Java is a typed language. Ben and Casey have simply overloaded binary() for all the types that can be passed in. However, JavaScript is typeless. John Resig started the Processing.js project and looking at his code, what he does is this: when he parses an artist’s or developer’s sketch, he simply finds an int or byte and converts to a JavaScript Number. I think. I’m still trying to find my way around these wacky regular expressions.

So the problem is this: when the user calls my binary function, I have no way of knowing how to distinguish between a byte and an int. For example when calling typeof on different arguments, this is what I get:

color => object
int => number
char => number
byte => number

Now, I may be able to do some tricks to single out the char, but it’s the int and byte that’s causing me grief. Okay, there is the problem: When my function is called, I have no way to determine what type was used to declare the variable that was passed to my function, thus I don’t know how many bits my return string should contain.

Brainstorming 101

Now, let’s take a look at possible solutions. Of course, brainstorming has no filter, so every idea is considered. Who knows, it could lead to another avenue which could hold a solution.

Drop the course. Haha, I’m just joking. I’m here to learn, right?

Give up. Yeah, I thought about it a bunch of times. Walk away from the problem and watch my course mark get slashed. This is just a last resort. Hopefully it won’t be necessary.

Assign it to someone else. My class if full of smart developers, I’m sure some of them could solve this faster than I can. I may even be able to get someone online to do it for me for free (please?).

Rent-A-Coder? Nay, I’m still a student. I like to keep my money where I can see it, which is in my wallet.

Break the binary() standard . Regardless of what’s passed in, always return a 32-bit String object unless the user asks for less. This goes against what binary is supposed to do of course. Once I have that working (c’mon it took half an hour with JavaScript’s bit shifting operators), I can try to fix it for 0.3.

Break the binary() standard another way. Force the user to enter in the number of bits to return. Does this ever sound sweet. The function would still be testable and prove it is working like it should except for the argument list. I could then later figure out the finer details of how to get the type and remove the unnecessary argument.

Postpone to 0.3. I can always take on something else for 0.2 and come back to this horrible, horrible function for 0.3. However, I would be very careful about my selection this time.

Do some crazy regex. Al suggested a piece of regex. But since the parsing code runs over all the Processing.js code first and converts it to JS, I won’t have access to how the variables were defined anymore (byte, int, char).

Play with variable names. Dave suggested I could parse the user’s variable names and include meta data. so int i = 6; would become int i_32 = 6; I looked into this, but I’m not sure it can work. I know some languages let you get the name of the variable itself, but I’m not sure if this can be done in JavaScript. And if it can, don’t I only have access to my local variable?

Create some meta table. Generate a table on startup and everytime a user creates a variable, throw in the reference and some meta data about that variable. Sounds like a lot of work. It could also break a lot of other library code. What if the references change? What about locals? What about casts?

Convert ‘primitives’ to objects. If I created Int, Char and Byte objects whenever a user declares int, char or byte, I could put in as much meta data I want and I could later query that within binary(). Unfortunately this will also require modifying most of the other functions already in the library.

Making a Commitment

Now is the time to pick a solution from this crappy list. I guess I should choose the one that sucks the least. But I also don’t want to start down one path, then hit another wall. I want to be sure the solution will work. Unless I hear otherwise, I’m going to force the user to supply the type/size. Once I know my function is working with the training wheel argument and I have time left over before my 0.2 submission, I’ll take another crack and this. Rest assured, I’m not at all happy with my selection, but it doesn’t look like I have much choice. Unless of course you can offer a better solution. I’m also running out of time and I know putting 3D and lights into the library will be exponentially more difficult than this. Or will it be easy? I have no idea, I’m just a developer.