AccuRev Sucks: The Horrors of Deep Overlap

•November 16, 2013 • 5 Comments

For the longest time, I thought the problems I encountered with AccuRev were just a basic fact of version control. The sort of thing that you just need to accept, like the tides. I’m starting to appreciate that AccuRev is really the cause of many of my frustrations.

So, let’s talk about some ways in which AccuRev screws things up.

there’s no going back

You ran accurev update and discovered the build is broken. The obvious thing to do is to yell at the guy who broke it. While he’s fixing the problem, you can base your workspace off an earlier point in history and keep working. Or, heck, just roll your workspace back to how it was before you updated.

After a little hunting, you find that via the command line you can specify the transaction to update to… but it only accepts transaction numbers greater than the transaction you’re currently updated to.

There is no way to revert your workspace back to how it was before you updated.

stream inheritance sucks for features

Let’s say you naively decide to create feature streams. You have your main DevStream at the root of your depot and a pair of feature streams as its children. We’ll call them FeatureStreamA and FeatureStreamB.

Alice and Anthony are working in FeatureStreamA.
Bob and Benjamin are working on FeatureStreamB.

Everyone is happy.

Alice finishes the feature in FeatureStreamA.
Alice pushes the changes from FeatureStreamA into DevStream.

Bob and Benjamin are no longer happy.

AccuRev will automatically bring changes down from DevStream into child streams. That sounds really convenient, except if any file merge is required, the files which conflict will not be updated! They’re marked as being in ‘deep overlap’ and that’s it.

FeatureStreamB is left in a halfway state. What kind of garbage is that? A stream should never contain half a commit. Until the merges are resolved, no part of the offending commit should be in the stream.

silent update failures

Similar behaviour can be spotted when updating workspaces. If you have ‘kept’ files in your workspace, merge conflicts in those files will no longer block updates. Instead, the files will be marked as ‘overlapped’ and you’ll be left with the old version. Unless you explicitly look for the conflict, you’ll never even know it exists. Your code will just be missing a smattering of changes, breaking your program in confusing ways.

but wait, there’s more

I could rant about other similarly egregious issues, but I think I’ll save those for another time.

Adventures in Reptilian Programming Languages

•October 28, 2013 • Leave a Comment

I’ve been tinkering with Python over these past few months. It really has impressed me. XKCD was right. For some weird reason I decided I’d buy Learn Python the Hard Way, which I’ve been told is quite good. The weird part is that I bought it, since it’s available from its authors for free online.

I’ve only just started the book, but I absolutely love what I’ve read thus far. It takes a very straight-forward approach to teaching Python. I’ve seen no better advice for fledgling programmers:

If a programmer tells you to use vim or emacs, just say “no.” These editors are for when you are a better programmer. All you need right now is an editor that lets you put text into a file. We will use gedit, TextWrangler, or Notepad++ (from now on called “the text editor” or “a text editor”) because it is simple and the same on all computers. Professional programmers use these text editors so it’s good enough for you starting out.

A programmer will eventually tell you to use Mac OSX or Linux. If the programmer likes fonts and typography, he’ll tell you to get a Mac OSX computer. If he likes control and has a huge beard, they’ll tell you to install Linux. Again, use whatever computer you have right now that works. All you need is and editor, a Terminal, and Python.

I’ve seen that sort of bad advice given to new programmers over and over again. There’s a time and a place to learn a new text editor or operating system. It’s probably not at the same time as when you’re learning your first language.

If you’re going to learn the one true editor, you should give it your undivided attention.

Building Qt5 on RHEL5 and CentOS 5

•August 20, 2013 • 2 Comments

I’ve tried to get this to work, I really have, but the problems are numerous. The platforms are not supported, so it shouldn’t really be any surprise that they don’t work. Still, it’s unfortunate.

RHEL5 and CentOS 5 are basically identical, so anything I say about CentOS 5 can be taken as also applying to RHEL5.


The version of Perl included with CentOS 5 is too old to run the init-repository script. A little bit of hacking can work around the problem, but consider instead downloading a source code release rather than acquiring it from git. The zip file releases don’t require the init-repository script.


Qt Multimedia requires a minimum version of gstreamer 0.10.24. Unfortunately, the version available on RHEL5 is gstreamer 0.10.20. Building the minimum required version of gstreamer from source on CentOS 5 is a difficult endeavour. I gave up after my build failed on a flex version check. I found it easier to just delete the Qt Multimedia and Qt Quick Multimedia folders and live without those features. The Qt build script is rather nice in that if it doesn’t find a module’s folder, it will skip the module without triggering an error.


