Wednesday, October 17, 2007

The fuzz factor released

Today I've decided to release the patch for bug 199846 - Misuse of the fuzz factor.

Personally, I don't believe that the fuzz factor was never there. I think that because of the fact that nobody was sure how it should work and it wasn't enough documented the fuzz factor somehow evolved into the state we have now. But what does it mean? How was the fuzz factor actually "misused"?

We all work with patches (at least most of us), so we are familiar with the Apply Patch wizard. I'm sure you all noticed the mysterious "Guess" button and the "Maximum fuzz factor" text field. Referring to Eclipse Help doesn't help much. All you can read there about it is : "This factor determines how much the location of the patch in the target file may have changed since the patch was originally generated. The default value is two, but it's not automatically applied. Press the Guess to calculate the fuzz factor that will allow the most hunks to be matched."

Well, you know that it has something to do with the location of the patch and that by pressing the "Guess" a miracle can happen and you will be able to apply the patch. But what happened to the definition of the fuzz factor I mentioned in one of my previous posts. The definition for patch command on Linux man page says: "... [if] the maximum fuzz factor is set to 1 or more, then another scan takes place ignoring the first and last line of context. If that fails, and the maximum fuzz factor is set to 2 or more, the first two and last two lines of context are ignored, and another scan is made."

There is nothing about the patch location there, it's more about context lines, isn't it? The definition from Eclipse Help tries to describe how the fuzz factor is used at this moment - changing the value for the maximum fuzz factor the user was setting how many lines a hunk can be shift up or down in order to be matched. I've heard about people who simply put "999" there and pressed the "Guess" button. This is not the way we would like it to have. According to Michael's suggestion the shifting should be done automatically and the fuzz factor to use should be either selected by the user or guessed (after the "Guess" button has been clicked).

And this is what the patch is all about. From now on, when the user enters a value for the maximum fuzz factor it will define how many context lines will be ignored when applying the patch.

PS. Even though the bug is marked as FIXED there are still some issues related to the patcher. They are all addressed by following bugs: 205761, 205762, 205789 and 206062.

Friday, October 12, 2007

My first commit

It looks like the process is completed and finally I became a committer. To be more precise I got commit rights for the Team component. I believe that I don't have to add that I'm very happy and proud to be a member of this elite group. And like during Oscars I think should thank somebody, so the first person that came to my mind is Michael Valenta - Thanks Mike!

This is a screen shot of my first commit (a patch for bug 204358):

Tuesday, October 2, 2007

Fixing the Patcher (part 2): testing

Due to the complexity of the algorithm there was no doubt that we would need a set of tests to ensure proper behavior. In the first place we need to make sure that introducing the fuzz factor won't break anything and then we need to check if the fuzz factor mechanism works as the user would expected.

Tests related to the patcher are located in the PatchTest class. Having in mind that I will need to write plenty of tests to cover as many corner cases as possible I started to think how to make the job a little bit easier. This is when the idea of the "testPatchdataSubfolders" came to my mind. I thought it would be great if one could test the patcher by simply adding a directory with some files in it (as this what writing patch test is actually all about). So now what I need to do is create a subfolder in the "patchdata" folder (e.g. "196847" for bug number 196847). To properly run the test a specific set of file need to be place inside the subfolder:
  • context.txt - this is an original file
  • patch.txt - this is a patch we would like to apply
  • expected_context.txt - this is an expected result of the patch applied
  • actual_context.txt - this is an actual result after applying the patch
Part of a filename in bold fold is used to determine what's the role of the file (e.g. if there is a "exp" substring somewhere in a filename it will be used a expected result). There is no special pattern for the context file. If we want to use a specific fuzz factor when applying a patch we add to the filename "fuzzX" or simply "fX" (for fuzz factor equal 2 it will be "fuzz2" or "f2"). At this moment the test can be run for fuzz factors from 0 to 3. If there is no fuzz factor specified the patcher will try to guess it. File for the actual result is optional.

The other idea I had to test the patcher was to write a fully automated test class. The class could change a file content according to some algorithm or given parameters. The change couldn't be random as a possible failure need to be reproducible. Here are the steps:
  1. Create a project with a file and share it
  2. Make a change in the file
  3. Create a diff (patch) for the file
  4. Override and update the file (revert to previous version)
  5. Apply the patch and check if it's the same as in 1.
  6. Go to 2.
