This keeping in sync hasn't worked out, so I wrote this little script to convert the vim colors to the gvim ones:

Download the makegvim script, and use it like:

$ ./makegvim < ~/.vim/colors/<yourfile> > /tmp/x
$ mv /tmp/x ~/.vim/colors/<yourfile>

And now the colors of gvim should be identical to those of vim.

Note: colors like 000 must be used like cterm=0 otherwise the conversion fails (the script isn't that smart).

But how do you merge a commit from a forked git repository? Turns out it is not that difficult.

The commit I want has the hash 5a11e88ddbef4ce7513aae93bdcd377449f45efb.

The steps:

• Create a remote branch:

  git remote add hamnis https://github.com/hamnis/pandoc2rfc
  

• Fetch the contents of it:

  git fetch hamnis
  

• Cherry-pick the commit you need:

  git cherry-pick -c 5a11e88ddbef4ce7513aae93bdcd377449f45efb
  [master 7501f13] transform.xsl: Supporting the output from pandoc 1.8.2.1:  
  * table/title 
  instead of table/caption  
  * table/tgroup/thead/row/entry instead of table/thead/tr/th  
  * table/tgroup/tbody/row/entry instead of table/tbody/tr/td
   Author: Trygve Laugstøl <trygvis@inamo.no>
   1 files changed, 3 insertions(+), 3 deletions(-)
  

Voila.

When writing RFC 4641 we directly wrote the XML. Needless to say is was kinda tedious even thought the XML of xml2rfc is very "light".

Nowadays I'm a fan of the markdown syntax and especially the syntax as supported (created?) by Pandoc.

So for my next RFC (if ever!) I decided I wanted to use Pandoc. As xml2rfc uses XML I thought the easiest way would be to create docbook XML and transform that using XSLT.

The XML generated is suitable for inclusion in either the middle or back section of an RFC. The easiest way is to create a template xml file and include the appropriate XML:

<?xml version='1.0' ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>

<rfc ipr='trust200902' docName='draft-gieben-pandoc-writing-rfcs-01'>
 <front>
    <title>Writing I-Ds and RFCs using Pandoc</title>
</front>

<middle>
    <?rfc include="middle.xml"?>
</middle>

<back>
    <?rfc include="back.xml"?>
</back>

</rfc>

See the Makefile for an example of this. In this case you need to edit 3 documents:

1. middle.mdk;
2. back.mkd;
3. template.xml (probably a fairly static file).

The draft (draft.txt) is automatically created when you call make. Note that this README.mkd is converted to an RFC-like document when you call make.

It needs xsltproc and pandoc to be installed.

What is supported?

• section with anchor and title attributes, see README.html;
• list style=symbols, see README.html;
• list style=numbers;
• list style=letters;
• list style=format, both lowercase and uppercase roman numerals;
• list style=hanging, see README.html;
• figure/artwork, see README.html;
• blockquote - this isn't supported by xml2rfc, so this is converted to figure/artwork paragraph. See README.html;
• refs: external (eref), see README.html;
• refs: internal (xref) see README.html;
• spanx style=verb, style=emph, style=strong, see README.html;
• tables, see README.html.

What's not?

• list style=empty;
• irefs: index (no pandoc syntax available);
• crefs: for comments (there is no pandoc syntax for this).

The heavy lifting is done by transform.xsl that transforms the Docbook XML to xml2rfc XML.

Check out the pandoc2rfc github repository.

Pandoc Constructs

What do you need to type in Pandoc to get the correct output. Note this is just basic Pandoc format, so you might be better off reading the README from Pandoc itself.

section

Just use the normal sectioning commands available in Pandoc, I tend to use

# Section1 One
Bla

Converts to xml2rfc: <section title="Section1 One" anchor="section1-one"> If you have another section that is also named "Section1 One", that anchor will be called "section1-one-1". Referencing the section is done with See [](#section1-one), see .

list style symbols

A symbol list.

* Item one;
* Item two.

Converts to xml2rfc: <list style="symbol">

list style numbers

A numbered list.

1. Item one;
2. Item two.

Converts to xml2rfc: <list style="numbers">

list style letters

A numbered list.

a. Item one;
b. Item two.

Converts to xml2rfc: <list style="letters">

list style format

A roman numbered list.

I.  Item one;
II.  Item two.

(note: 2 spaces after the numerals).

Converts to xml2rfc: <list style="format %I.">

list style hanging

This is more like a description list, so we need to use:

First item that needs clarification

:   Explanation one
More stuff, because item is difficult to explain.
* item1
* item2

Second item that needs clarification

:   Explanation two

Converts to xml2rfc: <list style="hanging"> and <t hangText="First item...">

figure/artwork

Just indent the paragraph with 4 spaces.

Converts to xml2rfc: <figure><artwork> ...

blockquote

This is not supported by xml2rfc, but any paragraph like:

> quoted text

Converts to xml2rfc: <figure><artwork> ...

refs: external

Any reference like:

[Click here](URI)

Converts to xml2rfc: <ulink target="URI">Click here ...

refs: internal

Any reference like:

[Click here](#localid)

Converts to xml2rfc: <link target="localid">Click here ...

For referring to RFCs (for which you manually need add the reference source in the template), you can just use:

[](#RFC2119)

And it does the right thing. Referencing sections is done with:

See [](#pandoc-constructs)

The word 'Section' is inserted automatically: ... See ...

spanx style

The verb style can be selected with back-tics:

`text`

Converts to xml2rfc: <spanx style="verb"> ...

And the emphasis style with asterisks:

*text*

Converts to xml2rfc: <spanx style="emph"> ...

And the emphasis style with double asterisks:

**text**

Converts to xml2rfc: <spanx style="strong"> ...

I went searching and found "xoria256" a color scheme suited for 256 color terminal and a dark background. There is even a Ubuntu/Debian package for it: vim-scripts. Unlike solarized it doesn't come with a custom palette, just use Tango in gnome-terminal (or whatever your favorite is).

But of course I wasn't completely happy with it as I wanted some more blue-ish colors in there.

So tweaked it a little, and this is the result:

I've also ported it over to mutt, so that it has a matching color theme.

• Download the vim color scheme;
• Download mutt color scheme.

Note: I haven't changed the name of the color scheme, but it should be called something different, xoria256m or something. It is also still a work-in-progress, I will probably open a git repository on github soonish.

To summarise a long presentation I gave to non-programmers:

• There are 12 million programmers in the world
• The majority of those programmers are scarcely qualified
• Most technology decisions are made by a combination of following the crowd and a false understanding of risk.
• The high cost and failure rate in software development is no coincidence.

Remember the Stevie Wonder rule - "When you believe in something you don't understand then you suffer". In this case that means "Perhaps making programming language decisions based on what 12 million powerless idiots are doing isn't the golden road to glory and great hacks."

Go is a genuine attempt to improve the state of systems programing language beyond the point they reached in the early 1970s. As a result the sort of people using it are mostly that small community of people who understand and care about the concerns that drive such a development.

You're not going to catch those 12 million people unless you can market heavily enough the idea that their future income depend on jobs/contacts built around go, but that goal just draws resources and energy away from making the language better.

Arguably Java also suffers from it's large community of corporate drones. The slavish tendency to build baroque, mausoleums of intricate classes, dense with state and dripping with verbose XML is a reflection of the unthinking insanity of the 12 million.

I'd rather a tiny community use the language well, built successful applications and organically grew the user base whilst establishing a clean, sane library base that might later be used to improve the lives of a wider population of programmers.

I've said more than enough, I'll trundle back to the twelve million and take my punishment now.

• BASIC - with line numbers! At the time (I was 11) didn't know there was something else out there. Fun and easy language, although I never programmed in it ever again.

• Pascal - After BASIC, there is no going back to Pascal. Only briefly looked at it in my youth and discarded it in favor for BASIC...

• PHP - a language for children, by children. Insecure, weird and no namespaces (and that for a dynamic language). I always need to look up function prototypes, like the difference of the thing you are looking for in these functions:

    int preg_match ( string $pattern , string $subject ...

And

    int substr_compare ( string $main_str , string $str ...

And then you find a nice function on www.php.net, which is 'deprecated' because of various reasons.

• C - old, but functional. Obviously no gc and namespaces, but you get a real sense of power and nicely documented in manual pages I still use C today for rdup for instance.

• Perl - love it. Easy to write, easy to read (after using it for a few years).

• Python - not for me. I just don't like OO programming and the format rules are really not for me.

• Unix Shell - sucks, except for short stuff. See Bash: Gotchaes:

!/bin/bash
echo nothing | while read line; do
    foo=bar
    echo foo1: $foo
done
echo foo2: $foo

Example output:

foo1: bar
foo2:  (shouldn't be empty)

• Java - never dared venturing in to it. Way too verbose and again I don't really like OO programming.

• C++ - I will rather be shot in the shoulder than to use this. See this nice pdf for some horrific examples, Pdf is from fefe.de (Felix von Leitner).

• Lisp - nice language. One of the oldest languages out there and still interesting. But learning (common) Lisp now (without concurrency and stuff) isn't worth the effort.

• Erlang - great language. I could not cope with the syntax, although I even found the functional aspect of it rather nice.

• Go - better than C, simpler than C++. And has concurrency, namespaces and gc. The more I code in it the more I like it. Even the OO implementation (using Interfaces{}) is nice.

• Assorted macro languages, like LaTex and m4. Fun, but obscure.

I want to create a set (n in 2..N) goroutines. Each of these routines will check if it can divide a number (i) by n (integer division). If so the number i is not prime, otherwise it is given to the next goroutine. Communication between the goroutines is done via channels as in this example.

Sieve

In this small example I have 5 goroutines, and we give it the number 3 and 4. The table shows the reminder when dividing by n.

            n = 2   3   4   5  ... ...
-------------------------------------------
i  = 3 % n      1   0   3   3   3   3   ...
i  = 4 % n      0   1   0   4   4   3   ...

From here we see that i = 3 is prime, because it has an 1 in the column where n = 2, i = 4 is not prime, because it has a zero in the column where n = 2.

The algorithm for each goroutine thus becomes (in pseudo code):

function(n, i) {
if i == 0 then copy to next goroutine; return
if n >= i then copy to next goroutine; return

// test for primeness, if not prime return the *magic* 
// number 0
if i % n == 0 then
    // not prime
    give 0 to the next goroutine
fi

give i to the next goroutine
}

Or in Go's syntax:

func f(left, right chan int, n int) {
    i := <-right;
    if i == 0 || n >= i {
        left <- i;
        return;
    }
    if i%n == 0 {
        // too bad
        left <- 0;
        return;
    }
    left <- i;
}

Main

The rest of the Go program should setup the goroutines, channels and handle the flags. N - 1 goroutines are set up, and each is connected to its neighbor.

Even nicer would be to really do this in parallel, i.e. send i to all goroutines, and then just see if one of them returned zero. If none of them do, its a prime. For now the following must suffice.

In Go code:

leftmost := make(chan int);
var left, right chan int = nil, leftmost;
for n := 0; n < *prime-1; n++ {
    left, right = right, make(chan int);
    go f(left, right, *prime-n);
}
right <- *prime;        // bang!
x := <-leftmost;        // wait for completion
fmt.Println(x);

This outputs 0 when the number tested is not prime, it outputs the number itself given when it is prime.

% ./sieve -p 32
0           # not prime

% ./sieve -p 11
11          # prime ;-)

Complete listing

package main

import (
    "flag";
    "fmt";
    "os";
)

var prime = flag.Int("p", 13, "test for primeness")

func f(left, right chan int, n int) {
    i := <-right;
    if i == 0 || n >= i { 
        left <- i;
        return;
    }   
    if i%n == 0 { 
        // too bad
        left <- 0;
        return;
    }   
    left <- i;
}

func main() {
    flag.Parse();

    if *prime < 2 { 
        fmt.Fprint(os.Stderr, "You know this already\n");
        os.Exit(1);
    }   

    leftmost := make(chan int);
    var left, right chan int = nil, leftmost;
    for n := 0; n < *prime-1; n++ {
        left, right = right, make(chan int);
        go f(left, right, *prime-n);
    }   
    right <- *prime;        // bang!
    x := <-leftmost;        // wait for completion
    fmt.Println(x);
}

So today's exercises:

1. Write a cat implementation in Go. See below.
2. Write a grep implementation in Go. See below.

Cat in go

package main

// A implementation of cat in Go

import (
    "os";
    "fmt";
    "bufio";
    "flag";
)

var numberFlag = flag.Bool("n", false, "number each line")

func cat(r *bufio.Reader) bool {
    i := 1;
    for {
        buf, e := r.ReadBytes('\n');
        if e == os.EOF {
            break
        }
        if *numberFlag {
            fmt.Fprintf(os.Stdout, "%5d  %s", i, buf);
            i++
        } else {
            fmt.Fprintf(os.Stdout, "%s", buf)
        }
    }
    return true;
}

func main() {
    flag.Parse();
    if flag.NArg() == 0 {
        cat(bufio.NewReader(os.Stdin))
    }
    for i := 0; i < flag.NArg(); i++ {
        f, e := os.Open(flag.Arg(i), os.O_RDONLY, 0);
        if e != nil {
            fmt.Fprintf(os.Stderr, "%s: error reading from %s: %s\n",
                os.Args[0], flag.Arg(i), e.String());
            continue;
        }
        if !cat(bufio.NewReader(f)) {
            os.Exit(1)
        }
    }
}

Grep in go

package main

// A implementation of Unix grep in Go
// TODO(mg) better error handling

import (
    "os";
    "fmt";
    "bufio";
    "regexp";
    "flag";
)

var numberFlag = flag.Bool("n", false, "number each line")
var filenameFlag = flag.Bool("l", false, "print names of matching files")

func grep(r *bufio.Reader, reg string) (match bool) {
    i := 0;
    for {
        buf, e := r.ReadBytes('\n');
        i++;
        if e == os.EOF {
            break
        }
        if m, _ := regexp.Match(reg, buf); m == true {
            match = true;
            if *filenameFlag {
                return match
            }
            if *numberFlag {
                fmt.Fprintf(os.Stdout, "%5.d:  %s", i, buf)
            } else {
                fmt.Fprintf(os.Stdout, "%s", buf)
            }
        }
    }
    return match;
}

func main() {
    flag.Parse();
    if flag.NArg() < 1 {
        fmt.Fprintf(os.Stderr, "%s: missing regexp\n", os.Args[0]);
        os.Exit(1);
    }
    if flag.NArg() == 1 {
        if grep(bufio.NewReader(os.Stdin), flag.Arg(0)) {
            if *filenameFlag {
                fmt.Fprintf(os.Stdout, "(standard input)\n");
            }
        }
    }
    for i := 1; i < flag.NArg(); i++ {
        f, e := os.Open(flag.Arg(i), os.O_RDONLY, 0);
        if e != nil {
            fmt.Fprintf(os.Stderr, "%s: error reading from %s: %s\n",
                os.Args[0], flag.Arg(i), e.String());
            continue;
        }
        if grep(bufio.NewReader(f), flag.Arg(0)) {
            if *filenameFlag {
                fmt.Fprintf(os.Stdout, "%s\n", flag.Arg(i))
            }
        }
    }
}

package main

// An implementation of Unix cat in Go

import (
    "os";
    "fmt";
    "flag";
)

func cat(filename string) bool {
    const NBUF = 512;
    var buf [NBUF]byte;
    if f, e := os.Open(filename, os.O_RDONLY, 0); e != nil {
        fmt.Fprintf(os.Stderr, "cat: error reading from %s: %s\n",
            filename, e.String());
        return true;
    } else {
        for {
            switch nr, _ := f.Read(&buf); true {
            case nr < 0:
                os.Exit(1)
            case nr == 0:   // EOF
                return true
            case nr > 0:
                if nw, ew := os.Stdout.Write(buf[0:nr]); nw != nr {
                    fmt.Fprintf(os.Stderr,
                        "cat: error writing from %s: %s\n",
                        filename, ew.String());
                    return false;
                }
            }
        }
    }
    return true;
}

func main() {
    flag.Parse();   // implement -n TODO
    if flag.NArg() == 0 {
        cat("/dev/stdin")
    }
    for i := 0; i < flag.NArg(); i++ {
        if !cat(flag.Arg(i)) {
            os.Exit(1)
        }
    }
}

In something like 50 lines you have a cat program. I'm really starting to like Go. Next up: extra features and a grep command.

I also re-watched the presentation Rob Pike gave for Google Tech Talks on youtube.com. In there he presented the following program chain.go: (Formatted with gofmt as it should)

package main

import (
    "flag";
    "fmt";
)

var ngoroutine = flag.Int("n", 100000, "how may")

func f(left, right chan int)    { left <- 1+<-right }

func main() {
    flag.Parse();
    leftmost := make(chan int);

    var left, right chan int = nil, leftmost;
    for i := 0; i < *ngoroutine; i++ {
        left, right = right, make(chan int);
        go f(left, right);
    }
    right <- 0;             // bang!
    x := <-leftmost;        // wait for completion
    fmt.Println(x);         // 100000
}

In this short program we make a chain of 100000 goroutines which are connected to each other. Each one adds 1 to the value it gets from its right neighbor. We start it of by giving the last one (right) a value of 0. Then we wait until they are finished and print it.

Compile and run

To compile the above program you

8g chain.go 
8l -o chain chain.8

And then run it

./chain

On my crappy laptop this takes about 2.3 seconds. Not too bad :)

Vim

For Go code editing, I've added the following to my ~/.vimrc

autocmd Filetype go set textwidth=0
autocmd Filetype go set noexpandtab
autocmd Filetype go set tabstop=8
autocmd Filetype go set shiftwidth=8
autocmd Filetype go set softtabstop=8
autocmd Filetype go set number
autocmd Filetype go command! Fmt %!gofmt

The last line adds a new command which reformats your Go code. Just do <ESC>:Fmt and you'll end up with properly formatted Go code. The coding style rules for Go are simple. Its what you get when you run it through to gofmt.