The real sticking point for me has been xcb. The version that comes with Qt fails to build on CentOS 5, presumably because it requires a more recent version of X. There’s quite a few compile errors stemming from missing values in X headers and stuff like that. I hacked around the first few errors, but eventually I ran into problems that were too complex and too numerous for me to solve with confidence that my changes would still result in working software.

Acquiring xcb libraries from ATrpms was also not sufficient. In building Qt I would get errors stating certain xcb libraries could not be found. Unfortunately, I believe this is because they do not meet the minimum working version required. I may yet investigate further, but this seems to be hopeless.

If Wishes Were Fishes: Forward Declarations (part 2)

•August 1, 2013 • Leave a Comment

So, last time I talked about how tricky forward declarations are in C++. I mentioned a scheme that would be nicer, so let’s take a look at whether it’s is even possible.

Class and Struct

Both of those seem simple enough. If class and struct names were mangled the same way, there’d be no problem using a single keyword for both. In fact, you can get away with forward declaring structs using the class keyword when compiling with gcc. Microsoft’s Visual C++, however, does mangle classs and structs differently, forcing you to be a little more careful.


While this is not currently possible, it seems feasible. If C++ enums could be implemented as classes by the compiler, you’d no longer have to distinguish them in forward declarations.

The struct enum in the example above there doesn’t have quite the same semantics as real enum types, but you can see where I’m going with this. If you were designing the language from scratch, enum types could easily be designed to be expressed as a shorthand for a particular sort of class. And since class types are forward declarable, enum types would be too.

I’m not sure why the standard doesn’t already allow forward declarations. Perhaps there’s some silly way in which enums and classes are treated differently in the standard? If so, that highlights one of the really annoying things about C++: there are a lot of concepts that are just ever so slightly different from each other.

Embedded Poetry

•July 25, 2013 • Leave a Comment

The OpenEmbedded project has embedded a poem in one of its bjam configuration files:

# Sometimes I wake up screaming. Famous figures are gathered in the nightmare,
# Steve Bourne, Larry Wall, the whole of the ANSI C committee. They're just
# standing there, waiting, but the truely terrifying thing is what they carry
# in their hands. At first sight each seems to bear the same thing, but it is
# not so for the forms in their grasp are ever so slightly different one from
# the other. Each is twisted in some grotesque way from the other to make each
# an unspeakable perversion impossible to perceive without the onset of madness.
# True insanity awaits anyone who perceives all of these horrors together.

Dealing with that arcane build system clearly pushes one to the edges of sanity.

Building Qt 5.1 without WebKit on Fedora 19

•July 7, 2013 • Leave a Comment

I’m pretty excited by the release of Fedora 19 and Qt 5.1 this week. Fedora 19 uses gcc 4.8.1, which is a C++11 feature-complete compiler. With Qt 5.1 comes Qt Quick Controls (formerly Qt Desktop Components), bringing the flexibility of QML to more traditional desktop applications.

Here are the steps I took to build Qt 5.1 on a clean install of Fedora 19.

Setup sudo

Setting up sudo makes the next steps simpler. From the Fedora Project’s wiki:

Become the root user using the su command. Enter the password for the root account when prompted.

su -

Run this command, using your user account name in the place of “sampleusername”:

usermod sampleusername -a -G wheel

You must now log off and back on in order to have access to the wheel group. Note that when sudo prompts you for a password, it expects your user password, not root’s.

Fedora Project wiki content is available under the Attribution-Share Alike 3.0 Unported license.

Install dependencies

Some packages in the commands below may already be installed, and that’s fine. Just give yum the whole list at let it sort things out.

This is quite a long command, so be sure to copy the whole thing. There may be a scroll bar if you hover the mouse over the code. Run it in a terminal to install these packages.

There is an xcb package required that is not yet in the default repository. You’ll need to get it from updates.

Download and extract Qt 5.1

We’ll download from the zipped source packages, because that’s an easy way of doing things. There are all sorts of goodies in Qt’s official releases bin.

Then, we’ll delete the qt webkit stuff. It’s a big library, takes a while to compile and has a whole bunch of extra dependencies. If you’re not going to be using it, it’s not worth building it.

