Standing On Their Shoulders: A Short Processing.js Tale

So this semester's reading week has come and gone and once again, as is the familiar post-mortem assessment, I have discovered the ratio of “useful" to “superfluous" work done is heavily biased toward the latter.

On the Processing.js (Pjs) front we have more baby steps!

Don't mind if I do...

For pushStyle() and popStyle() I've come full circle. First I fiddled around with storing and retrieving variables in the library, then I moved onto storing and retrieving canvas variables, and have since returned to working on the Pjs library variables.

In my previous post, I discovered some code by Andrew Peace. As it turns out, not only did Peace's work handle the Pjs variables, he also did it in a more JavaScript savvy way then I would have done.

The example that sticks out in my mind was his handling of arrays. While I was busy incrementing and decrementing a counter to figure out how many states I had and which element to store and retrieve from, Peace simply used the push() and pop() functions that grace all JavaScript arrays.

I have incorporated Peace's code with only cosmetic changes, and JavaScript's push() and pop() functions for arrays has since entered my corpus of All Knowledge. My hat off to Mr. Peace!

But does it work?

In my previous post I also intimated that some work was going on with boolean(). There was some code but no testing. In the last little bit I've started cobbling together a few test cases, and even thought still incomplete they've already helped flush out a few bugs.

The nice test page layout was provided by classmate Daniel Hodgin. Thanks!

DPS909 Project - Processing.js – v0.1

Last month on [insert name of media production here]...

First, a brief recap. This semester at Seneca College I am taking a course revolving around open source development. As part of the course the students (yours truly being no exception) were nudged into getting involved in some Mozilla related projects, produce code for the real world, and see fist hand how the whole open source thing works.

I chose to work on Processing.js (Pjs), a JavaScript port of the Java-based Processing. More specifically, I volunteered to work on porting over the functions pushStyle(), popStyle(), and boolean().

I've got to release something...!

