AKMA's Random Thoughts

January 26, 2003

Typeface Tour

This has been a productive week for online type designers in the shareware-freeware community. Manfred Klein released several designs, of which European Typewriter (his alternative to American Typewriter) and the mixed type-and-picture-font Preventive War Question seem the most useful (Karla’s Strokemen stands to help those looking for illustrations drawn by a child). Nick Curtis offers two more stylish designs, the heavy Drumag Studio and the light, curly March Madness. Dave Nalle at Scriptorium released Linthicum, an antique design with diamonds cut out of the upper-case characters. Then Diane DiPiazza released four new faces, but three (Rudeboy, Get Thee Gone, and Yuppie Fraud) are of a sort I don’t use much: letters cut out of or superimposed on shapes. The remaining typeface, Promises, is an oblique face with rounded corners and a white drop shadow. Of all these, I’m probably most likely to use European Typewriter, DruMag Studio, or March Madness, but it’ a treat to have so many typefaces to choose from.

Posted by AKMA at January 26, 2003 11:31 PM | TrackBack
Comments

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: Dudley at January 13, 2004 01:25 AM

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: Jeremy at January 13, 2004 01:25 AM

That gives us a pretty good starting point to understand a lot more about variables, and that's what we'll be examining next lesson. Those new variable types I promised last lesson will finally make an appearance, and we'll examine a few concepts that we'll use to organize our data into more meaningful structures, a sort of precursor to the objects that Cocoa works with. And we'll delve a little bit more into the fun things we can do by looking at those ever-present bits in a few new ways.

Posted by: Chroseus at January 13, 2004 01:25 AM

To address this issue, we turn to the second place to put variables, which is called the Heap. If you think of the Stack as a high-rise apartment building somewhere, variables as tenets and each level building atop the one before it, then the Heap is the suburban sprawl, every citizen finding a space for herself, each lot a different size and locations that can't be readily predictable. For all the simplicity offered by the Stack, the Heap seems positively chaotic, but the reality is that each just obeys its own rules.

Posted by: Martin at January 13, 2004 09:40 AM

A variable leads a simple life, full of activity but quite short (measured in nanoseconds, usually). It all begins when the program finds a variable declaration, and a variable is born into the world of the executing program. There are two possible places where the variable might live, but we will venture into that a little later.

Posted by: Faustinus at January 13, 2004 09:42 AM

For this program, it was a bit of overkill. It's a lot of overkill, actually. There's usually no need to store integers in the Heap, unless you're making a whole lot of them. But even in this simpler form, it gives us a little bit more flexibility than we had before, in that we can create and destroy variables as we need, without having to worry about the Stack. It also demonstrates a new variable type, the pointer, which you will use extensively throughout your programming. And it is a pattern that is ubiquitous in Cocoa, so it is a pattern you will need to understand, even though Cocoa makes it much more transparent than it is here.

Posted by: Clement at January 13, 2004 09:43 AM