Edson Carvalho

Today is a sad, sad day. Our good friend Edson Carvalho has passed away.
Hoje é um dia muito triste. Nosso bom amigo Edson Carvalho faleceu.

Farewell, my friend. May your courage, your never-ending will to follow your dreams (despite of what others would say), your beautiful voice and your high spirits serve as an inspiration for us all. You will be missed.

Adeus, meu amigo. Que a sua coragem, sua garra para perseguir seus sonhos (apesar do que dissessem os outros), sua bela voz e seu sempre alto astral sirvam de inspiração a nós todos. Sentiremos muito a sua falta.

This is the only solo recording I have of Edson. I'm not sure how old it is, but it shows the great potential in his beautiful tenor voice. I wish things could've been different for this young lad.

No Man's land: or why Brazil is a dump

People being robbed and murdered in broad daylight, people being kidnapped and mutilated for small sums of money, people being forced to change the way they live their lives, trying to dodge an ever increasing mob of criminals that feasts on this scared, powerless population. No, I am not talking about Iraq, or some remote place in Africa that is being decimated by civil wars. I am talking about some other No man's land, I'm talking about Brazil.

Brazil has been going through a long process of decay. There are many things happening, and no single issue is responsible by itself. I will not pretend to understand this process in its full complexity, but there are some things I *do* understand, and those are the ones I intend to share with you here.

The majority of the population no longer has access to education, or public health care. Public schools have underpaid, under qualified teachers. The few good teachers that are left live in constant fear because of the criminals that ride our schools, and have no authority in the classroom, being unable to educate. In fact, the authorities in our schools cannot deal with the kind of violent characters that are infiltrated in there, making our teaching environments as a No man's land as the rest of this country. How can we expect anything good to flourish?

What about our government? What measures are being taken to counter that situation? Well, a few weeks ago I heard that a lobbyist named Cláudio Gontijo has been financing the mistress of the president of our senate, Mr. Renan Calheiros -- in fact, everything points to their relationship being way deeper than that. Now, why do you think this lobbyist would do anything for Mr. Calheiros? Because he looks so good? No, it's because Mr. Calheiros sold our senate to this lobbyist in exchange for personal favors. Now that ought to improve things.

This small story (believe me, that one is nothing compared to what we hear every day) tells what kind of politicians we have in Brazil -- selfish pricks who have no regard whatsoever for what's happening to the rest of the country, and who have no shame in selling the soul of our country to the benefit of no other than themselves.

What about our president, Mr. Lula, the "people's voice"? Oh, he has already expressed his support to Mr. Calheiros during these "difficult times" he must be going through. Mr. Calheiros is an important ally for the government, you know. This mutual "ass covering" points to the fact that our authorities are no longer authorities, they are as criminals as the criminal population they are raising.

This country is a No man's land, and the prognostics do not look good. Looks like non-criminal brazillians will have to accept the fact that their families are going to be murdered while their tax money is used to finance the private endeavors of our politicians.

I love this country.

Being cocky and rude ...

... is the first step to becoming stupid. I've seen enough great minds going to waste because of this. If you're a smart guy, then please, don't be cocky, let alone rude towards those (you think) know less than you do. You might miss a great opportunity to learn something.

No, it hasn't happened to me recently, but I see it happen every day and truly dislike it. We should learn from each other, not shoot at each other. Winning an argument or showing you know more than everyone else shouldn't be your motivation - becoming a better person and better at what you do should.

Cheers.

On implementing symbolic debuggers for languages that get compiled to some closed-source VM bytecodes


That's what I want to do. How do you go on and implement a symbolic (aka source-level) debugger for a language that has an open source compiler and which gets compiled to some Virtual Machine bytecodes? If you're using the Java Virtual Machine, that's a piece of cake. You just have to modify the compiler so that it generates the correct mapping of source code and bytecode in a format that is meaningful to the JPDA. And bang! All of a sudden, you have support for breakpoints, stepping, and remote debugging - just like that, out of the blue. It might not be as easy if you have some weird language that doesn't map very well into the control flow of the bytecodes, but it's a feasible approach for many languages.

