Since I took care of XII, I can finally get going with Revenant Wings. A grin quickly formed on my face upon booting up the game as I was able to hear the familiar soundtrack of FFXII once again. It was also nice to see the cast from the first game once again.

Since I’ve only played through one stage, my opinion probably isn’t worth much, but I’d like to note that I enjoyed it quite a bit nonetheless. Given that it’s a real-time strategy game, it shouldn’t be surprising to know that the battles were extremely engaging, much like its predecessor.

As some of you may have saw, I made a very brief post about this episode a week ago when I watched the raw then. As you can tell, this episode was totally right up my alley in terms of plot development since things are finally going my way for once.

I’ll admit that there is still a danger though since there are still four episodes left. I mean, there’s still one third of the series that still has to unfold. It’s obvious that Noe still has a role to play here (I mean, she still has to collect tears, right?), but I think she’s officially out of the pairing loop after her conversation with Shinichirou by the shore.

From the previews, it looks like there’s going to be a confrontation between Jun and Hiromi in the next episode. It was obvious from episode 6 that Jun’s always known that Hiromi liked Shinichirou and not himself, so I don’t know what this is going to do, if anything.

The question of how one could contribute to the Eclipse community has been brought up a couple of times on IRC in the past few months. There are a variety of ways of contributing to Eclipse projects, one can help the Eclipse effort by filing bugs and enhancement requests or answering questions on the newsgroup and IRC. The one that comes to mind for most young, aspiring software developers is probably in the form of contributing code, so that’s what I’m going to talk about here.

The easiest way to contribute some of your hand-crafted coded to an Eclipse project is probably by finding a bug that you are interested in fixing or a feature that you are interested in implementing. The Bug Day wiki page is a good start, you can also just run your own Bugzilla queries if you wish. I personally run a query on Bugzilla every couple of hours every day on all Eclipse bugs (the ‘Eclipse’ in this context would be the top-level Eclipse project) to see what’s been filed today to help with the triage work and bug fixing. I’m going to base this “exercise” around a bug that Tomasz filed a couple of days ago, bug 221652.

Not every bug is as straightforward as this one and while I had a feeling that it was a going to be an easy fix, I still wanted to know how the Compare team wanted it done. So, I asked. :) If you find a bug you’re interested in working on but are a little lost, make sure you ask like I did! Someone with the relevant know-how will then be able to give you some pointers and provide more context about the bug like Tomasz did in his reply. Alright, now that we’ve been told how the team wants it fixed, it’s time to start hacking!

Or at least, that’s what code monkeys like me likes to think. But, where do we go from here? How do I know which plug-in the code is in, let alone which class? If you don’t know the answer, you can usually just ask on the bug. But since the Workspace team is a busy bunch, let’s not bother them. Instead, I’m going to walk you through a little trick I use often when I need to find classes at the UI level.

The first thing any plug-in developer should do before writing plug-ins would be to add all of their base target platform’s plug-ins to the Java search scope for easy access via ‘Open Type’. So fire up the ‘Plug-ins’ view and then add them all to the Java search path.

Once you’ve done this, you should also unfilter that secret PDE project from the ‘Package Explorer’ while you’re at it.

You should now see the ‘External Plug-in Libraries’ project in your ‘Package Explorer’, this will come in handy later. Anyway, now that I have all the Java classes at my disposal, I need to start thinking about the bug and where its code comes from. Since I know we’re dealing with wizard pages here, I can make a pretty safe assumption that the wizard page class that the Compare team crafted is going to be subclassing WizardPage. We can use this to our advantage by putting a breakpoint in its constructors and subsequently start up a debugged Eclipse instance. Now if we try to reproduce the bug, the wizard pages will get constructed and our breakpoint should hopefully be hit! :D

Well, look at that, from climbing up the stack trace, we discover that the wizard pages are being constructed within the GenerateDiffFileWizard’s addPages() method. By thinking about the class hierarchy of the user interface elements you are interacting with and placing breakpoints intelligently, you can find classes quite easily. There’s been cases where I’ve setup some breakpoints in places like Button or Label’s setText(String) method with a condition that the passed in string was equal to some value so that the code would stop right when the control was being created. Pretty hacky, but hey, it works. ;) Desperate times calls for desperate measures, as I often like to say.

