AKMA's Random Thoughts

August 27, 2003

Photo Albums

Margaret points out that the Choir Tour photo albums may have been pushed so far down the page by my tedious long-windedness that no one will ever find them again — so look here, here, here, here, here, here, here, and here for photos from St. Luke’s Choir Tour, 2003.

As a side note, someone at Apple ought to make it possible to add photos to an album page once the page has already been started. For instance, if I wanted to add a picture of Mr. Fennig or Mr. Taipala (who eluded my camera in the individual photo sessions), I’d have top go through all sorts of baroque rigamarole to include them on the portraits page. That ought to be easy-peasy, as they say.

Posted by AKMA at August 27, 2003 09:47 AM | TrackBack
Comments

The rest of our conversion follows a similar vein. Instead of going through line by line, let's just compare end results: when the transition is complete, the code that used to read:

Posted by: Geoffrey at January 12, 2004 07:04 PM

Inside each stack frame is a slew of useful information. It tells the computer what code is currently executing, where to go next, where to go in the case a return statement is found, and a whole lot of other things that are incredible useful to the computer, but not very useful to you most of the time. One of the things that is useful to you is the part of the frame that keeps track of all the variables you're using. So the first place for a variable to live is on the Stack. This is a very nice place to live, in that all the creation and destruction of space is handled for you as Stack Frames are created and destroyed. You seldom have to worry about making space for the variables on the stack. The only problem is that the variables here only live as long as the stack frame does, which is to say the length of the function those variables are declared in. This is often a fine situation, but when you need to store information for longer than a single function, you are instantly out of luck.

Posted by: Ebulus at January 12, 2004 07:04 PM

We can see an example of this in our code we've written so far. In each function's block, we declare variables that hold our data. When each function ends, the variables within are disposed of, and the space they were using is given back to the computer to use. The variables live in the blocks of conditionals and loops we write, but they don't cascade into functions we call, because those aren't sub-blocks, but different sections of code entirely. Every variable we've written has a well-defined lifetime of one function.

Posted by: Paul at January 12, 2004 07:04 PM

Note the new asterisks whenever we reference favoriteNumber, except for that new line right before the return.

Posted by: Barnabas at January 13, 2004 12:56 PM

Each Stack Frame represents a function. The bottom frame is always the main function, and the frames above it are the other functions that main calls. At any given time, the stack can show you the path your code has taken to get to where it is. The top frame represents the function the code is currently executing, and the frame below it is the function that called the current function, and the frame below that represents the function that called the function that called the current function, and so on all the way down to main, which is the starting point of any C program.

Posted by: Juliana at January 13, 2004 12:56 PM

Since the Heap has no definite rules as to where it will create space for you, there must be some way of figuring out where your new space is. And the answer is, simply enough, addressing. When you create new space in the heap to hold your data, you get back an address that tells you where your new space is, so your bits can move in. This address is called a Pointer, and it's really just a hexadecimal number that points to a location in the heap. Since it's really just a number, it can be stored quite nicely into a variable.

Posted by: Charles at January 13, 2004 12:57 PM