Git Gui

By popular demand (and by demand I mean Donna), here’s a blog about what I know about my basic knowledge of Git Gui (which stands for graphical user interface).  I’m going to skip the installation part, since Anna’s done a pretty comprehensive guide here (for Windows) and here (for Mac).  There’s also the Github resources for Windows, for Linux and for Mac.

After installation, you can immediately access the gui.  For Linux, the easiest way I’ve found is to open up a terminal and type git gui and hit enter.  That’ll bring it up for you.  For Windows, you can do the same thing with the mysysgit terminal or use the icon provided in the installed folder.  I’ve had someone test this with a Mac (I could be wrong since I didn’t do any of the testing myself) and you can only open it up through the icon provided – typing git gui on the console of a Mac just comes up with errors.  I’ve also not included how to link your git client to the Github repo (using SSH keys).  If you need help with that, just follow these links for Windows, Linux, and Mac.

So after starting up the application, the first screen you get will be the following:

Since this is most likely you’re first start up, I’ve highlighted the clone existing repository link which you would have to click.  If you’ve already cloned a repo, just open it using the link below the one I highlighted that says “Open Existing Repository” and skip to the next image past the one below.  Cloning, however, gives you the next following screen:

The screen above is pretty self-explanatory.  The source is the remote repository and the target is the local one you wish to put it in.  After clicking the clone button, you’ll get the main screen as shown below.

I’ve loaded up the main screen with a few changes to help explain the ideas better.

1)  It’s what I believe is the most important part.  The label tells you what current branch you’re working on.  This in itself is way better than the command line as you’d have to type git branch over and over again just to make sure you’re on the right branch.  It’s a very useful item.
2)  This section includes all the files that have changes and needs to be looked over and staged.  This is where you would find items with merge errors as well.
3)  This is the staging area.  All the files here are ready to be committed.
4)  The diff box is what I like to call this area.  It tells you the changes made in the file.  + for additions and – for subtractions at the beginning of each line.
5)  I’m labeling this area as the git (tool)kit.  These buttons are going to be the most used buttons while you use git gui.  This is especially true if you submit a lot of patches for your remote repo.  “Rescan” looks through the local repo for any changes.  “Stage Changed” takes everything that can be staged in section 2 and puts it into the staging section 3.  “Sign Off” puts your name in the commit message (you’d have to have this configured already with SSH keys and such).  “Commit” takes all the files in the staging section and commits it to your local repo.  The “Push” button, of course,  pushes to your already linked remote repo.

How do you link your repo to your remote one?  Good question.  It’s normally generally already linked when you create it.  Which brings me to the next topic at hand, how do we create a repo with git gui?  The picture below shows the menu to create and deal with branches.

When you click the Branch menu, the drop down brings up the list above.  Checkout allows you to switch to other branches linked to your repo (more on this later).  Rename, reset and delete are pretty self explanatory.  Note:  All those commands, only apply to your local repo (until you push to your remote one).  Creating a new branch on your local machine is as easy as clicking Branch then create (or Ctrl-N for those ahead of everyone else).  Creating a new branch brings up this screen:

When creating a new branch, I generally like to leave everything defaulted.  However, there are generally a few options to fiddle with still.

1)  You have to name this branch.  Totally up to you on what it could be… there are probably limits but I haven’t found the need to be that creative with my naming convention yet.
2)  This shows all the branches on your local machine.
3)  This shows all the branches you are keeping track of.  This is especially useful for those who pull from other people’s remote repositories.
4)  The list of the radio button list option above.  This is also what you would select your new branch be based on.  (Note:  General good practice is to update/merge your master and create new branches off your master branch).

If you’re switching branches, you click Checkout on the branch menu and you’d get the screen below.

Look familiar?  Probably because it’s very similar to the create screen (minus the naming of the branch).  Checkout works an awful lot like creating a branch.  You pick which branch you would like to switch to and you have the option of using a local branch or a branch you are tracking (either your remote repo or other people’s remote repo).  This brings up the question of “How do you track other people’s repo?”  Look at the next screenshot to find out!

