Recent Content

Syncthing: Syncing...

Published on:

SyncThing is a very interesting distributed file sharing option. It is a lot like (what I understand of) Dropbox and the file sharing capabilities of ownCloud, as well as SparkleShare, SeaFile and others. The biggest difference compared to all of these, though, is that SyncThing is distributed, or peer-to-peer, there is no central server used in the file sharing.

Setting it up is a breeze. Install it, run it and you're almost done. Once you have it installed on at least two computers (or know someone else who has installed it), you have to let them know eachother. You do this by exchanging their node ids. SyncThing know two things: Nodes and Repositories. Nodes are the different machines you want to share with and repositories are the different directories you want to share with certain nodes. Exchanging node ids requires an actual exchange. If you're managing both machines yourself it shouldn't be too hard to manage, if you're sharing with someone else you need another channel of communication to get this data across. Once you've exchanged node ids and your firewall is setup properly (it needs to let through a special TCP port for global discovery) your machines will connect. If you're both on a local network it should happen quickly, if you're across a large gap of land it should still happen fairly quickly.

After both your machines are connected, or even before, you should setup some repositories and share them with the node you just connected with, otherwise nothing will happen. Again there's some communication involved here, because both sides will have to share a repository with the same name. If either side doesn't share a repository with the other side, it won't sync. After you've communicated which names to use, though, all should go smoothly. It check once every 60 seconds whether or not anything's changed and if it has it'll try and sync with the other machine(s).

One downside to this program, at least on Linux, compared to ownCloud, at least using the ownCloud Client, is that there is no notification of newly arrived files. So again you'd have to send the person owning the node you're sharing with a message telling them that something new should be waiting for them.

A very nice thing on the other hand, is that everything is encrypted. And because there's no central server involved, only the people you choose to share with (and possibly they choose to share with) will have the files. There is no single server that can get hacked into where all your files can be found. It's also open source, which of course makes it possible for you, or anyone else, to look at, improve, audit or do anything with the code you want to or need to to ensure to yourself that it's not doing anything it shouldn't be doing.

I haven't been able to test it thoroughly in the real world. I'm currently just sharing between my desktop PC and my laptop, and I'm sharing with a good friend of mine. So I'm looking forward to seeing more of it.


rcm: Another dotfile manager

Published on:

A little while ago I saw a link pass by about rcm, a RC file (or dotfile) manager. It seems a lot like using GNU Stow for your dotfiles.

The basic idea seems to be that you create links to all your dotfiles and the actual files are all kept in a single directory structure, presumably for easy sharing with, for example, git.

The good...

It seems that rcm has a few interesting features.

Host-specific dotfiles

It gives you an option to have host-specific dotfiles, which is very handy when you're working on multiple (types of) system. My laptop doesn't always have the same needs as my PC and my server(s) definitely have different needs.

The bad...

In the short time I've spent with it, I've also found a few things I don't much like.

Everything in a single directory

I'm not so sure about the choice to put everything in a single directory structure, which top-level dotfiles in the top-level directory. This links all the files together in a repository-idea kind-of way. I can't have a zsh repository and an Emacs repository without also having different rcm source directories.

Actually, this isn't entirely true. I can still separate them, with the use of labels, but not in an ideal fashion.

Unfriendly to directories

It doesn't seem to like linking directories, though it can. Linking directories is essential for me as I can on occasion remove a file from one of my configuration directories and I don't want to have to keep track of dead links like that manually. If you do link a directory, instead of it showing up in lsrc as a single entry, all the files in the directory are shown separately.

Labels

The labels are a nice idea, but they aren't what I expected them to be when I read the description. Like host-specific dotfiles, labeled dotfiles are put in their own directory. This allows you to separate the dotfiles from others. What I didn't like about this implementation is that afterwards you always have to specify which label you want to use, which seems to make it impossible to still setup your dotfiles in a single command.

Conclusion

I personally won't be using rcm to manage my dotfiles. The solution I have right now with GNU Stow works better and is easier to setup, although that too has its drawbacks.

This is not a definitive description or review of the software, I have spent only a small amount of time with it and these are the findings I made when trying to set it up with a few config files. If you really want to know about it you should try it, it has quite a bit of documentation to get you going.


There is an Evil in your Emacs