Well, this was just an idea but I thought it was worth writing it down. Anyway, in the end I decided that writing tests (or in this case providing set of files) is much better and faster in finding a corner case. But who knows, maybe I will return to this idea in the future, until then I will stick to "manual" testing.

Wednesday, September 26, 2007

Fixing the Patcher (part 1)

This week I've started to work on bug 199846. Frankly speaking, I was shocked after I'd discovered that the mysterious fuzz factor is not what it should be. Probably I wasn't the first guy who did it, but first who dare to log in on Bugzilla.

First, I read what Eclipse Help says about the fuzz factor. You can find the information here (paragraph "Options for applying a patch", point 4). Now you know why I'm calling it mysterious. I knew that I will need more details on that topic to start fixing the bug. After googling around I came across these two pages:
They both gave me a fair background of the fuzz factor so I could to start working on it. Next step was to get familiar with classes involved in the patching mechanism. The story should start with Patcher and WorkspacePatcher classes. This is where a patch is loaded, parsed, applied and so on. Let's take a closer look at classes which represent structure and content of a patch. Here a sample patch file:





DiffProject - "A diff project represents a project that was read from a workspace patch. It contains the set of file diffs that were associated with the project in the patch file."

FileDiff - "A file diff represents a set of hunks that were associated with the same path in a patch file."

Hunk - "A Hunk describes a range of changed lines and some context lines."
All above classes are located in org.eclipse.compare.internal.patch package of the Compare project so they are internal and there is no javadoc generated for them.

Classes that hold result of the patching process are: FileDiffResult and HunkResult.

To be continued...

Friday, September 14, 2007

Mylyn Task list organization

I am a big fan of Mylyn. I've been using it to organize my tasks for a long time, but today I reconfigured my Task List completely.

I am a member of Workspace team, so the bugs I am playing with are from these 4 components: Resources, Team, CVS and Compare. This also determines that I work with at least two workspaces: one with Resources projects, one for projects for the other 3 components. Each workspace has a separate Task List attached.

Resources workspace:
  • Resources - Mine
  • Resources Queries - New Bugs**
TEAM* workspace:
  • Compare - Mine
  • CVS - Mine
  • Team - Mine
  • Compare Queries - New Bugs**
  • CVS Queries - New Bugs**
  • Team Queries - New Bugs**
* TEAM is the term I'm using to name Team, CVS and Compare components all together.
** These queries are taken from here. I made them using "Create query from existing URL" option.

This is how I've got my new task list organized in the TEAM workspace:
  • TEAM - New Bugs
  • TEAM - Mine for 3.3.1
  • TEAM - Mine for 3.4
  • TEAM - Mine for 3.4 M1
  • TEAM - Mine for 3.4 M2
  • TEAM - Mine for 3.4 M3
  • TEAM - Mine for 3.4 M4
  • and so on
I will do the same with the Resources workspace task list as soon as I get some more bugs to fix from this component (no need to hurry).

As you can see I rebuilt my task list from a component-oriented to a milestone-oriented. The only thing I'm missing is "Target on Milestone" switch, an equivalent of current "Focus on Workweek". On second thought I figured out that I could use the "Go Into" but decided to stay "on top" and have a wider view on all my tasks.

I'm wondering how you guys organize your task list. I'm aware that my idea is not a rocket science, but I'm pretty sure that one can organize the Task List in many flavors. Anyway, as you've probably already noticed this post is all about showing you how cool is Mylyn. If you haven't tried it yet, please do.

Wednesday, September 12, 2007

Priority of content types

Today I found an interesting thing about the content types in Eclipse.

Yesterday I was trying to fix Bug 198544. I went the wrong way trying to fix the issue due to the reporter's hint. Looked good...

Today I found that the priority is respected indeed, but as a second criteria. Those who are interested in the case should look at org.eclipse.core.internal.content.ContentTypeCatalog class in org.eclipse.core.contenttype project.

:-)

Thursday, September 6, 2007

"Add to .cvsignore" dialog

It seemed to be an easy to fix bug. We just wanted to prevent a user from adding a filename with spaces to a .cvsignore file. A suggestion was to use a custom pattern with '?' instead of all the spaces. At the same time I decided to dust the dialog off a little bit. To achieve that I thought it would be a good idea to get some information about Eclipse UI Guidelines. This is when the fun started.

