release.2009-12-09

[Russ Cox]

We've just tagged a new Go release, release.2009-12-09.
As usual, you can update by running:

hg pull
hg update release

(We've changed the way we assign the "release" tag, to avoid
problems people saw with "hg update release" walking backward
in a fresh checkout.)

Since the last release there are two changes to the language:

* new builtin copy(dst, src) copies n = min(len(dst), len(src))
elements to dst from src and returns n. It works correctly
even if dst and src overlap. bytes.Copy is gone.

Convert your programs using:
gofmt -w -r 'bytes.Copy(d, s) -> copy(d, s)' *.go

* new syntax x[lo:] is shorthand for x[lo:len(x)].

Convert your programs using:
gofmt -w -r 'a[b:len(a)] -> a[b:]' *.go


In addition, there have been many smaller fixes and updates:

* 6g/8g/5g: many bug fixes
* 8g: fix 386 floating point stack bug (thanks Charles Dorian)
* all.bash: now works even when $GOROOT has spaces (thanks Sergio Luis
O. B. Correia),
starting to make build work with mingw (thanks Hector Chu),
FreeBSD support (thanks Devon O'Dell)
* big: much faster on 386.
* bytes: new function IndexByte, implemented in assembly
new function Runes (thanks Peter Froehlich),
performance tuning in bytes.Buffer.
* codereview: various bugs fixed
* container/vector: New is gone; just declare a Vector instead.
call Resize to set len and cap.
* cgo: many bug fixes (thanks Eden Li)
* crypto: added MD4 (thanks Chris Lennert),
added XTEA (thanks Adrian O'Grady).
* crypto/tls: basic client
* exp/iterable: new functions (thanks Michael Elkins)
* exp/nacl: native client tree builds again
* fmt: preliminary performance tuning
* go/ast: more powerful Visitor (thanks Roger Peppe)
* gob: a few bug fixes
* gofmt: better handling of standard input, error reporting (thanks
Fazlul Shahriar)
new -r flag for rewriting programs
* gotest: support for Benchmark functions (thanks Trevor Strohman)
* io: ReadFile, WriteFile, ReadDir now in separate package io/ioutil.
* json: new Marshal function (thanks Michael Hoisie),
better white space handling (thanks Andrew Skiba),
decoding into native data structures (thanks Sergey Gromov),
handling of nil interface values (thanks Ross Light).
* math: correct handling of sin/cos of large angles
* net: better handling of Close (thanks Devon O'Dell and Christopher Wedgwood)
support for UDP broadcast (thanks Jonathan Wills),
support for empty packets
* rand: top-level functions now safe to call from multiple goroutines
(thanks Roger Peppe).
* regexp: a few easy optimizations
* rpc: better error handling, a few bug fixes
* runtime: better signal handling on OS X, malloc fixes,
global channel lock is gone.
* sync: RWMutex now allows concurrent readers (thanks Péter Szabó)
* template: can use maps as data (thanks James Meneghello)
* unicode: updated to Unicode 5.2.
* websocket: new package (thanks Fumitoshi Ukai)
* xgb: preliminary X Go Bindings (thanks Tor Andersson)
* xml: fixed crash (thanks Vish Subramanian)
* misc: bbedit config (thanks Anthony Starks),
kate config (thanks Evan Shaw)

My apologies if I have missed anyone's contributions in the above list.
We appreciate all the help.

To see all changes, you can, after updating, run

hg log -r release.2009-11-17:tip

Have fun!

Russ

[peterGo]

The Go Programming Language Specification at golang.org has been
revised to reflect the changes in this release.

[Helmar]

Thank you very much, especially for foo[x:]

-Helmar

On Dec 9, 6:26 pm, Russ Cox <r...@golang.org> wrote:

> ...good stuff...

[Brian Slesinsky]

Regarding the copy() builtin, it seems strange to put the destination
before the source, in the opposite order of cp(1). It seems like this
can easily lead to errors?

- Brian

[ziyu_huang]

If you comes from C world, it won't be that strange.
try man 2 memcpy

[Russ Cox]

It's the same order as io.Copy and assignment (dst = src)
and many other functions. It's true that it's backward from cp(1).

Russ

[Michael Wookey]

2009/12/11 Brian Slesinsky <bsles...@gmail.com>:

> Regarding the copy() builtin, it seems strange to put the destination
> before the source, in the opposite order of cp(1). It seems like this
> can easily lead to errors?

Think of it as..

destination = source

[Brian Slesinsky]

It's also opposite of Java's System.arraycopy().

I suppose it's error-prone either way. It seems like overloading
assignment between slices would be nicer:

dest[] = src[]

dest[1:3] = src[4:6]

On Dec 10, 6:31 pm, Michael Wookey <michaelwoo...@gmail.com> wrote:
> 2009/12/11 Brian Slesinsky <bslesin...@gmail.com>:

[Russ Cox]

> dest[] = src[]
>
> dest[1:3] = src[4:6]

We spent a long time batting around possible syntaxes
for that and didn't come up with anything without problems.
The biggest drawback of the above is that it invites people to
expect dest[1:3] = src[10:15] to work, but that's a very
expensive operation. Also, having bytes.Copy showed that it's
often quite useful to have an operation that takes the
minimum length of the two slices and returns the number
of bytes copied. Using function call syntax makes returning
and using that number very easy.

Russ

[Qtvali]

On Dec 11, 5:38 am, Russ Cox <r...@golang.org> wrote:
> We spent a long time batting around possible syntaxes
> for that and didn't come up with anything without problems.
> The biggest drawback of the above is that it invites people to
> expect dest[1:3] = src[10:15] to work, but that's a very
> expensive operation.

I don't see any definite operation, which should be done there - like
one might think that it runs through src with step 2 over one element
and might think that if it's float array, it does dest[1]=(src[10]+src
[11])/2 etc, but there is no one specific operation for creating array
longer, it more like depends on the specific type of what's inside.

Additionally, I think it's precisely a case where compiler can give an
error - get this error once and won't excpect it any more. Anyway, if
dest[1:3] = src[10:15:2] to copy over one, this would be nice to have,
because for "nondiscrete" arrays like images and function diagrams
this makes sense to go like that, even src[10:15:1.5] would make sense
and make things lot more beautiful for arrays, which have some kind of
middle operation implemented - like having typeof(src).betweenvalue
(firstelement, secondelement, distance) implemented, which would give
int.betweenvalue(4, 8, 0.5) as 6 ...or if I could directly overload int
[].floatindex for that. Then, to show that this kind of expensive
operation is needed with autocalculated step size, src[10:15:] would
be used to put a checkmark that programmer has read a manual, then src
[10::2] would give the same slice with step.

Also, how it is about arrays of several dimensions in Go? I personally
would like very much to have multidimensional slices like dst[1:4,
3:2] to go through 1,3;2,3;3,3;4,3;1,2;2,2;3,3;4,2 - and I would like
to swap things with giving negative step size etc. This would give
some possibilities to make many typical raster image and also vector
space operations simple. If I could have an interface to provide my
own slice types - knowing that they are slow when I have read manual
enough to implement them.

So if I could create an interface for my own int slice (taking int[]
as parent type) and then using those slices together with other
slices. Such overloaded slice would have some signature in it's name
making it clear that it's overloaded and not a real type - like ()
somewhere.

I personally was a little bit frustrated that I couldn't use complex
number as simulated array's index in python - this matrix code is
example about that, one could not use tuple or complex number as index
neither two comma-separated values to have one index pointer. I
personally think that [1:3, 1:5] and [1:3][1:5] should be both
possible and also using tuple as in [[(1,3), (1:5)]] with [(1,3),
(1:5)] being precalculated. Not with basic types, but in overloaded
types and in such way that one doesn't think accidentially that this
is a fast primitive, even if it might be. I would need [1:3, 1:5] for
structures, which don't split into several arrays (own class); [1:3]
[1:5] when there are arrays inside arrays and [[(1,3), (1:5)]] if I
have precalculated positions to take slices from one or more arrays.
Also, if dst[1:4] is a pointer, then doint reverse(dst[1:4]) should
give dst[4:1:-1] as in python. But getting a chance to overload it
gives nicer and more elegant code, I'm sure, and copy is also an
assign operation, which should look instantly recognizable.

I think that major problem with programming language syntax design is
using human's image processing ability in most effective ways. "Copy"
is distinguishable shape as some typesetting specialist would probably
agree, but I think everyone agrees that "=" is more of that and pretty
definitely more optimized in human brain. Thus this syntax might be
worth of tradeoff of getting some error or warning when trying to do a
slow thing.

> Russ