Published on:

When I first started using GNU/Linux I was looking for a proper text editor. I only had any experience with Visual Studio on Windows because I was a .Net developer at the time, and didn't really have much of a choice. One of the main things I wanted was an editor that worked in a terminal.

Naturally I came to Vim and Emacs (as well as Nano, and perhaps some others as well). For a few weeks I kept switching between Vim and Emacs. I liked Vim's syntax highlighting better, but on the other hand I liked Emacs' keybindings/modelessness better as well. I ended up going with Emacs mostly because of Vim's moded editing.

For years the thought of Vim's moded editing gave me nightmares. I never really realised the best thing about Vim. Even when a post appears on Stack Overflow about grokking Vim. I was already so blinded by the idea that Emacs was the superior editor for me that I failed to register the information. It took a long time, but eventually I opened up to the possibility of such moded editing. By now I was stuck with Emacs because I just couldn't give up its customizability or extensibility. Also, I've grown to love Lisp, and specifically Emacs Lisp, so to go from that to Vimscript wouldn't be quite ideal.

Eventually I decided I really did want to try it. Thankfully Emacs has a package for that: Evil, the Extensible Vi Layer for Emacs. There is one other problem, though: I use the Colemak keyboard layout. The usual hjkl keys are more like hynu, with the up key at the bottom of the keyboard, down at the top and left and right diagonally from eachother. Again Emacs has a package for that, colemak-evil. It rebinds some of the keys so that Evil will work with the Colemak keyboard layout. It is based on that the creator of the Colemak layout used to use in Vim. It's a bit aggressive, so I customized it to be a little less so, mostly removing rebindigs from the motion and emacs state maps.

The real power is in the composability of the commands. In Emacs you have commands like forward-kill-word, forward-kill-sexp and forward-kill-char. In Vim you have the delete operation, which can be combined with, for example, the forward-word motion, or the next-line or forward-char motion. I probably have the names wrong, but hopefully they convey the meaning of what they do. This is what it is all about, or at least from what I've learned to use so far. Of course the powerful ed-like editing features called forth through the Vim ex mode, such as %s/find/replace. Lastly, of course, the fact that a lot of editing can be done in normal mode helps in preventing Emacs-pinky.

I haven't yet been able to work with the extensible part, but some of the modules that exist for evil speak volumes of it.

If you are interested in increasing your productivity, or you like to experiment with new things, you might really want to try it. It may not completely be Vim, but it's still completely Emacs. If you use the colemak-evil package as well you'll also notice that in the insert state all your regular Emacs keys work normally, which is a great combination of the two editors. So far I feel that Vim is great for editing existing code and text, but Emacs still feels better when writing a lot of new code or text.


Testing with Lua

Published on:

Last time I wrote about my project avandu-lua and I mentioned how I was having some trouble testing the different types of functions. I've since found a way to mock the functions in such a way that I can safely test functions with IO operations without having to actually perform them. It seems that Lua modules are mutable. Perhaps this isn't strange given that Lua modules are basically tables, but I hadn't considered it before. I'm not entirely sure if it is a language feature or just something that happens to be true right now, so this method of mine might soon become useless.

Testing operations

So, to test these functions that would normally have side-effects or would require a lot of extra work setting up to work correctly, we basically have to replace the existing functions. Normally in a running program you really wouldn't want to do this, save for when you have dynamic scope, which I haven't yet found in Lua.

So I want to test that everything works properly when the io.access function reports it can't access a certain file, I'd change the function like so:

-- You must first require it, so you have the same module.
local posix = require 'posix'

-- ...

posix.access = function ()
   return false
end

This way I know what the function will do, when it eventually gets called.

Travis-CI

After finally getting some tests in my project and making sure that I have full test coverage of my module, I thought it would be fun to see if I could automatically test everything with travis-ci. It was a little challenging because I don't normally run Ubuntu or Debian, so I don't know what they name their packages, and one of my dependencies (luasec) had some trouble finding the libssl library.

After a little poking around, a few retries and a false-success, it's now finally running:

My .travis.yml is pretty simple:

language: erlang

env:
  - LUA="lua"

branches:
  except:
    - gh-pages