Here are the guidelines applied to the dialog, most of them are citations taken from Top Ten Eclipse UI Guidelines.
  • Offer mnemonics
  • Use proper margins size
  • Use single quotes for all references to element names embedded in text (Properties for 'Test')
  • Dialog title should use headline style capitalization
  • Dialog title should relate to the action that brought up the dialog ('Apply Patch', 'Package Selection')
  • Dialog title should be short and unique so they can be referred by in bug reports / documentation
  • When visible for the first time always set a focus field
  • When visible for the first time don't show an error until the user made the first modification
Other pages related to Eclipse UI guidelines/best practices:
So as you can see what seemed to be an easy bug became something a little bit more... time consuming. Anyway let's see the result. This is how the dialog looked before (it's ugly, isn't?):



and this is how it looks now:


I hope you'll like it's new appearance as much as I do. Those little things can really make you happy and proud.

Tuesday, September 4, 2007

Photo session

We made this photo session specially for readers of our blog . For those who don't know us...
Zaza (Tomasz Zarna) is in an orange t-shirt, Simon Good (Szymon Brandys) is in black :-) and Kristek (Krzysztof Michalski) is the third guy.














Enjoy ;-)

Monday, September 3, 2007

In search of a bug

Everyone working with Eclipse Bugzilla makes more than a dozen of searches everyday. Here are my few tricks to make this a little easier. I'm a Firefox fan, so all IE users can stop reading here.
  • Smart Keywords in Mozilla Firefox

  • I've created a Smart Keyword which when I type "b <bug number>" into Firefox's Location bar and hit enter takes right to the page with that bug. This is how I've done it:

    1. Visit the page that has the search field you're interested in - https://bugs.eclipse.org/bugs/query.cgi

    2. Right click on the search field. Choose "Add a Keyword for this Search...".



    3. The Add Bookmark dialog will appear. Give the bookmark a name, e.g. "Bug Search" and create a keyword e.g. "bug" (I'm to lazy to type the whole word so I'm using "b" only) and save the Bookmark.


    4. That's it. Now when you enter "bug <bug number>" into the Location bar and press Enter you will get the page with that bug.

  • OpenSearch plug-in for Mozilla Firefox

  • Next thing I would like to share with you is an idea of how to use an OpenSearch plug-in to work with Eclipse Bugzilla. I've created two for my own use. One for Team, Compare and CVS components and the second one for Resources component only. Plese visit this page if you want to install them. You can freely modify the to plug-ins to fit your needs.

    To make a plug-in work for the SWT component for example, simply change attributes as shown below:
    <SearchPlugin xmlns="http://www.mozilla.org/2006/browser/search/">
    <ShortName>Eclipse SWT Bugs</ShortName>
    <Description>Search Eclipse Bugzilla for a bug in SWT component</Description>
    <InputEncoding>UTF-8</InputEncoding>
    ...
    <Url type="text/html" method="GET" template="https://bugs.eclipse.org/bugs/buglist.cgi">
    <Param name="query_format" value="advanced"/>
    <Param name="short_desc_type" value="allwordssubstr"/>
    <Param name="short_desc" value="{searchTerms}"/>
    <Param name="classification" value="Eclipse"/>
    <Param name="product" value="Platform"/>
    <Param name="component" value="SWT"/>
    <Param name="long_desc_type" value="allwordssubstr"/>
    ...
    To make things even easier you can use Ctrl+K to send the cursor into the search box and then you can navigate up and down the engine list using Ctrl+Up Arrow and Ctrl+Down Arrow.
And last but not least, give Mylyn a try. It's really worth the effort, but this is a whole new story requiring a separate post.

I hope you find both tricks as useful as I do.

The Beginning

Today is the day. We agreed that we should start our own blog. The only problem was (excluding choosing a nice template) picking the blog's name to register. We had plenty of ideas. Just to mention few of them:
  • Soldats of Eclipse
  • Eclipse Troops
  • Workspace Eclipse Team (WET)
  • Polish Eclipse Team (PET)
  • Eclipse Clan
  • Polishing Eclipse
  • Polishin Eclipse aka Polish in Eclipse
Finally, we decided to pick one of the last two, but we couldn't decide which one should it be. Tomek's pick was "Polishing Eclipse" and my favourite was "Polishin' Eclipse". Krzysztof liked both of them or simply couldn't make up his mind. We will never know :) Anyways, there is only one way out from such a situation - a duel. Only a deathmatch could help us here. And when we're talking about a deathmatch, Soldat is the only choice.

Wait for 5 minutes...

As you can see on the movie, I won (YEAH). So, I am glad to inform that you are on the right page and since now this is the official blog of our team.

And at the end I would like to thank Tomek who actually is the author of the post and I modified it only a bit ;-)