Skip to content

OSD600 so far

January 24, 2011

Well after Thursdays class, Humph told us to choose a bug from both processing.js and popcorn.js and solve them as our intro into open source.  So on thursday night i figured I would give the processing.js one a shot (here).  I had an idea of what the bug was describing so I downloaded the html file the guy who posted the bug had up and then downloaded processing.js from the processing website.  After looking over the processing code a bit I figured I should go back to the processing website and read some of the descriptions on the functions, especially the fill() function as thats what the supposed bug had to do with.  After reading the description on how to use the function and looking at the html file the guy posted, it seemed he was using quotations around the hex values he was passing as parameters to the fill function.  Once I realized this and tested it a bit on my own, I informed Daniel and he confirmed that what I said was the issue.  He later marked it as invalid and suggested I choose another bug to work on.  Awesome.

 

After not really feeling like that was much of a challenge as I really didn’t do anything, I figured I’d choose a bug about something in which I had no idea on how to solve.  I found writing a function that converts a character in a string into a unicode value and returns that value as a string.  I read it, had no idea what so ever on how to do it, and figured I’d give it a shot (here).  From what I read, and what Pomax(the poster of the bug) said, apparently when java was developed they were under the impression that 16 bits would be enough to cover every character in every language throughout the world, but as it turns out, they were wrong.  One of the example characters that Pomax posted for example was 21 bits, which is definitely out of the default 16 bit range.  I figured the best course of action for this bug was to take a look at the Java version of the function and test it out.  After running a few tests in java and reading about how the method worked, I wondered if someone, somewhere, had already created a program that did something similar in javascript.  After searching the internet for a while I stumbled across a fix that mozilla had actually posted.  I came across it by searching up a similar function called charCodeAt() which returned the unicode value for a character that was <= 16 bits(im guessing here) .  After reading through the function definition there was actually a code snippet for a fix for multilingual characters.  I thought id give it a shot.  After changing it around a bit (making the function a prototype of the string class so you could do something like string.codePointAt(position);) , I made a small test to see if it would output the same unicode value as what pomax posted in the thread of the bug.  To my surprise, it actually worked!  I was surprised to say the least!

 

Today humph told me to create a patch and install github and run some tests (all of which I had no idea how to do at the time).  So far I’ve installed github(which looks awesome), forked the processing.js repo to mine, and started reading a bit on how github commands and such work.  As its 12:37am right now and I have an 8am class, I figured its best to call it quits for today and tackle everything tomorrow.

 

P.S.  – Thanks to dhodgin and Lennon on irc, you guys helped me a ton in figuring out how to get github working!

Advertisements

From → school

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: