Age | Commit message (Collapse) | Author | Files | Lines |
|
R=r
CC=golang-dev
http://codereview.appspot.com/872045
|
|
$ godoc xml | grep Copy\(\)
func (c CharData) Copy() CharData
func (c Comment) Copy() Comment
func (d Directive) Copy() Directive
func (p ProcInst) Copy() ProcInst
func (e StartElement) Copy() StartElement
--------------------------------------------
$ godoc -src xml | grep Copy\(\)
func (c CharData) Copy() CharData
--------------------------------------------
$ godoc -src xml Copy
func (c CharData) Copy() CharData { return CharData(makeCopy(c)) }
--------------------------------------------
The command "godoc -src pkg_name" should output the interface of the named package, but it excludes all duplicate entries. Also the command "godoc -src pkg_name method_name" will output the source code only for one method even if there are more of them with the same name in the same package. This patch set fixes this issue.
R=gri
CC=golang-dev
http://codereview.appspot.com/883051
Committer: Robert Griesemer <gri@golang.org>
|
|
R=rsc
CC=golang-dev
http://codereview.appspot.com/912041
|
|
fmt.Printf("float32 %f\n", float32(1234.56789))
fmt.Printf("float64 %f\n", float64(1234.56789))
->
float32 1234.567871
float64 1234.567890
this is a snapshot. extended instruction support, corner cases
and fixes coming in subseuent cls.
R=rsc
CC=dpx, golang-dev
http://codereview.appspot.com/876045
|
|
R=rsc
CC=golang-dev
http://codereview.appspot.com/840045
|
|
R=r
CC=golang-dev
http://codereview.appspot.com/920041
|
|
R=r
CC=golang-dev
http://codereview.appspot.com/854048
|
|
R=rsc
CC=golang-dev
http://codereview.appspot.com/815044
Committer: Russ Cox <rsc@golang.org>
|
|
R=rsc
CC=golang-dev
http://codereview.appspot.com/851045
Committer: Russ Cox <rsc@golang.org>
|
|
R=rsc
CC=golang-dev
http://codereview.appspot.com/915041
Committer: Russ Cox <rsc@golang.org>
|
|
much rewriting and improving, but it's still experimental.
R=rsc
CC=golang-dev
http://codereview.appspot.com/875045
|
|
R=rsc
CC=golang-dev
http://codereview.appspot.com/824049
|
|
R=gri, adg
CC=golang-dev, r, rsc
http://codereview.appspot.com/857048
Committer: Andrew Gerrand <adg@golang.org>
|
|
- don't log normal EOF
- fix ServeConn to block as documented
R=rsc, msolo
CC=golang-dev
http://codereview.appspot.com/886043
|
|
R=ken2
CC=golang-dev
http://codereview.appspot.com/891050
|
|
R=rsc, r
CC=golang-dev
http://codereview.appspot.com/891048
Committer: Rob Pike <r@golang.org>
|
|
fmt.Printf("%b", int8(-1)) prints 64 ones instead of 8.
This happens only for signed integers (int8, in16 and int32). I guess it's because of the way the conversion between integer types works. From go spec: "Conversions between integer types. If the value is a signed quantity, it is sign extended to implicit infinite precision ....". And there are several conversions to int64 and uint64 in the fmt package. This pathch solves only half of the problem. On a 32 bit system, an fmt.Printf("%b", int(-1)) should still print 64 ones.
R=golang-dev, r
CC=golang-dev
http://codereview.appspot.com/891049
Committer: Rob Pike <r@golang.org>
|
|
R=rsc
CC=golang-dev
http://codereview.appspot.com/888045
Committer: Russ Cox <rsc@golang.org>
|
|
R=ken2
CC=golang-dev
http://codereview.appspot.com/840043
|
|
R=ken2
CC=golang-dev
http://codereview.appspot.com/902044
|
|
R=ken2
CC=golang-dev
http://codereview.appspot.com/883049
|
|
R=golang-dev, rsc
CC=golang-dev
http://codereview.appspot.com/849049
Committer: Russ Cox <rsc@golang.org>
|
|
R=rsc
CC=golang-dev
http://codereview.appspot.com/901042
Committer: Russ Cox <rsc@golang.org>
|
|
R=rsc, r
CC=golang-dev
http://codereview.appspot.com/903044
Committer: Rob Pike <r@golang.org>
|
|
R=rsc, r
CC=golang-dev
http://codereview.appspot.com/822047
Committer: Rob Pike <r@golang.org>
|
|
R=rsc, r
CC=golang-dev
http://codereview.appspot.com/823045
Committer: Rob Pike <r@golang.org>
|
|
R=gri, r
CC=golang-dev, rsc
http://codereview.appspot.com/819042
Committer: Rob Pike <r@golang.org>
|
|
R=r
CC=golang-dev
http://codereview.appspot.com/811044
|
|
equivalents TrimFunc, TrimLeftFunc, TrimRightFunc
R=rsc, r
CC=golang-dev
http://codereview.appspot.com/799048
Committer: Russ Cox <rsc@golang.org>
|
|
remove internal functions from traces in gopprof instead.
R=r
CC=golang-dev
http://codereview.appspot.com/855046
|
|
R=r
CC=golang-dev
http://codereview.appspot.com/909041
|
|
R=rsc
CC=golang-dev
http://codereview.appspot.com/908041
Committer: Russ Cox <rsc@golang.org>
|
|
R=rsc
CC=golang-dev
http://codereview.appspot.com/831045
Committer: Russ Cox <rsc@golang.org>
|
|
This is required to make cgo export work on Darwin. Note that
this corrects the stack alignment when calling initcgo to that
required by gcc on amd64.
R=rsc
CC=golang-dev
http://codereview.appspot.com/907041
|
|
The new //export comment marks a Go function as callable from
C. The syntax is "//export NAME" where NAME is the name of
the function as seen from C. If such a comment is seen, cgo
will generate two new files: _cgo_export.h and _cgo_export.c.
The _cgo_export.h file provides declarations which C code may
use to call Go functions. The _cgo_export.c file contains
wrappers, and is to be compiled with gcc.
The changes to Make.pkg support using this from a Go Makefile,
though it could probably be more convenient.
R=rsc
CC=golang-dev
http://codereview.appspot.com/853042
|
|
These functions are used to call from a C function back to a
Go function. This only includes 386 support.
R=rsc
CC=golang-dev
http://codereview.appspot.com/834045
|
|
R=rsc
CC=golang-dev
http://codereview.appspot.com/857045
|
|
R=rsc
CC=golang-dev
http://codereview.appspot.com/902042
|
|
R=golang-dev, r
CC=golang-dev
http://codereview.appspot.com/872043
Committer: Rob Pike <r@golang.org>
|
|
R=adg
CC=golang-dev
http://codereview.appspot.com/867046
|
|
tested on linux/amd64, linux/386, linux/arm, darwin/amd64, darwin/386.
freebsd untested; will finish in a separate CL.
for now all the panics are errorStrings.
richer structures can be added as necessary
once the mechanism is shaked out.
R=r
CC=golang-dev
http://codereview.appspot.com/906041
|
|
when garbage collector sees recovering goroutine
Fixes issue 711.
R=r
CC=golang-dev
http://codereview.appspot.com/869045
|
|
Could not take a signal on threads other than the main thread.
If you look at the spinning binary with dtrace, you can see a
fault happening over and over:
$ dtrace -n '
fbt::user_trap:entry /execname=="boot32" && self->count < 10/
{
self->count++;
printf("%s %x %x %x %x", probefunc, arg1, arg2, arg3, arg4);
stack();
tracemem(arg4, 256);
}'
dtrace: description 'fbt::user_trap:entry ' matched 1 probe
CPU ID FUNCTION:NAME
1 17015 user_trap:entry user_trap 0 10 79af0a0 79af0a0
mach_kernel`lo_alltraps+0x12a
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
0: 0e 00 00 00 37 00 00 00 00 00 00 00 1f 00 00 00 ....7...........
10: 1f 00 00 00 a8 33 00 00 00 00 00 01 00 00 00 00 .....3..........
20: 98 ba dc fe 07 09 00 00 00 00 00 00 98 ba dc fe ................
30: 06 00 00 00 0d 00 00 00 34 00 00 00 9e 1c 00 00 ........4.......
40: 17 00 00 00 00 02 00 00 ac 30 00 00 1f 00 00 00 .........0......
50: 00 00 00 00 00 00 00 00 0d 00 00 00 e0 e6 29 00 ..............).
60: 34 00 00 00 00 00 00 00 9e 1c 00 00 00 00 00 00 4...............
70: 17 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 ................
80: ac 30 00 00 00 00 00 00 1f 00 00 00 00 00 00 00 .0..............
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
a0: 48 00 00 00 10 00 00 00 85 00 00 00 a0 f2 29 00 H.............).
b0: 69 01 00 02 00 00 00 00 e6 93 04 82 ff 7f 00 00 i...............
c0: 2f 00 00 00 00 00 00 00 06 02 00 00 00 00 00 00 /...............
d0: 78 ee 42 01 01 00 00 00 1f 00 00 00 00 00 00 00 x.B.............
e0: 00 ed 9a 07 00 00 00 00 00 00 00 00 00 00 00 00 ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
...
The memory dump shows a 32-bit exception frame:
x86_saved_state32
gs = 0x37
fs = 0
es = 0x1f
ds = 0x1f
edi = 0x33a8
esi = 0x01000000
ebp = 0
cr2 = 0xfedcba98
ebx = 0x0907
edx = 0
ecx = 0xfedcba98
eax = 0x06
trapno = 0x0d
err = 0x34
eip = 0x1c9e
cs = 0x17
efl = 0x0200
uesp = 0x30ac
ss = 0x1f
The cr2 of 0xfedcba98 is the address that the new thread read
to cause the fault, but note that the trap is now a GP fault with
error code 0x34, meaning it's moved past the cr2 problem and on
to an invaild segment selector. The 0x34 is suspiciously similar
to the 0x37 in gs, and sure enough, OS X forces gs to have
that value in the signal handler, and if your thread hasn't set
up that segment (known as USER_CTHREAD), you'll fault on the IRET
into the signal handler and never be able to handle a signal.
The kernel bug is that it forces segment 0x37 without making sure
it is a valid segment. Leopard also forced 0x37 but had the courtesy
to set it up first.
Since OS X requires us to set up that segment (using the
thread_fast_set_cthread_self system call), we might as well
use it instead of the more complicated i386_set_ldt call to
set up our per-OS thread storage.
Also add some more zeros to bsdthread_register for new arguments
in Snow Leopard (apparently unnecessary, but being careful).
Fixes issue 510.
R=r
CC=golang-dev
http://codereview.appspot.com/824046
|
|
Added Signbit(), revised Copysign()
R=rsc
CC=golang-dev
http://codereview.appspot.com/822045
Committer: Russ Cox <rsc@golang.org>
|
|
Avoids spurious wakeups during other sleeping by that goroutine.
Fixes issue 711.
R=r
CC=golang-dev
http://codereview.appspot.com/902041
|
|
Fixes issue 677.
R=rsc
CC=golang-dev
http://codereview.appspot.com/834046
|
|
channel recv data.
R=rsc
CC=golang-dev
http://codereview.appspot.com/896041
|
|
data just read from the channel.
this will make it easier to
recognize when to garbage
collect and finalize.
R=rsc
CC=golang-dev
http://codereview.appspot.com/882043
|
|
The cycle is *netFD -> cw chanl *netFD in struct ->
same *netFD in channel read buffer.
Because channels are finalized, the cycle makes them
uncollectable. A better fix is to make channels not
finalized anymore, and that will happen, but this is
an easy, reasonable workaround until then.
Another good fix would be to zero the channel receive
buffer entry after the receive. That too will happen.
R=r
CC=golang-dev
http://codereview.appspot.com/875043
|
|
R=rsc
CC=golang-dev
http://codereview.appspot.com/864044
|