If you haven’t heard, there are a few KDE projects testing Phabricator for patch review and project management.
KActivities are amongst those.
So, from now on, if you want to provide patches, you are advised to do that through http://phabricator.kde.org/ and the Arcanist tool instead of the ReviewBoard.
We are also going to organize our work tasks on Phabricator instead of todo.kde.org.
The ultimate goal is to test whether Phabricator is a viable alternative to a few of our services.
The ReviewBoard is still working, but if you do send patches there, please also ping me on IRC, or send me an email since it is easy to miss those mails.
Published
in the Prog C++ section,
on 4 March 2015
I’m almost back from the C++ Russia conference held in Moscow these past few days. Heading home later today.
I must say that Sergey created a really nice conference, with a carefully tailored set of talks mostly focussed on parallelism and concurrency.
The conference was opened by Sean Parent, with a keynote somewhere along the lines of “don’t use raw threads” (after his previous hits like “don’t use raw for-loops”). It had everything, great examples from the his projects at Adobe, a few bigger chunks of code, and even abstract scientific parts related to flows in graph theory.
And that was just the beginning.
It was followed by Zoltan Porkolab’s talk on debugging and profiling C++ meta-template programs. Fantastic talk that deserves a separate blog post since it can make a lot of TMP-related headaches go away. I’ll write it one of the following days, when I get my bearings.
It was also a pleasure to listen to Bartosz Milewski talking about category theory and presenting monads in quite an interesting way; Rainer Grimm on how to cope when you need to use the lower-level concurrency primitives; and Guntram Berti on how to properly write your generic code.
Unfortunately, a lot of talks were in Russian, so I was not able to follow them. Otherwise, I would not only mention the foreign speakers.
During the intermissions, I talked to local programmers about their environment and popularity of C++ and Qt in Russia. Obviously, since it was a C++ conference, everybody that was present was using C++. But the thing that surprised me is that Qt is also very much alive in these parts of the world. And these were not small IT companies, far from it (not going to mention the names, I have no idea whether this information is public or not :) ).
For the end, a proof that Linux/KDE/C++ people are vandals:
Now, a continuation (pun intended) of that story is happening. I was invited by Sergey Platonov to speak at the C++ Russia conference in Moscow alongside Sean Parent and Bartosz Milewski (very humbled and thrilled to be in the same group as them).
The presentation will be on the task scheduling using the continuation monad. It will be based on parts of my Berlin talk, but with much less time spent on monads, and with the second part about continuations significantly expanded.
A few days ago, Elias Probst asked me to provide some shell functions to easily fetch the current activity so that he could use it with the TaskWarrior - to separate tasks for different activities. These are now avilable in the KActivities repository and … I’m not going to explain them in this post. Maybe the next one.
When he said the name “TaskWarrior”, I just had to see what it is.
In a nutshell, it is an awesome command-line tool for task management. It supports tags, custom annotations, separating tasks from different projects etc. and sorting tasks by automatically calculated urgency (you can check out the docs to see how it is calculated). It has a couple of different TUIs and GUIs including one for Android (works on BlackBerry 10 as well).
It can use multiple different databases specified via an environment variable. At first, I wanted to implement the activity-task-separation that way. It worked ok, but created problems with syncing tasks between different devices, and you could not list tasks from all activities in one command.
After that, I decided to change the approach and use the project tag of a task for activities. I have written a small Python wrapper that uses the activity name as the task’s project (lately, I’ve been using Haskell for things like these, but in this case I chose Python because more people have it installed on their systems).
If you do not specify the project tag manually, the wrapper will automatically tag it with the name of the current activity; and if you do specify a project, the wrapper will prefix it with the name of the activity like this:
As seen in the screenshots, it only shows the tasks from the current activity by default. It is also possible to list all the tasks from all activities by calling ‘task.py all’ (I’ve created aliases t = task.py and ta = t all for convenience):
Potential problems
It is never advisable to use the activity names directly, since those can be changed, but I decided to do it this way because it would be really ugly to have UUIDs as project names.
I hope this will not create problems for the users - I don’t expect people to change the activity names that often.
One of the possible future developments would be to also tag the tasks with activity:UUID tag and renaming projects when the activity names change, but we’ll see whether that is the best way to do it. A downside is that this might create problems for synchronization because ‘the same’ activity will have different IDs on different devices.
Published
in the Other section,
on 2 February 2015
The last time I posted something like this, it was about RSI and using a tablet as a keyboard replacement.
Now, a different story.
I never have enough screen real-estate. I sometimes keep six files open at the same time in split-screens, but that requires my Vim windows to be maximized, and then I don’t see the terminal. So I can not see the results of auto-tests (for example), and the relevant code at the same time.
I was thinking of getting a bigger screen (an ultra-wide 21:9 one), but I don’t want to throw away the one I’m currently using - it works without any issues. And I do not really have the space for two screens on my desk.
The solution was to move the tmux session with the compilation and auto-tests output to a secondary device which can be seen on the picture here. Vim sends all needed commands to the tmux session using the awesome slimux plugin so that I don’t need to touch the second device at all.
This way, I have the most important stuff always on my main screen, while the second one has things that do not need attention that often.
p.s. Yes, that is a home-made replica of Tom Baker’s sonic screwdriver I made for a cosplay party.