Generally, the top 3 sub-menus would only be initially filled with “origin”.  Which is to say, your original remote repo.  To track more repos, you would have to go to the Add section of the Remote menu.  I didn’t provide a screenshot of that menu as it is pretty self explanatory.  You provide a name and the git link for the repo you wish to track and voila that repo shows up in the top 3 sub-menus.  The main function I tend to use is the “Fetch from specific repo”.  This allows me to track the branches of that repo and helps populate the tracking branch section of the create and checkout menus shown above.  After fetching a repo, my normal course of action is merging a branch from that repo to the current working branch of my local repo.  The merging menu is shown below.

Abort merge removes all the changes you made with the current merging that’s being done.  It’s only normally used if you’re in the middle of a merge and made a mistake.  Clicking local merge brings up this next screenshot.

Again with the familiarity.  It looks similar to the checkout and create menus!  Now, this list (under the tracking branch) should be filled.  If it’s not, you probably haven’t “fetch from” someone else’s remote repo.  If it’s not and you have done that, then your current branch is up to date with everything they have in their branch.  You can also merge from other branches in your local repo if you click the local branch radio button option.  If you merge quite often, which I do suggest, then you shouldn’t really have any merge problems.  If you end up with merge errors (git couldn’t complete the merge for you), it’ll show up in the diff box.  You will have to go into the files and fix it manually though.  Git makes it easy enough to find those problems by providing you with <<<  and >>> notation.

One last piece of information for git gui comes from the Commit drop-down menu shown below.

Some of these options are presented in the buttons below, like Rescan, Sign Off, Commit and Stage Changed.  “Stage to Commit” stages only the specific file selected in the Unstaged section.  “Unstage from Commit” does the opposite and removes a single file from the staged section and puts it in the unstaged section.  “Revert changes” turns back the specified files and returns it to it’s original standing (before any recent uncommitted changes were made to it).

Well, that’s all the basics I think should be out on the web.  If you have specific questions, feel free to leave a comment and I’ll try to answer it as best I can.  Thanks for reading and I hope it helps!

New School Year, still working on the same projects

Though do not let that sound resentful; it’s not at all.  I’m still glad to be working at Seneca’s Centre for Development of Open Technology.  It’s great to be able to do work on open source tech (and get paid for it).  Processing.js is coming to a close for several of us.  At least, with the release of 1.0, maintaining the library will become less of a daily thing for most of us.  There’s definitely still bugs to work on and if anyone out there is interested in helping out, just go to this link: here.  Sign up and take a bug to fix!

In the meantime, I’m continuing my work (that I’ve previously stalled) on XB Pointstream.  I’ll initially be working on a reader that converts a proprietary file format to something that’s more usable in the open web (and for our library).  This will probably take me a couple of weeks to get done.  After that, I’ll be working on the many bugs we have filed plus some that are still processing in our heads.  This is definitely going to be a fun semester!

Unfinished Business 0.8 – 0.9 – 1.0

This post is looooonnnnngggg overdue, considering my last post was in March.  I figured I could do this while Minefield was building (but I was wrong considering it only takes like 20 mins for it to build on these machines).

0.8 Release

I really didn’t do all too much for the 0.8 release.  I was busy with other things.  I realize, now, that I should’ve thought more importantly of this project and should’ve made as much time as possible for it.  Unfortunately, there’s not much I can do about the past but learn from it and dedicate my time better.  I did feel badly for not doing as much for the 0.8 release as my colleagues were depending on me and hopefully made up for it somewhat with my work with the 0.9 release.

0.9 Release

