In any case, let’s get this party started.

1. Grab the Mono 1.9 ‘Other Linuxes’ installer binary from their website.
2. Run the installer. You’ll probably need to use chmod +x on it first though. This guide assumes that you did not opt in on modifying your ~/.bashrc file. I will assume that you installed it into some place like ~/mono-1.9/.
3. Start Eclipse up and point it at a new workspace. You mise well start fresh, right? Note that this has been tested on Eclipse 3.2.2 but since we don’t make any internal API calls, future versions should be a-okay also.
4. Checkout edu.arizona.cs.mbel2, emonic.base, org.emonic.debug.core, org.emonic.debug.ui, org.emonic.debugger, emonicinformator, and Emonic.DebugFrontend from SourceForge. You can use the handy CVS “path” below to fill up the wizard faster:
   :pserver:anonymous@emonic.cvs.sourceforge.net:/cvsroot/emonic
5. Now we need to change the DebugFrontend.build build file located in the Emonic.DebugFrontend project. Point its debuggerLibs property to /home/username/mono-1.9/lib/mono/mono-debugger/.
6. Next, we need to change the Emonic.DebugFrontend project’s build_release.sh file’s TARGET variable. Point that at /home/username/workspacename/emonic.debugger.
7. We also need to change the build_release.sh file in the emonicinformator project. Change ~/workspace_new/ to wherever your workspace is.
8. Open a terminal and run source ~/mono-1.9/bin/setup.sh.
9. Invoke the build_release.sh script from the Emonic.DebugFrontend folder in the same terminal.
10. Now invoke the other build_release.sh script that’s in the emonicinformator project.
11. Back in Eclipse, we need to create a new ‘Eclipse Application’ launch configuration that includes edu.arizona.cs.mbel2, org.emonic.base, org.emonic.debug.core, org.emonic.debug.ui, and org.emonic.debugger.
12. Next, we need to switch to the ‘Environment’ tab. Set LD_LIBRARY_PATH to /home/username/mono-1.9/lib/ and PKG_CONFIG_PATH to /home/usernamemono-1.9/mono/lib/pkgconfig/. I think this step isn’t necessary if you did opt in to change your ~/.bashrc file, but since I’d rather not have my readers taint their setup needlessly, I decided to walk you all through the “long” way.
13. Make sure ‘Append environment to native environment’ at the bottom of the tab is set. This should be what it is by default.
14. Run the second Eclipse.
15. In your second Eclipse, open up the preference page and then go to the ‘.NET > Installed Frameworks’ preference page and add a framework that points to /home/username/mono-1.9. Now switch over to the ‘.NET > Building’ preference page and then click ‘OK’.
16. Open the preferences again, you should be on the .NET > Building page, configure the NAnt command and point it at /home/username/mono/bin/nant. It is imperative that you followed these past two steps correctly. There is a bug that causes the values to not persist properly and resort to their defaults when switching pages and the like. If in doubt, redo it again.
17. Create a new .NET project. Accept the defaults, the build mechanism should default to ‘nant’.
18. Using the created src folder in the project, create a new C# class through the wizard. You’ll need to create a new target, give it a name.
19. Write some code. Two print statements would be a good test.
20. Right-click on the margin and select ‘Toggle Breakpoint’ on the line with the first print statement (although it is very primitive).
21. Create a new debug launch configuration for a ‘.NET Application’. Point it at your project and then browse to the compiled .NET executable that should be in the bin folder.
    launch configuration. NAnt should’ve been run every time you saved, otherwise, the .NET executable may not have been created.
22. On the ‘Common’ tab, unselect ‘Allocate Console (necessary for input)’.
23. Click ‘Apply’ and then ‘Debug’.
24. After a bit of waiting, switch to the ‘Debug’ perspective by hand. To those that prefer the perspective switching to happen automatically, sorry, that hasn’t been implemented yet.
25. The application should’ve stopped at the first print statement.
26. Try hitting F6 and see that the print statement appears properly.
27. Enjoy!

All feature requests should go here and all bug reports should go here. If you want to leave any comments about the debugger, you should consider posting them here. For personal compliments (or hate mail if applicable), please route them to Harald as I don’t handle the debugger integration on Emonic. This is very much still in alpha, so don’t expect too much.

Yes, we know that creating a regular ‘Run’ configuration doesn’t make anything show up on the ‘Debug’ side. Due to the decoupled nature of our current plug-ins, the two are not tied together.

And no, it doesn’t work on Windows because there is no ‘mdb’ on the Windows Mono build (at least, I didn’t see one when I installed it on Vista). If someone wants to try and write a debugger for us (ahahaha, who am I kidding?) or provide an interface with MDbg or something, please let us know.

Once I got the logistics of hotel check-ins and all done, I headed off to the registration area where I bumped into Nitin. After hanging around there for a little while, I met Markus who told me that he was hanging out outside of the bar with some other folks so off we went. I got to meet Tom and Markus’s coworker (whose name evades me) there. Paul and Eric also dropped by a little later to say hi. Some time later, we headed back over to the registration booth where I took some pictures of those AMD machines since my brother works for them. We also spotted Scott here. Markus and he had a good chat while Nitin, Achim, and I started yapping about the difficulties around implementing a shared editor.