install:
  - sudo apt-get update
  - sudo apt-get install luarocks libssl1.0.0
  - sudo luarocks install busted
  - sudo luarocks install luasocket
  - sudo luarocks install luasec OPENSSL_LIBDIR=/usr/lib/x86_64-linux-gnu
  - sudo luarocks install luajson
  - sudo luarocks install luaposix

script: "busted -m 'lua/?.lua' -o TAP"

# ...

I'm using the erlang environment, because there isn't a Lua one (yet). I've written my library for lua, not luajit, so busted needs to know which to run, it always runs luajit first it seems. I don't need the tests to be run again when the gh-pages branch is updated, since that has nothing to do with the code itself, I would actually like to have tests run on all other branches.

Then we get to the dependencies. Nothing major except for the luasec dependency. I'm not entirely sure how long that OPENSSL_LIBDIR will remain where it is now, but it works for now. I didn't discover the location myself, I found it on someone else's .travis.yml as a comment.

Lastly we have the script. Since the tests live in /spec and the code lives in /lua I run the tests from the project root and include the lua directory in the module path. I use TAP output because with the default output failures also return 0, when a failure occurs with the TAP output, a non-0 exit status is returned and travis knows they didn't pass. That is why build 6 passed even though there was still a failed test.

The rest is notification settings which isn't interesting enough to duplicate here.

Still to do

Now I should start expanding it a little. Well, actually I still need to add the proper license information.


Avandu in Lua

Published on:

A little while ago I started using the Awesome window manager again. I've started to play some PC games (such as Rogue Legacy) and have to use some more graphical applications again. Stumpwm just wasn't quite cutting it and suddenly it seemed that my workflow didn't quite fit with a completely-manual tiling experience.

So now that I'm back with Awesome I wanted to have a count of the number of unread articles in Tiny Tiny RSS in my wibox. I already have a project named avandu, which is an Emacs interface for Tiny Tiny RSS, and for a little while I used that in combination with Emacs' daemon mode to get the number of unread RSS items. This halt my Emacs for a few seconds every minute, though, so that was unpleasant. It also caused a lot of "Connecting to host: ..." messages to appear in my Emacs' echo area, which is a little annoying.

So I decided to write a lua module to get this count, since I didn't have a lua project yet. That is avandu-lua. Right now it only implements a login and unread functions, which allow you to log-in to get a session key (so you can do other things), and get the number of unread articles (what a shock!).

I've written a bit of documentation for it, hosted by github. There isn't much to document of course, but I try.

I still need to add tests, but I'm having difficulty deciding on how to do this. busted looks really nice, but their idea of stubs and mocks doesn't seem to be very useful if you're testing a function that calls, for example, http.call, which returns 4 distinct values, not none. I can't decide if I should keep looking, (try to) write something or use _TEST checks everywhere. I'm leaning towards that last one, perhaps I'll add that.

I don't currently have any concrete plans of extending it to have more functions than the ones I've added so far, I might do it for fun at some point, or if you'd really like to be able to call Tiny Tiny RSS from lua let me know and I might put some more effort into it.

It's been nice to work with lua. I don't particularly love the language and it certainly doesn't beat Lisp on any front, but it has its moments and niceties.

Some things that still need to be done:

  • As I said, I need to add tests.

  • I think I should try to see if coroutines can be used, it seems to hang Awesome now on occasion.

  • Add license info. Yeah I really should almost do this before I do anything else when I start a new project. It's going to be LLGPL in any case.

  • Release an actual version. Always installing from just a git checkout can be a little annoying.


Rogue Legacy

Published on:

A little while ago Rogue Legacy was on sale on gog.com and it looked like fun, so I bought it. Today I "finished" it, by which I mean that I killed the big boss and get to start over. There are still a lot of things I can (try to) do, but the "story" is over.

So, at the start of this game you are a legendary knight and you go into this castle, for what reason is not explained until later. This game is about his children, somehow. At the end of the tutorial the knight dies and a child of his will take his place and walk into the very same castle, possibly to avenge their father.

Each time you die you get to pick a new child to work with, each has a class which affects certain stats and each may have one or two traits. These traits can be useful, funny, annoying or sometimes even make you sick. Some traits include being near-sighted, having no pulse in your feet or being a giant. They make for some interesting experiences and some laughs as well. Classes include a Paladin which isn't particularly good at anything, an Archmage which has a lot of magic power, and a Knave which is pretty bad at everything except has a killer critical hit.