For 0.9, I worked on beginShape, vertex and endShape.  I had a barely working product for 3D (untested and unused) before the Processing.js workshop.  It was barely working due to the fact that my changes broke the 2D version.  During the workshop, I was able to run tests and completely revamp the way beginShape/endShape worked.  With the 2D version, the functions were set to draw as the vertices were put in.  I changed it so that it collects that information and then renders at the end.  I, also, spent a whole day on fixing bugs and testing the code.  This was needed due to the fact that it was a large amount of code.  My examples and tests can be found on at the following link:  click here.  (Note: that 3D tests and demos require a pre-release browser that supports WebGL… such as Minefield, Chromium or Webkit).  Here’s a more prominent 3D demo using beginShape/endShape (again you need a 3D capable browser):

After that weekend, I was able to work on converting 2D quad and triangle primitives to work in 3D space.  This wasn’t really too tough as it was merely a wrapper

1.0 and Future Releases

1.0 is a goal for the end of May… however, we will be doing mini-releases along the way to sort out some fixes and release some more needed features.  My first goal is to make that RGB Cube demo working up to speed.  This entails converting a bit of the current endShape code to take in colours for the vertices and render them.  I, also, have to make sure that these objects take normals so they can be lit up in a 3D environment.  After, I plan to work on the PGraphics object and make sure that the fix works with 3D objects being displayed in createGraphics.  My final plan of action before the 1.0 release date is to ensure the PShape datatype is working within the PJS environment.  Of course, I’ll also be fixing any bugs that come along the way.

0.7 release

I was a little hard-pressed for this week’s release.  Mainly because I thought the release to be next week.  I did have some stuff done before but I wasn’t in much of a rush to finish it, until I found out it was to be out this Monday morning.  I got in gear but still had much trouble with beginCamera() and endCamera().  The functions you see there seem pretty simple but having to use the inverse of camera threw me for a loop.  I had to look for the problem everywhere in the code.  At one point, I rewrote the whole invert function only to find out it was working properly.  Some key objects I was missing were dependent on deprecated functions.  At least, the code within the Processing native said they were to be removed from the future.  In that sense, my colleague decided it wasn’t needed in PJS.  I quite agree with him still.  It’s not completely needed, some of those inverse functions anyway.  I could and will probably recycle some of the regular functions and just apply the inverse.  I did add them all for now though.

That’s not all there is to it either.  As I was submitting an example through git, I found a bug that still currently resides with my checked-in code.  It may seem like it works properly, but insert a camera() function in there and the changes don’t take.  That is definitely a problem because suppose it’s put in a draw{} statement.  It wouldn’t have an anchor that can put it back to place… it’ll just continue to transform.  It’s somewhat of a big bug that I can’t finish tonight.  I’m leaving it up to the reviewers to pass or fail.  I doubt it’s going to pass… I’m not sure I would pass it either.

On a lighter note, I was able to finish the dist-3d days ago.  I was just so wrapped up with beginCamera() and endCamera() that I never wrote the tests for it.  I wrote my first unit tests earlier today and it was a breeze.  I’m definitely glad that was added to the PJS scope.  It definitely makes unit tests much easier.

Anyway, off to bed.  Maybe someone will have read this blog and figured out a way to help me with the camera.  Dave was right.  It was my fault for waiting til the last second to ask for help.  I’ll blog more soon… still have to get PGraphics off the ground.

Back to work

I’ve just finished reading week and it’s time to get back to work.  Getting back into the groove is always hard, including blogging again.  I realize it’s been a while since my last post and it was mostly due to midterms and hell week.  This is going to be a long post due to having to wrap up previous releases and talking about the upcoming 0.7 release.  I won’t make this intro too long so I’ll just get on with it…


In this release, we got 3D up and running!  It’s fairly old news but exciting nonetheless.  I’ve taken some of Corban‘s examples (which he was using to show if the functions were working or not) and put them on my matrix account.  This first demo was a test with translate and how it was working improperly when first put in (please note that you’d need a WebGL enabled browser to view 3D… like Mozilla’s Minefield).  It has been fixed and is currently working within that demo.

The picture above is a comparison of Processing and Processing.js.  It links to the other demo that previews the ortho() function is working as intended.  And by that, we mean it’s working exactly how Processing is doing it.