After this, Nitin and I headed off to Ian’s blogger party.

This is where Ian asked me if I ever go to class. And the answer is, why yes, I do go to class. Although I will admit I do sit on IRC during some lectures, but not all, mind you. In any case, the rest of the day ended rather uneventfully.

On Monday, I was up early to grab some food and drinks. I bumped into Pascal, Andrew, and Steffen while I was darting around the tables.

The first tutorial I went to was Benjamin’s “Plastic Surgery For Eclipse: Custom SWT Widgets, RCP Customization, And More“. While I’ve done plenty of UI work in the past, I’ve never done any of the things that Benny talked about, so this was certainly well worth my time.

I skipped the second time slot since Andrew and I were going to head over to Google to visit Igor. We waited for the time to pass on the second floor whilst checking emails and the likes on our notebooks.

I was lucky enough to bump into McQ there as I hadn’t met him since my Extreme Blue internship at IBM Ottawa ended. I wasn’t so lucky since I had bugzilla open on my notebook screen, which he was quick to critique about. I guess I failed to show him that I was working on my “work/life balance“.

Time flew by soon enough and it was time for Andrew and I to head off to Google. I asked someone to take a picture of us. Here you can see Dave, yours truly, Andrew, and Neil. McQ had already left, hence he is not here. :(

Google’s buildings are quite elaborate and their food is certainly one of a kind. I forgot to take any pictures so you’re just going to have to take my word on this one. Our trip back wasn’t so great as Andrew had noted, but no problem, we only lost a few minutes. Being Paul’s unofficial underling, I felt compelled to go to his tutorial, so I did. It’s hard to help fix Paul’s bugs if I don’t understand the stuff he works on after all.

While I was waiting for Nitin’s tutorial to get started, I went off to go look for Tomasz and Szymon. Szymon was busy attending to someone else but I was able to have a nice chat with Tomasz.

Nick dropped by Nitin’s tutorial after I pinged him and he, Dave, and I started reminiscing about the good times we’ve had together on #eclipse.

After the last of the tutorials, it was time for the community awards. There was some good Jeopardy action before that first though. I don’t remember what the question was but this answer was real long. I think it was something like “What does the Eclipse Foundation do?” or “What is the Eclipse Foundation responsible for?”. I do believe no one got it.

The community awards came after the two rounds of Jeopardy concluded. Thank you all for your support! :)

Once the event was over, it was on to the BOF sessions. Of course, this wasn’t before having a brief chat with Jeff and Dale and a photo with Nitin first.

I attended the SOC BOF first with Igor where I got to meet Wayne for the second time and Rob for the first time. It was nice having Igor and Rob there as it helped give us a bit of an “insider’s perspective”. Prior to the ECF BOF, Igor and I went over to look for Andrew where I was able to meet the famed Billy Biggs.

At the ECF BOF, we had Scott, Jan, Markus and me from the team. Rob, Pascal, and another fellow were also there to join us. We talked about p2 and ECF’s discovery APIs as well as shared editing.

Upon its conclusion, I waved my farewells and headed off back to my hotel room. I listened to some tunes from Final Fantasy XII before I retired to bed. I was pretty surprised that they had such a device, but hey, I’m totally down with that.

The next day, I woke up at 0400 and took a cab at around 0435 to head to the airport. Hopefully, I’ll be able to attend again next year. Oh, and staying longer next time wouldn’t hurt either. ;)

This will be my second time going to EclipseCon and I’ll be setting new lows by staying for an even shorter amount of time than I did last year. I’ll be flying in to San Jose on Sunday afternoon and departing on Tuesday at 0620. Yeah, that’s right, I said 0620. The reason I have to do this is because I have other obligations that I need to fulfill. All this juggling of time is actually part of my master plan to achieve “work/life balance”. Though, of course, it’s not going very well right now (since I just sit on IRC all day long), but someday…

In any case, if you’re looking for me at EclipseCon, you’ll probably find me wherever the “IRC posse” (as Tod coined us) or Platform team is. I’ll also be at the SOC and ECF BOF sessions, so you can look for me there too.

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!

While KOS-MOS is capable of many things, she can only do so much! So if you’ve got some spare cycles during the day, please consider dropping by to interact with Eclipse’s IRC community. :)

So how hard is it to implement this? If you’re trying to do a quick and dirty hack as a prototype for your product manager for that meeting this coming Monday, have no fear, it’s completely doable! Hell, I just did it this morning.

Look at that, it’s like child’s play.

Here are some tips for the aspiring breadcrumb hacker:

• in your EditorBreadcrumb subclass, make sure you call setTextViewer(ITextViewer) or your will get an NPE when you return true for the open(Object) or reveal(Object) methods
• when creating your ITreeContentProvider implementation, make sure you implement getParent(Object) properly, in standard TreeViewers, it never seemed to matter (from my own experience), but it does in this scenario
• the JDT dependencies can be safely removed, I ended up using a Twistie instead of porting the images over, feel free to do either or
• the code will even work on Eclipse 3.2 (and possibly lower, but I didn’t try)

