Archive for the ‘ Programming ’ Category

Global constructor bug in GCC 4.5.1

I’ve recently returned to programming my Seeeduino Mega (ATmega1280) for my tricopter. Yesterday I discovered that every time I included serial code in the sketch, the sketch seemed to freeze as if it was not running the loop(). After several hours, I identified the source of the bug to be in the gcc-avr compiler that Linux uses. Note that this bug does not affect the ATmega328p of the Duemilanove.

I am compiling and uploading sketches from the command line (another small adventure I will post about later) with Arduino 0018 on 64-bit Arch Linux.

This blog post explains the bug pretty well. Until an official patch comes out, there are two workarounds: downgrade to GCC 4.3.3 or make the proposed patch. I tried installing the 4.3.3 version from archived sources but ran into other bugs that did not let me compile.

This GCC Bugzilla report describes the patch with proper line numbers. After building the patched source and installing the package, I was able to compile and upload fully-functioning ATmega1280 sketches.

Here is the compiled package for 64-bit Arch Linux.



Again from If programming languages were cars…:

Haskell is an incredibly elegantly-designed and beautiful car, which is rumored to be able to drive over extremely strange terrain. The one time you tried to drive it, it didn’t actually drive along the road; instead, it made copies of itself and the road, with each successive copy of the road having the car a little further along. It’s supposed to be possible to drive it in a more conventional way, but you don’t know enough math to figure out how.

[Monadic version:]

Haskell is not really a car; it’s an abstract machine in which you give a detailed description of what the process of driving would be like if you were to do it. You have to put the abstract machine inside another (concrete) machine in order to actually do any driving. You’re not supposed to ask how the concrete machine works. There is also a way to take multiple abstract machines and make a single abstract machine, which you can then give to the concrete machine to make multiple trips one after another.

So here is my hello.hs:

main = putStrLn "Hello World!"

C++ Language Tutorial — Basics of C++: Structure of a Program

Initially, I looked at C++ Language Tutorial by Juan SouliƩ, but I found Thinking in C++ by Bruce Eckel recommended on the KDE development page, so I am going to read both.

At first glance, Eckel’s book looks like a really heavy read. If I may say so, it’s very… hard-core? Perhaps bleak? Okay, I may be biased toward pretty, colorful code blocks used in the C++ Language *Tutorial*, but really—Eckel’s first chapter is a slightly ominous, philosophical “Introduction to Objects.” The chapters are much more detailed than SouliĆ©’s tutorial (after all, it’s just that, a tutorial).

Hopefully, I’ll be able to pluck up some courage to read that chapter once I’ve learned a reasonable amount of syntax and structure. It seems like a great book, but it looks way too scary right now.

So getting started with the tutorial:

A basic C++ program as a model, copied from the site:

// my first program in C++

using namespace std;