Configure, build and install Qt 5.1

I use a pretty vanilla configuration, but there’s a lot of different options. Just run ./configure -help to see them listed.

Run the commands below one at a time, ensuring that each succeeds before going onto the next one.

Now you’re done! You have a working version of Qt installed to /opt/Qt-5.1.0/


For doing this all super-fast, here’s the whole thing (after sudo is setup) as one set of commands.

If Wishes Were Fishes: Forward Declarations

•June 12, 2013 • Leave a Comment

So, you hear that you can reduce your compilation times by replacing includes with forward declarations. Now you embark on a quest to forward declare your types. Only, after a little while you discover it’s often annoying and repetitive, or even impossible. Let’s take a look:

So, if I had my wish, how would things work? Well, you could make radical changes to the compilation model, but let’s just limit our scope to declaring functions and types.

Wouldn’t that be nice? Just forward declare the types how they’re used. That way, you could replace a typedef with a real type, or add a default template argument without changing your forward declarations.

Unfortunately, as sensible as these things may first appear, some of them fall apart when you look at linking, and a few of them even earlier than that. I’ll examine those problems in my next post on this topic.

GStreamer Really Wants To Build Those Tests

•May 27, 2013 • Leave a Comment

I came across something interesting while building gstreamer.

[slavik@localhost gstreamer-0.10.24]$ ./configure --disable-examples --disable-tests
....[lines removed]....
configure: WARNING: Sissy ! By asking to not build the tests known to fail, you hereby waive your right to customer support. If you do not agree with this EULA, please press Ctrl-C before the next line is printed. By allowing the next line to be printed, you expressly acknowledge your acceptance of this EULA.
....[lines removed]....
[slavik@localhost gstreamer-0.10.24]$

Seems a little extreme, doesn’t it? I’ll admit I was amused, having found this buried in the configuration output. It takes quite some gall to insult your users, even in jest.

Do What I Mean

•February 7, 2013 • Leave a Comment

It was a pleasant surprise when I discovered udpate was a synonym for update. No more must my typing speed be constrained by accuracy; Accurev knows what I mean.

A Good Reputation

•August 17, 2012 • 1 Comment

Well, I just hit 1000 points on StackOverflow. I do have to say that I really love that site. It has given me so many insights into how other programmers think, what other technologies are out there, and how to solve common (or not-so-common) programming problems.

1,000 Reputation

But there is one thing that really bugs me. My best answers are not my highest-rated ones. In fact, for some of my best answers, I’ve gotten practically no recognition. That’s a little frustrating. Especially when some of my highest rated answers are vague statements about general design and development of software: things that are easily repeated, and are too vague to be of much direct use.

There’s two main reasons for this problem:

  1. Vague answers about general design are easier to verify as correct than detailed research into APIs and standards. More verifiable means more votes.
  2. Questions with popular tags seem to get more traffic. There are roughly 10x as many questions and users for C++ as for Qt. More traffic means more votes.

The traffic problem is the worse of the two, as well. It has a terrible side-effect of funnelling a large volume of ignorant C++ developers into questions tagged both ‘c++’ and ‘qt’. Horrific things will occasionally happen when a general C++ developer attempts to answer a Qt-specific question. Surprisingly, even veteran members will attempt to answer questions they clearly have no understanding of.

This becomes a serious problem, because there are a lot of C++ developers looking through the question. I suspect they outnumber Qt developers nearly 10:1, leading to bad voting. My worst example of this would be in a question asking whether it is safe to create a QLayout on the stack. The original accepted answer was so painfully wrong I had to write a detailed answer citing documentation to contradict its mistaken assertion. But, despite that, the correct answer still has just 1 upvote and the falsehood has 5. Five upvotes for this? Really?

Every QObject deletes its children. Only objects with no parent can have automatic storage.

Alas, that sounds reasonable. Thus, it was highly upvoted by numerous people who did not know any better. That’s the danger of a ‘c++’ tag on your Qt question. Of course, voting sometimes does pull through. Another question I saw about throwing exceptions across signal/slot connections had some confused comments and a confused answer (all posted by vanilla-C++ developers), but the rating system ultimately did its job.

So, StackOverflow has its warts, and it’s clearly not fair. But generally speaking, it works. Things usually turn out ok in the end, and it is a fantastic resource even for those who do not participate in its community.