Getting the keybindings to work properly and all will probably be difficult, but don’t look at me, because I didn’t even try. ;) Good luck!

Creating the project is as simple as can be. An Eclipse plugin is available making Android development a snap. You’ll need to have Eclipse 3.3 (Europa) or higher installed, and you’ll need to install the Android Plugin for Eclipse. Once you have those installed, come back here.

If you were thinking about using the ADT on 3.4M3 (since it says “or higher”), don’t even try, because you can’t even get past the first step of the ‘Hello, Android!‘ tutorial since the wizard won’t even open.

At this point, you might try to click on the ‘OK’ or the ‘Details >>’ button, but this will not work. I don’t know if it’s because I’m on Fluxbox (which isn’t a real desktop environment,) or not, but if it doesn’t work for you, you should Alt+Tab off that window back to the ‘New Project’ wizard and close that dialog. Once that’s closed, you can now go back to the error dialog and close that with the ‘OK’ button.

If you look at your workspace logs, you will find something like the following…

!ENTRY org.eclipse.jface 4 2 2007-11-12 23:20:50.557
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.jface".
!STACK 0
java.lang.NoSuchFieldError: JavaProjectWizardFirstPage_NameGroup_label_text
at com.google.android.adt.project.NewAndroidProjectCreationPage.createProjectNameGroup(NewAndroidProjectCreationPage.java:230)
at com.google.android.adt.project.NewAndroidProjectCreationPage.createControl(NewAndroidProjectCreationPage.java:202)
at org.eclipse.jface.wizard.Wizard.createPageControls(Wizard.java:170)

So it seems like Google is using internal Eclipse APIs or something of that nature (as they appear to be accessing JDT’s externalized strings directly) which got removed in the 3.4 stream. This should be no surprise since the top portion of the two wizards look the same.

]]> http://blog.hantsuki.org/2007/11/12/adt-03-does-not-run-on-34m3-so-dont-even-try/feed/ http://blog.hantsuki.org/2007/11/04/an-old-friend-the-navigator-view/ http://blog.hantsuki.org/2007/11/04/an-old-friend-the-navigator-view/#comments Mon, 05 Nov 2007 00:58:42 +0000 Remy http://blog.hantsuki.org/2007/11/04/an-old-friend-the-navigator-view/ While I’m sure we all threw up the ‘Navigator’ view once in a while back in the pre-3.2 days of Eclipse, I can’t say that I’ve opened it up much anymore. With the working set support in the ‘Project Explorer’ view, the ‘Navigator’ is just way too disorganized for me to stand. The only time I ever pull it up nowadays is for a quick view of all the files in my projects (usually for the .* resources that are hidden by default by filters). This is all fine and dandy for us veterans but the presence of two views that seem to offer identical but not actually identical features is a nightmare for new users.

So, if you will, please join the discussion on bug 208693 and voice your opinion on the topic!

]]> http://blog.hantsuki.org/2007/11/04/an-old-friend-the-navigator-view/feed/ http://blog.hantsuki.org/2007/10/23/emonic-03-released/ http://blog.hantsuki.org/2007/10/23/emonic-03-released/#comments Tue, 23 Oct 2007 22:24:15 +0000 Remy http://blog.hantsuki.org/2007/10/23/emonic-03-released/ The final version has officially gone out the doors! Take note that this doesn’t imply that the team has shifted into low gears at all. Dominik has actually already started working on improving the code completion (with images, for starters,) and I’m hoping to commit some code to allow us to plug into the Common Navigator Framework some time before the end of the week. :) Stay tuned!

]]> http://blog.hantsuki.org/2007/10/23/emonic-03-released/feed/ http://blog.hantsuki.org/2007/10/14/emonic-03-rc1-released/ http://blog.hantsuki.org/2007/10/14/emonic-03-rc1-released/#comments Mon, 15 Oct 2007 02:56:29 +0000 Remy http://blog.hantsuki.org/2007/10/14/emonic-03-rc1-released/ Bernhard has officially pushed RC1 out into the wilds. We’ve implemented quite a few new features in addition to fixing a good number of bugs. These new features include, but are not limited to, the following:

• ‘Quick Outline’ via Ctrl+O
• faster ‘Outline’ parsing
• better handling of .NET environments
• improvements to the build mechanism
• console hyperlink support
• launching support for .exe files

I’ve tested this on Eclipse 3.2.2 as well as I20071009-2255 and things look okay. Of course, since I don’t really know too much about C#, I can’t really comment on how well it fares as an actual development environment. So, please do download the zip file and give it a go if you can. If you have any features or bugs that you’d like implemented or fixed, please let us know in our issue tracking system on Sourceforge. :)

]]> http://blog.hantsuki.org/2007/10/14/emonic-03-rc1-released/feed/