I didn’t do too much for the 0.6 release.  Like I said, I was a bit busy with midterms and assignments.  I did try to do what I could and pitch in where I could help.  I did more than half the peer reviews submitted.  I’m not going to list them all since there were so many… but almost all of them did end up getting checked-in so you can look through this list if you wish.

I did add one function, applyMatrix().  It wasn’t a tough one to add… it was mostly just a simple wrapper but I didn’t expect some of the complications I did have.  I ended up making a demo/example to make sure it worked properly.  More details about my problems can be found here.


For this upcoming release, I’m going to finish beginCamera() and endCamera().  So, we can have some 3D Camera movement.  I’ve already got an idea of how this can be implemented involving the modelView and cam matrices.  There maybe even some use of the 3d matrix stack that I’ve previously created.

I’ve also added two more items to put in for this release.  One is to implement a working dist for 3d.  This should be fairly simple by using an existing PVector.dist() function and wrapping that to work with this.  The second is an important function which I’ve yet to determine if it will be easy or hard.  Mainly due to my not having that much experience with this particular problem.  I’m going to implement the much needed PGraphic.  Now, this could be very elaborate or as simple as recalling the p object into a buffer.  I’m going to talk to Corban/F1LT3R/humph more about this particular function/object.  I’m not exactly sure on where to start either.  So, that would be some good advice to begin with.

Well enough chit-chat… that’s my update and it wasn’t as long as I thought it would be.  Now back to work…

Mistakes and new functions

In my previous post, I was doing some tests.  Somehow, be it tiredness or plain out carelessness, I messed up one of my tests and forged ahead on a commit.  Luckily it was caught by Andor, and a bad release was avoided.  Then again, that’s what we have peer-reviews and super-reviews for.  However, I was able to find the problem and fix it… still the same old problem with the variables not updating once a resize is called.  It seems that I forgot to update an important variable.  I also took some time to test for the ortho function (since it was easy to change one line).  I added that update to the repo as well.

As can be seen above, the outputs are the same as what would be done in Processing.  I have also added in the necessary variable names that Andor was looking to use.  I’m still working on the current matrix stack and hopefully can get the testing finished either today or tomorrow.

I adapted PMatrix3D into all the camera functions already as Andor is working on it and should come out with the release at the same time as my functions.  I am a little concerned with how he implemented PMatrix3D though… it’s not an object, unlike PVector.

Testing camera, frustum and perspective

Anna, our new project manager, was doing a follow-up on me yesterday.  She brought up a valid point of me not blogging enough (which everyone already knows as well, if you’ve been following anyway).  I was stuck on a problem the past few days and just let it go, as I was busy with other things.  But I realize that if I blogged about it, I could have gotten the answer while I left it alone.  I did find the problem when I threw it out on IRC and people read it and provided feedback.  I ended up filing a bug (267) for the problem to get looked at in the future.

Anyway, I did get my tests done and the results were working as intended… and by that I mean my matrices were lining up with what Processing has…

I’m still thoroughly testing PMatrix3DStack… as there’s not default tests with that, I’m just plugging in some random numbers.  The biggest concern is mult… if it’s being multiplied properly.  If I can finished PMatrix3DStack testing tonight, I should be able to write a test for ortho() as well.

Triaging and Reviews – Release 0.4

With the recent finish (or almost finish due to one last ticket – linting), I figured I should write a blog post about it… considering we’re supposed to blog about each release… anyway, I also figured I’d start to set an example for Dave’s new students (whom I told to take the class), who are new to the world of blogs.

I took on a number of tickets for peer review.  Tickets #: 1, 42, 60, 61, 171, 188, 205.  Luckily, most of the code worked and had tests… so making sure they worked and the code looked simple and easy to read wasn’t too hard a task.

Ticket #1
This ticket was the first one inducted into lighthouse and it still hasn’t made the repo.  It was my job to make sure it passed.  It wasn’t very hard considering all of Daniel’s code looked great.  He did have an old test that wasn’t working anymore up.  I remember it working before though so I just took his code and plopped it into a newer instance and it worked.  I passed it for super-review.

