Polishin' Eclipse aka Polish in Eclipse

Eclipse Birthday Party in Krakow

2011-11-25T11:37:00.014+01:00


	I got used to Eclipse DemoCamps so much that not having one in Krakow would be a shocking experience for me. So I'm glad to say that we had the event last Tuesday and it was again very good. I would like to thank all presenters and participants for coming. For those who couldn't come I have some pictures. See you next time!

Better late then never

2009-09-17T14:45:00.004+02:00

I won't tell you where I found it but it has been there for almost 6 years ;) Your day has come!

A quick reconnaissance in the UI testing tools

2009-07-08T23:28:00.011+02:00

Task: A quick reconnaissance in the UI testing tools area
Team: Platform Workspace Team
Time: Couple hours

Result: http://wiki.eclipse.org/Automated_Testing#UI_tests
Casualties: 1 Whiteboard Marker M.I.A

Further steps: Need more people to update the table with results (see http://wiki.eclipse.org/Automated_Testing#UI_tests)

Eclipse DemoCamp in Cracow - Round 3

2009-06-28T23:56:00.019+02:00

This is the third time when Eclipse DemoCamp was organized in Krakow. On Jun 27 (Saturday) Eclipse fans from Krakow met in Baraka club at Kazimierz in Krakow.

Kazimierz is an old Jewish department of Krakow. You can read more about it here. For us important is the atmosphere there which is in favor for such events.

Since we wanted to celebrate the Galileo release, we didn't fill the whole time with talks and demos.

More than a half of the time was just chatting with beer and pizza in hands. This way we managed to answer more questions and meet more people personally than we could do otherwise.

People came despite the rain. I understand that this could be hard to wake up early on Saturday when it rains. However Eclipse people are tough guys and girls, so rooms at the club were full.

Moreover we found a new application for laptops. Yet another proof that ThinkPads rules :)

The agenda and the list of attendees can be found here.

Don't forget that the next DemoCamp is in November and you are all welcome. Cheers!

New proxy settings UI

2008-11-24T16:55:00.003+01:00

This is my first post to this blog. I've been in the Workspace team for a few months but didn't have anything to show... until now:) I've just finished work on the UI part of the proxy support redesign.

The new UI aims at complains about the proxy support in Eclipse. First of all you can see settings that are pulled from the OS. They can be obtained from Windows IE setting, Linux environment variables or GNOME settings.

It also makes changes necessary to provide an extension point for supplying custom proxy providers. We plan to add such an extension point in the future. IMO this will be the best feature of it, at least the coolest one.

If you want to play with it simply download the latest build and go to Window > Preferences > General > Network Connections. Any bugs are welcome. I mean any valid ones;)

EclipseDemocamping in Krakow

2008-07-01T17:53:00.006+02:00

The first edition of Eclipse DemoCamp in Krakow was a spectacular success.

The room was full ;) ...

... people could see some new trends in technology ...

... and everyone was happy.

Read more about the event and see more pictures.

Leaving Santa Clara, CA

2008-03-22T20:20:00.008+01:00

We should have left Santa Clara yesterday. But darn, because of bad weather conditions in Chicago we got stuck in San Jose. The nice thing is that we had one extra day in California at the airport expense. The hotel was quite nice with nice food served in The Island Grill ;-)

Today our trip started again. So far so good, we managed to hit the airport in Denver. 4 hour stop in Colorado let us to release some changes for M6 :-)

The next flight is in 2 hours. I hope that the rest of the trip will go like clockwork.

How to make the hunk compare editor more informative

2008-03-06T14:55:00.027+01:00

Quick intro:

I've been working with the Apply Patch wizard recently. Following bugs has been fixed:

But the real goal is to address 3 bugs reported by Stefan Xenos:

Before I start working with them I will need to solve these:

Especially the 217076 appeared to be a hard nut to crack. There has been a short discussion in one of the bugs from Stefan about how the editor should look like. I agree with one of the comments there that it would be great to have an editor to play with, but let me first quickly present changes made so far. This could also to a good place to start the discussion again.

Flow:

Screens (currently):

This is what user sees in the editor when trying to apply a conflicting patch. The patch consists of 3 hunks. By a conflict in this case I mean a change made to one of context lines (see Fig 2).

Fig 1. The editor indicating that there is a conflict. "I can't apply the first hunk".

Let us see what is the problem. Double-clicking of the hunk loads its content and shows that the patcher expects "[02]" in the second line, but the line has been changed to "[02] CHANGE". The line is actually the second line of context for the first hunk. If it doesn't match the hunk cannot be applied.

Fig 2. The editor showing details of a conflict.

Below is a proposition how conflicts can be shown in the editor*.

Fig 2a. The editor showing details of a conflict marked red.

Click the newly arrived "Show matched" option. This will allow us to see whole patch.

Fig 3. The editor showing full structure of the patch.

Clicking "Guess" results in the fuzz factor set to 2. This is how many lines need to be ignored to successfully apply the conflicting hunk.

Fig 4. The editor after guessing the fuzz. "Fuzz factor factor to the rescue!".

Double click on the hunk to see the details.

Fig 5. The editor showing details of the conflicting hunk after the fuzz applied. "I can apply the hunk if the fuzz factor is 2".

I though that maybe using a fuzz factor should be indicated with yellow:

Fig 5a. The editor* showing the context lines matched with a fuzz factor marked yellow.

The user can also inspect other hunks to check if everything's fine.

Fig 6. The editor showing details of a matched hunk. "I can apply this one smoothly".

* both screen shots for figuers 2a and 5a are show a different patch, but I hope they still give the idea

Funny code snippets in Eclipse (part 1)

2008-01-17T11:34:00.000+01:00

First of all, my intention is not to embarrass any of the snippet's owners. I think it's great, that using a serious tool as a programming language we can create such funny things. So, this series is donated to the wonderful world of those little pieces of code that make our bored, programmers faces lit up in a smile :)

1. When right is left

2. A workaround method

3. To fix or not to fix

To be continued...

The fuzz factor released

2007-10-17T18:43:00.000+02:00

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.

My first commit

2007-10-12T18:08:00.000+02:00

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):

Fixing the Patcher (part 2): testing

2007-10-02T18:16:00.000+02:00

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:

Create a project with a file and share it
Make a change in the file
Create a diff (patch) for the file
Override and update the file (revert to previous version)
Apply the patch and check if it's the same as in 1.
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.

Fixing the Patcher (part 1)

2007-09-26T22:32:00.000+02:00

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:

Diff on wikipedia
Patch on Linux man page

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...

Mylyn Task list organization

2007-09-14T15:56:00.000+02:00

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.

Priority of content types

2007-09-12T14:15:00.000+02:00

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.

:-)

"Add to .cvsignore" dialog

2007-09-06T00:29:00.000+02:00

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:

Eclipse User Interface Guidelines, same article on wiki can be found here.
UI Best Practices v3.x
Platform UI/Accessibility Features

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.

Photo session

2007-09-04T11:46:00.000+02:00

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 ;-)

In search of a bug

2007-09-03T11:00:00.000+02:00

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

Smart Keyword

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

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

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.

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

OpenSearch

this page

<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"/>
...

Ctrl+K

Ctrl+Up Arrow

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

2007-09-03T09:27:00.000+02:00

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 ;-)