Planet CDOT

Check it out world — an on time release (although this blog post isn’t)!

There isn’t much new, but I plan to make up for it with some pretty cool stuff for 0.3.
So after the first release, the feedback I got suggested less UI, so that was what I tried to work towards in terms of achievement.

This release seems very scrawny in comparison to the amazing progress being accomplished by other students of my class, mainly the Processing.js crew. But check it out–here are some of the goals I have set up for my 0.3 milestone:

1. Code a function to disable next/prev button if current message is last/first
2. Code a function to allow seeing a short
3. Code a function to allow skipping spam using navigation
4. Test extension’s display flow on a netbook
5. Navigation buttons that look nice
6. Consult other netbook users and seek review on basic UI left available

This release point is the result of one four-hour and one three-hour sessions in my office, where all I need to test front end code between edits is a lightning quick firing up of Thunderbird. These two days of work resulted in a total of +7 -2 lines of code, but I find victory in the fact that that is 7 hours of material I don’t have to learn again. I moved forward from understanding how to add elements to nodes (in layman’s terms: to insert a new control with its own attributes and programmability into item groups used in the base code of Thunderbird) and got comfortable with a new set of different controls and attributes.
My first aim was to get rid of the top toolbar to free up a good chunk of vertical space for the message content portion, so my plan of attack was to ask if element removal is possible in the #extdev channel. I was hooked up with two attributes to choose from, removeelement and hidden.
Removeelement sounded like a bucket of fun, so I gave that a try on the whole mail-toolbox toolbox. That actually ended up being kinda volatile, as the fs window would no longer recognize any selected message, and simply show a blank white inner space. So I dug one level deeper into the node and removed the two toolbar elements individually, one at a time, and found that it was the top [File, Edit, View, etc...] that shouldn’t be removed. Ever.
But even with one toolbar taken down, it still doesn’t look seamless. So the out-in-the-open answer became hidden. mail-toolbox hidden=”true”, that is. Great success!

Next thing to do was add a Prev & Next button for navigating through emails with the mouse. It took me about almost two hours and several different placements to get the feng shui just right and make sure that they wouldn’t warp or displace themselves like this:

but the two young buttons seem satisfied in their new home behind a spacer. Their auto-fitting with the vertical space was fixed by simply removing the align=”end” attribute I put in. Now they just need funky arrow icons to express their adolescent creativity, and stuff.

Oh yeah and I fixed the minimum version of Thunderbird problem. I set it to 2.9.*, since it seems the safest bet any 3.0pre build.

Also along this road I tried some other attributes that ended up not being necessary, but still cool tools to understand. The first is observes, which I noticed was on a most of the toolbox items, and insertbefore/insertafter. observes is like a radio to a broadcast tower, a broadcaster, sending the signal to adhere to any changed default attributes in the broadcaster. There’s a better explanation here. And have a XUL element reference also for good measure.

And along this road a few more cool feature ideas popped into my head;
People might like to be able to see or know if the next or previous message is junk and would prefer to skip it.
Perhaps add an easy way to zoom the size of text, both in and out to accommodate many different display settings.
A drop down list of message folders (inbox, sent, deleted, etc), with folder change going to the latest non-junk message, but I’m not dead set on keeping this idea if testers don’t feel it necessary.

Will keep you updated.

I’m still working to finish up IO_Form,  just checking to make sure that everything is coded before I move on. I had a few problems trying to figure out how to call the functions correctly but I’ve gotten past that part right now.

I’m going to move over to the VEdit function as soon as I’ve finished.

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

qw(3D)

0.2 Deliverables

• I wrote this blog
• I updated my wiki page
• I committed and pushed my work to github
• I created a patch
• I wrote a test for sort()
• I wrote a test for binary()
• I wrote a demo for sort() and binary()
• I wrote a test for size() and background()
• I wrote demo for size(), background() and frameRate

sort()

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.

binary()

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.

size()

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.

background()

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(0×0000FF);, 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.

frameRate

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()

I’m having some problems with the SVN, all of a sudden, a file is missing!

It’s IO_Field.cpp I believe. It used to be there, and now it’s gone…

Edit : Problem solved, it was there after all…

Did I meet the requirements set in the project outline?

Yes, and no. Here is my target as stated in the project outline:

Data collected and entered using static analysis tool (related interfaces etc.)

After a few bugs (see below) I produced the static-analysis docs and test copied one to my user profile. However a problem with function pointers leaves some errors in the pages. (See the last bug) Until this last bug is resolved I will hold off on uploading the docs.

What was not accomplished?

Besides not having all the documentation for the static-analysis uploaded I had originally planed to write a little about using some of the functions in the external string classes. I will probably update my project outline 0.3 to have examples of the functions being used to have examples in the documentation. To me examples are the best things to have in documentation. I hope to accomplish this via an extension.

Bugs:

1. xpcom analysis Makefile produces error about “.deps”
2. xpcom analysis type-printer.js qualified member problem
3. xpcom analysis Makefile for external linkage
4. type-printer.js error with function pointer parameter

What does this release comprise of:

1. Even though it is quite broken I do have an example of the static-analysis docs
2. Bugs, some small some big.

As I stated in my revised .02 schedule, I am working on PImage. I have been playing around with it but unfortunately I haven’t been able to get the image on the screen. Here is a run down of PImage:

