Processing.js – String::equals() (or: how I filled something in on the way)

Pothole? What pothole?

Open source development is like driving on a road with potholes where every driver also happens to be a road worker. One day you may just get fed up with driving over the same crater over and over again and decide to do something about it in the most direct way possible: stop the car, get out, and fill it in yourself.

Of course, some holes get away for a while because they're just not that bad, or too deep. Other's scream for immediate rectification. Like the maws that open up suddenly and force you to slam on the breaks less you go careening into the deeps of the Earth. Or the holes just big enough to swallow a wheel and bring the scheduled excursion to a halt.

Well, on the way to giving nf() a nudge I discovered one of those wheel eaters. Like Java, Processing uses an equals() method to compare two Strings. JavaScript gets away with just ==, and for the past while Processing.js (Pjs) has done without equals() and used just ==. This was all well and good... until I started writing tests for nf().

The nf() tests compare the String result of nf() and an expected String result. Depending or not the two Strings are the same the output's colour changes. To ensure the code used for the test in the Processing Development Environment and in Pjs were the same I needed equals(). (Mind you, I could have used == in Pjs, equals() in Processing, and get the same output, but that would have been cheating.)

So with that short story aside, I present a quick and dirty String::equals() for Pjs. May this hole never become deeper.

How the road looks now

So here's how it looks in Pjs. (Again, we'll have to make due with a link. Minifying the code for insertion into the post didn't work out to well.) This example is extended from the Processing example.

And here's how the same code looks like in Processing:



Links

• Lighthouse ticket #246 "str1".equals("str2") function
  
• GitHub commit

Processing.js – Improving min() and max()

And another brick

So here's another little improvement for Processing.js.

In Processing, the min() and max() functions may take 2 or 3 numeric arguments, or one argument if its an array of numbers. For a while the Pjs implementation could only take two arguments. I have since taken it in hand and the Pjs implementation should now be able to do what the Processing implementation can do.

Well, not exactly. In fact, the Pjs implementation will happily take a great many more numeric arguments than just three. It'll even take one number in a pinch. Passing in non-numeric arguments, aside from a single array, will cause "undefined" to be returned. Trying to be clever and pass in an array as one of two or more arguments will also return "undefined". In Processing these "undefines" would be "thrown exceptions".

My eyes!

This will be another post where I'll provide links to the Pjs tests and comparison Processing images.

Basic Processing example for min() in Pjs, and how it looks in Processing:



Basic Processing example for max() Pjs, and how it looks in Processing:



3 and 4 numeric arguments, and argument type discrimination, for min() in Pjs, and how it looks in Processing. Note that only three arguments is tested in Processing since the rest cause exceptions.



3 and 4 numeric arguments, and argument type discrimination, for max() in Pjs, and how it looks in Processing. Note that only three arguments is tested in Processing since the rest cause exceptions.



For the tests I had to pull a patch or two fixing Ticket #57 Boolean array bug.

Links

• Lighthouse ticket #185 The min() and max() functions effectively take only two arguments
• GitHub commit

DPS911 Project – Processing.js – v0.4

A bit of touching up
So here we are: the first release for DPS911 this semester! For this release I've added missing functionality to Processing.js's (Pjs) implementation of text(). Unlike before, the function may now handle the printing of variable of integers, floats, doubles, and bytes, in addition to strings.

Now I wait for a (hopefully) favourable peer review.

Pretty pictures
Here we see a live demo of how it works in Pjs now as shown on this page:



And here we see the same demo as displayed in the Processing Development Environment:


What are we looking at?
The Pjs implementation had to take a few things into account. Processing displays floats and doubles to the thousandths digit, which is easy enough to replicate in JavaScript using toFixed(). But notice how Processing rounds: for 2.7185 it rounds down to 2.718 instead of up to 2.719.

toFixed(), by itself, rounds 2.7185 to 2.719, so a little bit of extra code was needed to alter this, like so:

if ( (val*1000) - Math.floor( val * 1000 ) == 0.5 ) {
  val = val - 0.0001;
}
val = val.toFixed(3);

So for 2.7185 we craftily modify it to 2.7184 before sending it to toFixed().

Pertinent links

• Lighthouse ticket (with patch)
• GitHub repo commit where it comes together

Thoughts on the Proper Care and Feeding of Git Repos on GitHub

The nature of the problem

Last semester I and the other students working on Processing.js (Pjs) started using GitHub. We all made our own branch of the Pjs trunk repo and started hacking away. Over time we committed to our branches and some of our improvements went into trunk.

But our very success started to have some unintended consequences. Trunk advanced but our branches did not gain the improvements merged into trunk. This made our antiquated branches increasingly poor bases to produce patches for trunk. Needless to say, this inconvenience was not appreciated by anybody.

