Using scp on a directory/file with spaces

The protocol when copying/moving a file that has spaces in the filename in a terminal window is to use “\ “, or

cp ~/some\ directory/some\ thing.zip ~/destination/

Oddly enough, scp doesn’t employ the same protocol.  Instead, I’ve found that this works:

scp 'myname@location:"~/some directory/some thing.zip" ' ~/destination/

That is, wrap the entire call after scp in single quotes, and the path in double quotes

Or an easy solution: don’t put spaces in filenames or directories

Adapting Your Makefile To Work On Any Operating System

Like most developers, I test my code on multiple different types of operating systems. While this is a good practice, it can become very annoying reassigning libraries and paths that are operating system-dependent. It would be nice if there was a way to tell a Makefile to use a certain set of paths if you’re using linux, and another set if you’re using a Mac.

But there is a way! Here’s how:

One example where this comes up is when you’re compiling code that requires OpenGL. To compile in linux, you type:

-lGL -lGLU -lglut

whereas in Mac OS X you would type:

- framework GLUT -framework OpenGL -framework Carbon -L”/System/Library/Frameworks/OpenGL.framework/Libraries”

and in Windows you would type:

-lopengl32 -lglu32 -lglut32

So to tell the makefile to use either version depending on your operating system by employing the “shell uname” command:

LIBPATH = -lGL -lGLU -lglut

ifeq "$(shell uname)" "Darwin"
LIBPATH = -L"/System/Library/Frameworks/OpenGL.framework/Libraries"
LIBPATH = -framework GLUT -framework OpenGL -framework -Carbon
endif

if  "$(shell uname)" "Windows_NT"
LIBPATH = -lopengl32 -lglu32 -lglut32
endif

We set the linux variables as default by initializing those first. Then by comparing what’s returned by “shell uname” we can alter the variables accordingly. Using this as a template should adjust your makefile accordingly.

Shaders in Java

I’ve recently started developing shaders in Java. Shaders are a set of software instructions used to calculate rendering effects on graphics hardware.  More specifically, they usually come coupled as two types of shaders: vertex and fragment (or pixel) shaders. There are also geometry shaders but these are less implemented. Shaders are used to program the graphics processing unit (GPU) rendering pipeline to allow for customizable geometry transformations and shading functions. To be more specific, we consider this image:

where the business-as-usual diagram of the graphics pipeline is shown on the top. What shaders do is redirect the pipeline so it processes the vertex processing and fragment processing how you want.  Note that setup and rasterization is left undisturbed, so interpolation (for example) is still being implemented by the hardware. Yay!

The language that is typically used (not always) it called GLSlang, or simply GLSL. Basically by making a few extra calls to OpenGL one can implement their own vertex and fragment shader algorithms. The shaders are written as a basic text file (extension is arbitrary – I’ve seen .glsl, .vertex, .fragment, .fp, .vp, .shd, etc. I use .glsl to avoid confusion). There is an extension to VIM to allow syntax highlighting, so for VIM users who use shaders this is useful.  Then by reading in the text file the user can compile and apply their shader algorithm. Let me emphasize that GLSL is its own language. It’s roughly based off C, and follows much of the guidelines that C and Java do, in that clauses are concluded with semicolons, and functions are wrapped in brackets, etc. For more information I recommend that you consult the OpenGL Orange Book. While there are quite robust methods of programming GPUs, it is not quite standardized as of yet (note CUDA, HLSL, Cg, and the list continues).

So, why do we want to use shaders? Put succinctly, shaders are written to apply transformations to a large set of pixels at a time. Meaning, shaders are well suited to parallel processing, and most modern GPUs have multiple shader pipelines to facilitate just that, thus dramatically reducing the computation time of rendering processes.

Using shaders in Java requires almost less effort than in C (I know — tell me what’s new). For example, forget using the OpenGL Extension Wrangler, or GLEW. This is unnecessary. What you need to look out for is how to load the files. Since shaders are essentially just text files, you want to load in the shader file as a String object. I find that this helps tremendously:

FileInputStream f = new FileInputStream(fileName);
int size = (int)(f.getChannel().size());
byte[] source = new byte[size];
f.read(source,0,size);
f.close();
return new String(source,0,size);

where, assuming this is embedded in a function that returns a String, this will read in the file to allow the function glCompileShader (or glCompileShaderARB) to compile your shader function.

Below is a very simple Java class I’ve created which reads in a shader file that can be called later for compilation. It’s very straightforward, and if you’re programming the GPU using shaders in Java this may be very useful. I might add more later if I see fit.

Using Python’s Core Graphics bindings in Snow Leopard

If you’ve recently upgraded to Snow Leopard, you may have noticed that you can’t import Core Graphics in Python. Each Mac is built off its Core Graphics framework, which includes the pair of Mac OS X technologies Quartz 2D and the Quartz Compositor. Following the transition from Leopard to Snow Leopard, Apple updated the Python binaries to be (by default) 64-bit. The CGBindings did not survive this transition (mistake? oversight?). When you try to import CoreGraphics into Python you may receive the following error:

ImportError:
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/
CoreGraphics/_CoreGraphics.so: no appropriate 64-bit architecture
(see "man python" for running in 32-bit mode)

The bindings are still available to 32-bit Python, however. One workaround (as suggested by Jaharmi) is to specifically set your preferred python version to 32-bit:

$ export VERSIONER_PYTHON_PREFER_32_BIT=yes

This will set your Python to run in 32-bit mode. Is this what you want? Not necessarily… we are given the 64-bit binaries hence we want to use them for development. After all, Snow Leopard operates off a 64-bit hybrid kernel. This is simply a workaround.

While you can use CGBindings for 32-bit Python, you must use PyObjC to replace their functionality in the default 64-bit system. It seems Apple wants to completely switch over to this completely and in the meantime has offered a grace period for transition. Therefore making the switch is inevitable, albeit inconvenient.

Enabling the stencil buffer in JOGL (OpenGL & Java)

In OpenGL the stencil buffer is used to mask pixels on the screen. This can be used for shadow volume rendering, as well as a myriad of other applications. Constructing stencil tests is the same as in C, for example glStencilFunc(GL_KEEP,GL_KEEP, GL_INCR); is just as valid in Java.  However, if you’re noticing that your stencil test is always passing, i.e. your stencil bits are always returned as 0, then you probably haven’t initialized the stencil bits.

In order to use stencil tests, you MUST (emphasize MUST) request stencil bits to the canvas.  Otherwise, the test will always pass. This isn’t incredibly well documented for JOGL… It took a few days of internet searching until I found a breadcrumb of help on this.  In C, one would be using GLUT, so calling glutInitDisplayMode() would be the function to call to request stencil bits.  In Java, this is in the GLCapabilities object.

So, to request stencil bits, in your init() function, put:

GLCapabilities cap = new GLCapabilities();
cap.setStencilBits(8);
GLCanvas canvas = new GLCanvas(cap);

or incorporate this into your code wherever deems fit.  Basically this says, initialize new GLCapabilities, and assign 8 bits in the stencil buffer. Then when you create your GLCanvas, set it as a parameter.  Now you’re good to go, and your stencil tests should work!

Getting Matlab 2009 and Snow Leopard To Play Together

If you’re one of the thousands of Mac OS 10.6 users, and you want to run the new version of Matlab (2009a or 2009b), you may run into the error where it’s trying to find “libactivation.jnilib”.  More specifically, you may read a error that says:

Can’t load library: /Applications/MATLAB_R2009aSV.app//bin/maci64/libactivation.jnilib

If you go to the directory /Applications/MATLAB_R2009aSV.app/bin/ most likely you don’t actually have a directory maci64.  The reason it’s looking for that directory is because your Java Preferences are set to 64-bit.  This is the default Java Preference for 10.6.  10.5 it was 32-bit, and now it’s 64.  What Matlab does is it detects what your JRE is set to and then looks accordingly.  Problem is, the Matlab available for MAC is 32-bit only.

To fix this, open up /Applications/Utilities/Java Preferences.app.  When it loads, click and drag to put the 32-bit Java Application setting to come first (see image).

Make sure your Java Application is set to 32-bit

Now it should work just fine.

Drawing an Ellipse in OpenGL

So earlier I alluded to how you can go about drawing an ellipsoid in OpenGL.  I’ve also noticed a lot of people have been coming to this site expecting to find a tutorial on drawing ellipses (2D).  This is a quick how-to on building these.  It’s short, and to the point, but this works.

We first parametrize the equation of an ellipse (in the X-Y plane) centered at (x,y,0):

In this case, we’re parametrizing over , and and are the major axes lengths.  To implement this in programming, we can build the “vertices” of in a loop:

float[] a = new float[3*361]; // 3-coordinates and 361 angles
for (int i=0; i<=360; i+=3) {
    a[i+0] = x+(float)cos(i*PI/180)*rx; // X
    a[i+1] = y+(float)sin(i*PI/180)*ry; // Y
    a[i+2] = z;                         // Z
}

Drawing it using GL_LINE_LOOP will then render a completed ellipse:

When both axes are equal, you create a circle

Differing radii will render an ellipse

Organizing Your Research PDFs on a Mac: Papers

If you’re like me, say you’re in research or academia, you are constantly reading research papers.  In the old days, you would print off these papers and then organize them in folders or in stacks on your desk.  Well, my desk isn’t that big.  And paper and ink is expensive so the nowadays most people keep their research papers on their computers in the form of PDFs.  There are pros and cons of doing this, and I will talk about how to fix the biggest con which is organizing these beasts.  If you have and use Firefox, then you’ve probably heard of Zotero, which is a Firefox plugin that manages all your research documents.  There are two requirements to use this however: you must be a user of Firefox (I am not anymore), and you must be online (What if you took your laptop to a café with no WiFi?)  There are also two very big Pros to this program: it’s free, and it can export to BibTeX.

