fidzu : gnome

During the last few days there has been an ongoing Twitter storm about 10× developers. And like all the ones before it (and all the future ones that will inevitably happen) the debate immediately devolved into name calling and all the other things you'd except from Twitter fights. This blog post is not about that. Instead it is about a personal experience about productivity that I had to experience closer than I would have liked.

Some years ago I was working for company X on product Y. All in all it was quite a nice experience. We had a small team working on a code base that was pretty good. It had nice tests, not too many bugs, and when issues did arise they were usually easy to fix. Eventually the project was deemed good enough and we were transferred to work on different projects.

I have no idea what our "industry standard performance multiplier" was when we worked on that project, but for the sake of argument let's call it 1×.

The project I got transferred to was the thing of nightmares. It was a C++ project and all the bad things that have ever been said about C++ were true about that code base. There was not much code but it was utterly incomprehensible. There were massively deep inheritance hierarchies, , compilation speed was measured in minutes for even the most trivial changes, and so on. It was managed by an architecture astronaut that, as one is wont to do, rewrote existing mature libraries as header only template libraries that were buggy and untested (one could even say untestable).

Thus overnight I went from being a 1× down to being a 0.1× or possibly even a 0.01× developer. Simply trying to understand what a specific function was supposed to do took hours. There was, naturally, a big product launch coming up so we needed to get things finished quickly. All in all it was a stressful, frustrating and unpleasant situation to be in. And that was not the worst of it.

After a few weeks my manager wanted to talk to me in private. He was very concerned about the fact that I had not achieved any visible progress for a while. Then I explained to him in detail all the problems in the current project. I even demonstrated how compiling a simple helloworld-level program with the frameworks we had to use took tens of seconds on the beefiest i7 desktop machine I had available. He did not seem to be able to grasp any of that as his only response was "but you used to be so productive in your previous project". Shortly thereafter the same boss started giving me not-al-all-thinly-veiled accusations that I was just slacking off and that this could lead to serious reprimands.

This story does not have a happy ending. The project eventually failed (due to completely different reasons, though), money was squandered and almost everyone involved got fired. In the aftermath I seriously considered getting out of the software engineering business altogether. The entire experience had been so miserable that becoming a 0× developer was seriously tempting.

Is there something we can learn from this?

16 Jul 2019 2:40pm GMT

The final API so far in this mini-series on new APIs in the GLib 2.62 series is g_array_binary_search(), put together by Emmanuel Fleury and based on code by Christian Hergert. It's due to be released in 2.61.2 soon. But first, a reminder about GLib version numbering.

Like the rest of GNOME's official module set, GLib follows an odd/even versioning scheme, where every odd minor version number, like 2.61.x, is an unstable release building up to an even minor version number, like 2.62.x, which is stable. APIs may be added in unstable releases. They may be modified or even removed (if they haven't been in a stable release yet). So all of the APIs I've blogged about recently still have a chance to be tweaked or dropped if people find problems with them. So if you see a problem or think that one of these APIs would be awkward to use in some way, please say, sooner rather than later! They need fixing before they're in a stable release.

Back to today's API, g_array_binary_search(). As its name suggests, this does a binary search on an array (which it requires is already sorted). You can use it like this:

static gint
compare_guint64 (gconstpointer a,
                 gconstpointer b)
{
  guint64 uint64_a = *((guint64 *) a);
  guint64 uint64_b = *((guint64 *) b);

  if (uint64_a < uint64_b)
    return -1;
  else if (uint64_a > uint64_b)
    return 1;
  else
    return 0;
}

g_autoptr(GArray) my_array = g_array_new (FALSE, TRUE, sizeof (guint64));

for (guint i = 0; i < 100; i++)
  {
    guint64 random_uint64 = ( (guint64) g_random_int () << 32) | g_random_int ();
    g_array_append_val (my_array, random_uint64);
  }

g_array_sort (my_array, compare_guint64);

/* Is '1234' in the array? If so, where? */
const guint64 search_uint64 = 1234;
guint search_index;
if (g_array_binary_search (my_array, &amp;search_uint64, compare_guint64, &amp;search_index))
  g_message ("Found '1234' at index %u", search_index);
else
  g_message ("Didn't find '1234'");

As all computer science algorithms courses will tell you, a binary search is faster than a linear search, so you should use this in preference to iterating over an array to find an element in it, where possible.

