opcontrol: command not found

Wanted to share how to use oprofile nowadays. Every tutorial on the Internet I found uses opcontrol, but, well…

$ sudo opcontrol --reset
sudo: opcontrol: command not found

Searching for package with the filename tells that opcontrol exists neither in Archlinux nor in Ubuntu. Perhaps the command just was renamed? Let’s search for an option of opcontrol in manuals:

$ man -k start-daemon
start-daemon: nothing appropriate.

I don’t know what happened, but the way it works now is through operf. E.g. sudo operf mycommand — or rather, since we don’t want to run the profiled app with elevated rights, just run the app, and connect operf to its pid, like sudo operf --pid=8888.

For some reason operf stay running even when the app exited, just press ^C to stop operf, it would create a profiling data, then you can use opreport as usual, like in tutorials.

Missing icons of kmix and klipper in bar of i3

It’s a quick note for anyone coming from search. If you’re not using a full-featured DE, rather something as simple as i3, or Awesome, or XMonad, or Fluxbox, or anything else not including bells’n’whistles; and you’ve missing or wrong icon of klipper/kmix in bar(and, probably, some other Qt apps), then you’ve to set XDG_CURRENT_DESKTOP="xfce" for those apps.

E.g. I’m using i3, and have the variable set to “kde” (for dolphin, and likes), so I’m just autostarting klipper and kmix like XDG_CURRENT_DESKTOP="xfce" kmix.

The reasons is probably that those DEs provides some API which applets expect to use. Using "xfce" variable in the case of absent DE is fine though.

Archlinux: Compose key

It was hard to find, so I want to share how I got Compose key configured’n’working on Archlinux. Note: if you’re reading it in the future, I hope some of the problems (e.g. with ibus) are outdated. Leave a comment if that’s true.

At the moment of writing this, the Internet has pretty scarce info about text input internals for GNU/Linux. Most of the info I got by arguing with ibus maintainer here, here, and here. What you may want to know with relation to Compose key, is that the input (including XCompose) is done with XKB protocol. It sounds pretty X11, but is used on Wayland either.

An important note: the Compose Input Methods in either ibus or fcitx has lame imitations, they doesn’t even read ~/.XCompose. That’s not what you want, the real XCompose have to be configured with XKB, and is not an IM.

To make XCompose working with ibus you’d have to set globally (in the /etc/profile) GTK_IM_MODULE and QT_IM_MODULE variables to ibus, then “XMODIFIERS=@im=ibus” (this one may be not mandatory, Idk), and either execute setxkbmap -option compose:rwin (substitute rwin with the favorite key if needed), or set it up in the dungeon of XKB configuration (I couldn’t find quickly for where and how, and configured via X-files, see below, but it won’t work obviously with Wayland).

The ibus way worked with gnome-on-wayland as well as on X11, but you didn’t really want ibus as it’s pretty raw. To me the most annoyng are non-working LED on layout switch, and missing support for multicharacters, i.e. you can’t configure getting the on pressing Compose+t. CJK people doesn’t like ibus either, idk why. Fortunately, even though ibus maintainer doesn’t seem to be interested in fixing anything personally, at least they maintains it, so you can write a patch, and hope the PR to be merged.

I’m using instead the fcitx implementation of Compose (and I didn’t test it with Wayland), but it is tricky, so follow the hands!

  1. Install fcitx.
  2. Add into the /etc/profile (or wherever to be exported globally, overwrite if you had the variables set to anything else):
    export XMODIFIERS=@im=none
    export GTK_IM_MODULE="fcitx"
    export QT_IM_MODULE="fcitx"
  3. Important: make sure that fcitx daemon is not running! Idk why, but for it starts, everything breaks. The daemon shalt not pass! From what I understand, Qt and GTK, and may be EFL, are having some internally supplied fcitx modules (about GTK it’s for sure) that probably get called. Still, why fcitx daemon kills the fun, is a puzzle.

  4. Configure the Compose key. For starters, just to test if it works, you could run setxkbmap -option compose:rwin (to set the right win-logo key as Compose), then press some combinations. Ideally you’d have to have the ~/.XCompose file, and to press its combinations, to make sure it’s being read. If everything is fine, you could configure it via X11 files (and may be XKB ones, but Idk how). Here the X11 example I’m using:

    $ cat /etc/X11/xorg.conf.d/00-keyboard.conf
    # Read and parsed by systemd-localed. It's probably wise not to edit this file
    # manually too freely.
    Section "InputClass"
            Identifier "system-keyboard"
            MatchIsKeyboard "on"
            Option "XkbLayout" "us,ru"
            Option "XkbModel" "pc105"
            Option "XkbOptions"    "grp:rctrl_rshift_toggle,grp_led:scroll,lv3:ralt_switch,compose:rwin"

Now, if you look at 00-keyboard.conf example thinking of ibus, make sure to remove the language switch option, so that it wouldn’t conflict with ibus config.


You may want a ready to go XCompose file (the dotxcompose in the repository) as a ~/.XCompose. It’s made to be backward-compatible with system XCompose file, so you may want to overwrite some combinations, in particular these to press a ^ just single time.

Pass +RTS options to GHC’n’GHCi

For working with projects, I’m using apps from Stack. Besides, I usually also have GHCi running for quick checks. And for I didn’t really want duplicating shared libraries and file cache in RAM (i.e. the ones the system GHC is using, plus the ones that Stack does), I’m trying to stick to Stack for everything.

So to force Stack to pass RTS options to ghc and ghci you’d have to use --ghc-options and --ghci-options respectively.

I.e. I saved aliases to my ~/.zshrc (if you’re using bash, it’d be a ~/.bashrc).

alias ghci512="stack ghci --ghci-options '+RTS -M512m -RTS'"
alias ghci="stack ghci --ghci-options ''"
alias ghc="stack ghc --ghc-options ''"

Aliases won’t always work (like if you’re using a script not knowing about them), nevertheless are useful most of the time.

UPD: with aliases were problems that I fed up with, so I made up scripts instead:

$ cat /usr/bin/ghciMath512 
stack ghci --ghci-options "+RTS -M512m -RTS -ghci-script /home/constantine/.ghciMath `echo $@`"
$ cat /usr/bin/ghci       
stack ghci --ghci-options "`echo $@`"

Note the echo — it’s needed to collapse multiple arguments into a single with space-separated words.

Compile Yi with Pango

By default Yi doesn’t compile Pango frontend, only vty (and “batch”, whatever it is). To compile Pango with stack (btw, use stack, as it would remove some problems; also stack install rebuilds faster, then cabal install does), execute in the yi directory:

$ stack init
$ stack install --flag yi:pango

Then, to run the editor with Pango frontend:

$ stack exec yi -- -f pango

P.S.: There’s annoying thing, that in Vim’s normal mode the cursor — the Pango frontend problem — is not a big black box. It’s the problem, specific to GTK2-3, it just didn’t have an API to make such a cursor. Technically, there’s a workaround to enable “insert” mode, i.e. like if one would press “Insert” key. The first time when I met the editor, I tried to fix this bug as part of a student paper, but didn’t manage to go so far as to finally get it fixed. I did much tho, and wrote on IRC about it, but peoples there wasn’t interested. Granted, I ought to at least report a bug. Well, let’s see what can I do today.