It is a JavaScript class that holds attributes of an image: it’s width, height, format, and an array of each pixel it is made up of. It also has methods like: get(), set(), loadPixels(), updatePixels(), save(), blend(), copy(), mask(), filter(), resize(). You can check out the Java reference to read more on PImage.

My firs task if the constructor. The constructor either excepts: 0 parameters, the height and width, the height and width and format, or an image.   I decided to tackle the constructor that accepts and image.  This seemed simple enough as the image being passed in already has the width, height, format, and pixel array. Now here is the hard part, how do you get the pixel array? From all of the references I have read I get the impression that before you can load any pixels, you first have to use the loadPixels() which actually takes the pixels on the screen and stores them in an array. From this perspective though, the image should already be displayed on the screen. So i am following these steps;

• load image using loadImage(“name.ext”) this returns a var img
• create PImage by passing it the var img created above
• display the image on the screen image(img,0,0)
• calling the PImage loadPixels()
• display the PImage on the screen

Unfortunately, I get nothing. I will let everyone know once its finally working though.

Well after much fussing about with porting a bug fix that was intended for Firefox in dealing with multi-touch scrolling issues into  Thunderbird, I resolved the process and now have 3 finger swipe scrolling.  In the end, the final fix was removing a shortcut of “Ci” that was used in Firefox code to represent “Components.interfaces”.

My patch is posted here, and a sample package of Thunderbird for Mac with my patch in place is here.

After an excellent introduction to components and their idl interfaces in class today, this fix was almost simple.  In turn, this got the function that a firefox developer came up with which was to scroll a window by synthesizing a mouse scroll event.

Previously I had found a way to isolate out the 3 different panes in the Thunderbird main window…. being:  Folder pane, Message thread pane, and the Message pane.  In the end this wasn’t necessary, but it may come in handy for other custom actions.

Currently, preferences for these events aren’t propagating through Thunderbird properly and I have to learn the preferences system in Thunderbird to get it in use.  I imagine this will help to slim out the code and ensure better integration for extension/add-on capabilities for customizing the multi-touch behaviors.

There also seems to be a change in the behaviour of the synthensized mouse event that I am calling.  Since updating my revisions, the forced scroll behaviour now only seems to do a pageUp/pageDown event instead of a full scroll Top/Bottom.  I will need to investigate and maybe explicitly synthesize pageTop/pageBottom key strokes.

I’m going to be honest. I … hate … git.

Figuring out how to use git to push my changes up for 0.2 took longer than it did to write all my 0.2 code and all the tests and demos that went along with each function (over 1000 lines of code for all the tests and demos).

So to make sure I never have to go through this hell on earth again I’m writing a post to remind myself how to do it later and to help out anyone else who has trouble with git.

This is a ‘git for dummies’ tutorial strictly laid out for the people working on processing.js and the commands are all tailored to what we have to do from start to finish.  From cloning the repo locally to making changes, committing, checking status, and then pushing the changes to your fork.

This will include only the bare essentials to just do it and avoid any of the other crap you just don’t need to know and that will confuse you (and me later when I reread this to do my next releases). A more detailed tutorial for the basics is here.

This tutorial assumes you already have git installed and configured to connect properly.  If you do not have that then read an excellent post by Anna from my DPS909 course on how to setup git for the processing project here.

Steps:

1. Create a fork of the latest code.
2. Clone the repository to copy the latest code to your computer. OR pull the latest updates if you have already cloned before.
3. Make the changes to the code with your new content.
4. Mark your changed files by committing them and add a comment about the changes you made.
5. Push your new code up to your fork.
6. Request a pull of your new code from F1LT3R.

That’s it.  Here are the details

1. Create a fork of the latest code. If you already have an old fork and need to delete it just click the edit button and all the way at the bottom you’ll see a delete option.  git wouldn’t let me have 2 forks going at the same time. Or its a bug that when you click fork on the newest code it doesn’t let you and takes you to your old fork I don’t really know why or care anymore at this point.

From the picture below go to this address and select the fork button.  Give it about 20 seconds and refresh the page and it will be your new fork.

fork the master code base

2. Clone the repository to copy the latest code to your computer. OR pull the latest updates if you have already cloned before. I did a fresh clone in a new directory to make it simple.

clone repository

3. Make the changes to the code with your new content. Change whatever you need to in the code.

4. Mark your changed files by committing them and add a comment about the changes you made.  After making changes to your files you have to commit which files you want to prepare to be pushed up to the repository.

This picture explains the process well.

To commit use the command ‘git commit -a’ for all changed files. Or use ‘git commit <filename>’ for one specific file at a time.  Using commit only queues the file up  to be pushed soon it doesn’t send the file to the repository right away.  Add the attribute -m on the end of the command to specify a comment for the commit when it gets pushed to git hub later.

Look at this picture for how I did it

git commit processing.js -m 'comment'

5. Push your new code up to your fork. Now that your code is marked as committed and ready to be pushed you just have to push it.  First you can check the status of what is ready to be pushed with >git status.

git status

It says no changes added to commit but its wrong don’t worry about that the important part is it says ‘your branch is ahead of origin/master by 1 commit’.  Now your ready to push.

Type >git push git@github.com:<username>/processing-js.git

