Programming Gems (on GemStone)

In preparation for a class in January, I’m studying Computer Graphics. I’ve spent several hours getting OpenGL working in my environment so I can try out some of the examples. This blog post will describe the steps I’ve taken (that now seem very simple!).

My use case is running Ubuntu Server 18.04.3 as a guest using VMware Fusion 11.5.1 on macOS 10.15.1 as a host.

XQuartz on macOS

Install XQuartz then, from a Terminal, configure it to enable indirect GLX:

defaults write org.macosforge.xquartz.X11 enable_iglx -bool true

Now you can log in to your Ubuntu machine by name or IP:

ssh -Y ubuntu

The remaining commands are in Ubuntu.

Update Ubuntu

sudo apt update
sudo apt upgrade -y
sudo apt dist-upgrade -y
sudo apt autoremove -y

Basic C/C++ Development

Install the basic C/C++ development tools:

sudo apt install -y build-essential

Create a test C program using your favorite Ubuntu editor:

// hello.c
#include <stdio.h>
int main()
{
   printf("Hello, World (from C)!\n");
   return 0;
}

From the shell, compile and run the program:

gcc hello.c; ./a.out

Create a test C++ program:

// hello.cpp
#include<iostream>  
using namespace std; 
int main() 
{ 
     cout<<"Hello World (from C++)!" << endl; 
    return 0; 
} 

From the shell, compile and run the program:

g++ hello.cpp; ./a.out

X11

Install X11 on your Ubuntu machine:

sudo apt install -y xorg xorg-dev

Test the X11 install by running a command in Ubuntu to open a clock on your macOS desktop:

xclock &

OpenGL

Install OpenGL on your Ubuntu machine:

sudo apt install -y mesa-common-dev mesa-utils freeglut3-dev 

Test the OpenGL install by running a command in Ubuntu to open a picture on your macOS desktop:

glxgears &

This may report an error: “Error: couldn’t find RGB GLX visual or fbconfig.” As best I can tell, OpenGL does not like the video driver provided by VMware Fusion. A workaround is to install a driver that it recognizes, and try again:

sudo apt install -y nvidia-340
glxgears &

Calling OpenGL from C/C++

Create glut-starter.c. From the shell, compile and run the program:

gcc glut-starter.c -lGL -lGLU -lglut -lm; ./a.out

Create openGL.cpp

// http://www.codebind.com/linux-tutorials/install-opengl-ubuntu-linux/
#include <GL/glut.h>
 
void displayMe(void)
{
    glClear(GL_COLOR_BUFFER_BIT);
    glBegin(GL_POLYGON);
        glVertex3f(0.5, 0.0, 0.5);
        glVertex3f(0.5, 0.0, 0.0);
        glVertex3f(0.0, 0.5, 0.0);
        glVertex3f(0.0, 0.0, 0.5);
    glEnd();
    glFlush();
}
 
int main(int argc, char** argv)
{
    glutInit(&argc, argv);
    glutInitDisplayMode(GLUT_SINGLE);
    glutInitWindowSize(400, 300);
    glutInitWindowPosition(100, 100);
    glutCreateWindow("Hello world!");
    glutDisplayFunc(displayMe);
    glutMainLoop();
    return 0;
}

From the shell, compile and run the program:

g++ openGL.cpp -lglut -lGLU -lGL; ./a.out

Conclusion

I’ll be giving this as instructions to some students in January. If you find issues or have questions, let me know in the comments.

Booch’s classic book on OO (now in its third edition with five co-authors) is an excellent introduction to object-oriented concepts. I read the second edition in the 1990s when I was learning Smalltalk and I find myself still visualizing some of the images or figures used to illustrate the concepts (especially the cat) when I think about OO. This year I taught a 10-week undergraduate course on OO and used Booch’s book as a primary text (I also use a Booch video on the history of computing in a survey class). This gave me a chance to revisit the text in detail a couple decades after I was introduced to it.

Although the book has aged well, I found that there were a few areas where I wanted to respond. These comments or criticisms should be taken in the larger context of my appreciation for the book and its influence on me and others.

Aggregation

Aggregation is introduced in the discussion on Relationships among Objects (section 3.2 of the 3rd edition). Booch describes “two kinds of objects relationships [that] are of particular interest”, links (denoting a peer-to-peer relationship) and aggregation (denoting a whole/part relationship).

Booch asserts (p. 91), “By implication, an object that is part of another object has a link to its aggregate [emphasis added].” I believe that the the link is from the aggregate (whole) to the part. I’m not sure if this is a typo or if I’m not understanding the vocabulary.

Booch continues with a discussion of “physical containment”:

Aggregation may or may not denote physical containment. For example, an airplane is composed of wings, engines, landing gear, and so on: This is a case of physical containment. On the other hand, the relationship between a shareholder and his or her shares is an aggregation relationship that does not require physical containment. The shareholder uniquely owns shares, but the shares are by no means a physical part of the shareholder. Rather this whole/part relationship is more conceptual and therefore less direct than the physical aggregation of the parts that form an airplane. [p. 92]

Is this simply suggesting that objects can represent both physical and conceptual things? If so, then why discuss it as part of aggregation? Or is there more intended here? Is there a type of aggregation that includes ‘containment” and a type that doesn’t? If there is “physical containment,” is there also “non-physical containment”, or is containment only (always?) for physical objects? Could you have aggregation of physical things (say, a fleet of vehicles) without them being bolted together? The suggesting that some types of aggregation are “less direct” seems to allude to the aggregation vs. composition discussion (ownership and lifetime), discussed next.

Finally, section 3.2 ends with the assertion that “There are clear tradeoffs between links and aggregation [emphasis added].” I don’t see the clear distinction, or how links permit looser coupling.

Physical Containment and Composition

Section 3.4, Relationships among Classes, returns to the topic of aggregation, and under the heading Physical Containment, explains that with “physical containment … [an] object does not exist independently of its enclosing” aggregate. “Rather, the lifetimes of these two objects are intimately connected” such that if the whole is destroyed, by implication we also destroy the part. [p. 110] But returning the the aircraft example from page 92 above, it doesn’t seem to be necessary that an engine’s lifetime (or that of the seat-back entertainment system) is tied to the airplane on which it is installed. It can be (more or less easily) unbolted and moved to another aircraft.

Continuing on page 110, Booch introduces “A less direct type of aggregation …, called composition, which is containment by reference. … [Here] the lifetimes of these two objects are not so tightly coupled as before: We may create and destroy instance of each class independently.”

A few chapters later, in section 5.7, Class Diagrams, Booch returns to a discussion of aggregation (to describe the notation). Here, “composition (physical containment)” is described as parts that “are defined as having no meaning outside the whole, which owns the parts; their lifetime is tied to that of the whole.” [p. 196]

So, on page 110 composition is “not so tightly coupled” and objects can be created and destroyed independently. But on page 196 composition is equivalent to physical containment and tightly coupled. I think that the later discussion is consistent with the remainder of the book (and with the outside references I’ve found), so I think that the earlier discussion is wrong.