@Thameera is developer and a hacker I know for sometime who likes to make new things. Like typing.lk which he made last year that trended on Hacker News, this year @thameera and to @malithsen made their newest hack, an idea that I wanted to make for some time now, called Best at LK.

If you haven’t seen it yet go check it out at bestatlk.com.

Best at LK shows popular tweets, tweeted by Sri Lankan twitter users in real time. I wanted to make something like this because there are more and more users joining Twitter from the country and everyday they make up good hash tags and Tweet funny things. I wished if we can get all these hashtagged tweets in to one place and read them later whenever we can. I think *Best at LK* is something that’s on the way of doing that.

I’d like to make some feature requests that I’d like to see,

• Display of currently popular hashtags and topics, maybe in a separate page or in the main page. The current version has a timeline that’s mixed with different hashtagged tweets.
• A set of upcoming hashtags that users have started to tweet but is not popular yet, however maybe popular later.
• An archive of hashtags that were popular in the past with their tweets, so we can come and read them in a later time.

I wish them luck on their new project.

Have you ever opened a core dump with gdb, tried to print a C++ std::vector element, and got the following?

(gdb) p v[0]
You can't do that without a process to debug.

So after seeing this for years, my thoughts traveled along the path of, we could make a process out of the core dump.

No really, there used to be Unices with a program called undump that did just that. All you need to do is take the (say) ELF core dump file and generate an ELF executable file which loads the memory image saved in the core (that's actually the easier, portable part) and initializes registers to the right values (the harder, less portable part). I even wrote a limited version of undump for PowerPC once.

So we expended some effort on it at work.

And then I thought I'd just check a live C++ process (which I normally don't do, for various reasons). Let's print a vector element:

(gdb) p v[0]
Could not find operator[].
(gdb) p v.at(0)
Cannot evaluate function — may be inlined.

Very funny, gdb. "You can't do that without a process to debug". Well, I guess you never did say that I could do that with a process to debug, now did you. Because, sure enough, I can't. Rolling on the floor, laughing. Ahem.

I suggest that we all ditch our evil C arrays and switch to slow-compiling, still-not-boundary-checked, still-not-working-in-debuggers-after-all-these-YEARS std::vector, std::array and any of the other zillion "improvements".

And gdb has these pretty printers which, if installed correctly (not easy with several gcc/STL versions around), can display std::vector - as in all of its 10000 elements, if that's how many elements it has. But they still don't let you print vec[0].member.vec2[5].member2. Sheesh!

P.S. undump could be useful for other things, say a nice sort of obfuscating scripting language compiler - Perl used to use undump for that AFAIK. And undump would in fact let you call functions in core dumps - if said functions could be, um, found by gdb. Still, ouch.

P.P.S. What gdb prints and when depends on things I do not comprehend. I failed to reproduce the reported behavior in full at home. I've seen it for years at work though.

Kevin Kelleher suggested an interesting way to compare programming languages: to describe each in terms of the problem it fixes. The surprising thing is how many, and how well, languages can be described this way.

Algol: Assembly language is too low-level.
Pascal: Algol doesn't have enough data types.
Modula: Pascal is too wimpy for systems programming.
Simula: Algol isn't good enough at simulations.
Smalltalk: Not everything in Simula is an object.
Fortran: Assembly language is too low-level.
Cobol: Fortran is scary.
PL/1: Fortran doesn't have enough data types.
Ada: Every existing language is missing something.
Basic: Fortran is scary.
APL: Fortran isn't good enough at manipulating arrays.
J: APL requires its own character set.
C: Assemby language is too low-level.
C++: C is too low-level.
Java: C++ is a kludge. And Microsoft is going to crush us.
C#: Java is controlled by Sun.
Lisp: Turing Machines are an awkward way to describe computation.
Scheme: MacLisp is a kludge.
T: Scheme has no libraries.
Common Lisp: There are too many dialects of Lisp.
Dylan: Scheme has no libraries, and Lisp syntax is scary.
Perl: Shell scripts/awk/sed are not enough like programming languages.
Python: Perl is a kludge.
Ruby: Perl is a kludge, and Lisp syntax is scary.
Prolog: Programming is not enough like logic.