Assuming your fork is called processing-js.git just substitute <username> for your username.  Just check your fork location in the repository for what to put here.  It’s not jeresig/processing-js.git.

git push

6. Request a pull of your new code from F1LT3R. Go to your fork on the website and click the ‘pull request’ button. From the popup select F1LT3R from the list of people and click ‘Send pull request’ at the bottom.

request a pull

You can check if everything worked ok by looking at the network graph.

check if it worked

Hopefully it worked for you.  If it didn’t … then may your god have mercy on your soul.

My 0.2 release has been pushed to git hub for review by F1LT3R  !

After 2-3 days of trying to figure out git I finally managed to get everything right and push up my changes.  Thanks to Matthew Lam for showing me how to delete my old fork it was giving me issues.  Once I did that I was able to refork the latest code and then clone, commit, and push the new stuff up.

In the process of banging my head against the wall to get git working I stuck all the commands into a word file so I would remember how to do it later for future releases.  I’m going to post a 2nd blog post after this tonight with a step by step guide to go from having nothing on your PC to downloading, updating, and sending changes up for review.

A full guide to the whole process.

Here’s a quick list of what I added in my 0.2 release.  Full details of the patch are here

Added:

• nfc()
• log()
• exp()
• tan()
• asin()
• acos()
• atan()

I coded the map() function as well and then realized later it was already in the library but it was never erased from the list of remaining functions to be coded.  My code matched up with what was already in the library exactly though so I knew what I did was correct and that what was already there was correct.  I wrote a good test for map() so I’m confident what is already in the library is ok.

Fixed:

• nf() crashing with infinite loop
• color() for 1 argument passed in that has a value outside 0-255 it will be interpreted as a color and not a grayscale now

From failure, to opportunity, to failure, to a success that will hopefully lead to another success… but inevitably, the cycle will continue!

What is all this referring to?   My work on implementing multi-touch controls on Thunderbird. It’s a bug in the Mozilla community and its a major project for my Open Source Development course.  You can also follow this on my project wiki page.

The Starting Point of this Phase

My 0.1 release acts as the starting point that I am referencing here.  Back then, I managed to get a 3 finger swipe in all directions to make an action over the 3 pane message window in Thunderbird.  The 3 page message window consists of a pane on the left for showing the folders in your email account, a pane at the top that is the thread of messages for the selected folder, and a pain below that that shows the selected message… no, that’s not a spelling error!

So although there was an action for all 4 swipe direction, it was the same action that impacted the same pane, regardless of which pane your cursor was hovering over.  The community concluded, and I agreed, that a distinct action should occur that impacts the pane that your are over top of.  So… this is where it begins.

A Possible Solution from a Firefox Bug

Along came a spider who sat down beside her and said…”check out this bug, its scrolling the page without requiring a focus event!”.  Ok ok…. it’s a little late at night and I’m writing blogs again… but seriously, out of what seemed like now where, I received an email from someone adding a “polished” whiteboard comment to a bug that I happen to have been following.

I was considering that maybe for my solution in Thunderbird, I need to do something that wouldn’t hold a focus to the content window itself (which contains all of the panes) and instead NOT hold a focus to the window in lieu of retaining it for one of the panes alone.  When I saw the bug linked above, they were trying to remove focus on elements on a webpage and thus allow the parent element to scroll so that the scroll event doesn’t get trapped by the child.

Try this  (… if you can)

