Bash Line Editor (
ble.sh) is a command line editor written in pure Bash scripts which replaces the default GNU Readline.
One of the oldest pieces of software still in use was recently described as
A sort of hybrid between Windows Notepad, a monolithic-kernel operating system, and the International Space Station.
Of course, they were talking about Emacs. And yes, it is kinda true.
Given that the main development workflow for most kernel maintainers is with email, I spend a lot of time in my email client. For the past few decades I have used (mutt), but every once in a while I look around to see if there is anything else out there that might work better.
One project that looks promising is (aerc) which was started by (Drew DeVault). It is a terminal-based email client written in Go, and relies on a lot of other go libraries to handle a lot of the “grungy” work in dealing with imap clients, email parsing, and other fun things when it comes to free-flow text parsing that emails require.
aerc isn’t in a usable state for me just yet, but Drew asked if I could document exactly how I use an email client for my day-to-day workflow to see what needs to be done to aerc to have me consider switching.
Note, this isn’t a criticism of mutt at all. I love the tool, and spend more time using that userspace program than any other. But as anyone who knows email clients, they all suck, it’s just that mutt sucks less than everything else (that’s literally their motto)
I did a (basic overview of how I apply patches to the stable kernel trees quite a few years ago) but my workflow has evolved over time, so instead of just writing a private email to Drew, I figured it was time to post something showing others just how the sausage really is made.
Anyway, my email workflow can be divided up into 3 different primary things that I do:
basic email reading, management, and sorting
reviewing new development patches and applying them to a source repository.
reviewing potential stable kernel patches and applying them to a source repository.
Given that all stable kernel patches need to already be in Linus’s kernel tree first, the workflow of the how to work with the stable tree is much different from the new patch workflow.
Interactive rebase is sometimes called the “Swiss Army Knife” of Git – because it contains so many different tools, for so many different use cases! However, there’s one main, overarching use case: cleaning up your local commit history.
Mind the word “local”: it should only be used for cleaning up your own, local commit history, for example before integrating one of your feature branches into a team branch. In contrast, it should NOT be used on commit history that has already been pushed and shared on a remote repository. Interactive rebase is one of those tools that “rewrite” Git history – and you shouldn’t do this on commits that have already been shared with others.
With this little warning message out of the way, let’s look at some practical examples!
I’ve been writing code in vim for the past several years, and in this post I’d like to share some tips on configuring a development environment. This post contains some notes on configuration that would have helped me when I first started using vim and working on my own config. I hope that as a result of reading this, you will be able to improve your workflow with some new features and make the development process easier and more convenient.
In this article, we will look at common tasks that occur when editing code and try to automate and improve them using vim. Each section contains a brief description of the problem, a proposed solution, overview of alternatives, a full code listing for the configuration, and a screenshot or animated screencast with a demonstration. At the end, additional links to useful plugins and resources will be provided.
Most of the tasks come down to installing and properly configuring one or more plugins. I assume that you are an experienced vim user and already use one of the plugin managers.
All of these tips are applicable in both vim and neovim. Also, despite the title, some of these tips can be applied not only to C++, but also to your favorite language.
Thonny is a Python IDE meant for learning programming.
Learning a new editor can be a daunting task, especially when coming over from a non-modal editor. I personally started with Emacs, and it took me weeks to be productive when I started using Vim. The modal paradigm is a powerful tool, but picking it up is generally not a painless experience.
When I discovered Kakoune a few years ago, it felt like the jump from Vim to it was even bigger than the one I’d made when transitioning over from Emacs to Vim. Despite the two being fairly close on paper, one still needs to unlearn all the muscle memory patiently cultivated over the years and grow it back up from scratch. If we ignore the fact that in those days the only (comparatively sparse) documentation was centralised in the README file of the project, which might have contributed to why the jump made itself felt so strongly, new comers still have to primarily focus their efforts towards learning the “modal language”, or flavour, of Kakoune.
In order to save them some time, whether they’re disembarking off the Emacs (non-modal) or Vim (modal) boats, I’ve documented in the following article some common configuration options. They won’t fit anyone’s workflow exactly right, I trust the user to tweak the settings how they see fit. They will however allow turning the two hours it would have taken me to figure out what lines to write down in my user configuration to get a boilerplate setup going into two minutes — the time it takes to read this introduction and save the final
kakrconto one’s system.
I’ve recently joined a company that for security reasons doesn’t allow their source code on laptops. Development happens strictly on workstations inside their private networks, with some using their text editor’s support for remote file editing and others running editors on those machines via SSH.
Adapting to this situation has indirectly led me into a bit of a rabbit hole, forcing me to acknowledge my core values, better understand the relation between progress and human flourishing, and ponder about the question: why technology?
Here’s a non-exhaustive list of programs that are all meant to help create or manage virtual environments in some way:
Hatch, VirtualEnvManager, autoenv, fades, inve, pew, pipenv, pyenv-virtualenv, pyenv-virtualenvwrapper, pyenv, pyvenv, rvirtualenv, tox, v, venv, vex, virtual-python, virtualenv-burrito, virtualenv-mv, virtualenv, virtualenvwrapper-win, virtualenvwrapper, workingenv
Clearly, this stuff must be really hard to get right. I also must be a moron, since, after having written some thousand lines of Python, I don’t even know what problem we are trying to solve here, and the abundance of relevant programs with subtly different names has deterred me from reading up on it so far.
distcc is a program to distribute builds of C, C++, Objective C or Objective C++ code across several machines on a network. distcc should always generate the same results as a local build, is simple to install and use, and is usually much faster than a local compile.
distcc does not require all machines to share a filesystem, have synchronized clocks, or to have the same libraries or header files installed. They can even have different processors or operating systems, if cross-compilers are installed.
So I’ve been using the Github flow for some years now from both the maintainer side and contributor side to open source projects. I’ve also been using the email workflow for git from both sides for about a year now. Using email for git sounded quite horrible before I actually started using it. Now I prefer it so I thought I would document my experience here.
CTL is a fast compiling, type safe, header only, template-like library for ISO C99.
When coming to Radicle from a centralized code collaboration network like GitHub or Gitlab, users might be puzzled by Radicle’s unique social model at first. In contrast to centralized code collaboration platforms, on Radicle:
Peers are in control of their social interactions
Each peer effortlessly self hosts their own content and the content of the peers they follow that they are interested in
Peers have subjective views over the projects they follow
This post attempts to contextualize the Radicle social model, the trade-offs it makes, and how it differs from the models of well-known centralized platforms.
CIDER started its life as an effort to replace a hacked version of SLIME1 with a proper environment for Clojure development on Emacs. Many of you probably don’t remember those days, but initially almost everyone was using a modified version of SLIME for Clojure development. The work on CIDER was fueled mostly by the advent of nREPL which was the first project that aimed to provide a common tool-agnostic foundation for Clojure development tools.
CIDER was started in spring 2012 (under the name
nrepl.el) by Phil Hagelberg (of Leiningen fame), who hacked a prototype of an nREPL client in Emacs Lisp on a flight to San Francisco. He got a bit stuck on the socket-based bencode functionality and dropped it after the flight, but not before pushing the code out and mentioning it on the Clojure mailing list. What followed is the best example of the power of open-source software…
Two years ago I filed Microsoft/vscode#65559 asking for WebAssembly support in VSCode extensions. At the time, WASM was supported by Node.JS but the WebAssembly symbol wasn’t available in the extension’s evaluation scope. That issue didn’t get much activity from upstream but the other day I tried it again, and … it worked!
Below is a small “hello world” LSP-based extension that loads a WASM module in onInitialize(). It uses the vscode-languageserver library; readers new to VSCode extensions can follow along using Microsoft’s Your First Extension and Language Server Extension Guide tutorials.