Every time you enter the castle it will normally be completely different from last time, save for a few constants. In my opinion this makes it vastly replayable, as every time you have to start over everything is new.

Thankfully this is not such a cruel game that every time you die you have to start over from scratch. Each run through the castle will result in some gold, this gold can be used by the next generation to buy some upgrades, and thus level up. So even if you are exceptionally bad at a game like this, as I probably am myself, you'll still be able to make progress simply by trying over and over again. Of course there are also better armors and weapons to be bought and runes to be equipped to help you even more.

The gameplay is very nice. It's very action/platform in nature as there is a lot of swinging of the sword, dodging of projectiles and jumping on platforms to be had.

Installation on linux

The game is available for linux, although since I bought it through gog.com I only had an option of windows or mac. I didn't try asking the developers if they could let me download the linux version since I didn't think to check if there was one until I was already well underway with my game.

It works in wine, version 1.7.20, at least. To install it in wine first you'll need to have the proper XNA installed. On my Archlinux installation this was a matter if installing winetricks and then using it to install xna:

sudo pacman -S winetricks
winetricks xna

I didn't fully test it with a normal 64-bit wine prefix, but using a 32-bit one worked fine for me. After having installed XNA installation of Rogue Legacy went fine and I didn't have any trouble playing it at any point. On my laptop that is a different story, I just can't get it installed there, even though it's the same version of everything I can think of (it also has Archlinux installed).

Conclusion

It's a very nicely designed game, both visually and gameplay-wise. There are a lot of funny things in it and a lot of things for you to find. You start out thinking you'll never ever be able to go through the entire castle (or at least I did) only to find that gradually you learn the enemies' ways and get stronger and things get easier, and then you find a boss (and subsequently lose hope again, or at least I did).

It took me some 34 hours and some minutes to kill the big boss and 136 generations of heroes, it was my first play through and I have to say I was a little addicted during those hours, I haven't played a game this much in a very long time.

This article is tagged as: games

A blogging challenge

Published on:

Lately I've been thinking that I should blog more. I've had a blog for as long as I can remember, I'm constantly trying out new platforms or new ways of blogging and I never really actually post anything. I sometimes get stuck in this spiral of meta-activity where, for example, I work hard on getting my blog ready or am figuring out how to best present some project I'm working on or its documentation, instead of actually blogging or working on/documenting that project. I get so bad that I occasionally even have projects around these meta-activities, like edocs.

Thankfully, after a while I recognize that I'm not actually really doing anything and basically just stalling, and I try to do something about it. So, I'm going to try to stop doing that and just write. Yesterday I wrote about HabitRPG and now I'm going to try to use that to encourage myself to write more blog posts. So far it's starting out well, two days and two posts.

So, please excuse my two posts of mostly filler content and I'll try to write something a little more interesting tomorrow.

This article is tagged as: meta

HabitRPG

Published on:

A quick post just to have written one, it's been awhile...

HabitRPG is a to-do application unlike many others. It gamifies your task list by adding Role Playing Game elements. You create a character, you have HP, XP, (eventually) MP and gold. There are three categories of tasks: habits, dailies and to-dos. They're colored from red (bad) to yellow (neutral) and blue (good). Not completing dailies will cost you HP and turn them red, leave them incomplete for too long and your character will die and lose a level. You gain XP and coins by completing tasks. You can use your MP for certain special abilities, for example strike hard at a task and shift its color more towards blue. You can use coins to buy rewards, either self-made or thought-up by the HabitRPG developers.

You can also start a party and go questing with friends, or join a guild. There are also challenges, which are sets of tasks specified by someone else, as a challenge.

I've tried many a to-do application. I've even tried writing my own a few times. I've never really been satisfied. For a long while now I've been using org-mode for Emacs, both because it is Emacs and because it flexible enough to change completely to your own needs. The only problems remaining are identifying your needs and keeping up with your task list. Both are tricky to me, but that last one gets worse the bigger my task list gets.