You can try this if you have a mac with a multi-touch trackpad… Open up Firefox (I know, you are already using it, so this is for those who don’t KNOW yet…. …. and:

1. Go to the Google Homepage (www.google.ca).
2. Narrow the height of the window so that your vertical scroll bar appears.
3. Place your cursor inside the textbox where you’d type in your search for Google.
4. Now try and scroll by sliding up or down with 3 fingers on your trackpad.
5. Witness the fact that it does not scroll the page at all!
6. Now remove your cursor from the textbox by touch the Firefox image.
7. Now scroll again as you did above… it scrolls!
8. The solution that they created fixes this so that it scrolls for both situations.
   (unfortunately it seems that other code updates have compromised their proposed patch, so I’ve left them a warning comment regarding this).

Their solution calls an interface which has access to a function that synthesizes the affect of a mouse scroll event.  So I attempt to drop the code in place… by skipping some steps and I try to call the mouse scroll function directly… failure!

There is something too different from the way that there code is received in Thunderbird on this 3 pain window!

Seeing the Forest from the Trees

Ok, so I had some of their code in place, and simply be eliminating the window._content.focus from the page didn’t solve the problem as I had hoped.  Despair started to seep in, especially as the latest firefox updates had changed the code base to my gesture support comparison and now I had to monkey around reverting my code base back to its original state with Time Machine on my mac (the backup software on my laptop).  Issue after issue arose just trying to compile and get Firefox up and running so that I could learn from it a little bit better.  I did manage to get it back and ran through a walkthrough (by leaving a trail dump(“output messages”);  as the program ran so that I could track all of the events that occurred for a single swipe!

but thought about this… maybe the interface that is being called for the scroll event has a problem with the window pane that it’s focused on.  Of course, but how to isolate out which pane I was working on…..   of course!

Javascript: The Good Parts to the Rescue!

The first thing I was to do… (in hopes that this is the correct trail that I’m following while lost in the forest) was to get some code in place that would track what the current code is actually looking at.  For those real keeners… here’s a cleaned up PDF of the output so you can follow along.

Essentially, when the scroll event happened over the message pane, it was showing up as a XPCNativeWrapper object as the event’s target object.  For the other two panes, they were coming back as XULElement object items.  hummm…. I need more information so that I can start defining what is happening.

Do to some ungrateful slams against javascript… my teacher conceded to point out the fact that we have no idea how javascipt works and that’s why we think its crap!  So he gave a very quick introduction to its advanced concepts and also pointed out two Javascript books that were the only ones worth getting.  One of which was “Javascript: The Good Parts”.  Yes, the name implies correctly that there are a number of bad parts… the beauty is this book is super concise and distinguishes the good from the bad and points out in a simple approach the more advanced (and good) parts of Javascript.  SO with this book now in hand…. I march on.

Search through the Properties

I remember in a section that I read on properties and objects that you could enumerate through the properties and he even pointed out how to avoid the properties that were functions.  This was my next step:

let doc = aEvent.target;
var docNameX;
for ( docNameX in doc){
  if(typeof doc[docNameX] !== 'function') {
    dump("\n" + docNameX + " : " + doc[docNameX] + "")
  }
}
dump("\n end of property list  \n\n");

This produced some wonderful output.  The XPCNativeWrapper object was rather unreliable in providing output, but the XULElements had all sorts of interesting properties related to them.  The trick now was to find some conditions that would isolate them out.

Isolating the Pains…  I mean Panes!

So I had tested some various conditions and found that even if I tested a property with the javascript object method hasOwnProperty (I also could have been using it in the wrong context) would cause the XPCNativeWrapper to crash out when it checked for a true/false against this object.  I was expecting a false scenario, but instead as mentioned, the function beyond that test just fails.  So I discovered this alternative, which successfully isolated out the pane that I was swiping over top of.

if(doc['namespaceURI'] !== null){
  // it is at least a XULElement (folder pane or message thread page
  if(doc['tooltip'] == "folderpopup"){
    dump("\n  You are over the Folder Pane!");
  } else {
    dump("\n  You are over the Message Thread Pane!");
  }
} else { // its a XPCNativeWrapper (message viewer)
  dump("\n  You are over the Message Pane!");
}
dump("\n  Did you find your correct Pain!  \n");

Success!…

Next Steps….  How to trigger an event for these conditions based on the correct pane now being capable of isolation.

It has been quite a while since I last blogged. However, since I have to blog about the progress I have been making in the oop322 course, here is a little something I did this week. Well, I am in the team++ group. Our group assignment is 75% done. I uploaded the IO_Vedit class yesterday. To tell you the truth, it is the easiest of all the classes in the assignment. Since all of the classes were taken by group members, I was left to do that. Anyway, it is straight forward. You have everything explicitly written as an instruction. I just followed it and did what was asked and run it.

Yay! Some pictures of my actual work!! Docs can be cool too! Well, if you think graphs are cool… Which for the record, I do.

Even though I am still having another issue, I seem to have Dehydra working well enough to generate some docs. Basically ignoring the previous issue, I came across:

set -e;  \
for class in `cat graphtypes.list`; do \
dot -Tpng -o${class}-graph.png -Tcmapx -o${class}-graph.map ${class}-graph.gv; \
done
/bin/sh: line 2: dot: command not found
make: *** [classapi] Error 127

This happens to be a nice, soothing error at this point. I found the dot command and tried yum search "directed graphs" which pointed me to Graphviz.

A quick yum install graphviz later and no problem! Up above are a couple of the graphs generated for what I will be making for the MDC.

I’ve created a simple Dehydra script to check for alwayszero functions. There are some issues however. Here’s the script:

function process_function(f, body)
{
  if (f.type.type.name == 'void' || !f.isVirtual) {
    return;
  }

  var alwayszero = true;

  function processStatements(stmts) {
    for(var j = 0; j < stmts.statements.length; j++) {
      var s = stmts.statements[j];
      if (s.isReturn && s.value != 0) {
        alwayszero = false;
      }
    }
  }

  for (var i = 0; i < body.length; i++) {
    processStatements(body[i]);
  }

  if (alwayszero) {
    print("alwayszero function: " + f.loc.file + " on line " + f.loc.line +
          ", column " + f.loc.column + " : " + f.type.type.name + " " + f.name);
  }
}

I actually have a more elegant version using a for in loop and iterate_vars but after watching that Douglas Crockford lecture I’m a bit paranoid about such things (both report the same results though).

After doing a bit of post-processing on the output I can report the following:

Functions meeting the above criteria are encountered 5920 times during compilation but most of these are duplicates since there are quite a few method definitions within include files.

Removing all of the duplicates reduces the number to 243 instances encountered (shouldn’t be too difficult to patch manually or with some shell script hackery).

A link to the list of 243 unique instances is here. The full output list can be obtained here (warning: big file).

Unfortunately I have encountered at least one false positive with this script:

gfxFont.cpp on line 960, column 35 : gfxFont::RunMetrics gfxFont::Measure(gfxTextRun*, PRUint32, PRUint32, gfxFont::BoundingBoxType, gfxContext*, gfxFont::Spacing*)

Viewing the definition here, I’m not sure why this function was captured by my analysis but I’ll have to investigate. Ultimately, I think doing this with a Treehydra script might make more sense. There’s already an existing script that does all the heavy lifting, but I haven’t been able to link this into an independent analysis pass on mozilla-central (yet).

Edit: Argh… found another false positive here:
nsSVGContainerFrame.cpp on line 264, column 82 : gfxRect nsSVGDisplayContainerFrame::GetBBoxContribution(const gfxMatrix&)

More Issues:

When I get the plugin ready to go with mozilla, I’ll add a script to xpcom/analysis to ensure that every function which has the user(("alwayszero")) attribute meets the above criteria.

As to excluding non-virtual member functions from the analysis, as far as I can tell GCC should already be able to optimize these away. Perhaps there’s a corner case I haven’t considered though.

Another issue I thought of today is that this script can potentially flag floating point functions as alwayszero which will result in bad things happening if I apply my plugin as originally written to them.

Luckily a fix to the plugin was not that difficult:

static bool
sane_tree_type (tree t)
{
  enum tree_code code = TREE_CODE (TREE_TYPE (t));
  return code == INTEGER_TYPE || code == BOOLEAN_TYPE;
}

 /* other stuff --- see previous posts for context */

static unsigned int
execute_alwayszero_opt (void)
{
  gimple_stmt_iterator gsi;
  basic_block bb;

  FOR_EACH_BB (bb)
    {
      for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
        {
          gimple stmt = gsi_stmt (gsi);

          tree lhs = gimple_get_lhs (stmt);

          if (is_gimple_call (stmt) && lhs != NULL_TREE &&
              is_alwayszero_function (stmt) && sane_tree_type (lhs))
            {
              tree zero = build_int_cst (TREE_TYPE (lhs), 0);
              gimple assign = gimple_build_assign_stat (lhs, zero);
              tree var = create_tmp_var (TREE_TYPE (lhs), "dummy_var");
              add_referenced_var (var);
              mark_sym_for_renaming (var);
              gimple_call_set_lhs (stmt, var);
              gsi_insert_after (&gsi, assign, GSI_CONTINUE_LINKING);
            }
        }
    }

  return 0;
}

This will exclude pointer types as well which is probably a good thing. If it’s really necessary to optimize away alwayszero REAL_TYPE functions this could be done as well, but they will have to be handled separately. Actually this should be pretty easy but it’s not really a priority at the moment. It probably makes more sense to check the type of the function rather than that of the lhs, but consider the above a proof of concept.

The next step is getting my plugin to work with the GCC 4.3.4 with backported plugin support used to build Dehydra which I now know will not be too difficult. The main issue is that the gimple_stmt_iterator is nowhere to be seen (even though it shows up in the Changelog … wtf) so I’ll have to use the block_stmt_iterator instead which will require a slight bit more ugliness.

The main problem though is getting a plugin to build under the GCC 4.3.4 with backported plugin support used to build Dehydra. 4.5 includes a separate plugin include directory and an easy to use -print-file-name=plugin flag to get at the directory. I’ve tried hacking a build rule into the existing configure script in Dehydra but I’m a complete noob with make and configure stuff so I haven’t had any success yet. Hopefully I can rectify this shortly.

Also, I’ve been attempting to get FF built with 4.5 but have encountered some issues. Once I get a nice sequence of steps that follows the instructions on this page I’ll bring this to the attention of the GCC people.

If only our attention spans could stretch longer than our own lives, or our perception of time was in a range where every dawn could be seen as a beat of the Earth’s heart, we could notice something awe-inspiring:

the speed of innovation is increasing.

And not only that, but the speed of complete infrastructure redesign is also increasing.

If we think about the elementary meaning behind the word ‘tool’ and what it symbolizes – a construct, something external, that is designed with a purpose, and quite simply allows us to do what we are not biologically engineered to accomplish au naturel. The knife is a tool. Plausibly the very first tool, which may have been inspired by our teeth. What our primitive brethren couldn’t penetrate with a finger nail, tear with their hands, or sever with their teeth, they employed a blade. This cause-effect relationship based on necessity is the one pattern all technology follows. Keep that in mind.

So, life before the tool was indeed a world we would not recognize, as its advent brought with it a paradigm shift, albeit slow and progressive.

We could consider harnessing of electricity as another paradigm shift. Ask yourself, did binary matter to the Empire of Rome? Doubtful.
By necessity, the human world evolving into an age of electrical power required a new infrastructure of logic, which was quite simply power-on/power-off. From there, binary developed into boolean algebra, which developed into complex computing commands based on laws and rules, functions and variables. None of this would have had any implementable purpose in the eras that predate the 1800s, there simply was no necessity for these entirely new leagues of information.

Shift happens.

The internet is nothing if not a total paradigm shift. Information has gone from a physical block of stuff on a page to nonlocal storage! Knowledge is no longer something that needs to be touched, held, and transported across space and time to be exchanged. We have tapped into the world of the formless and amorphous, I believe this signifies a step in our progression towards the divine, nonphysical universe. The necessity is there. I don’t know if you’ve noticed, but we’re running out of space; space to park our cars, space to place houses with backyards and driveways, etc… Space is an abstract constant, and it is finite by design.
As the ancient Chinese saying goes: Round Heaven, Square Earth. The brilliance of this understanding strikes me in noticing that the square is the most space-efficient shape we can employ, and illustrated in how right angles dominate the designs of our structures. It just seems very appropriate and captures the essence of this tangible world of ours.
It also makes one look deeper at Da Vinci’s Vitruvian Man.
But I’m getting off topic.

And I cannot exclude the Open Source revolution. It is another delocalization, but this time of the power to forge and manufacture digital tools. In this context, imagine a factory no longer manufacturing/distributing a product, but now offering the knowledge on how to make that product yourself instead. That is how you empower the consumer.

So what comes next, you may ask. What new system will reinvent the court in which we play ball, and will it come in our lifetime?
I can only tell you that you ask silly questions. The future is meant to be unknowable, that’s how it is programmed. If you went back 70 years and told someone that you heat your food in a box that zaps it with invisible, electromagnetic energy without even heating the air around it, they would tell you to lay off the drugs. Even the pioneers of the television thought the appliance would be a passing fad, and never would have believed seeing a TV in every household.
And it is probably less a matter of ‘will‘ shift occur in our lifetime than ‘how many‘ shifts. Let’s never forget, the speed of change increases exponentially.

The stone age – several tens of thousands of years.
The bronze age – a few thousand.
The industrial age – 300 years.
The chemical/plastic age – one hundred.
The information age – 30 years old.
The Biotechnology age ~ 10 years.
And who knows, the nanotechnology age might last a whole 8 minutes.

Over the course of our existence, all these tools go from just things we use to extensions of our very selves. We are the tools we use, we are the machines that compute and manipulate, and we are a different class of creature as a result.

But in the scope of what comes next, there seems to be a new trend in technological advancement (other than ever-more intelligent robots), and that is an evolution from the use of input artifacts like keyboards and mouses to a more intuitive system of manipulation. Through this branch of innovation, we can see that we are really working towards hybridization with our creations, whether consciously or not. How better to illustrate how we are become ever-more united with our machines on a personal/mechanical level than with progress like muscle-based input, Mattel’s Mindflex, the thought-based interface of Audeo, and something truly astounding called SixthSense.
Seriously. It’s like the internet all over again.
Nonlocality of information is going even further in that access will delimit itself from a local computer, and the invisible infinite can be carried with us and plugged into real life objects with real time plugging in to hyperinformation.

[*Note of interest: As if SixthSense's hardware costing no more than $300 was amazing enough already, its software has gone open source.]

The world is just freaking awesome.

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).”

I previously published my release schedule (check it out). I finished my 0.1 release despite some bugs that i will need to fix. Check out my blog and help me test my cursor functions. Note: cursor does not yet work on mac. The main problem with my release schedule is that i allocated 3D functions for my 0.2 release. Unfortunately, all of the implementation of 3D has not been completes so I decided to push curve() box() and sphere() to my 0.3 release. For my 0.2 release, i will be implementing PImage, and once I complete it i will fix my cursor functions to use PImage, one of the bugs.

Here is the new schedule

0.2 Release Monday November 20, 2009

• PImage
• cursor(image, x,y) edit image parameter to be PImage: any variable of type PImage

0.3 Release Monday December 7, 2009 – this is very optimistic and I doubt I will have all browser capability. I will first need to learn more about 3D and OpenGL

• curve()
• box()
• sphere()
• rotateX()
• rotateY()
• rotateZ()

View all of my blogs on Processing.js
View all of my blogs

Falling behind with my blog is not a good thing because I have a lot to report. Some/most of it is old news by now but I need to get it up here. Incidentally I’ve completed a rudimentary Dehydra analysis on the mozilla-central repository so that my plugin can eventually be applied, however I will present the results in my next post (here’s the post, btw).

Anyway, last week, upon embarking on the static analysis component of this project, I ran into trouble using my GCC plugin on two of the CDOT’s x86_64 Fedora boxes. The plugin compiled, but using it on any test code invoked an internal compiler error (a segmentation fault). This was quite troubling since the plugin worked fine when compiled for i386 (tested with my personal Debian machine and another Fedora i686 system at Seneca).

Ultimately I solved the problem by finding a slightly different way of coding the optimization, but I’ll document a few of the steps I’ve attempted.

Although I have now updated it with the fix, the plugin code of my previous post contained the following (see that post for the context):

  tree lhs = gimple_get_lhs (stmt);
  tree zero = build_int_cst (TREE_TYPE (lhs), 0);
  gimple assign = gimple_build_assign_stat (lhs, zero);
  tree var = make_rename_temp (TREE_TYPE (lhs), "dummy_var");
  gimple_call_set_lhs (stmt, var);
  gsi_insert_after (&gsi, assign, GSI_CONTINUE_LINKING);

One clue about the issue is that the call on line 4 to make_rename_temp warns “initialization makes pointer from integer without a cast”. At the time my thoughts on the issue were “who cares, it works”. Even getting the ICE (which complained about the call to make_rename_temp), I figured that changing the code wasn’t the thing to do. Instead a convoluted journey of debugging the plugin with gdb, examining the registers, etc, etc, was what I had in mind. Conclusion: the call to make_rename_temp results in a crash.

In any event, I found a solution although it’s been long enough that I can’t quite remember how I arrived at it:

  tree lhs = gimple_get_lhs (stmt);
  tree zero = build_int_cst (TREE_TYPE (lhs), 0);
  gimple assign = gimple_build_assign_stat (lhs, zero);
  tree var = create_tmp_var (TREE_TYPE (lhs), "dummy_var");
  add_referenced_var (var);
  mark_sym_for_renaming (var);
  gimple_call_set_lhs (stmt, var);
  gsi_insert_after (&gsi, assign, GSI_CONTINUE_LINKING);

All of that add_referenced_var/mark_sym_for_renaming business is because the call to create_tmp_var creates a temporary that’s not in SSA form ie you’ll have an initialization like int dummy_var.0; and then when it’s used you’ll get dummy_var.0 = 0; when what you want is dummy_var.0_1 = 0;.

Looking at the code for mark_sym_for_renaming in tree-dfa.c, note that it’s basically identical to the code I used to replace it’s call:

tree
make_rename_temp (tree type, const char *prefix)
{
  tree t = create_tmp_var (type, prefix);

  if (TREE_CODE (TREE_TYPE (t)) == COMPLEX_TYPE
      || TREE_CODE (TREE_TYPE (t)) == VECTOR_TYPE)
    DECL_GIMPLE_REG_P (t) = 1;

  if (gimple_referenced_vars (cfun))
    {
      add_referenced_var (t);
      mark_sym_for_renaming (t);
    }

  return t;
}

So where is the error with my original approach given that it works on i686? I’m thinking that the representation of a tree as a union of tree nodes may be at issue ie I was sticking the return of make_rename_tmp where it should not be stuck.

Although it wasn’t of much use to me, I’ll present a quick example of debugging GCC with gdb for those interested (this applies to GCC plugins as well). I have found this page, on debugging a segmentation fault, particularly useful. For those who just want to step through the compiler for kicks, those instructions will work as well.

Here’s a concrete example:
I’ve installed my GCC at /home/ehren/gcc/dist/bin/gcc and am compiling hello.c which is in my home directory. The compiler was produced with -g3 -O0.

First run the compiler with -v to determine the actual command passed to cc1 or cc1plus (gcc or g++ is just a driver for these programs)
~$ gcc/dist/bin/gcc hello.c -v

The output will contain the following line:
/home/ehren/gcc/dist/libexec/gcc/i686-pc-linux-gnu/4.5.0/cc1 -quiet -v hello.c -quiet -dumpbase hello.c -mtune=generic -auxbase hello -version -o /tmp/cctQO1Kb.s

Now invoke cc1 with gdb:

~$ gdb /home/ehren/gcc/dist/libexec/gcc/i686-pc-linux-gnu/4.5.0/cc1

And then run it using the arguments given in the line above (the -v is now unnecessary but there’s no harm in including it). Set a breakpoint first if you’re not getting an internal compiler error:

(gdb) break main
(gdb) run -quiet -v hello.c -quiet -dumpbase hello.c -mtune=generic -auxbase hello -version -o /tmp/cctQO1Kb.s

And you’re good to go.

Just a quick bloglet on my progress on placing C3DL into PJS. I got lights and animation working! I’ll post up my work once I have something less hacky.

In my previous post classapi with a Little Treehydra on the Side I received help to get a little farther when making classapi, or docs from Dehydra.

*If you want these pictures to make any sort of sense you have to keep reading…

This time make did start running some stuff, and created classapi.out, but inside classapi.out:

DUMP-TYPE(nsAString_internal)
/home/rdicke/src/xpcom/analysis/type-printer.js:248: JS Exception: Member name not qualified?
:0:     #0: Error("Member name not qualified?")
/home/rdicke/src/xpcom/analysis/type-printer.js:248:    #1: dumpType([object DehydraType])
/home/rdicke/src/xpcom/analysis/type-printer.js:394:    #2: input_end()
/home/rdicke/src/config/static-checking.js:101: #3: ()

Let it be noted that I am working with external strings while internal strings are what I am generating now. I just want to get what we know works working before I graduate to producing the docs for external strings.

So with this new problem solution in transition, humph told me I had a bug and that I should have a look at it myself. In the beginning I hoped that I could just use Dehydra and only have to play in my beloved C++… *JavaScript! “They found me. I don’t know how but they found me!” (there seems to be some strange connection between BTTF and JavaScript??)

A look at type-printer.js line: 248

Well, it throws the error we see above, here it is with it’s if statement:

if (m.name.indexOf(qname) != 0)
throw Error("Member name not qualified?");

I commented out the throw and added my own line:

print("--- qname: " + qname + "\n--- m.name: " + m.name + "\n--- m.name.indexOf(qname)" + m.name.indexOf(qname));

Now I get all kinds of goodies! And in classapi.out:

DUMP-TYPE(nsAString_internal)
--- qname: nsAString_internal::
--- m.name: EqualsLiteral
--- m.name.indexOf(qname)-1
--- qname: nsAString_internal::
--- m.name: EqualsLiteral
--- m.name.indexOf(qname)-1
--- qname: nsAString_internal::
--- m.name: LowerCaseEqualsLiteral
--- m.name.indexOf(qname)-1
...code>

Well there you have it, the error message makes sense now. m.name would be "nsAString_internal::EqualsLiteral" if it were qualified. And… It isn’t. Noticing that I put the print under the if, meaning that it would only print if the member name was not qualified, I decided to try commenting out the if.

DUMP-TYPE(nsAString_internal)
--- qname: nsAString_internal::
--- m.name: nsAString_internal::~nsAString_internal()
--- m.name.indexOf(qname)0

Looky there! Qualified members. So why are there some in there trying to ruin my fun? And why do we hate non-qualified members anyway? I’m sure to find out.

Today’s OOP344 topic was binary file acess. Fardad wrote a program that would read a series of doubles from a binary file and print them on the screen using cout.

He then challenged us to modify his code to print the numbers in reverse from the end of the file, and that a similar question may end up on a test.

Well, if that’s the case I probably won’t get a 0 on the next test because I think I have a solution:

#include <iostream>
#include <fstream>
using namespace std;

int main(){
  double d =0;
  fstream fin("nums.bin",ios::in| ios::binary);
  int i;
  fin.seekg(sizeof(double)*980);
  for(i=0;i<1000 && !fin.fail() ;i++){
    fin.read((char*)&d,sizeof(double));
    if(!fin.fail()){
      cout<<i<<": "<<d<<endl;
    }
  }
  fin.clear();
  cout<<"---------------"<<endl;
  for(i=0;i<1000 && !fin.fail() ;i++){
    fin.seekg(sizeof(double)*-(1+i), ios::end);
    fin.read((char*)&d,sizeof(double));
    if(!fin.fail()){
      cout<<i<<": "<<d<<endl;
    }
  }
  fin.clear();
  return 0;
}

works, but there’s probably a better way of doing it XD

I was trying to make some changes to my team’s website and the table was always showing up at the bottom of the page.

I want the table to be directly under the first header on the page, followed by subsequent headers but as I keep adding content, it always shows up above the table.

Probably a syntax error somewhere but I can’t seem to spot it.

Weird!

Spent most of Saturday helping F1LT3R setup a new bug/feature/issue tracking web application for processing.js.

It’s called Lighthouse and if I was to describe it i’d say its a simplified bugzilla bug tracking system.

But what is a bug ?  A bug is not just a broken feature in a piece of software it’s  anything that has to do with a change that can, will, or might happen to a piece of software.  A bug can be a request for a new feature.  It can be a problem report for a crash issue.  It can also be a request to change the way something works or fix something and make it better.

Improvements, Innovations, Implementation, and Invention.

So what’s the purpose of Lighthouse exactly then?  It’s to allow us to use a centralized location to start tracking processing.js changes, bugs, feature additions, and improvements.  Most importantly though its a way for the community to be able to know what everyone else is working on and to bring the community closer together.  It’s also to help F1LT3R in the review process as well.

I wrote up a short tutorial on how to use lighthouse to place a ‘Ticket’ (tickets are bugs, milestones are due dates for deliverables) for processing.

F1LT3R also wrote an intro on how the project workflow should go and how to go about implementing your own work on processing.

I think in the future we plan to tie Lighthouse into Github as well.

After building what I thought was (and now am only unsure is) a successful static analysis build of Mozilla I attempted to “generate the docs” by issuing the command:

make -C <objdir>/xpcom/analysis classapi

This command ends up with the error:

make: *** No rule to make target `.deps', needed by `classapi'.  Stop.

Getting some extra information from make using:

make -d -C objdir/xpcom/analysis classapi

I get:

...
Considering target file `classapi'.
File `classapi' does not exist.
Considering target file `.deps'.
File `.deps' does not exist.
...
Must remake target `.deps'.
...
make: *** No rule to make target `.deps', needed by `classapi'. Stop.
...

Touching base with Treehydra

The only thing in <objdir>/xpcom/analysis is the Makefile. The previously mentioned Building with static checking instructions specifically uses  gcc_treehydra.so so I though I would build Treehydra if not as a fix, just to have it.
Which brings me to a nice discovery, something I should have been aware of prior perhaps, Benjamin Smedberg’s blog post talking about the steps he had given me before. In that post he mentions the same page on MDC mentioned above.
I had used gcc_dehydra.so.  It seemed to build just fine, but when I ran make check_treehydra however it ended with 100% errors. I noticed that the cc1plus it was using was the systems version, not the plug-in version.

Using:

make CC1PLUS=../../installed/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/cc1plus check_treehydra

Made the test run much better however there were still 6 failures all mentioning:

../libs/treehydra.js:12: JS Exception: No case_val in this lazy object
:0:     #0: Error("No case_val in this lazy object")
../libs/treehydra.js:12:        #1: unhandledLazyProperty("case_val")
../libs/unstable/esp.js:481:    #2: ()
./esp_lock.js:41:       #3: process_tree([object GCCNode])

As interesting as this all is, I feel that I am getting sidetracked. I should be able to do something with gcc_dehydra.so alone, and at this point I feel that my static analysis build is faulty. On to IRC…

Solution

bsmedberg gives me the solution:

mkdir <objdir>/xpcom/analysis/.deps

Making the empty directory lets me get on with the build. At this point I have made a fresh static analysis build and am not using treehydra, I am sure I will get to play with it later. Visit me next time to see what other fun I am having!