Ticket #42
It was to fix the infinite loop happening in nf().  The fix looked simple enough that it didn’t even need to be tested.  I passed it for super-review.

Ticket #60, 61, 62
Andor’s release and awesome demo(needs 3D capable browser, like Minefield) proved it’s worth.  I, admittedly, didn’t even see the need to use the examples for a test.  I passed it for super-review.

Ticket #171, 188
The code was pretty straightforward using localStorage in the DOM.  I was a bit concerned about the tests slowing down my computer (as I could hear it struggling).  I brought this up to Corban and he said it was fine.  It was due to the strings being saved every time the canvas is redrawn (which was a lot).  I passed it for super-review.

Ticket #205
This was already pre-tested by me.  I used the tests that I wrote and plugged in sephr’s code.  It works well and is more efficient so I backed it and passed it for super-review.

Next release…

With 0.4 set, I am looking out for the next release.  Unfortunately, the code I checked in for 0.3 and that I got reviewed for 0.4 didn’t make the cut.  It was mainly due to my not testing and having a few bugs.  I’m currently working out the bugs and writing tests this weekend for it.  You can keep up with what the 3d squad will be releasing for 0.5 by clicking here.  Now that is a plan to integrate our work and make sure combining it goes smoothly.  Hopefully, it works.  I’ll let you know next week, if not sooner!

Continuing my journey in Open Source…

Just starting OSD700 and I’m a week behind already.  Luckily, the 0.4 release (which is out at the end of this week) involves more review than adding new functions.  We’ve also added some new members to the team… Tiago Moreira, who will be the project manager and release driver.  The other new member is Corban Brooks, who will act as another reviewer to help take the load off Al (aka F1LT3R).

Project Plan for OSD700

My project plan has already shifted.  I was initially going to try to tie up loose ends in my code and re-release my 0.3 code.  However, the group goal for 0.4 is to iron out previous code that may already be approved and put into the library.  So we’re starting a peer-review process and making the check-in process more efficient.  This will help future releases.  So, as far as the 0.4 release goes… there’s not supposed to be any really new code (which means I should postpone my changes until 0.5).  This is somewhat good because my future functions (or trying to take future functions) we’re looking a little bleak.  Anyway on to unveiling my plans:

Release 0.4 – Peer Review and Check-in working code (make sure PMatrix3D gets in)
Release 0.5 – Adjust camera functions to include PMatrix3D and more efficient in-library functions.
Release 0.6 – Pick up matrix functions that Ed Sin (MinyXO) left off with and make sure they get checked in.
Release 0.7 – Finalize any problems with the camera/matrix functions and finish beginCamera and endCamera.
Release 0.8 – Fix and bugs with beginCamera and endCamera.
Release 0.9 – bug fixing?
Release 1.0 – more bug fixing?

Untested (untestable) 0.3

I’ve finally had time to sit down and finish my 0.3 release.  It’s way late and I know I have several people waiting on parts of this release.  Andor has mentioned in several of his posts the reason as to why this release is untested or untestable.  I wish I could’ve had time to get together and work on this more with the group but things always got in the way, especially exams.  Anyway, my commit for 0.3 can be found by clicking here.  The tickets can be found here.

To describe them quickly, they’re the camera, ortho, perspective and frustum functions.  They required some calculations.  What ends up happening is after the calculations, the information gets put in a 3d matrix (which is essentially a 16 slot array).  I also created a primitive 3d matrix stack.  I’ll add more functions as they are required.  If you have any function requests for the stack, please place them in the ticket.

Now, this release will probably need more upgrades.  I can safely say that already because MinyXO created a PMatrix3D object, which makes for easy use of 3D matrices.  I’ll have to modify the functions and variables I’ve created to reflect that addition to Processing.js once it’s added.  So, that will probably be part of my 0.4 release as I’ve indicated on my tickets already.

Hopefully, with more free time over the holidays, I can talk to some of the group and get some testing done for my release.