(That's not entirely true: the overheads of accounting for the binary search bounds, and the slowness of scattered memory loads from the array in a binary search vs sequential access in a linear search, will probably make it slower than a linear search for small arrays. But both will be fast, and if you need to care about that level of performance, you should be using a custom data structure rather than GArray.)

16 Jul 2019 10:51am GMT

July Marked the beginning of II GSOC coding month. This month our goal is to make the diff bar model as accurate and intuitive as possible.

One of the biggest thing which I learnt so far is how to contribute on upstream repositories on which our project depends.

In our case this was with Libgit2, we discovered a bug in Libgit2 while doing our project, and Albfan made this a perfect example to show me how to contribute on upstream, how to raise bugs and how to do discussions for getting it solved.

https://github.com/libgit2/libgit2/issues/5153

While this got solved we can't wait to get the solutions merged. So we filtered out which patches works best for us and I learnt how to apply patches to projects with Flatpak.

I really think the Flatpak team has done a great job on this one, and it was super easy and useful for me to get those patches working with my project. Without flatpak manifest Idk how I would have pulled it off.

https://gitlab.gnome.org/gaurav1999/diferencia/commit/3c5c93137acfd3c11d5aeeffdd03af68523d6e3e

I tried to understand how amazing is Gtk.TextView and I used something called Gtk.TextTag for highlighting the Diff text in appropriate colors.

Red -> Removed Text

Green --> Insertion Text

In order to make grounds for Three way merge diff view, we are able to make sure now we paint the diff bar in relative manner.

For this, we introduced a reverse direction property which essentially makes the model know which direction we will be painting the diff curves, Right to Left or Left to Right.

https://gitlab.gnome.org/gaurav1999/diferencia/commit/79ff5406f3ecdca07c3caed204ca1aff13922a2c

Now comes the hard part…

Right now our model works on DiffLineCallback, where we basically pick up each line diff and paint the indicating curve for it. The disadvantage of doing this is that, the curves are getting overlapped and it not looks good.

So I tried to do some pre processing of the data and improve this situation.

and the results look pretty!

While there are still tuning required for the algorithm, and I hope we get this completed real soon.

Now, the most Hard part !!!!!

Visa , It's really hard to arrange all of your documents required for European visa, really hoping my hard work pays off and I meet you all Gnome Folks in GUADEC soon.

In the end it's almost one and a half week left for this month to get end, and I have learnt a lot like always!

15 Jul 2019 2:24pm GMT

The All Systems Go! 2019 Call for Participation Re-Opened for ONE DAY!

Due to popular request we have re-opened the Call for Participation (CFP) for All Systems Go! 2019 for one day. It will close again TODAY, on 15 of July 2019, midnight Central European Summit Time! If you missed the deadline so far, we'd like to invite you to submit your proposals for consideration to the CFP submission site quickly! (And yes, this is the last extension, there's not going to be any more extensions.)

All Systems Go! is everybody's favourite low-level Userspace Linux conference, taking place in Berlin, Germany in September 20-22, 2019.

For more information please visit our conference website!

14 Jul 2019 10:00pm GMT

11 Jul 2019 11:00pm GMT

For a long period of time, I'm cultivating the desire of having a habit of writing monthly status updates. Someway, Drew DeVault's Blog posts and Martin Peres's advice leverage me towards this direction. So, here I am! I have decided to embrace the challenge of composing a report per month. I hope this new habit helps me to improve my writing and communication skills but most importantly, help me to keep track of my work. I want to start this update by describing my work conditions and then focus on the technical stuff.

In the last two months, I've been facing an infrastructure problem to work. I'm dealing with obstacles such as restricted Internet access and long hours in public transportation from my home to my workplace. Unfortunately, I can't work in my house due to the lack of space, and the best place to work is a public library at the University of Brasilia (UnB). Going to UnB every day makes me waste around 3h per day in a bus. The library has a great environment, but it also has thousands of internet restrictions. The fact that I can't access websites with '.me' domain and connect to my IRC bouncer is an example of that. In summary: It's been hard to work these days. So let's stop talking about non-technical stuff and get into the heart of the matter.

I really like working on VKMS. I know this is not news to anybody, and in June, most of my efforts were dedicated to VKMS. One of my paramount endeavors it was found and fixed a bug in vkms that makes kms_cursor_crc, and kms_pipe_crc_basic fails. I was chasing this bug for a long time as can be seen here [1]. After many hours debugging it, I sent a patch for handling this issue [2], however, after Daniel's review, I realized that my patch didn't fix correctly the problem. So Daniel decided to dig into this issue to find the root of the problem and later sent a final fix. If you want to see the solution, take a look at [3]. One day, I want to write a post about this fix since it is an interesting subject to discuss.

