Dr. Drang:
I guess the real question is whether those who’ve signed up for app.net are actually prepared to leave Twitter for it. So far, it looks like most of them are still tweeting, and I’m curious as to how many of them can leave.
I get why people are looking for a Twitter alternative, but using Twitter plus another service doesn’t seem to be a very good solution. And the robotweeting and having to pay to reserve your username leave a bad taste.
Alex Hillman:
App.net is a fascinatingly similar Rorschach test on the community surrounding it. It’s a mirror, it reflects back to them what they want and care about. And people are spending $50, $100, & $1000 at a time based on what they believe the creator intends to do. Dalton has stated his intentions, to a point, but most of the 3rd party discussion has turned to speculation.
Dave Winer:
What seems very unlikely to me is that the new thing will fall neatly in place on one company’s servers, or even with one company’s servers at the center. It’s never been that way.
Clark Goble:
The main debugger, lldb, comes with Python built in! […] it appears you can actually have a Python script run when a breakpoint gets hit. The current stack frame and breakpoint location are passed to your function.
I tend to instrument my code because I really dislike clicking around in the debugger. This seems to have a lot of potential for making debugging faster.
Update (2012-08-15): Clark Goble:
What you could do to make the above function a tad more useful is keep a global counter that is incremented in every call to the Python function and then increment the column in Numbers by the same amount. That’ll give you a nice spreadsheet listing variables and their value according to time. More than a slight bit more readable than trying to traverse the output of numerous NSLog calls. You could even write a script that reads the values in say the first column down, treating them as variable names, and then print their values.
Update (2012-08-16): Clark Goble:
When you print things from your Python scripts the first time off a break not everything will print. At first I thought Python-lldb weren’t seeing all the variables. However everything gets copied to the spreadsheet properly. So it’s really a bug in Xcode where all the text output isn’t getting displayed correctly. This is useful to know if you start relying on lldb and scripting. Interestingly the second time you run your script on a single breakpoint the problem disappears. Until you advance your position in code whereupon it all begins again. Undoubtedly a small bug that will be fixed in a future Xcode version.
John Gruber:
I’ve been staring at a variation of that cursor since the 1980s. Perfectly vertical on the left, stair-stepped at precisely 45° on the right. Now, though, on this machine, it’s a perfect arrow, as perfectly un-jaggedly straight on the diagonal as it is on the vertical.
I think this is one of those cases where the technology was inevitable, but Apple getting behind Retina displays will really speed up their adoption. As Gruber says, you kind of have to see it to believe it. I hope that my external display holds up, but I don’t want to buy a new one that’s non-Retina.
Incidentally, Daring Fireball has now been a top-quality site for ten years. Congratulations. That’s about as long as I’ve been following other Mac writers and developers via RSS and writing my own blog. I hope that we’ll all be around in another ten.
Glenn Fleishman and Jeff Carlson:
You could set up device-specific iMessage accounts and mark each as the Caller ID sender for its particular device. This is a little absurd, but it would work for enabling you to receive an incoming message on all devices, but have subsequent replies directed only to a particular device. For example, Glenn could set up glenn@tidbits.com on each of his devices, so iMessages to that address would show up everywhere. But, if the Caller ID address for his Mac was glenn-osx@tidbits.com and his iPhone was glenn-iphone@tidbits.com, responses to his iPhone-generated replies would come back solely to the iPhone. Similarly, when he initiates a conversation from a given device, his recipient doesn’t need to know that’s where it comes from; they just reply.
