Well, this makes the third or fourth formal occasion on which I’ve heard David Weinberger talk about weblogs, and I think (if he’s sick or indisposed, or double-commits himself) I’m getting the presentation down well enough to sub for him. But that catch is, he’s great, and the point of these presentations isn’t simply to find out something about weblogs — I mean, there were a bunch of people at the talk who have no particular reason to learn more about weblogs — but to listen to David, who is not only an ambassador from the tech world to the civilian establishment, but is also a magnificently gifted communicator. Jack Vinson blogged the talk, for which he had the benefit of having seen David talk when he came to Seabury.
Posted by AKMA at June 1, 2003 09:32 AM | TrackBackThanks for your presence and contribution at the DG conference. I'm sorry I didn't have more opportunity to speak with you in person ...
I'm spending a bit of time exploring the blog-space around the conference and have started with your summaries here. Are you aware of any indexing of other blogs concerning the conference. I'm guessing Alex won't be getting to this soon since he has many other pressing matters, and perhaps someone else has already done this. The URL above is sort-of my highly "techie" blog, where I just drop files in a directory on my hosting server and let the web server index and timestamp them. I'm planning on writing up some of my thoughts from the conference and more. I've skimmed a little of the disseminary site, and am quite impressed by the vision and quality. I'll probably write more about this as well.
Let's take a moment to reexamine that. What we've done here is create two variables. The first variable is in the Heap, and we're storing data in it. That's the obvious one. But the second variable is a pointer to the first one, and it exists on the Stack. This variable is the one that's really called favoriteNumber, and it's the one we're working with. It is important to remember that there are now two parts to our simple variable, one of which exists in each world. This kind of division is common is C, but omnipresent in Cocoa. When you start making objects, Cocoa makes them all in the Heap because the Stack isn't big enough to hold them. In Cocoa, you deal with objects through pointers everywhere and are actually forbidden from dealing with them directly.
Posted by: Hercules at January 12, 2004 10:18 PMWhen a variable is finished with it's work, it does not go into retirement, and it is never mentioned again. Variables simply cease to exist, and the thirty-two bits of data that they held is released, so that some other variable may later use them.
Posted by: Arnold at January 13, 2004 11:50 AMWhen a variable is finished with it's work, it does not go into retirement, and it is never mentioned again. Variables simply cease to exist, and the thirty-two bits of data that they held is released, so that some other variable may later use them.
Posted by: Justinian at January 13, 2004 11:50 AMInside 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: Joshua at January 13, 2004 11:50 AM