Daniel also noticed some concurrency problems in the CRC code and sent a patchset composed of 10 patches that tackle the issue. These patches focused on creating better framebuffers manipulation and avoiding race conditions. It took me around 4 days to take a look and test this series. During my review, I asked many things related to concurrency and other clarification about DRM. Daniel always replied with a very nice and detailed explanation. If you want to learn a little bit more about locks, I recommend you to take a look at [4]. Seriously, it is really nice!

I also worked for adding the writeback support in vkms; since XDC2018 I could not stop to think about the idea of adding writeback connector in vkms due to the benefits it could bring, such as new test and assist developers with visual output. As a result, I started some clumsy attempts to implement it in January; but I really dove in this issue in the middle of April, and in June I was focused on making it work. It was tough for me to implement these features due to the following reasons:

1. There is not i-g-t test for writeback in the main repository, I had to use a WIP patchset made by Brian and Liviu.
2. I was not familiar with framebuffer, connectors, and fancy manipulation.

As a result of the above limitations, I had to invest many hours reading the documentation and the DRM/IGT code. In the end, I think that add writeback connectors paid well for me since I feel much more comfortable with many things related to DRM these days. The writeback support was not landed yet, however, at this moment the patch is under review (V3) and changed a lot since the first version; for details about this series take a look at [5]. I'll write a post about this feature after it gets merged.

After having the writeback connectors working in vkms, I felt so grateful for Brian, Liviu, and Daniel for all the assistance they provided to me. In particular, I was thrilled that Brian and Liviu made kms_writeback test which worked as an implementation guideline for me. As a result, I updated their patchsets for making it work in the latest version of IGT and made some tiny fixes. My goal was helping them to upstream kms_writeback. I submitted the series with the hope to see it landed in the IGT [9].

Parallel to my work with 'writeback' I was trying to figure out how I could expose vkms configurations to the userspace via configfs. After many efforts, I submitted the first version of configfs support; in this patchset I exposed the virtual and writeback connectors. Take a look at [6] for more information about this feature, and definitely, I'll write a post about this feature after it gets landed.

Finally, I'm still trying to upstream a patch that makes drm_wait_vblank_ioctl return EOPNOTSUPP instead of EINVAL if the driver does not support vblank get landed. Since this change is in the DRM core and also change the userspace, it is not easy to make this patch get landed. For the details about this patch, you can take a look here [7]. I also implemented some changes in the kms_flip to validate the changes that I made in the function drm_wait_vblank_ioctl and it got landed [8].

July Aims

In June, I was totally dedicated to vkms, now I want to slow my road a little bit and study more about userspace. I want to take a step back and make some tiny programs using libdrm with the goal of understanding the interaction among userspace and kernel space. I also want to take a look at the theoretical part related to computer graphics.

I want to put some effort to improve a tool named kw that help me during my work with Linux Kernel. I also want to take a look at real overlay planes support in vkms. I noted that I have to find a "contribution protocol" (review/write code) that works for me in my current work conditions; otherwise, work will become painful for my relatives and me. Finally, and most importantly, I want to take some days off to enjoy my family.

Info: If you find any problem with this text, please let me know. I will be glad to fix it.

References

[1] "First discussion in the Shayenne's patch about the CRC problem". URL: https://lkml.org/lkml/2019/3/10/197. ⤴

[2] "Patch fix for the CRC issue". URL: https://patchwork.freedesktop.org/patch/308617/. ⤴

[3] "Daniel final fix for CRC". URL: https://patchwork.freedesktop.org/patch/308881/?series=61703&rev=1. ⤴

[4] "Rework crc worker". URL: https://patchwork.freedesktop.org/series/61737/. ⤴

[5] "Introduces writeback support". URL: https://patchwork.freedesktop.org/series/61738/. ⤴

[6] "Introduce basic support for configfs". URL: https://patchwork.freedesktop.org/series/63010/. ⤴

[7] "Change EINVAL by EOPNOTSUPP when vblank is not supported". URL: https://patchwork.freedesktop.org/patch/314399/?series=50697&rev=7. ⤴

[8] "Skip VBlank tests in modules without VBlank". URL: https://gitlab.freedesktop.org/drm/igt-gpu-tools/commit/2d244aed69165753f3adbbd6468db073dc1acf9a. ⤴

[9] "Add support for testing writeback connectors". URL: https://patchwork.freedesktop.org/series/39229/. ⤴

09 Jul 2019 3:00am GMT