Avian’s Blog

So, this is the device that employs the circuit boards I've been writing about lately:

(click here if you can't see embedded video)

From the electronic standpoint it's a pretty ordinary clock with a quartz oscillator for the time base. The digital part is composed of standard LSI and MSI chips from the 74HC family. There's also a small back up NiMH battery (the kind you sometimes see on computer motherboards) so that you don't need to set the time every fortnight when the distribution company decides to cut your power.

What makes it stand out a bit is the fact that the time is displayed as a binary-coded decimal in 24-hour format. That's not a new idea of course.

Well, what does make it special is that it's a limited edition, with exposed circuitry and a nice, heavy wooden stand.

Matching balanced constructs (like some text that must contain matching pairs of parentheses) is a classical example where traditional regular expressions fail. It isn't surprising then that the Perl FAQ says that you should use text parsing functions from Text::Balanced module when you need to do that.

Perl however also provides extended regular expressions that among a lot of other things also support this kind of matches. Theory says that such extended expressions can't be compiled to finite automata and so typically have worse complexity than the traditional O(n) - something that is also mentioned in another part of Perl documentation.

So when I was confronted today with a problem that involved matching balanced "{{{" and "}}}" pairs (guess what kind of markup uses them) I naturally followed the suggestion in the FAQ.

Well, it turned out that that suggestion isn't one of the best ones. Text::Balanced is slow. Actually it's so slow that the identical code that uses the extended regular expression from Regexp::Common::balanced is around 50 times faster.

So much for the difference between theory and practice.

I take one thing back from what I said on Saturday about boards made by Bilex-LP.

The weren't perfectly etched. One of the four boards had this little glitch on it, which we found only after one of the finished circuits wasn't working properly. Luckily it wasn't hard to spot - a signal line had a short-circuit to the ground fill:

Anyway, even considering this problem it was still a good deal.

One thing that I learned at Zemanta is never to underestimate processing power and memory needed to do anything non-trivial (and also a lot of trivial things) with English Wikipedia dumps. After you spend some time dealing with these huge XML files you gradually learn from your mistakes and accept that as a fact.

The resources needed to process Wikipedia also became kind of a recurring inside joke at the office, especially when this needs to be explained to someone new in this field:

(this is, of course, a completely unofficial imitation of a xkcd comic)

Remember this little project? Yesterday the first batch of circuit boards arrived by post from manufacture.

These were made by Bulgarian Bilex-LP. I first heard about them some years ago in Berlin on one of CCCs and this was an opportunity to try them out (since now Bulgaria is part of European union and there aren't any customs charges).

The boards are nicely manufactured. Copper is perfectly etched as far as I can see and RoHS coating is flawless. The only glitch I found is that the drilling is off for maybe 1/4 mm and silk screen print off for a mm on one piece, but at least for these boards that's nothing near critical. Definitely better than what I could done in my home workshop.

Their prices are also lower than Slovenian companies - at least if you need only a couple of boards and don't mind waiting three weeks for manufacture and delivery. So it's definitely a positive experience (and I'm willing to forget that they renamed me first to Tomaz Solz and, after I reminded them, to Thomas Solc).

Linux mmap() call is full of surprises. Take for example the MAP_PRIVATE option. According to the man page, mmap() with this option makes copy-on-write pages, meaning that any changes the process makes to the mmaped region will not be propagated to the underlying file.

This is of course works as advertised, but there is a catch. What if some other process modifies the file? Take for example this simple program:

#include <stdio.h>
#include <fcntl.h>
#include <sys/mman.h>

int main() 
{
	int fd = open("file", O_RDRW);

	char *p = mmap(NULL, 1, 
			PROT_READ | PROT_WRITE, 
			MAP_PRIVATE, fd, 0);

	while(1) {
		printf("%c\n", *p);
		sleep(2);
	}

	close(fd);
}

If file contains a character "A", this program will print a string of As to the console. Now while the program is running you change the contents of the file. Does the output of the program change?

It turns out it does! However only if the program didn't change something in the mmaped region. If you modify the program above so that it writes something, the stream of characters on the console will not change when you modify the contents of the file.

Why is this significant (and why I spent a couple of hours exploring it)? It turns out that the dlopen() call in Linux loads shared objects by simply mmaping them (look at the strace output if you don't believe me). So if you change a .so file on the disk while some application is using it, you'll get a nice segmentation fault.

Now, /proc/*/maps file reveals that the executable itself is also mmaped. However a program doesn't crash when you modify the executable file, so either something gets changed in the program's image after it gets mmaped or I still don't understand everything that's going on here.

Last time I've read on Eee User forums some measurements that suggested that lowering CPU frequency (via the cpufreq kernel module) to conserve battery power isn't useful because the current Eee draws from the battery is the same regardless of the frequency (sorry, can't find that post now). I find that odd, but I would happily get rid of the ondemand CPU frequency governor that's making things sluggish if it really doesn't help a bit.

After some searching around the internet I found some alternative theories why lowering your CPU clock when on battery isn't good. They say that modern CPUs have the ratio of power consumption between idle and full power so high that it is better to always have the CPU at the highest clock so that it spends as little time out of idle as possible.

So today I wanted to solve this out once and for all with some measurements of my own. Unfortunately it wasn't as simple as I thought it will be. It turns out that my particular laptop will not run with an ampermeter in series with the power supply. Without the battery it starts, but is very unstable and most times resets before Debian stops booting. With the battery it doesn't even do that. Weird. I'm guessing the added inducance and resistance is causing some undervoltage protection to trigger.

Well, I'm not going to give up that easily, but this will have to wait until I can set up a more serious experiment.

They say that Douglas Adams liked the sound they make when they fly by. But what if you really, really want to meet them? Well, so far I've seen three different ways of doing that:

The "let's finish early to leave some time for last minute problems" strategy,

the "perfect planning and hope for no mistakes" strategy and

the "the deadline is coming so we have to work really, really hard now" strategy.

Suffice to say I'm a fan of the first one, but I admit I sometimes fall back to the second way.

If you know your deadline in advance, why would you choose any other way? Isn't the point of knowing when you have to finish something exactly that you can plan your work? So excuse me if I don't buy the third option.

Of course, I'm not the only one that draws graphs like this.

A couple of weeks ago a post on geda-dev mentioned a new, free (as in freedom) application for designing printed circuit boards - LiquidPCB. At its web site Hugo Elias, LiquidPCB's author, points out some shortcomings of gEDA's PCB and other traditional CAD tools and how he attempts to fix them in his software. He says it's all about a new, modern user interface.

Discussion that followed on gEDA's mailing list didn't actually touch any of the problems pointed out by Hugo. With some help I managed to get LiquidPCB running this weekend on an old laptop with Windows, so here are some of my thoughts about it.

I mostly agree with Hugo regarding user interface problems. gEDA's PCB has an archaic GUI - most core developers still use its Lesstif incarnation (Lesstif is an reimplementation of Motif, a GUI toolkit from 1980). It surely requires quite a lot clicking around that could be avoided in this or other way, not to mention that it looks a bit out of place on a modern desktop. However I think most of these problems could be solved in a way that doesn't depart so radically from what everyone is used to today.

I think problems that LiquidPCB tries to solve can be split into two groups: First there are those that are shared by basically every complex desktop application today. I believe it's wrong to try to solve this kind of problems separately in each application. For example LiquidPCB reimplements a file selector dialog. From the usability standpoint this is a component that should be shared between all applications. So I believe a better way of solving this problem would be for example to submit patches for GTK file chooser dialog.

Another example are problems with the menu and toolbars. I believe this can be solved with better placing of entries in menus (gEDA's PCB for example has a problem with "Select" and "Buffer" menus where I often open the wrong one). I can't say if the hexagon menu system used by LiquidPCB is better than a well done traditional interface. I found it awkward, but that's because I'm used to traditional interfaces. What bothers me the most is the requirement to hold down the right mouse button while traveling through menus. What I'm almost sure of is that it can't replace keyboard shortcuts. The keyboard with its 100 and so buttons still provides a faster way of switching program states (like switching between select mode, via mode, etc.).

The other group of problems is specific to PCB design. In this field the approach of LiquidPCB looks superior to anything PCB has to offer. What you are doing in PCB design is solving a topological problem. You have a graph and you need to place the vertexes and edges on the plane so that their placement follows certain rules. Now the approach LiquidPCB takes is that it makes you solve that exact problem without requiring you to fiddle with side issues like the exact location of elements. You only say "pin A is placed on this side of line B" and LiquidPCB takes care of the rest. It feels like an autorouter that uses a user's brain to do what it does best (solving the topology) and the computer to do what it does best (finding placement for vias and lines). The example of LiquidPCB's web site showing how to insert a via in the middle of four tracks shows just how much work this approach saves you. In PCB this operation would really involve hundreds of steps where you would first move each of the existing lines out of the way (which could also require moving several components) and only then insert that new via.

I see some purely practical problems with LiquidPCB's approach. For example the constant dynamic optimization means that just opening a file also makes modifications in it. And also, at least from half an hour of playing with it today, it seems it is quite easy to make a mess of things if you're not careful. But I'm sure these problems will be easy to fix.

So in conclusion I think LiquidPCB addresses some quite real problems and shows some promising solutions to them. The program itself is in an early stage of development and isn't useful yet for anything more than playing with it. It will be very interesting to follow its development.