After a bit of experimentation I managed to find a way to keep my branch up to date without deleting it and starting fresh. Mickael Medel (aSydik), one of my classmates, has requested I spread the joy and blog about what I did. So here it is.

Fractional-reserve coding

In five easy steps most, if not all, problems, may be averted.

Step 1 – Pull from trunk to the branch on your local system

Before making any changes locally make sure you have the latest version of trunk. Pulling from trunk every time it changes isn't such a bad idea: it's much easier for Git to automatically merge code when the difference is small or simple. If the difference is too complex Git may cry "conflict!" and make you sort out the mess. Not good.

For us monkeys working on Pjs, I believe the pertinent pull command is:

git pull git://github.com/jeresig/processing-js.git master

Now, if you have more than one development system (as I do: desktop at home, and laptop) you may need to pull from your own repo instead of trunk. In that case the pertinent command is something like:

git pull git@github.com:yourusername/processing-js.git master

Step 2 – Hack on your local branch

So now have a totally updated version on your local system and the time has come for you to work your magic. Hack, surf, and make merry!

Step 3 – Commit on your local branch

After many hours of fruitful hacking you look out the window and the sun has been suspiciously replaced by the moon. It's time to call it a morning and push things back to your GitHub repo. But wait! Remember to commit the changes first, otherwise you'll have nothing to push.

I guess that Step 2 and 3 are just reminders, right?

Step 4 – Push your local commits to your online repo

Now comes the culmination of your efforts, fuelled by countless grams of caffeine and other tasty goodies: the big push. At this point you need to update your online repo to match the local repo. Not to hard, just plug in something that looks like this:

git push git+ssh://git@github.com/yourusername/processing-js.git

If all goes well the local commits will flood across cyberspace, and you shall know balance and harmony...

Step 5 – Back to Step 1

… for a little while. When you're ready to go at it again, collect your $200 and sally back to Step 1.

Opposites attract, but sometimes we wish they wouldn't

The above works very well if your branch is kept up to date. But if you're sitting on some really old revision chances are Git will be unable to do the merge in Step 1. It'll cry "conflict!" and you'll have to sort it out. By this I mean you'll need to do the merge manually (yes, lots of copying and pasting and what not.)

If the situation is really bad you may simply want to kill and remake your branch from scratch, keeping in mind to regularly update the resuscitated branch this time round.

If you slog through the manual merge, then commit changes to finish the merge. Committing will also tell Git the conflict has been resolved and you'll be back in business. At least, that's what I think happened when I resolved my first (and so far only) conflict.

Only now, at the end, do you understand.

I hope that was helpful for those in need.

I apologize to Mickael for the tardy post. He asked for this last Thursday and it took me a while to cobble this together. You see, I use an unholy combination of the command line and the EGit plugin for Eclipse to interface with GitHub so I wasn't quite sure what the exact commands were. I tested them with my latest commit to GitHub so I hope they work for everybody else.

Yes, I use Eclipse to hack Processing.js, but only because EGit appeals to my laziness. Otherwise I'd do what sane people do and use a "regular" text editor.

2010, DPS911, and more Processing.js!

The Times They Are a-Changin'
Last semester in 2009 (so long!) I wandered into DPS909 and busied myself porting some functions over from Processing to Processing.js (Pjs).
For more on what Pjs is about check out a previous ancient post.
In a fitting continuity of events , this semester in 2010 (hello!) I've wandered into DPS909's follow-on, DPS911 and will continue futzing around with Pjs. The work done for DPS909 were released as 0.1 to 0.3, so not surprisingly the work for DPS911 will be released as 0.4 to the big 1.0.

The Plan
For v0.4 to v1.0, I hope to port over some new functions in addition to fixing existing bugs. The prospective task list and timeline is given below:

• Release 0.4 – Jan. 22, 2010
  • Fix text() to accept non-String arguments.
• Release 0.5 – Feb. 5, 2010
  • Fix min() and max() to take more than two arguments each.
• Release 0.6 – Feb. 19, 2010
  • Port loadBytes().
• Release 0.7 – Mar. 13, 2010
  • Port normal().
• Release 0.8 – Mar. 27, 2010
  • Port printMatrix().
• Release 0.9 – Apr. 9, 2010
  • Port printCamera().
• Release 1.0 – Apr. 23, 2010
  • Padding for overruns and to give time to fix any bugs from releases 0.1 to 0.3 from DPS909.
  • If that happens not to be necessary, I'll just choose another function to port of bug to fix.

Obligatory List of Relevant Links

• Processing.js @ Lighthouse
• Processing.js @ zenit.senecac.on.ca
• My Processing.js Project Page @ zenit.senecac.on.ca
• My Processing.js repository @ GitHub