Unexpectedly, HabitRPG's rewards and random loot are stimulation enough for me to keep completing tasks. I've been using it for a couple of weeks now and I'm still completing stuff, which is quite unusual for me. And I put lots of stuff in there, such as "Drink water", which is a habit I want to stimulate; or "Exercise" (three days a week as a daily), which is something I've been needing to do in a long time and so far I'm keeping it up well; or single tasks like "Clean up ~/projects", which I've yet to do.

I suppose it helps that I've always liked computer RPGs, and this wouldn't work if I didn't feel that the reward of being able to buy a new weapon for my character is any kind of motivation.

Anyway, if you have trouble motivating yourself to actually complete tasks on your to-do list and it sounds like fun to you, you might try it.


Auto-suggestions for DuckDuckGo in Conkeror

Published on:

Recently DuckDuckGo gave its UI a big overhaul. One of the new parts of the UI is the auto-suggestions, which are pretty cool, especially when working with !bang syntax. I want that in my conkeror webjump! So I started looking...

Turns out that Conkeror can work with OpenSearch descriptions to create webjumps and actually already has a DuckDuckGo OpenSearch XML file. However, DuckDuckGo has a newer version of that file.

So, for starters you should download the proper XML file. After this, you can replace the /usr/share/conkeror/search-engines/duckduckgo.xml file1 with the newly downloaded one and you'd be done, ready to use the new auto-suggest functionality2.

If, however, you don't like overwriting your package's files because they may get overwritten again in the future3 or you really don't think it's proper, you can also create a custom webjump that does the same thing, which is what I did.

In case you are following my lead, first we'd need to put the downloaded XML file somewhere. I suggest ~/.conkerorrc/search-engines because that way everything in your configuration stays nice and contained, although you might want to put it in your ~/.conkeror.mozdev.org/conkeror/CODE.PROFILE/search-engines, where CODE is an eight-character alphanumeric sequence (as far as I can tell) and PROFILE is the name of the profile you use4, because that should already be included in your opensearch_load_paths.

If you put the XML in your .conkerorrc you'll need to add that directory to your opensearch_load_paths, so put something like the following in your init.js, or whichever filename you use for your conkeror init:

opensearch_load_paths.push(make_file("~/.conkerorrc/search-engines"));

After Conkeror knows where to find your custom search engine specifications you can create a webjump for it:

define_opensearch_webjump("ddg", "ddg.xml");

Once you evaluate these lines or restart your Conkeror, you should have a ddg webjump with auto-suggestion. Yay!

Footnotes

  1. I have Conkeror installed in /usr, so if you have it installed somewhere else your path will be different.

  2. You might have to restart Conkeror first, I didn't test it without restarting.

  3. This can of course happen when, for example, your package manager updates your Conkeror installation.

  4. The default profile is named (appropriately) default.


Stop shr from using background color

Published on:

Here's just one more example why Emacs is so awesome

Reading mail in Gnus is very nice, but shr has become a little too good at its job. Add to this the many occasions when a background is specified without specifying a foreground, plus a color theme that is the inverse of what is usually expected, and you can get hard-to-read HTML messages, gray foreground and gray background.

I've looked at the other possible renderers, but they don't look very nice compared to shr. So just remove its ability to add background colors.

(defun oni:shr-colorize-remove-last-arg (args)
  "If ARGS has more than 3 items, remove the last one."
  (if (> (length args) 3)
      (butlast args)
    args))

(with-eval-after-load 'shr
  (advice-add #'shr-colorize-region :filter-args
              #'oni:shr-colorize-remove-last-arg))

This blog covers archlinux, avandu, avandu-lua, cask, ci, clark, common-lisp, config, conkeror, diff, dispass, dispass.el, editors, elisp, emacs, eshell, evil, exherbo, experiments, file-synchronization, games, git, github, gnus, hla, html, javascript, lisp, lua, markam, meta, mpd, notion, org-mode, ox-coleslaw, projects, rc, sbcl, small-recent-posts, software, stumpwm, systemd, tasks, tekuti, testing, tips, todo, ttrss, utility, vagrant, vc, vim, visual, wdocker docker docker-compose, wm, wordpress, yoshi-theme

View content from 2016-02, 2015-09, 2015-08, 2014-12, 2014-10, 2014-08, 2014-07, 2014-06, 2014-04, 2014-01, 2013-11, 2013-10, 2013-08, 2013-05, 2013-04, 2013-02, 2013-01