In any case, now that you’ve identified the class(es) you’re interested in (GenerateDiffFileWizard and its inner class OptionsPage, in my case), you should use the ‘Link With Editor’ feature.

This will expand the ‘Package Explorer’ and “link” the opened file in the editor with a selection in the ‘Package Explorer’. By scrolling up, I can quickly find the class’s containing jar. This tells me I need to checkout the org.eclipse.team.cvs.ui module from CVS HEAD.

I’ll skip the details about this since I assume all my readers knows how to use the CVS plug-in that comes with the Eclipse SDK. Once that’s taken care of, we should make a new launch configuration and make sure that this launch configuration has the proper plug-ins selected in the ‘Plug-ins’ tab.

You can see that I’ve set my launch configuration to include the copy of org.eclipse.team.cvs.ui from my workspace. Make sure it’s unselected from your ‘Target Platform’ tree. Once that’s taken care of, we should launch Eclipse again to ensure that the bug is still reproducible with the latest code from the repositories. If we get a positive, we can go about and try to fix the bug…

When the bug’s been fixed, a ‘Team > Synchronize’ on the modified projects in question through the context menu is in order so that we can check up on our changes. Once you’ve identified that no conflicts are in place and removed some of the cruft you may or may not have added (such as test code that was commented out or unnecessary/excessive whitespace changes), it’s time to make a patch!

I’d recommend setting the ‘Patch Root’ to ‘Workspace’ even if you’re only patching one project. I caused Paul some grief during my first couple of contributions to Platform/UI since they were all at the ‘Project’ level and made the applying of patches require a few additional mouse clicks on his part. Might as well streamline the whole process for the person that is going to be reviewing your patch, those extra brownie points do add up! Anyway, once the patch has been created, it’s time to attach your patch to bugzilla!

And that’s that! Someone will look at your patch as soon as time permits and provide you with the necessary feedback to improve on it if applicable. Subsequently, with a bit of luck, it could get pushed to the repositories! :D Though, I’m sure none of you need any luck since I’m sure my fellow readers are better programmers than yours truly. ;)

Happy hacking! Don’t be shy about volunteering to help, everybody loves contributions!

*picks up jaw off of the floor*

My search for a new wallpaper ends here.

This was one hell of an exciting episode. There was action going on throughout the whole episode leaving you with very little room to breath. It’s amazing how Wilhelmina was able to keep up with Sabrac’s attacks. She certainly is one experienced flame haze.

This fight has probably been the best fight so far across both seasons in my opinion. I really enjoyed the different forms of attacks that Wilhelmina pulled out of her hat to try to defeat Sabrac, very creative indeed. One minor complaint I had with this fight was that Wilhelmina wasn’t fighting with her mask on. Yes, I know she put it on when she threw that giant ball of energy at Sabrac, but I was hoping to see her with the mask on throughout the whole fight, ah well.

The next episode is likely going to remain on high gears like this one. On one hand, I have a feeling that Sabrac might live to see another episode but on the other hand, since episode 22 is named 「クリスマス・イヴ」, I’d like to kind of think otherwise. But since these episode names are rarely what you actually think they are, it’s really all up in the air. ;)

Hot off of today’s episode 9…

Hells yeah! I approve!

I don’t know how they do it but they sure know how to pace this series. There actually isn’t a lot of information to reveal (in my opinion). All we really “need” to know can be revealed by Shinichirou’s parents and all we really need to see is Shinichirou and Hiromi get together. All this can be taken care of within two episodes but they just twist things around in such clever ways that this gets dragged on without getting boring.

Of course, we shouldn’t forget about Miyokichi and Ai. It’s hard to say whether they’ll get back together although I would like to see that since I think they make a good couple. However, since it seems that Ai never really genuinely liked Miyokichi, I’m not sure if I’m going to accept a sudden change of heart so easily.

When Shinichirou finally gets together with Hiromi, what’s going to happen to Noe? Is she just going to have a change of heart like Ai? It’s certainly something that needs to be resolved properly. I suppose there are more things to take care of than I originally envisioned in my first paragraph.