Now, the approach works because the class file format is open, because the debugger protocol is open, and because the format of the debugging information is open - you can leverage these in your favor. Suppose, however, that the class file format were open but the debugger protocol were not, and that you didn't have something like the Java Debug Interface to alleviate your pain. Also, suppose that the VM were proprietary and you knew close to nothing about it. Well, that's where I stand. When you have something like that, your only option is adding support for debugging at the bytecode level. Now the question: How do you implement a symbolic debugger at the bytecode level - no VM help at all?

The problem with bytecodes is that they are, from the VM point of view, application-level code. This means you're pretty much restricted to what applications are allowed to do, which might just not be enough when you're trying to build a debugger (except if you're using Smalltalk, LISP, or some other environment with non-mainstream reflective capabilities). Still, I have to build such a debugger - a source-level debugger for a domain-specific language which is based on a closed-source virtual machine with less-than-adequate reflective capabilities.

Sounds like fun. :-) I have a couple of ideas in mind, and all of them seem to impact performance badly. I'll have to try them out one by one, and I promise I'll blog about them (not that anyone cares). :-P

Today I am sleeping on a red bar. I hate sleeping on red bars.

Reborn from the ashes...

I had given up on updating this blog because I thought no-one was reading it. To my surprise, however, we have at least two readers! One of them even subscribed to my RSS feed! Wow! I'm no longer a lonely looser!

Anyway, that's more than enough reason to get this blog up again. I have made significant progress since my last post, and now we even have a couple of screenshots at my website at Eclipse@IME to show off.

As you may probably be aware of, I am developing a distributed debugger for Eclipse. This distributed debugger is actually a composition of other debuggers - and these debuggers are, in turn, symbolic debuggers based on an extended version of the Eclipse debug model (extended for distributed debugging). The distributed debugger may also be seen as a core under which these extended symbolic debuggers will run. I am going to provide, for starters, an implementation of a simplified Java debugger (that can be plugged into the core). I hope I can run the JDT debugger instead of mine one day, however.

What people seem to be missing from what I'm doing, however, is the fact that my debugger isn't just a collection of independent symbolic debuggers running toghether - the Eclipse debug framework already provides that. My debugger implements the concept of a distributed thread to capture and reveal causal relations between the nodes of a distributed system. It also does neat things like remote process management and stream forwarding, but its main point is capturing causal relations and showing them in a meaningful way.

So, how do I do that? Well, as mentioned earlier, I show the distributed system as a collection of distributed threads. What the heck is a distributed thread? A distributed thread is that thread of control that you can mentally picture going into a remote object proxy and popping at the matching remote object when you use RPC/RMI middleware like CORBA or Java/RMI. Simple enough, huh?

Oh, man, I am bulging with new ideas. And I am definitely working on a collaborative debugger that Scott Lewis suggested as well.

And then I'm going to get a nice RSI from coding so much.

...

Time for bed.

Need RMA for my Brain

Today I spent 6 hours fighting a bug.
I think my brain has a defect. I was observing a weird behavior where some remote processes seemed to be dying earlier than they should. This only happened under I/O-intensive processes. All kinds of conjectures went through my head - from the simplest to the most complicated. I will spare you from the details.

Anyway, I was almost giving up when, all of a sudden, I saw this piece of code (blogger sucks for posting code, so cut me some slack on this):

while(true){

try{
...
}catch(){
...
}catch(){
...
}finally{

try {

if (closeOnExit)

lReader.close();

} catch (IOException ex) {

logger.error("Failed to close output stream.", ex);

}

}

}

}

This loop forwards the streams to the remote server. It only iterates when the buffer overflows, and the buffer only overflows if the flush timeout is small enough or if the process writes enough stuff to STDOUT/STDERR. So, I was essentially closing the stream on the first iteration, causing the underlying process to die earlier than I was expecting it to.

Damn. My tests weren't getting this because I use very large buffers (up to 2000 characters), and my toy test processes didn't produce that much output. When I attempted to dump the old testament on-screen (my favourite for stress tests), this odd behavior appeared.

Oh well. At least I'm getting somewhere.