main semantic change is to enforce single argument to panic.
runtime: change to 1-argument panic.
use String method on argument if it has one.
R=ken2, r
CC=golang-dev
https://golang.org/cl/812043
note that sortmain.go has been run through hg gofmt;
only the formatting of the day initializers changed.
i'm happy to revert that formatting if you'd prefer.
stop on error in doc/progs/run
R=r
CC=golang-dev
https://golang.org/cl/850041
the set() method and add() functions. But we rename add() to Var() for consistency.
Also rename FlagValue to Value for simplicity.
Also, delete the check for multiple settings for a flag. This makes it possible to
define a flag that collects values, such as into a slice of strings.
type flagVar []string
func (f *flagVar) String() string {
return fmt.Sprint(v)
}
func (f *flagVar) Set(value string) bool {
if v == nil {
v = make(flagVar, 1)
} else {
nv := make(flagVar, len(v)+1)
copy(nv, v)
v = nv
}
v[len(v)-1] = value
return true
}
var v flagVar
func main() {
flag.Var(&v, "testV", "multiple values build []string")
flag.Parse()
fmt.Printf("v = %v\n", v)
}
R=rsc
CC=golang-dev
https://golang.org/cl/842041
This is a modified version of the open source pprof
from code.google.com/p/google-perftools.
That version is likely to catch up to this one,
but it's still useful to ship our own copy since
we only need the one script from that project,
not all the C++ libraries.
R=r
CC=golang-dev
https://golang.org/cl/783041
In this change I'd like to combine the common code that is
present in syscall_darwin.go and syscall_freebsd.go. I
have three reasons for wanting to do this now:
1. reducing code duplication is nearly always good :-)
2. the duplication will get worse if I duplicate this code
a third time for the NetBSD port I'm working on, which
I need to do almost immediately
3. by making this change all in one lump and ignoring any
commonality with the syscall_linux*.go files the diff
is long but, I think, readable
In future it may be possible to cherry pick functions that
also apply to Linux and put them in (say) syscall_unix.go,
and of course some functions may diverge in future and have
to move out to OS or architecture specific files, but today
I want just the low hanging fruit.
Tested and passed on:
Darwin (Snow Leopard, 10.6): amd64 and 386
FreeBSD (8.0-RELEASE): 386 only(*)
(*) All my virtualisation software has stopped playing nice
with FreeBSD for the moment, so I don't have facilities to
test the amd64 port. As the OS X port is OK and the diff
looks all right to my eyes I shall keep my fingers crossed.
If someone with a FreeBSD/amd64 system cares to test and
report I would be appreciative.
2010-03-27 update: I have replaced my virtualisation software, and have working FreeBSD/i386 and FreeBSD/amd64 virtual machines again.
As I hoped (and expected -- programmers are optimists :-) the code built and passed all but the two currently known to fail tests on FreeBSD/amd64. I rechecked FreeBSD/i386 too: same results.
R=rsc
CC=golang-dev
https://golang.org/cl/751041
- new heuristic: if both the opening { and closing } braces are on the
same line, and the function body doesn't contain comments or is other-
wise too long (e.g. signature too long), it is formatted as a one-line
function
- related cleanups along the way
- gofmt -w src misc led to no additional changes as expected
R=rsc, rsc1
CC=golang-dev, ken2, r
https://golang.org/cl/758041
test/64bit.go: segfaults on sheevaplug(armv5)
The following have long runtimes when GC is on.
Sample run time in seconds for android emulator
and sheevaplug
test/stack.go: 4934s 1780s
test/ken/chan.go: 860s 296s
test/gc1.go: 218s 69s
R=rsc, kaib
CC=golang-dev
https://golang.org/cl/749041