Today I get to make my first (course mandated) release! And this is what it does (trotting out this little “demo" for the third time):




What's that? That, fine feathered friends, is pushStyle() and popStyle() working just a little bit. Nothing particularly amazing, it's just the Processing example copied verbatim.

A start on the boolean() code is also in the release, but it's not tested at all.

For those of you who want to see for yourself may:

• Download the full Pjs library (my patched version)
OR

• Download just the patch

Toward 0.2

The march to enlightenment continues, and there is still much to do. The implementation of pushStyle() and popStyle() remains incomplete as demonstrated by this discussion on the Pjs Google Group. So far I have only saved the state of canvas variables, and not those in the library itself.

Then I need to see about putting through a more expansive test regimen. And there's already a bug: using Andrew Peace's test case, the “more pops than pushes" error alert just keep popping up. I like to think the intended behaviour is for a finite number of warnings.

On the other hand, boolean() seems much more straight forward to test.

A not-so-secret society

v0.1 releases just in time for this years Free Software and Open Source Symposium hosted by Seneca College. This is particularly important because Al MacDonald, Pjs project leader, is attending FSOSS and will no doubt want to have a few words with those DPS909 students working on Pjs.

David Humphrey suggested us students might want to look into setting up a Pjs bug tracker, discuss ways to compile our seperate test suites into one big suite, and perhaps set up a website to showcase the newly ported capabilities. I figure even if I somehow manage to get my project done way ahead of schedule there will not be a lack of things to do.

Fixing a Bug In A Harmless Test Environment

This week's DPS909 lab brought together everything covered thus far in the course: build the software, file a bug, find the offending code, make a patch. If this were any other course this lab might qualify as a "quest": not a quiz, not a test, but somewhere delightfully in between!

Step one was compiling a debug build of Thunderbird/Shredder. I checked out straight from the repo rather than use the code provided by the lab instructions. The process was similar to building Firefox/Minefield and went off literally without a hitch. A very palpable hit for me!

Nest was to confirm the bug's existence. The bug we were interested in deals with Thunderbird converting a string that looks like an email address into a hyperlink; the problem is the string does not represent a valid email address and so should not be converted. We can see the fubared behaviour below:


So having confirmed the existence of the bug without difficulty, bug #7243 was filed in the landfill. I like to think I included the bare-bones information in the description answering the questions of: "what is wrong?", "how may it be reproduced?", and "what version of the software are you using?".

Now came the matter of tracking down that needing futzing with. This took a while. I spent much time plopping in search terms into the Mozilla Cross-Reference without success. I looked into "parse message", "save draft", and the like to try and get into where the message was stored and perhaps displayed to the screen.

In desperation I went back to the program and, mousing over the offending email link, saw it was a mailto link. So I through in mailto as the search term and... there was light. (Just goes to show simplicity is golden.) Conveniently the very first result from that search took me exactly where I needed to go.

if (inString.FindChar('.', pos) != kNotFound)

The conditional only checked if a "." was found after the @ sign. What it also needed to do was check if there were any ".." after the @ too, which would mean it was not a valid address. Some way needed to be found to find whether a ".." was in the string. Unlike what was currently in mozTXTToHTMLConv.cpp I needed a way to check the presence of a string in the string, and not just a char in the string. According to the Mozilla internal string guide the correct way to find if a substring existed was to useFindInReadable in nsScannerString.cpp, However converting the code to use the newer approved way was probably a bit beyond what I wanted to delve into for this lab.

So I just stuck with the old way. Searching through the documentation some more I found nsDependentString had just the function I needed. The code mozTXTToHTMLConv changed to:

if (inString.FindChar('.', pos) != kNotFound && inString.Find("..", pos) == kNotFound)

A recompile later the situation was much improved:


I created the patch from ./comm-central/mozilla and ran it through JST Review. A few "longer than 80 characters" and extra whitespace/tabs warnings later, it was ready to be attached to the bug report.

Ehren graciously took some time to review the patch and found I had indented a line a bit too far. It was up to a patched patch to pass muster instead.

The tool-tips for the review options for attachments threw me off a bit. Super-reviews are only needed for world-shaking changes, but the super-review tool-tip says something somewhat different. I didn't request a super-review for the revised patch.

The patch and review comments have been copied to my Seneca College wiki page.

boolean() for Processing.js

And so we return for another (short) post in the irregular series on “What is Matthew doing with Processing.js?" Ah, the joys of lagging a bit behind from where where I should be. But onwards to putting a little bit more on my plate!

Seeking truth From variables

There is a spectre haunting the incompleteness of Processing.js (Pjs) (well, one of many spectres) - the spectre of boolean(). It is a spectre I hope to, at least, partially exorcise by December.

This little function takes a variable, may it be integer, String, object, or an array thereof, and spits out “true" of “false" (or even an array of such). A little peeking into the original Java code shows that the function is actually spread over five overloaded Java methods in class PApplet.

Of course, it will all have to be condensed into a single function in Pjs. Since it doesn't seem JavaScript requires the explicit declaration of data types, I'll have to search around to see how one might go about distinguishing between them. However I expect there will be plenty of examples to sink my teeth into. (I can't be the first person to ask: “How do I tell if a variable is an array?" after all!)

The project page has been given a minor revision to reflect the new bit on the plate. I really must get around to jotting down some documentation on my latest work with pushStyle() and popStyle(). See? Lagging behind.

Speaking of which...

In my previous post I displayed a basic working example for pushStyle() and popStyle(). Alas, I hosted the JavaScript library on a temperamental web host so it can't be seen half the time.

I redisplay the example here using (hopefully) a more reliable web host.



But where has the time gone? Release version 0.1 is just around the corner, and there is still things to ponder and code to crunch! I guess it would not be a student's life if one did not feel kinship to the tardy White Rabbit.

According to the Plan

… this shouldn't be happening.

In a previous post outlining my DPS909Processing.js (Pjs) project plan, I sketched out the implementation of pushStyle() and popStyle() over a period of over two months. As it turns out this may have been overly pessimistic.

Climbing the Stairs

In the beginning, the scheme called for storing and retrieving states from a nice 2D array. I opted for an object to store each state snapshot.I peeked into the Java Processing code (PStyle.java) to see what sort of variables I might be looking for. The variables listed under the comment // “Private" variables used to maintain state seemed like a good place to start.

Throwing the code into a test page, let's just say those were not, or not all, the variables I was looking for.

Finding the Elevator

Closer examination revealed a mysterious object stored as curContext, and it seemed the object's squishy innards contained what I was looking for. Since those innards didn't seem to be defined in the Pjs library I turned to Google, and that turned up the canvas element documentation.

As it turns out canvas comes fully equipped with functions to save and retrieve state snapshots. So using those functions instead of the array, and state-saving objects, we get something like:



Assuming one's browser comes with the requisite bells and whistles, it should look suspiciously similar to the Processing example.

Expanding the Catch

In terms of getting pushStyle() and popStyle() to work, there are a few things I still need to look into. In my current revision I am not handling any of the library's own variables at all. The basic example works without them but, but some may be relevant state variables and I have to figure out which ones (if any) are so.

Another concern is browser compatibility. Canvas implementation seems to be all across the board right now. If Pjs has to work now, without reservations, then I'll have to go back to the state-saving object and array scheme, while saving all of the canvas variables manually. On the other hand, if the onus is not on Pjs to work on browser's with incomplete canvas implementations, then that's one less thing to worry about.

But the bottom line is that the project as I envisioned it will most likely be done long before early December. This is not acceptable for DPS909 and therefore I must find additional bits of Pjs to hack away at. I'll be figuring that out soonish and changing altering my wiki project page to reflect that.