Lately I've been dealing a lot with CSV and other text file formats for storing data. One thing that disappointed me was that there aren't very good command-line utilities for dealing with CSV and other tabular text formats. Most things are purely line-oriented.

So I did the natural thing, and wrote new programs (all on my GitHub). :)

• TSV: takes tabular data, with fields separated by spaces and all lined up, and converts it into CSV.


• Tabify: pretty much the reverse of TSV; takes tab-delimited data (or CSV in the near future implemented in commit 99345fc) and outputs a pretty table with all the fields lined up.


• CSVSel: the most powerful one, does …

read the whole post

Let's imagine a button press handler function for a C# Windows Forms application:

private void onClick(object sender, EventArgs e)
{


User clicks the button, and this is for an operation that's going to take some time, so we should do it in another thread and keep the main thread free.

In .NET this means using a BackgroundWorker:

BackgroundWorker worker = new BackgroundWorker();
worker.DoWork += new DoWorkEventHandler(
delegate(object workerSender, DoWorkEventArgs workerArgs)
{


Now we run some method that takes a while and gives us a collection of things to iterate over. Each of these items also needs to also be processed in a complex way. The results need to be displayed in a table, implemented as a DataGridView.

IEnumerable results = ComplexOperationDealie();
foreach (String result in results)
{
String refinedResult = AnotherComplexOperation(result);


It would be nice …

read the whole post

OK, so I pretty quickly realized that cross-compiling all of core for i586 from a x86-64 system was a bad idea. Arch Linux isn't a multilib system, and the number of multilib packages is really uselessly small.

So the solution is to set up an i686 system in a chroot from which I can build i586 packages more easily. I did this, and the number of packages that failed to build went down from 66 to 2

Problem #1: GCC.

GCC doesn't want to honor my changed CHOST variable; it insists on looking it up itself from uname, but this is wrong. In my chroot, my computer pretends it's an i686, so the CHOST ends up being i686-pc-linux-gnu, but that's not what I want. In my makepkg.conf I have it explicitly set to i586-pc-linux-gnu, but GCC doesn't want to use it. Still investigating how to fix this.

EDIT: it seems exporting CHOST in my makepkg.conf was enough to make GCC's makefile honor it, but now there's another bug:

ada/tracebak.o: In function …

read the whole post

I'm doing a bit of a retrocomputing project. I'm building an i586 (the original Intel Pentium) machine from various parts in my apartment, and I'm going to attempt to install Arch Linux on it.

Arch, like the vast majority of modern Linux distros, won't run on an i586 because the minimum architecture it targets is i686, the Pentium Pro. So before I can install Arch on this old machine, I have to recompile it for i586.

Due to the large number of packages that need rebuilding, I'm choosing to do this on my most powerful machine, which is running an Intel Core i7. This makes rebuilding even more complicated, because now I'm building 32-bit binaries from a 64-bit system. I'm now doing cross-compiling.

Luckily, Arch provides a very simple system for rebuilding its binary packages from source. It's called Makepkg. Every Arch package comes with a PKGBUILD file that can be used to rebuild it using Makepkg. By modifying Makepkg's configuration file, I can change how it builds, …

read the whole post

Some of my photos from the fireworks show in Lake Union. I was standing at Lakeview and Belmont overlooking I-5 towards the lake.

Happy Independence Day!






























…

read the whole post