Messing With Rofi: Inserting Unicode

 Computing, Linux, Working Notes  No Responses »
Feb 292020
 

I used to be able to remember all of the keyboard short-cuts I’d set up to insert ‘fun’ (or useful) Unicode characters … but my memory isn’t quite what it used to be, and I happened to catch a video that mentioned a menu to insert Unicode characters.

So I set out to create my own …

#!/bin/zsh
#
# Run a menu of Unicode characters to put into the clipboard

read -r -d '' menu << END
Þ       Thorn (Sym-t)
Þ	Capital thorn (Sym-T)
✓	Tick (Sym-y)
✔       Alternate tick (Sym-Y)
π	pi (Sym-p)
Π       PI (Sym-P)
★       Star
🖕      Finger
END

selectedchar=$(echo $menu |\
  rofi -dmenu -l 20 -fn misc-24 -p "Unicode inserter" |\
  awk '{print $1}')
if [ -z "$selectedchar" ]
then
  notify-send "Unicode Inserter" "Cancelled"
else
  printf "%s" $selectedchar | xclip -selection clipboard
  notify-send "Unicode Inserter" \
    "Character $selectedchar now in clipboard"
fi

This script :-

  1. Creates a variable with a whole pile of text inside it. The original script contains a lot longer list, but including it would be a) boring and b) give too much away. As it stands, the format of each line is pretty much anything you want as long as the first character is the Unicode character followed by whitespace.
  2. Runs rofi with the variable as input and selects the first field of the response.
  3. Guards against the empty selection (when the menu was cancelled) for neatness mostly.
  4. Prints the selected character (without a newline) into xclip so it can be pasted in. I did try using xdotool to type it directly into the active window, but this didn’t always work so well (i.e. xdotool couldn’t “type” some of the more esoteric characters).
  5. And uses notify-send to alert the dumb user (me!) that something has happened.

Lastly, to make this useful, I added an entry to my sxhkd configuration :-

super + F11
  /site/scripts/m-unicode-insert

Virtual Cores Are Not Physical Cores

 Computing  No Responses »
Feb 242020
 

Every so often, I tune into a video on some form of virtualisation which perpetuates the myth that ‘virtual cores’ that you allocate to a virtual machine are equivalent to the physical cores that the host has. In other words if you create a virtual machine with two cores, that is two cores that the rest of the host cannot use.

Preposterious.

Conceptually at least, a core is a queue runner that takes a task on a queue, runs that task for a while, and then sticks that task back on the queue. Except for specialised workloads, those cores are very often (even mostly) idle.

To the host machine, tasks scheduled to run on a virtual core are just tasks to be performed waiting in the queue; ignoring practicality, there is no reason why there should not be more virtual cores in a virtual machine than there are in the host machine.

If you take a look at the configuration of my virtual Windows machine in VirtualBox :-

You see :-

  1. I’ve allocated 8 virtual cores to this machine. I rarely use this machine (although it is usually running), but it does not take much resources to run idle cores.
  2. VirtualBox arbitrarily limits the number of cores I can allocate to the virtual machine to the number of threads my processor has; it also has a warning at the number of cores my processor has but doesn’t stop me allocating virtual cores in the “red” zone.

Qemu on the other hand has no such qualms about launching a virtual machine with 64 cores – well in excess of what my physical processor has.

Of course you have to be sensible, but creating a virtual machine with 4 cores does not make four cores unavailable to your host machine. If a virtual machine is idle, it won’t be running much (no machine is ever completely idle) on your real cores.

 Older Entries  Newer Entries