int main () {
  cout << "Hello World!";
  return 0;

All text after two slash signs (//) are comments. Block comments can be inserted between /* and */.

Lines beginning with a hash sign (#) are directives for the preprocessor. In this example, #include tells the preprocessor to include the iostream file, which is the basic input-output library in C++ (which defines cout).

“All the elements of the standard C++ library are declared within what is called a namespace… with the name std.” We call it with using namespace std, and it is frequently used in C++ programs that use the standard library.

int main () is the beginning of the definition of the main function, which is where all C++ programs start their execution. Other functions may be defined elsewhere and anywhere, but the main function will be executed first (thus is essential to every C++ program). The parentheses can optionally enclose a list of parameters. The body of the function is enclosed in a pair of braces.

A statement is an expression that can produce an effect. cout << "Hello World!"; outputs the string of characters Hello World! into the standard output (e.g., the screen). All expression statements are terminated by a semicolon.

The return statement in this example is followed by a return code of 0, which generally indicates a successful execution of the program. C++ console programs are usually ended in this way.

With the exception of lines of preprocessor directives (they are not statements), whitespace is insignificant. Semicolons are important.

Dive Into Python — Chapter 2. Your First Python Program

I’ve been working my tail off for the past two months to finish some schoolwork by a March deadline. It was my fault, but how I hate it! I still have a July deadline that is about to eat me, but you don’t care about that. :)

Because of the helpful distractions, I haven’t been able to do much else, including learning how to program (let alone doing the SPOJ exercises I promised myself to do). Now that I have a little more time, I am going to blog about what I learn from the various online textbooks on Python, C++, and Lisp that I am using. I am reading Dive Into Python by Mark Pilgrim.

Hopefully, this will force me to organize my thoughts more effectively and give me something to review later. So this is the first such entry.

Chapter 1 discusses installing Python on the various OSes… which, for me, was nothing harder than sudo aptitude install python on Ubuntu GNU/Linux.

2.1. Diving In

This first section gives a complete (short) Python program for me to chew on:

def buildConnectionString(params):
    """Build a connection string from a dictionary of parameters.

    Returns string."""
    return ";".join(["%s=%s" % (k, v) for k, v in params.items()])

if __name__ == "__main__":
    myParams = {"server":"mpilgrim", \
                "database":"master", \
                "uid":"sa", \
                "pwd":"secret" \
    print buildConnectionString(myParams)

2.2. Declaring Functions

Functions are declared using def:

def functionName(arg1, arg2)

The example provided uses CamelCase. I think C uses the same convention, though Lisp uses hyphens.

All functions return a value (its datatype is unspecified), even if it’s None, Python’s null value. Variables as well are not explicitly typed. This is in contrast to C++ and other statically typed languages like Java.

2.3. Documenting Functions

The doc string is defined using triple quotes. The example given:

def buildConnectionString(params):
    """Build a connection string from a dictionary of parameters.

    Returns string."""

The doc string, if present, must be the first thing defined in a function, and it is an attribute of the function.

2.4. Everything Is an Object

A function is an object. We can import a chunk of code as a module with the import command and access its functions, classes, or attributes with module.function. From there we can call a function’s doc string with module.function.__doc__.

Import search paths are defined in sys.path, so we can import the sys module and append our own paths with sys.path.append('/my/new/path').

This [fact that everything is an object] is so important that I’m going to repeat it in case you missed it the first few times: everything in Python is an object. Strings are objects. Lists are objects. Functions are objects. Even modules are objects.

For now, I’ll just take his word for it.

2.5. Indenting Code

Code blocks are defined by their indentation. It does not matter how much they are indented as long as it is consistent. I think four spaces is the norm.

I don’t know why some people hate it. I love the absence of braces! Here is an example given in the book:

def fib(n):
    print 'n =', n
    if n > 1:
        return n * fib(n - 1)
        print 'end of the line'
        return 1

Braces are for computers, not for human eyes. This also forces people to organize their code (and in the same way), so reading others’ code isn’t a pain.

2.6. Testing Modules

This section is a tip on using the __name__ attribute to help test modules. If we import a module, __name__ is the module’s filename without the directory path or its file extension. However, if it is run as a standalone program, __name__ holds a special value of __main__.

Thus, we can use an if statement like

if __name__ == "__main__"

to design a test suite that will only run when the module is run as a standalone program and not as an imported module as part of a larger program. This can help with debugging.

Learning Common Lisp

Many online sources say that Lisp is a “programmable programming language.” Defining my own macros, being creative, and all that sounded a lot like the Art of Problem Solving spirit. So I decided to learn it. I’m reading Practical Common Lisp by Peter Seibel. The examples make things clear. I can’t say much else because I’m still a novice.

From “If programming languages were cars…”:

Lisp: looks like a car, but with enough tweaking you can turn it into a pretty effective airplane or submarine.

[from Paul Tanimoto:]

Lisp: At first it doesn’t seem to be a car at all, but now and then you spot a few people driving it around. After a point you decide to learn more about it and you realize it’s actually a car that can make more cars. You tell your friends, but they all laugh and say these cars look way too weird. You still keep one in your garage, hoping one day they will take over the streets.

And from Paul Graham, author of On Lisp, another ostensibly good book:

Lisp code looks weird. But those parentheses are there for a reason. They are the outward evidence of a fundamental difference between Lisp and other languages.

For good measure, other entries from “If programming languages were cars…”:

Python is a great beginner’s car; you can drive it without a license. Unless you want to drive really fast or on really treacherous terrain, you may never need another car.

C++ is a souped-up version of the C racing car with dozens of extra features that only breaks down every 250 miles, but when it does, nobody can figure out what went wrong.

I hope I’m getting somewhere with all this.