I don’t use Firefox anymore, the newest version of Safari works perfectly for me without the fluff.  So, Zotero is out.  Plus I wanted a standalone program to use.  In comes Papers.  Papers was designed specifically for research and technical papers to organize.  It allows you to specify all the properties to be able to export to BibTeX, and even organize in different categories and subjects.  It even has a myriad of built-in search engines designed to find technical papers, such as Google Scholar, Citeseer, ACM, PubMed, etc.  These search engines can also help you complete the meta information for these papers.

Papers organizes your PDFs much like iTunes organizes your music.  It copies the PDF (and optionally deletes the original) to a directory where it organizes it based on a scheme of your choosing.  This is handy because before, and with Zotero, it just points to where the paper is.  So if you do any future organization, the links are broken and have to be reestablished.  This is annoying.

The downside?  It ain’t free.  It costs $42.  But in my experience, a lot of these types of programs really fall short on what they offer in simplicity, reliability and usability.  I did the free 30 day trial and I was satisfied enough to pay the money for it.

What they need to create is a program that parses the PDFs to grab the information, but that has yet to be done properly.

Screenshots.

Papers fits in very well with iWork

You can browse all your papers in the library (click for large)

You can also preview/read your PDFs directly in the program (click for large)

Editing Your Vim Parameters: .vimrc and .gvimrc

If you’re a programmer then you probably have heard of Vim.  Vim is a great text editor but the beauty lies in the syntax highlighting.  The idea is to be able to move swiftly through your code without lifting your fingers from the keyboard.  A mouse-less text editor.  It takes a little bit of practice, but won’t take long to learn.  If you’re running linux, you can grab it through apt-get, if you’re on a Mac, the check out MacVim, and Windows users should go through the Vim website.  To learn, after you’ve installed Vim type “vimtutor” in a terminal and start practicing, I won’t go into how to operate this here.

Vim currently supports a load of programming languages for syntax highlighting.  Although, I’m upset that there isn’t built-in support for Scala yet, you’ll have to find that file elsewhere.

Now that you have your GVim editor (Graphical Vim), you can edit some of its properties.  In comes the two files: .vimrc and .gvimrc.  The first file should already exist within your home directory, and the latter you may need to create (within your home directoy as well).

There are a number of settings you can manually set.  For my .gvimrc, for example, I have this:

</div>
<div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">set lines=40</div>
<div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">set columns=78</div>
<div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">set guioptions-=m</div>
<div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">set guioptions-=T</div>
<div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">set guifont=Monaco:h13</div>
<div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">

set lines=40
set columns=78
set guioptions-=m
set guioptions-=T
set guifont=Monaco:h13

This sets the lines, columns, font type and size, as well as disables that ugly toolbar.  Basically what you’re left with is a clean window for editing:

Programming simplicity

The .vimrc file has many options for you to throw in, and instead of listing everything, here are useful links to get you on your way:

• Jonathon McPherson: .vimrc and customization
• Vim Tips Wiki
• Vimdoc Sourceforge

Approximating an Ellipsoid In OpenGL Part Two: Recursively Subdivide

While an icosahedron hardly looks like a sphere (unless you are looking at it from far away), we can easily approximate a sphere.  This is taken directly out of The Redbook, and adapted for Java: (For more information I recommend checking out this great book)

float[] v1, float[] v2, float[] v3, float depth)
{
float[] v12 = new float[3];
float[] v23 = new float[3];
float[] v31 = new float[3];

// If done, add the final vertices and return.
if (depth==0) {
      // Do what you will with the vertices here
      return;
    }
// Find the midpoint.
for (int i=0; i<3; i++) {
v12[i] = (v1[i]+v2[i])/2.0f;
v23[i] = (v2[i]+v3[i])/2.0f;
v31[i] = (v3[i]+v1[i])/2.0f;
}

// Normalize the coordinates.
v12 = normalize(v12);
v23 = normalize(v23);
v31 = normalize(v31);

// Recursively subdivide
subdivide(v2,v23,v12,depth-1);
subdivide(v1,v12,v31,depth-1);
subdivide(v3,v31,v23,depth-1);
subdivide(v12,v23,v31,depth-1);
}

To break this down, we divide each segment in half.  To do this we must calculate the midpoint as shown above.  Next, we normalize each of those coordinates by using a function (which I called normalize) that can do whatever process you want to acquire the appropriate distance from the center.  (Purposefully being vague, but it’s not hard to figure out.)  We then take those new vertices and pop them into the recursion once again.  This will repeat until we’ve reached our target approximation.

Proper recursive subdivision will turn out icosahedron into a believable sphere.

0 recursion

Single recursion

Two recursions

Enough recursions will yield a nice sphere