Andrew Neitsch

Contact

andrew@neitsch.ca PGP
Call or text +1 (403) 472-1011

Research

In grad school, I studied software engineering to help become better at writing software.

I focused on build systems because I find them to be a big pain, but a big pain that’s absolutely worth it if done right. Usually you either spend too much time figuring out the build system at the start when there’s more important stuff to work on, or you end up wasting more time later on and getting frustrated with a poor build system that’s slow and occasionally fails to incorporate your latest changes. But when you have a great build system that instantly reflects all your source code changes in a running system, and gathers warnings and errors in an easy-to-remedy way—programming is just so much easier and more fun.

Master’s Thesis

Building programs that use multiple programming languages is more complicated than the normal single-language case. By studying multilanguage build systems, what can we learn about build systems in general?

By comparing the build systems of a sample of different multilanguage software packages, I found a set of common techniques for causing and solving build problems, and a possible explanation for why previous quantitative work has found that centralizing responsibility for the build system reduces overall build maintenance.

Because build systems are seen as secondary and relatively unimportant, people don’t usually focus on them. They reuse design decisions and abstractions from the application domain in the build system. The build system for Python is Pythonic and build systems for CORBA-based software use CORBA patterns. This phenomenon is beneficial if the application domain is systems-type software with the emphasis on correctness that build systems require, but if the application domain is something else, this phenomenon is likely to result in lower-quality builds. You can counter this by having specific build experts who work primarily on the build system, rather than sharing responsibility for the build system among all developers.

Downloads

Thesis, 121 pages, 1.2MB
Presentation, 83 slides, 3.5MB

#### Citation Andrew Neitsch. *Build System Issues in Multilanguage Software*, Master’s thesis, University of Alberta, 2012. [http://hdl.handle.net/10402/era.28641][doi] [doi]: http://hdl.handle.net/10402/era.28641 ### ICSM paper The major results of my master’s thesis were published at the [28th IEEE International Conference on Software Maintenance][ICSM2012] in 2012. [ICSM2012]: http://selab.fbk.eu/icsm2012/ #### Downloads

Paper, 10 pages, 192KB
Presentation, 29 slides, 1.1MB

Build diagram of one of the case studies, p. 62

Summary slide from presentation

Abstract

Building software from source is often viewed as a “solved problem” by software engineers, as there are many mature, well-known tools and techniques. However, anecdotal evidence suggests that these tools often do not effectively address the complexities of building multilanguage software. To investigate this apparent problem, we have performed a qualitative study on a set of five multilanguage open source software packages. Surprisingly, we found build system problems that prevented us from building many of these packages out-of-the-box.

Our key finding is that there are commonalities among build problems that can be systematically addressed. In this paper, we describe the results of this exploratory study, identify a set of common build patterns and anti-patterns, and outline research directions for improving the build process. One such finding is that multilanguage packages avoid certain build problems by supporting compilation-free extension. As well, we find evidence that concerns from the application and implementation domains may “leak” into the build model, with both positive and negative effects on the resulting build systems.

Citation

Andrew Neitsch, Kenny Wong, and Michael W. Godfrey. “Build System Issues in Multilanguage Software”, Proceedings of the 2012 28th IEEE International Conference on Software Maintenance (ICSM 2012), Riva del Garda, Trento, Italy, September 2012. http://hdl.handle.net/10.1109/ICSM.2012.6405265

Stack Overflow

Stack Overflow is an extremely useful site where people answer programming questions. I use it all the time to search for the answers to problems I run into while programming. Sometimes I answer questions there too, in order to earn imaginary “points.”

Here are some of the more interesting questions that I’ve answered there:

10683941: Clearing memory securely and reallocations

Q: I have a password in memory, and I’m doing all the right stuff to zero it from memory. Yet if I dump core on the program, the password still shows up in the core dump! What’s going on?

A: When you memcpy a big-enough string, the SSE registers are used as a buffer. Those registers contain a copy of your password, and are written to disk when you dump core.

14574109: SimpleDateFormat Exception on setting lenient to false

Q: I’m trying to parse the date 2012-03-11 2:46 a.m. in Java, with a SimpleDateFormat on which I’ve set the ‘lenient’ option to false. Why do I keep getting an exception?

A: That day was daylight savings time change day, so times between 2:00 a.m. and 3:00 a.m. don’t actually exist. Huh. I’ll have to remember to setLenient(false) on all SimpleDateFormat objects I create in the future.

14514997: Reopen a file descriptor with another access?

Q: On Linux, a file has been deleted from disk, but there is still one process that has the file open for writing. Is there any way to get the file back?

A: Sure! Reopen the deleted file via /proc/$pid/fd/$n.

1259084: What encoding/code page is cmd.exe using

Q: The Windows console is terrible at dealing with Unicode. Sometimes it seems capable of printing Unicode properly, but most of the time I get gibberish. How can I make it work?

A: If you open cmd.exe in a debugger—Microsoft’s symbol servers are really handy for this—it turns out that cmd.exe has special code to inspect the start of the file it’s about to type out. If it finds a UTF-16LE BOM, it uses WriteConsoleW to write Unicode to the console, regardless of the current codepage. You’ll have to transcode to UTF-16LE and call WriteConsoleW in your own programs too.