JavaScript is not Java

Just how deep does this rabbit hole go?

Make one to throw it away

The title of this blog becomes more and more true the more I work in open source, but if you don't know what the title means, let me describe to you something about open source before i tell you what it means.

Open source development differs from school, and I can only assume, propriety jobs like a bank because in open source, if something has been written before, why are you going to write it again? At school, you spend so much time writing code that has been written hundreds of times before, by hundreds of students before you, these assignments are possible, have been proven, and if they were not possible, and they asked you to do it, you would be pretty ticket off spending days trying to figure it out, and you would probably think you accomplished nothing, and wasted time. You are wrong. When you are working on something that has never been done before, you have to try different things, there is no one to tell you what works, only ideas, because no one has done it. You have to think for yourself, make decisions for yourself, and be prepared to be wrong most of the time, until you get it right. You can be wrong hundreds of times, but only be right once... per problem that is.

To "make one to throw it away" means, before you get code that is working, and doing what you want, you have to make one or more versions that fail. This isn't too bad when dealing with a couple hundred lines of code, but something like 8000+ well, that bring me to my next story.

I've been spending the last week, trying to figure out a way to remove the final with() function call from Processing.js. In order to remove the with() function call, I had to rewrite a lot of the code... 8000+ lines of code, which also meant I had to understand (more or less) 8000 lines of code. If you are curious, here is the source in all it's glory. When you "make one to throw it away", you have just written and thrown away 8000 lines of code... if you think that's a waste of time, you are again wrong. This was 8000 lines more educational for me than rewriting 500 lines. It's simple math, really.

lines written * rewrites = productivity score :P

Processing.js casting bug

I have been working on processing.js bug #625.

What's happening is there is some Java like code, that's being converted into JavaScript, so it can be run in a browser, and this bug deals with converting cast like syntax in java, into something usable in JavaScript.

JavaScript is typeless, what is important about this is the types between variables don't matter (for the most part) so when I create a variable of an int, I just create a variable, and make it an int, and if I need to know the type of the variable, I can check the type of what's in the variable, which would be an int. Looking at p5 append(), is what the cast is being used for in this bug.

"When using an array of objects, the data returned from the function must be cast to the object array's data type. For example: SomeClass[] items = (SomeClass[]) append(originalArray, element)."

In pjs, I don't think the cast is even needed, as append just returns an array, this is the pjs append code:

    p.append = function(array, element) {
      array[array.length] = element;
      return array;
    };

Maybe p5 (the Java version of processing) has append returning an array list, which would require the cast.

Either way, JavaScript does not need the cast.

I removed the cast in the example, and it works, but the problem still remains with parsing the cast, as it's valid code. In p5 the cast still needs to be handled by the parser, cannot just remove it. There is a way to do this currently in the parser, but it will only parse out classes inside a list.

One thing I could do is add "PVector" to the list of classes, which currently looks like this:

var classes = ["int", "float", "boolean", "String", "byte", "double", "long", "ArrayList"];

then in this code:

    // Remove Casting
    aCode = aCode.replace(new RegExp("\\((" + classes.join("|") + ")(\\[\\])*\\)", "g"), "");

It would find PVector, and remove the cast, without hurting anything else. Only problem I see in this is we'll have to add each and every pjs class to the list of classes, and if a new class is added to pjs, someone will have to remember to add the class to the list of classes. There must be a more dynamic way to accomplish this, which is what I want.

I thought about possibly parsing any instance of \(/w+\) and check that the match in w+ is "typeof Object" or something along those lines. Then I could remove the list of classes all together. Yes, I will try that. Thanks for the help blog.

Building Firefox on Fedora

Today I went to set up a working Firefox build environment ON Linux Fedora. It was actually easier than I first felt. When I would run into an error message, I would google it, and get an answer usually saying to add modifications in the config file to pass over, or to include, or change the version of various products.

Some of the problems:

• Something called necko-wifi was not compatible, researching it I found I could just disable it in the mozconfig file by appending a line "ac_add_options --disable-necko-wifi". Solved, next error!


• Something called maemo was causing an error message, and researching that I found a similar solution that didn't work, to append "ac_add_options --with-maemo-version=5", fixed, but this caused other issues.


• I then found out, I could do a search for the missing files Firefox was complaining about using Fedora's "yum search 'name of file'" looking for something that looked like what was missing, and then "yum install 'file you found'" and crossed my fingers, would sometimes take a couple hits and misses before it would build, but after that each and every error was solved in that manner, including maemo.

I have to say I'm liking Fedora a lot. I also found a neat trick using vim, where you can do ctrl-p while typing a word to finish it, or scroll through words kinda like auto-complete. Linux can pretty much do anything I would need now.