AKMA’s Random Thoughts

AKMA, I don't know you in RL so I don't know if you typically get worried about your sermons. If so, let me say simply that in my 'world,' you have nothing to be concerned about. I thought the Thursday sermon was terrific. I would only add that when we think about oppressed people, we sometimes forget to celebrate the resourcefulness and creativity that springs forth from them, as their spirit refuses to be squashed.

That said, if for some reason this sermon felt more risky than average, it is perhaps the subject matter. In this day and age, though we believe otherwise, all those 'isms' are still lurking about, like ghosts in broad daylight. Actually, they're more dangerous than your average ghost, since they don't just scare you, they can still draw blood (literal and metaphoric).

In short, you did take a risk, and I thank you for it.

Golly, Sara, thanks for your kinds words. The problem is that I didn’t upload any of the previous drafts; that would clarify the process of editing and refining.

But I don’t finally begrudge the editing, polishing process. That’s how my sermons get good; I just don’t have the capacity to honor my accountability to Scripture and my theological tradition and the congregation who bothered to come out for the service off the cuff.

And, he added a shade defensively, I only had seven minutes for the Thursday night sermon; there’ a lot more I’d have said if I had the time. Maybe I should have written out another draft!

Well, for a seven minute effort it is most impressive. And, I imagine that over time you'll have a chance to produce other drafts. No good story ever emerges fully formed.

I've always admired people who can preach spontaneously, but am fully aware that I am not among them. As for the Spirit... after doing some worship planning during college and grad school, I concluded that there was empirical evidence for the existence of the Holy Spirit on the grounds that everything came together almost all of the time. But I'm mostly just as glad that my tradition only features the very rare bat kol, especially now that I keep finding myself giving, ah, various sorts of talks in worship settings.

Being able to understand that basic idea opens up a vast amount of power that can be used and abused, and we're going to look at a few of the better ways to deal with it in this article.

Our next line looks familiar, except it starts with an asterisk. Again, we're using the star operator, and noting that this variable we're working with is a pointer. If we didn't, the computer would try to put the results of the right hand side of this statement (which evaluates to 6) into the pointer, overriding the value we need in the pointer, which is an address. This way, the computer knows to put the data not in the pointer, but into the place the pointer points to, which is in the Heap. So after this line, our int is living happily in the Heap, storing a value of 6, and our pointer tells us where that data is living.

When compared to the Stack, the Heap is a simple thing to understand. All the memory that's left over is "in the Heap" (excepting some special cases and some reserve). There is little structure, but in return for this freedom of movement you must create and destroy any boundaries you need. And it is always possible that the heap might simply not have enough space for you.

This code should compile and run just fine, and you should see no changes in how the program works. So why did we do all of that?

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.

Earlier I mentioned that variables can live in two different places. We're going to examine these two places one at a time, and we're going to start on the more familiar ground, which is called the Stack. Understanding the stack helps us understand the way programs run, and also helps us understand scope a little better.