hg update release.r<i>NN</i>

</pre>

<h2 id="r58">r58 (released 2011/06/29)</h2>

<p>

hg update weekly.<i>YYYY-MM-DD</i>

</pre>

<h2 id="2011-06-09">2011-06-09 (<a href="release.html#r58">base for r58</a>)</h2>

<pre>

<pre>

// Error codes returned by failures to parse an expression.

var (

...

)

</pre>

<pre>

owner := obj.Owner()

if owner != user {

}

</pre>

This would be useful if we wanted to refine the methods of <code>Logger</code>.

</p>

<pre>

job.Logger.Logf("%q: %s", job.Command, fmt.Sprintf(format, args))

}

</pre>

</p>

<p>

Callers that care about the precise error details can

use a type switch or a type assertion to look for specific

errors and extract details. For <code>PathErrors</code>

<!-- The Go Memory Model -->

<style>

p.rule {

after <span class="event">e₂</span>, then we say that <span class="event">e₁</span> and <span class="event">e₂</span> happen concurrently.

</p>

order expressed by the program.

</p>

<!-- title The Go Programming Language Specification -->

<!--

TODO

[ ] clarify what a field name is in struct declarations

(struct{T} vs struct {T T} vs struct {t T})

[ ] need explicit language about the result type of operations

[ ] should probably write something about evaluation order of statements even

though obvious

[ ] review language on implicit dereferencing

<a href="#Character_literals">character</a>, or

<a href="#String_literals">string</a> literal,

an identifier denoting a constant,

the result value of some built-in functions such as

<code>unsafe.Sizeof</code> applied to any value,

<code>cap</code> or <code>len</code> applied to

<li>The scope of a constant or variable identifier declared

inside a function begins at the end of the ConstSpec or VarSpec

and ends at the end of the innermost containing block.</li>

<li>The scope of a type identifier declared inside a function

</pre>

<p>

</p>

<ul>

</ul>

<p>

These conversions may change the representation of <code>x</code>

and incur a run-time cost.

All other conversions only change the type but not the representation

of <code>x</code>.

</p>

<h4>Conversions between numeric types</h4>

<ol>

<li>

When converting between integer types, if the value is a signed integer, it is

</ol>

<p>

if the result type cannot represent the value the conversion

</p>

<ol>

<li>

</li>

</ol>

<h3 id="Constant_expressions">Constant expressions</h3>

<p>

Executing the "goto" statement must not cause any variables to come into

</p>

<pre>

<p>

is erroneous because the jump to label <code>L</code> skips

the creation of <code>v</code>.

</p>

<h3 id="Fallthrough_statements">Fallthrough statements</h3>

</p>

<p>

to <code>s</code> of type <code>S</code>, which must be a slice type, and

returns the resulting slice, also of type <code>S</code>.

</p>

<pre class="grammar">

type ArbitraryType int // shorthand for an arbitrary Go type; it is not a real type

type Pointer *ArbitraryType

func Reflect(val interface{}) (typ runtime.Type, addr uintptr)

func Typeof(val interface{}) (typ interface{})

</p>

<pre>

</pre>

<p>

</p>

<pre>

</pre>

<p>

Calls to <code>Alignof</code>, <code>Offsetof</code>, and

</p>

<p>

The functions <code>unsafe.Typeof</code>,

</li>

</ol>

<ul>

</ul>

<p>

Let's start in the usual way:

<p>

</pre>

<p>

Every Go source file declares, using a <code>package</code> statement, which package it's part of.

The comment convention is the same as in C++:

<p>

<pre>

</pre>

<p>

Later we'll have much more to say about printing.

Here's how to compile and run our program. With <code>6g</code>, say,

<p>

<pre>

</pre>

<p>

With <code>gccgo</code> it looks a little more traditional.

<p>

<pre>

</pre>

<p>

<h2>Echo</h2>

<p>

Next up, here's a version of the Unix utility <code>echo(1)</code>:

<p>

</pre>

<p>

This program is small but it's doing a number of new things. In the last example,

we saw <code>func</code> introduce a function. The keywords <code>var</code>, <code>const</code>, and <code>type</code>

(not used yet) also introduce declarations, as does <code>import</code>.

Notice that we can group declarations of the same sort into

But it's not necessary to do so; we could have said

<p>

<pre>

</pre>

<p>

This program imports the <code>&quot;os&quot;</code> package to access its <code>Stdout</code> variable, of type

The declaration statement has the form

<p>

<pre>

</pre>

<p>

This is the <code>var</code> keyword, followed by the name of the variable, followed by

We could write

<p>

<pre>

</pre>

<p>

or we could go even shorter and write the idiom

<p>

<pre>

</pre>

<p>

The <code>:=</code> operator is used a lot in Go to represent an initializing declaration.

There's one in the <code>for</code> clause on the next line:

<p>

</pre>

<p>

The <code>flag</code> package has parsed the arguments and left the non-flag arguments

''success''; if you want to signal an erroneous return, call

<p>

<pre>

</pre>

<p>

The <code>os</code> package contains other essentials for getting

of course you can change a string <i>variable</i> simply by

reassigning it. This snippet from <code>strings.go</code> is legal code:

<p>

</pre>

<p>

However the following statements are illegal because they would modify

a <code>string</code> value:

<p>

<pre>

</pre>

<p>

In C++ terms, Go strings are a bit like <code>const strings</code>, while pointers

Arrays are declared like this:

<p>

<pre>

</pre>

<p>

Arrays, like strings, are values, but they are mutable. This differs

from a type followed by a brace-bounded expression like this:

<p>

<pre>

</pre>

<p>

In this case the constructor builds an array of 3 <code>ints</code>.

<p>

Using slices one can write this function (from <code>sum.go</code>):

<p>

</pre>

<p>

Note how the return type (<code>int</code>) is defined for <code>sum</code> by stating it

an array and slices it:

<p>

<pre>

</pre>

<p>

If you are creating a regular array but want the compiler to count the

elements for you, use <code>...</code> as the array size:

<p>

<pre>

</pre>

<p>

That's fussier than necessary, though.

data structure, a slice itself&mdash;using empty brackets with no size&mdash;is all you need:

<p>

<pre>

</pre>

<p>

There are also maps, which you can initialize like this:

<p>

<pre>

</pre>

<p>

The built-in function <code>len</code>, which returns number of elements,

and channels is the <code>range</code> clause on <code>for</code> loops. Instead of writing

<p>

<pre>

</pre>

<p>

to loop over the elements of a slice (or map or ...) , we could write

<p>

<pre>

</pre>

<p>

This assigns <code>i</code> to the index and <code>v</code> to the value of the successive

returns a pointer to the allocated storage.

<p>

<pre>

</pre>

<p>

or the more idiomatic

<p>

<pre>

</pre>

<p>

Some types&mdash;maps, slices, and channels (see below)&mdash;have reference semantics.

types you want to use the built-in function <code>make</code>:

<p>

<pre>

</pre>

<p>

This statement initializes a new map ready to store entries.

If you just declare the map, as in

<p>

<pre>

</pre>

<p>

it creates a <code>nil</code> reference that cannot hold anything. To use the map,

too little precision to represent the value.

<p>

<pre>

</pre>

<p>

There are nuances that deserve redirection to the legalese of the

language specification but here are some illustrative examples:

<p>

<pre>

</pre>

<p>

Conversions only work for simple cases such as converting <code>ints</code> of one

Next we'll look at a simple package for doing file I/O with an

open/close/read/write interface. Here's the start of <code>file.go</code>:

<p>

</pre>

<p>

The first few lines declare the name of the

<p>

First, though, here is a factory to create a <code>File</code>:

<p>

</pre>

<p>

This returns a pointer to a new <code>File</code> structure with the file descriptor and name

object. We could write

<p>

<pre>

</pre>

<p>

but for simple structures like <code>File</code> it's easier to return the address of a

<p>

We can use the factory to construct some familiar, exported variables of type <code>*File</code>:

<p>

</pre>

<p>

The <code>newFile</code> function was not exported because it's internal. The proper,

exported factory to use is <code>OpenFile</code> (we'll explain that name in a moment):

<p>

</pre>

<p>

There are a number of new things in these few lines. First, <code>OpenFile</code> returns

wrappers that eliminate common errors by capturing

the tricky standard arguments to open and, especially, to create a file:

<p>

</pre>

<p>

</pre>

<p>

Back to our main story.

in parentheses before the function name. Here are some methods for <code>*File</code>,

each of which declares a receiver variable <code>file</code>.

<p>

</pre>

<p>

There is no implicit <code>this</code> and the receiver variable must be used to access

<p>

We can now use our new package:

<p>

</pre>

<p>

The ''<code>./</code>'' in the import of ''<code>./file</code>'' tells the compiler

Now we can compile and run the program. On Unix, this would be the result:

<p>

<pre>

</pre>

<p>

<h2>Rotting cats</h2>

Building on the <code>file</code> package, here's a simple version of the Unix utility <code>cat(1)</code>,

<code>progs/cat.go</code>:

<p>

</pre>

<p>

By now this should be easy to follow, but the <code>switch</code> statement introduces some

new features. Like a <code>for</code> loop, an <code>if</code> or <code>switch</code> can include an

has the same idea.) The <code>switch</code> statement is general: it evaluates the cases

from top to bottom looking for the first case that matches the value; the

case expressions don't need to be constants or even integers, as long as

is a form of <code>if-else</code> chain. While we're here, it should be mentioned that in

<code>switch</code> statements each <code>case</code> has an implicit <code>break</code>.

<p>

Slices provide the standard Go way to handle I/O buffers.

<p>

Now let's make a variant of <code>cat</code> that optionally does <code>rot13</code> on its input.

so let's start by defining an interface that has exactly those two methods.

Here is code from <code>progs/cat_rot13.go</code>:

<p>

</pre>

<p>

Any type that has the two methods of <code>reader</code>&mdash;regardless of whatever

the type and implement the methods and with no other bookkeeping,

we have a second implementation of the <code>reader</code> interface.

<p>

</pre>

<p>

<p>

To use the new feature, we define a flag:

<p>

</pre>

<p>

and use it from within a mostly unchanged <code>cat</code> function:

<p>

</pre>

<p>

(We could also do the wrapping in <code>main</code> and leave <code>cat</code> mostly alone, except

for changing the type of the argument; consider that an exercise.)

we received into a <code>rotate13</code> and proceed. Note that the interface variables

are values, not pointers: the argument is of type <code>reader</code>, not <code>*reader</code>,

even though under the covers it holds a pointer to a <code>struct</code>.

Here it is in action:

<p>

<pre>

</pre>

<p>

Fans of dependency injection may take cheer from how easily interfaces

fits the current situation. Consider the <i>empty interface</i>

<p>

<pre>

</pre>

<p>

<i>Every</i> type implements the empty interface, which makes it

<p>

As an example, consider this simple sort algorithm taken from <code>progs/sort.go</code>:

<p>

</pre>

<p>

The code needs only three methods, which we wrap into sort's <code>Interface</code>:

<p>

</pre>

<p>

We can apply <code>Sort</code> to any type that implements <code>Len</code>, <code>Less</code>, and <code>Swap</code>.

The <code>sort</code> package includes the necessary methods to allow sorting of

arrays of integers, strings, etc.; here's the code for arrays of <code>int</code>

<p>

</pre>

<p>

Here we see methods defined for non-<code>struct</code> types. You can define methods

uses a function in the <code>sort</code> package, omitted here for brevity,

to test that the result is sorted.

<p>

</pre>

<p>

If we have a new type we want to be able to sort, all we need to do is

to implement the three methods for that type, like this:

<p>

</pre>

<p>

<p>

Within the <code>fmt</code> package, <code>Printf</code> is declared with this signature:

<p>

<pre>

</pre>

<p>

The token <code>...</code> introduces a variable-length argument list that in C would

can just say <code>%d</code>; <code>Printf</code> knows the size and signedness of the

integer and can do the right thing for you. The snippet

<p>

</pre>

<p>

prints

<p>

<pre>

</pre>

<p>

In fact, if you're lazy the format <code>%v</code> will print, in a simple

appropriate style, any value, even an array or structure. The output of

<p>

</pre>

<p>

is

<p>

<pre>

</pre>

<p>

You can drop the formatting altogether if you use <code>Print</code> or <code>Println</code>

and adds a newline. The output of each of these two lines is identical

to that of the <code>Printf</code> call above.

<p>

</pre>

<p>

If you have your own type you'd like <code>Printf</code> or <code>Print</code> to format,

the method and if so, use it rather than some other formatting.

Here's a simple example.

<p>

</pre>

<p>

Since <code>*testType</code> has a <code>String</code> method, the

default formatter for that type will use it and produce the output

<p>

<pre>

</pre>

<p>

Observe that the <code>String</code> method calls <code>Sprint</code> (the obvious Go

<p>

<p>

<pre>

</pre>

<p>

<pre>

</pre>

<p>

The code uses a ``type assertion'' (<code>v.(Stringer)</code>) to test if the value stored in

interface type defined in the <code>io</code> library:

<p>

<pre>

</pre>

<p>

(This interface is another conventional name, this time for <code>Write</code>; there are also

<p>

Here is the first function in <code>progs/sieve.go</code>:

<p>

</pre>

<p>

The <code>generate</code> function sends the sequence 2, 3, 4, 5, ... to its

output, discarding anything divisible by the prime. The unary communications

operator <code>&lt;-</code> (receive) retrieves the next value on the channel.

<p>

</pre>

<p>

The generator and filters execute concurrently. Go has

computation but in the same address space:

<p>

<pre>

</pre>

<p>

If you want to know when the calculation is done, pass a channel

on which it can report back:

<p>

<pre>

</pre>

<p>

Back to our prime sieve. Here's how the sieve pipeline is stitched

together:

<p>

then starts up. As each prime pops out of the channel, a new <code>filter</code>

is added to the pipeline and <i>its</i> output becomes the new value

of <code>ch</code>.

in this style of programming. Here is a variant version

of <code>generate</code>, from <code>progs/sieve1.go</code>:

<p>

</pre>

<p>

This version does all the setup internally. It creates the output

returns the channel to the caller. It is a factory for concurrent

execution, starting the goroutine and returning its connection.

<p>

anonymous function and invoke it on the spot. Notice that the local

variable <code>ch</code> is available to the function literal and lives on even

after <code>generate</code> returns.

<p>

The same change can be made to <code>filter</code>:

<p>

</pre>

<p>

The <code>sieve</code> function's main loop becomes simpler and clearer as a

result, and while we're at it let's turn it into a factory too:

<p>

</pre>

<p>

Now <code>main</code>'s interface to the prime sieve is a channel of primes:

<p>

</pre>

<p>

<h2>Multiplexing</h2>

to illustrate the idea. It starts by defining a <code>request</code> type, which embeds a channel

that will be used for the reply.

<p>

</pre>

<p>

The server will be trivial: it will do simple binary operations on integers. Here's the

code that invokes the operation and responds to the request:

<p>

</pre>

<p>

returning a third.

<p>

The <code>server</code> routine loops forever, receiving requests and, to avoid blocking due to

a long-running operation, starting a goroutine to do the actual work.

<p>

</pre>

<p>

We construct a server in a familiar way, starting it and returning a channel

connected to it:

<p>

</pre>

<p>

Here's a simple test. It starts a server with an addition operator and sends out

<code>N</code> requests without waiting for the replies. Only after all the requests are sent

does it check the results.

<p>

</pre>

<p>

One annoyance with this program is that it doesn't shut down the server cleanly; when <code>main</code> returns

there are a number of lingering goroutines blocked on communication. To solve this,

we can provide a second, <code>quit</code> channel to the server:

<p>

</pre>

<p>

It passes the quit channel to the <code>server</code> function, which uses it like this:

<p>

</pre>

<p>

Inside <code>server</code>, the <code>select</code> statement chooses which of the multiple communications

All that's left is to strobe the <code>quit</code> channel

at the end of main:

<p>

</pre>

...

</pre>

<p>

There's a lot more to Go programming and concurrent programming in general but this

Let's start in the usual way:

Every Go source file declares, using a "package" statement, which package it's part of.

It may also import other packages to use their facilities.

Next up, here's a version of the Unix utility "echo(1)":

This program is small but it's doing a number of new things. In the last example,

we saw "func" introduce a function. The keywords "var", "const", and "type"

(not used yet) also introduce declarations, as does "import".

Notice that we can group declarations of the same sort into

But it's not necessary to do so; we could have said

const Space = " "

The ":=" operator is used a lot in Go to represent an initializing declaration.

There's one in the "for" clause on the next line:

The "flag" package has parsed the arguments and left the non-flag arguments

in a list that can be iterated over in the obvious way.

of course you can change a string <i>variable</i> simply by

reassigning it. This snippet from "strings.go" is legal code:

However the following statements are illegal because they would modify

a "string" value:

Using slices one can write this function (from "sum.go"):

Note how the return type ("int") is defined for "sum" by stating it

after the parameter list.

Next we'll look at a simple package for doing file I/O with an

open/close/read/write interface. Here's the start of "file.go":

The first few lines declare the name of the

package&mdash;"file"&mdash;and then import two packages. The "os"

First, though, here is a factory to create a "File":

This returns a pointer to a new "File" structure with the file descriptor and name

filled in. This code uses Go's notion of a ''composite literal'', analogous to

We can use the factory to construct some familiar, exported variables of type "*File":

The "newFile" function was not exported because it's internal. The proper,

exported factory to use is "OpenFile" (we'll explain that name in a moment):

There are a number of new things in these few lines. First, "OpenFile" returns

multiple values, a "File" and an error (more about errors in a moment).

wrappers that eliminate common errors by capturing

the tricky standard arguments to open and, especially, to create a file:

Back to our main story.

Now that we can build "Files", we can write methods for them. To declare

in parentheses before the function name. Here are some methods for "*File",

each of which declares a receiver variable "file".

There is no implicit "this" and the receiver variable must be used to access

members of the structure. Methods are not declared within

We can now use our new package:

The ''"./"'' in the import of ''"./file"'' tells the compiler

to use our own package rather than

Building on the "file" package, here's a simple version of the Unix utility "cat(1)",

"progs/cat.go":

By now this should be easy to follow, but the "switch" statement introduces some

new features. Like a "for" loop, an "if" or "switch" can include an

has the same idea.) The "switch" statement is general: it evaluates the cases

from top to bottom looking for the first case that matches the value; the

case expressions don't need to be constants or even integers, as long as

is a form of "if-else" chain. While we're here, it should be mentioned that in

"switch" statements each "case" has an implicit "break".

Slices provide the standard Go way to handle I/O buffers.

Now let's make a variant of "cat" that optionally does "rot13" on its input.

so let's start by defining an interface that has exactly those two methods.

Here is code from "progs/cat_rot13.go":

Any type that has the two methods of "reader"&mdash;regardless of whatever

other methods the type may also have&mdash;is said to <i>implement</i> the

the type and implement the methods and with no other bookkeeping,

we have a second implementation of the "reader" interface.

To use the new feature, we define a flag:

and use it from within a mostly unchanged "cat" function:

(We could also do the wrapping in "main" and leave "cat" mostly alone, except

for changing the type of the argument; consider that an exercise.)

we received into a "rotate13" and proceed. Note that the interface variables

are values, not pointers: the argument is of type "reader", not "*reader",

even though under the covers it holds a pointer to a "struct".

Here it is in action:

$ echo abcdefghijklmnopqrstuvwxyz | ./cat

abcdefghijklmnopqrstuvwxyz

$ echo abcdefghijklmnopqrstuvwxyz | ./cat --rot13

nopqrstuvwxyzabcdefghijklm

$

Fans of dependency injection may take cheer from how easily interfaces

allow us to substitute the implementation of a file descriptor.

implement a "writer", or any other interface built from its methods that

fits the current situation. Consider the <i>empty interface</i>

type Empty interface {}

<i>Every</i> type implements the empty interface, which makes it

useful for things like containers.

As an example, consider this simple sort algorithm taken from "progs/sort.go":

The code needs only three methods, which we wrap into sort's "Interface":

We can apply "Sort" to any type that implements "Len", "Less", and "Swap".

The "sort" package includes the necessary methods to allow sorting of

arrays of integers, strings, etc.; here's the code for arrays of "int"

Here we see methods defined for non-"struct" types. You can define methods

for any type you define and name in your package.

uses a function in the "sort" package, omitted here for brevity,

to test that the result is sorted.

If we have a new type we want to be able to sort, all we need to do is

to implement the three methods for that type, like this:

Printing

can just say "%d"; "Printf" knows the size and signedness of the

integer and can do the right thing for you. The snippet

prints

In fact, if you're lazy the format "%v" will print, in a simple

appropriate style, any value, even an array or structure. The output of

is

and adds a newline. The output of each of these two lines is identical

to that of the "Printf" call above.

If you have your own type you'd like "Printf" or "Print" to format,

just give it a "String" method that returns a string. The print

the method and if so, use it rather than some other formatting.

Here's a simple example.

Since "*testType" has a "String" method, the

default formatter for that type will use it and produce the output

Here is the first function in "progs/sieve.go":

The "generate" function sends the sequence 2, 3, 4, 5, ... to its

argument channel, "ch", using the binary communications operator "&lt;-".

output, discarding anything divisible by the prime. The unary communications

operator "&lt;-" (receive) retrieves the next value on the channel.

The generator and filters execute concurrently. Go has

its own model of process/threads/light-weight processes/coroutines,

Back to our prime sieve. Here's how the sieve pipeline is stitched

together:

then starts up. As each prime pops out of the channel, a new "filter"

is added to the pipeline and <i>its</i> output becomes the new value

of "ch".

in this style of programming. Here is a variant version

of "generate", from "progs/sieve1.go":

This version does all the setup internally. It creates the output

channel, launches a goroutine running a function literal, and

returns the channel to the caller. It is a factory for concurrent

execution, starting the goroutine and returning its connection.

anonymous function and invoke it on the spot. Notice that the local

variable "ch" is available to the function literal and lives on even

after "generate" returns.

The same change can be made to "filter":

The "sieve" function's main loop becomes simpler and clearer as a

result, and while we're at it let's turn it into a factory too:

Now "main"'s interface to the prime sieve is a channel of primes:

Multiplexing

----

to illustrate the idea. It starts by defining a "request" type, which embeds a channel

that will be used for the reply.

The server will be trivial: it will do simple binary operations on integers. Here's the

code that invokes the operation and responds to the request:

returning a third.

The "server" routine loops forever, receiving requests and, to avoid blocking due to

a long-running operation, starting a goroutine to do the actual work.

We construct a server in a familiar way, starting it and returning a channel

connected to it:

Here's a simple test. It starts a server with an addition operator and sends out

"N" requests without waiting for the replies. Only after all the requests are sent

does it check the results.

One annoyance with this program is that it doesn't shut down the server cleanly; when "main" returns

there are a number of lingering goroutines blocked on communication. To solve this,

we can provide a second, "quit" channel to the server:

It passes the quit channel to the "server" function, which uses it like this:

Inside "server", the "select" statement chooses which of the multiple communications

listed by its cases can proceed. If all are blocked, it waits until one can proceed; if

All that's left is to strobe the "quit" channel

at the end of main:

...

There's a lot more to Go programming and concurrent programming in general but this

quick tour should give you some of the basics.

// Use of this source code is governed by a BSD-style

// license that can be found in the LICENSE file.

// - h2's are made from lines followed by a line "----\n"

// - blank lines become <p> marks (except inside <pre> tags)

// - "quoted strings" become <code>quoted strings</code>

package main

import (

"bufio"

"bytes"

"log"

"os"

)

var (

empty = []byte("")

newline = []byte("\n")

tab = []byte("\t")

quote = []byte(`"`)

sectionMarker = []byte("----\n")

preStart = []byte("<pre>")

preEnd = []byte("</pre>\n")

pp = []byte("<p>\n")

)

func main() {

read()

write()

}

func read() {

b := bufio.NewReader(os.Stdin)

for {

}

}

func write() {

b := bufio.NewWriter(os.Stdout)

for _, line := range lines {

b.Flush()

}

func coalesce(prefix []byte, fold func(i int) (n int, line []byte)) {

j := 0 // output line number goes up by one each loop

for i := 0; i < len(lines); {

lines = lines[0:j]

}

func foldPre(i int) (n int, line []byte) {

buf := new(bytes.Buffer)

for i < len(lines) {

return n, buf.Bytes()

}

func foldTabs(i int) (n int, line []byte) {

buf := new(bytes.Buffer)

buf.WriteString("<pre>\n")

if !bytes.HasPrefix(lines[i], tab) {

break

}

n++

i++

}

return n, buf.Bytes()

}

func headings() {

b := bufio.NewWriter(os.Stdout)

for i, l := range lines {

b.Flush()

}

func paragraphs() {

for i, l := range lines {

if bytes.Equal(l, newline) {

}

}

func quotes() {

for i, l := range lines {

lines[i] = codeQuotes(l)

}

}

func codeQuotes(l []byte) []byte {

if bytes.HasPrefix(l, preStart) {

return l

return buf.Bytes()

}

func trim(l []byte) []byte {

n := len(l)

if n > 0 && l[n-1] == '\n' {

return l

}

func expandTabs(l []byte) []byte {

return bytes.Replace(l, tab, indent, -1)

}

<li>the standard C libraries,

<li>the parser generator Bison,

<li>GNU <tt>make</tt> (version 3.81 or later),

</ul>

</p>

<a href="http://developer.apple.com/TOOLS/Xcode/">Xcode</a>.

</p>

make</code>. If you want to build 32-bit binaries on a 64-bit system you'll

also need the <code>libc6-dev-i386</code> package.

</p>

TXT=${1:-go_tutorial.txt} # input file

HTML=$(basename $TXT .txt).html # output file (basename)

if ! test -w $HTML

then

exit 1

fi

rm -f *.$O

for i in \

helloworld.go \

helloworld3.go \

echo.go \

// Convenience types for common cases

// Convenience wrappers for common cases

func ints() {

data := []int{74, 59, 238, -784, 9845, 959, 905, 0, 0, 42, 7586, -5467984, 7586}

sort.Sort(a)

if !sort.IsSorted(a) {

panic("fail")

func strings() {

data := []string{"monday", "tuesday", "wednesday", "thursday", "friday", "saturday", "sunday"}

sort.Sort(a)

if !sort.IsSorted(a) {

panic("fail")