mirror of
https://github.com/golang/go.git
synced 2026-01-30 23:52:05 +03:00
Compare commits
2 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
6174b5e21e | ||
|
|
4081aa1277 |
10
.gitattributes
vendored
10
.gitattributes
vendored
@@ -1,10 +0,0 @@
|
||||
# Treat all files in the Go repo as binary, with no git magic updating
|
||||
# line endings. Windows users contributing to Go will need to use a
|
||||
# modern version of git and editors capable of LF line endings.
|
||||
#
|
||||
# We'll prevent accidental CRLF line endings from entering the repo
|
||||
# via the git-review gofmt checks.
|
||||
#
|
||||
# See golang.org/issue/9281
|
||||
|
||||
* -text
|
||||
20
.github/ISSUE_TEMPLATE
vendored
20
.github/ISSUE_TEMPLATE
vendored
@@ -1,20 +0,0 @@
|
||||
Please answer these questions before submitting your issue. Thanks!
|
||||
|
||||
### What version of Go are you using (`go version`)?
|
||||
|
||||
|
||||
### What operating system and processor architecture are you using (`go env`)?
|
||||
|
||||
|
||||
### What did you do?
|
||||
If possible, provide a recipe for reproducing the error.
|
||||
A complete runnable program is good.
|
||||
A link on play.golang.org is best.
|
||||
|
||||
|
||||
### What did you expect to see?
|
||||
|
||||
|
||||
### What did you see instead?
|
||||
|
||||
|
||||
7
.github/PULL_REQUEST_TEMPLATE
vendored
7
.github/PULL_REQUEST_TEMPLATE
vendored
@@ -1,7 +0,0 @@
|
||||
Please do not send pull requests to the golang/* repositories.
|
||||
|
||||
We do, however, take contributions gladly.
|
||||
|
||||
See https://golang.org/doc/contribute.html
|
||||
|
||||
Thanks!
|
||||
45
.gitignore
vendored
45
.gitignore
vendored
@@ -1,45 +0,0 @@
|
||||
.DS_Store
|
||||
*.[56789ao]
|
||||
*.a[56789o]
|
||||
*.so
|
||||
*.pyc
|
||||
._*
|
||||
.nfs.*
|
||||
[56789a].out
|
||||
*~
|
||||
*.orig
|
||||
*.rej
|
||||
*.exe
|
||||
.*.swp
|
||||
core
|
||||
*.cgo*.go
|
||||
*.cgo*.c
|
||||
_cgo_*
|
||||
_obj
|
||||
_test
|
||||
_testmain.go
|
||||
build.out
|
||||
test.out
|
||||
doc/articles/wiki/*.bin
|
||||
misc/cgo/life/run.out
|
||||
misc/cgo/stdio/run.out
|
||||
misc/cgo/testso/main
|
||||
src/cmd/cgo/zdefaultcc.go
|
||||
src/cmd/go/zdefaultcc.go
|
||||
src/cmd/go/zosarch.go
|
||||
src/cmd/internal/obj/zbootstrap.go
|
||||
src/go/build/zcgo.go
|
||||
src/go/doc/headscan
|
||||
src/runtime/internal/sys/zversion.go
|
||||
src/unicode/maketables
|
||||
src/*.*/
|
||||
test/pass.out
|
||||
test/run.out
|
||||
test/times.out
|
||||
test/garbage/*.out
|
||||
goinstall.log
|
||||
last-change
|
||||
VERSION.cache
|
||||
|
||||
bin/
|
||||
pkg/
|
||||
65
.hgignore
Normal file
65
.hgignore
Normal file
@@ -0,0 +1,65 @@
|
||||
syntax:glob
|
||||
.DS_Store
|
||||
.git
|
||||
.gitignore
|
||||
*.[568ao]
|
||||
*.a[568o]
|
||||
*.so
|
||||
*.pyc
|
||||
._*
|
||||
.nfs.*
|
||||
[568a].out
|
||||
*~
|
||||
*.orig
|
||||
*.rej
|
||||
*.exe
|
||||
.*.swp
|
||||
core
|
||||
*.cgo*.go
|
||||
*.cgo*.c
|
||||
_cgo_*
|
||||
_obj
|
||||
_test
|
||||
_testmain.go
|
||||
build.out
|
||||
test.out
|
||||
doc/tmpltohtml
|
||||
doc/articles/wiki/*.bin
|
||||
misc/cgo/life/run.out
|
||||
misc/cgo/stdio/run.out
|
||||
misc/cgo/testso/main
|
||||
misc/dashboard/builder/builder
|
||||
misc/goplay/goplay
|
||||
misc/osx/*.pkg
|
||||
misc/osx/*.dmg
|
||||
src/cmd/6a/6a
|
||||
src/cmd/?a/y.output
|
||||
src/cmd/?l/enam.c
|
||||
src/cmd/cc/y.output
|
||||
src/cmd/dist/dist.dSYM
|
||||
src/cmd/gc/mkbuiltin1
|
||||
src/cmd/gc/opnames.h
|
||||
src/cmd/gc/y.output
|
||||
src/pkg/exp/norm/maketables
|
||||
src/pkg/exp/norm/maketesttables
|
||||
src/pkg/exp/norm/normregtest
|
||||
src/pkg/exp/ebnflint/ebnflint
|
||||
src/pkg/go/doc/headscan
|
||||
src/pkg/runtime/goc2c
|
||||
src/pkg/runtime/mkversion
|
||||
src/pkg/runtime/z*
|
||||
src/pkg/unicode/maketables
|
||||
src/pkg/*.*/
|
||||
test/pass.out
|
||||
test/run.out
|
||||
test/times.out
|
||||
test/garbage/*.out
|
||||
goinstall.log
|
||||
last-change
|
||||
VERSION.cache
|
||||
|
||||
syntax:regexp
|
||||
^bin/
|
||||
^pkg/
|
||||
^src/cmd/(.*)/6?\1$
|
||||
^.*/core.[0-9]*$
|
||||
110
.hgtags
Normal file
110
.hgtags
Normal file
@@ -0,0 +1,110 @@
|
||||
1f0a01c93d305f1ab636c68b67346659c5b957f7 weekly.2009-11-06
|
||||
64e703cb307da550861fe740ff70a482a2c14819 weekly.2009-11-10
|
||||
b51fd2d6c16034480f26c96ba32a11c598e4638e weekly.2009-11-10.1
|
||||
cb140bac9ab0fd9f734ee443cea9ebadc9c99737 weekly.2009-11-12
|
||||
d1b75410b793309532352a6fb6b44453f052f3f4 weekly.2009-11-17
|
||||
e205103b02e7393d4719df5faac2dac808234d3f weekly.2009-12-07
|
||||
3a47d2e3882bb12129de05382a2c131bb0c00964 weekly.2009-12-09
|
||||
a6fcf4303b0a92cce4011556b1c96044252d93af weekly.2009-12-22
|
||||
3887d4d81bca78b63d620985d93f1cc06c063871 weekly.2010-01-05
|
||||
40dd722155f6d0c83fa572c1a5abf7c6ff35049f weekly.2010-01-13
|
||||
0a2770db06efe92b08b5c6f30e14b7e8db012538 weekly.2010-01-27
|
||||
db4262ce882d8445764312d41547ee8f11a7f7a9 weekly.2010-02-04
|
||||
53fec18b83e2b93baafba4733b59bb86b8c1988e weekly.2010-02-17
|
||||
4a0661b86e50eae734dbe43ed1312c4a0304676b weekly.2010-02-23
|
||||
a215d03e7ee1013b2abe3f1e2c84457ec51c68e4 weekly.2010-03-04
|
||||
194d473264c1a015803d07bed200e0c312aca43e weekly.2010-03-15
|
||||
9482fde11a02ffd57ba0561dc8a4ac338061a3ae weekly.2010-03-22
|
||||
57380d620ee6b65eb88da1c52784b62c94d7e72e weekly.2010-03-30
|
||||
f98f784927abc56a61501eba0cf225966f2b0142 weekly.2010-04-13
|
||||
6cc6c0d85fc3234fc0a5ec0a8777aa9d59d05ae8 weekly.2010-04-27
|
||||
17ded5ad443b41ac05924864798f1bd8750da344 weekly.2010-05-04
|
||||
a85ad0a640154b5d33626ad8ea15ed17e3828178 weekly.2010-05-27
|
||||
f776656df34c009f2aad142bf7b34a778404acd1 weekly.2010-06-09
|
||||
113ec27f29f18825444f6f8a3cdc156c1df28e87 weekly.2010-06-21
|
||||
b761e0299e9bf66298778cf170b0f64216e3cf7d weekly.2010-07-01
|
||||
5992bf56aa72efcea87d8dff14985fc8fcc68575 weekly.2010-07-14
|
||||
db904d88dc0ebf6ee5b55e44088915695c1223ee weekly.2010-07-29
|
||||
8884f7b4c7750481ed246c249db47b61fe752c56 weekly.2010-08-04
|
||||
07d3a97302be88af68acff34c8a089589da21d18 weekly.2010-08-11
|
||||
18926649cda7498b8aa539b3a611abcff548f09f weekly.2010-08-25
|
||||
92fcf05736e8565a485adc52da1894270e06ed09 weekly.2010-09-06
|
||||
9329773e204fed50ec686ee78cc715b624bf1b1d weekly.2010-09-15
|
||||
1eec33c03bceef5d7607ea4636185f7bf773e0e4 weekly.2010-09-22
|
||||
c2b8c9f13fb8ad2b56920d9da2928c5314ebf725 weekly.2010-09-29
|
||||
7c2e97710bf49cdbe388260958a6674afefb6c0f weekly.2010-10-13
|
||||
ca4f9687cec0b9c4732afd57b8c2786c7fe242de weekly.2010-10-13.1
|
||||
79997f0e5823ee9d13a34ca9971a9d8811df1c4a weekly.2010-10-20
|
||||
4d5b0816392116d3a3452bb275b6dab6c6456278 weekly.2010-10-27
|
||||
c627e23260c7ddf4a1fcda6ef3197c98fa22551d weekly.2010-11-02
|
||||
a7800e20064a39585aa3ee339c2b7454ae1ce6d5 weekly.2010-11-10
|
||||
c5287468fcff0f8a7bb9ffaece2a4863e7e5d83e weekly.2010-11-23
|
||||
f7e692dc29b02fba8e5d59b967880a347b53607c weekly.2010-12-02
|
||||
56e39c466cc1c49b587eb56dc2166d61151637df weekly.2010-12-08
|
||||
26f4898dc1ca18bb77f9968aca23773637e34f0d weekly.2010-12-15
|
||||
61b2c52b0d2246430395f2869d7b34e565333cf5 weekly.2010-12-15.1
|
||||
51c777dbccb9f537ebffb99244f521c05bf65df6 weekly.2010-12-22
|
||||
8eeee945e358f19405e81792db0e16a1cad14bc0 weekly.2011-01-06
|
||||
514c7ba501a1dd74d69ea2d0a2b4116802ada2b5 weekly.2011-01-12
|
||||
72f9cb714f08b98c6a65ab2f2256fad6bb16967a weekly.2011-01-19
|
||||
d8ba80011a986470a54e5262ec125105aa4adc34 weekly.2011-01-20
|
||||
5b98b59dd37292e36afb24babb2d22758928e13d weekly.2011-02-01
|
||||
867d37fb41a4d96ab7a6202fd6ad54c345494051 weekly.2011-02-01.1
|
||||
b2be017f91348d5f8cbaf42f77a99fc905044b59 weekly.2011-02-15
|
||||
322350d6fdbf11d9c404d6fc766349d824031339 weekly.2011-02-24
|
||||
21848430d60167817ca965c813a2118068ca660f weekly.2011-03-07
|
||||
c5c62aeb6267e124cf05f9622e28dbd0dc6b971d weekly.2011-03-07.1
|
||||
c5c62aeb6267e124cf05f9622e28dbd0dc6b971d release.r56
|
||||
3b4e9c85b643a35860805718323b05186dd7f235 weekly.2011-03-15
|
||||
b84e614e25161f626a6102813c41a80a15e3a625 weekly.2011-03-28
|
||||
cd89452cfea3d125aaf75a1ec8004e2f6a868d38 weekly.2011-04-04
|
||||
d6903b7fbff40c13ee7ea3177c0ae54c7f89d2e6 weekly.2011-04-13
|
||||
2f0fa51fa2da6ab50fcebba526326153da8ed999 weekly.2011-04-27
|
||||
8493bb64e5592bd20c0e60e78e7f8052c1276fcf release.r57
|
||||
95d2ce135523c96c4cea049af94ce76dd8c7d981 release.r57.1
|
||||
c98449d685d2b6aa1df9bfd2e1cce9307efb6e00 weekly.2011-05-22
|
||||
3418f22c39eb8299053ae681199ee90f8cd29c6d weekly.2011-06-02
|
||||
c81944152e973a917797679055b8fcdc70fbc802 weekly.2011-06-09
|
||||
9d7967223815ef6415ff01aa0fe6ad38cdbc7810 release.r57.2
|
||||
dac76f0b1a18a5de5b54a1dc0b231aceaf1c8583 weekly.2011-06-16
|
||||
541c445d6c1353fbfa39df7dc4b0eb27558d1fc1 weekly.2011-06-23
|
||||
1b38d90eebcddefabb3901c5bb63c7e2b04a6ec5 release.r58
|
||||
16bfa562ba767aefd82e598da8b15ee4729e23b0 weekly.2011-07-07
|
||||
d292bc7886682d35bb391bf572be28656baee12d release.r58.1
|
||||
3c21f37b25a3f7a1726265c5339c8a7b0b329336 weekly.2011-07-19
|
||||
bb28251f6da4aca85658582c370c7df89d34efd4 weekly.2011-07-29
|
||||
d5785050f61d973fc36775f7bd2e26689529cb3e release.r59
|
||||
c17ce5ec06b4bd5cf6e7ff2ceb0a60c2e40e0b17 weekly.2011-08-10
|
||||
6eb2b9dbe489acb57a2bfc1de31ec2239ed94326 weekly.2011-08-17
|
||||
c934f6f5fe8b30b4b3210ee3f13669e6e4670c32 weekly.2011-09-01
|
||||
c77997547d546c36c7b969586a36de7ceda74e33 weekly.2011-09-07
|
||||
b0819469a6df6029a27192fe7b19a73d97404c63 release.r60
|
||||
8a09ce0cefc64deab4e6d1ed59a08a53e879bbee weekly.2011-09-16
|
||||
fd30c132d1bdeb79f8f111cb721fb1c78b767b27 release.r60.1
|
||||
d7322ae4d055a4cf3efaf842d0717a41acd85bac weekly.2011-09-21
|
||||
32a5db19629897641b2d488de4d1b998942ef80e release.r60.2
|
||||
3bdabf483805fbf0c7ef013fd09bfd6062b9d3f2 weekly.2011-10-06
|
||||
c1702f36df0397c19fc333571a771666029aa37e release.r60.3
|
||||
acaddf1cea75c059d19b20dbef35b20fb3f38954 release.r58.2
|
||||
6d7136d74b656ba6e1194853a9486375005227ef weekly.2011-10-18
|
||||
941b8015061a0f6480954821dd589c60dfe35ed1 weekly.2011-10-25
|
||||
7c1f789e6efd153951e85e3f28722fc69efc2af2 weekly.2011-10-26
|
||||
e69e528f2afc25a8334cfb9359fa4fcdf2a934b6 weekly.2011-11-01
|
||||
780c85032b174c9d4b42adf75d82bc85af7d78d1 weekly.2011-11-02
|
||||
f4397ad6e87c7ce5feac9b01686f1ebd6cbaac4e weekly.2011-11-08
|
||||
2f4482b89a6b5956828872137b6b96636cd904d3 weekly.2011-11-09
|
||||
b4a91b6933748db1a7150c06a1b55ad506e52906 weekly.2011-11-18
|
||||
80db2da6495a20ddff8305c236825811db8c8665 weekly.2011-12-01
|
||||
0beb796b4ef8747af601ed5ea6766d5b1340086b weekly.2011-12-02
|
||||
0c39eee85b0d1606b79c8ebcdeb3b67ed5849e39 weekly.2011-12-06
|
||||
82fdc445f2ff2c85043446eb84a19cc999dfcb95 weekly.2011-12-14
|
||||
4a82689277582a2a60f006e3f158985f2f8d1da3 weekly.2011-12-22
|
||||
354b17404643c0f1a710bdc48927dff02f203ae3 weekly.2012-01-15
|
||||
9f2be4fbbf690b9562c6e98b91daa0003f0913c7 weekly.2012-01-20
|
||||
1107a7d3cb075836387adfab5ce56d1b3e56637d weekly.2012-01-27
|
||||
52ba9506bd993663a0a033c2bd68699e25d061ab weekly.2012-02-07
|
||||
43cf9b39b6477d3144b0353ee91096e55db6107f weekly.2012-02-14
|
||||
96bd78e7d35e892113bdfa1bdc392d3a5f2e644b weekly.2012-02-22
|
||||
f4470a54e6dbcdd52d8d404e12e4754adcd2c948 weekly.2012-03-04
|
||||
3cdba7b0650c6c906ef3e782654f61701abd7dd2 weekly.2012-03-13
|
||||
bce220d0377405146527ab9478867cbc572a6886 weekly.2012-03-22
|
||||
659
AUTHORS
659
AUTHORS
@@ -2,851 +2,206 @@
|
||||
# This file is distinct from the CONTRIBUTORS files.
|
||||
# See the latter for an explanation.
|
||||
|
||||
# Names should be added to this file as one of
|
||||
# Organization's name
|
||||
# Individual's name <submission email address>
|
||||
# Individual's name <submission email address> <email2> <emailN>
|
||||
# See CONTRIBUTORS for the meaning of multiple email addresses.
|
||||
# Names should be added to this file as
|
||||
# Name or Organization <email address>
|
||||
# The email address is not required for organizations.
|
||||
|
||||
# Please keep the list sorted.
|
||||
|
||||
A Medium Corporation
|
||||
Aamir Khan <syst3m.w0rm@gmail.com>
|
||||
Aaron France <aaron.l.france@gmail.com>
|
||||
Aaron Torres <tcboox@gmail.com>
|
||||
Abe Haskins <abeisgreat@abeisgreat.com>
|
||||
Abhinav Gupta <abhinav.g90@gmail.com>
|
||||
Adrian Nos <nos.adrian@gmail.com>
|
||||
Adrian O'Grady <elpollouk@gmail.com>
|
||||
Adrien Bustany <adrien-xx-google@bustany.org>
|
||||
Aécio Júnior <aeciodantasjunior@gmail.com>
|
||||
Ahmed Waheed Moanes <oneofone@gmail.com>
|
||||
Ahmy Yulrizka <yulrizka@gmail.com>
|
||||
Aiden Scandella <ai@uber.com>
|
||||
Ainar Garipov <gugl.zadolbal@gmail.com>
|
||||
Akihiro Suda <suda.kyoto@gmail.com>
|
||||
Akshat Kumar <seed@mail.nanosouffle.net>
|
||||
Alan Shreve <alan@inconshreveable.com>
|
||||
Albert Nigmatzianov <albertnigma@gmail.com>
|
||||
Albert Strasheim <fullung@gmail.com>
|
||||
Alberto Bertogli <albertito@blitiri.com.ar>
|
||||
Alberto Donizetti <alb.donizetti@gmail.com>
|
||||
Alberto García Hierro <alberto@garciahierro.com> <alberto.garcia.hierro@gmail.com>
|
||||
Aleksandar Dezelin <dezelin@gmail.com>
|
||||
Alessandro Arzilli <alessandro.arzilli@gmail.com>
|
||||
Alex A Skinner <alex@lx.lc>
|
||||
Alex Brainman <alex.brainman@gmail.com>
|
||||
Alex Browne <stephenalexbrowne@gmail.com>
|
||||
Alex Carol <alex.carol.c@gmail.com>
|
||||
Alex Jin <toalexjin@gmail.com>
|
||||
Alex Plugaru <alex@plugaru.org> <alexandru.plugaru@gmail.com>
|
||||
Alex Schroeder <alex@gnu.org>
|
||||
Alex Sergeyev <abc@alexsergeyev.com>
|
||||
Alexander Demakin <alexander.demakin@gmail.com>
|
||||
Alexander Döring <email@alexd.ch>
|
||||
Alexander Larsson <alexander.larsson@gmail.com>
|
||||
Alexander Morozov <lk4d4math@gmail.com>
|
||||
Alexander Neumann <alexander@bumpern.de>
|
||||
Alexander Orlov <alexander.orlov@loxal.net>
|
||||
Alexander Reece <awreece@gmail.com>
|
||||
Alexander Surma <surma@surmair.de>
|
||||
Alexander Zhavnerchik <alex.vizor@gmail.com>
|
||||
Alexander Zolotov <goldifit@gmail.com>
|
||||
Alexandre Cesaro <alexandre.cesaro@gmail.com>
|
||||
Alexandre Normand <alexandre.normand@gmail.com>
|
||||
Alexei Sholik <alcosholik@gmail.com>
|
||||
Alexey Borzenkov <snaury@gmail.com>
|
||||
Alexey Palazhchenko <alexey.palazhchenko@gmail.com>
|
||||
Aliaksandr Valialkin <valyala@gmail.com>
|
||||
Alif Rachmawadi <subosito@gmail.com>
|
||||
Allan Simon <allan.simon@supinfo.com>
|
||||
Alok Menghrajani <alok.menghrajani@gmail.com>
|
||||
Amazon.com, Inc
|
||||
Amir Mohammad Saied <amir@gluegadget.com>
|
||||
Amrut Joshi <amrut.joshi@gmail.com>
|
||||
Andre Nathan <andrenth@gmail.com>
|
||||
Andreas Auernhammer <aead@mail.de>
|
||||
Andreas Litt <andreas.litt@gmail.com>
|
||||
Andrei Korzhevskii <a.korzhevskiy@gmail.com>
|
||||
Andrei Vieru <euvieru@gmail.com>
|
||||
Andrew Balholm <andybalholm@gmail.com>
|
||||
Andrew Bonventre <andybons@chromium.org>
|
||||
Andrew Bursavich <abursavich@gmail.com>
|
||||
Andrew Ekstedt <andrew.ekstedt@gmail.com>
|
||||
Andrew Etter <andrew.etter@gmail.com>
|
||||
Andrew Harding <andrew@spacemonkey.com>
|
||||
Andrew Lutomirski <andy@luto.us>
|
||||
Andrew Pogrebnoy <absourd.noise@gmail.com>
|
||||
Andrew Pritchard <awpritchard@gmail.com>
|
||||
Andrew Radev <andrey.radev@gmail.com>
|
||||
Andrew Skiba <skibaa@gmail.com>
|
||||
Andrew Szeto <andrew@jabagawee.com>
|
||||
Andrew Wilkins <axwalk@gmail.com>
|
||||
Andrew Williams <williams.andrew@gmail.com>
|
||||
Andrey Mirtchovski <mirtchovski@gmail.com>
|
||||
Andrey Petrov <andrey.petrov@shazow.net>
|
||||
Andriy Lytvynov <lytvynov.a.v@gmail.com>
|
||||
Andy Balholm <andy@balholm.com>
|
||||
Andy Davis <andy@bigandian.com>
|
||||
Andy Maloney <asmaloney@gmail.com>
|
||||
Anfernee Yongkun Gui <anfernee.gui@gmail.com>
|
||||
Angelo Bulfone <mbulfone@gmail.com>
|
||||
Anh Hai Trinh <anh.hai.trinh@gmail.com>
|
||||
Anmol Sethi <anmol@aubble.com>
|
||||
Anschel Schaffer-Cohen <anschelsc@gmail.com>
|
||||
Anthony Canino <anthony.canino1@gmail.com>
|
||||
Anthony Eufemio <anthony.eufemio@gmail.com>
|
||||
Anthony Martin <ality@pbrane.org>
|
||||
Anthony Starks <ajstarks@gmail.com>
|
||||
Apisak Darakananda <pongad@gmail.com>
|
||||
Aram Hăvărneanu <aram@mgk.ro>
|
||||
Areski Belaid <areski@gmail.com>
|
||||
Arlo Breault <arlolra@gmail.com>
|
||||
ARM Ltd.
|
||||
Arnaud Ysmal <arnaud.ysmal@gmail.com>
|
||||
Arne Hormann <arnehormann@gmail.com>
|
||||
Arnout Engelen <arnout@bzzt.net>
|
||||
Aron Nopanen <aron.nopanen@gmail.com>
|
||||
Artyom Pervukhin <artyom.pervukhin@gmail.com>
|
||||
Arvindh Rajesh Tamilmani <art@a-30.net>
|
||||
Atin Malaviya <amalaviy@akamai.com>
|
||||
Ato Araki <ato.araki@gmail.com>
|
||||
Audrey Lim <audreylh@gmail.com>
|
||||
Augusto Roman <aroman@gmail.com>
|
||||
Aulus Egnatius Varialus <varialus@gmail.com>
|
||||
awaw fumin <awawfumin@gmail.com>
|
||||
Ayanamist Yang <ayanamist@gmail.com>
|
||||
Aymerick Jéhanne <aymerick@jehanne.org>
|
||||
Ben Burkert <ben@benburkert.com>
|
||||
Ben Olive <sionide21@gmail.com>
|
||||
Benjamin Black <b@b3k.us>
|
||||
Benny Siegert <bsiegert@gmail.com>
|
||||
Benoit Sigoure <tsunanet@gmail.com>
|
||||
Berengar Lehr <berengar.lehr@gmx.de>
|
||||
Billie Harold Cleek <bhcleek@gmail.com>
|
||||
Bjorn Tillenius <bjorn@tillenius.me>
|
||||
Bjorn Tipling <bjorn.tipling@gmail.com>
|
||||
Blake Gentry <blakesgentry@gmail.com>
|
||||
Blake Mizerany <blake.mizerany@gmail.com>
|
||||
Blixt <me@blixt.nyc>
|
||||
Bobby Powers <bobbypowers@gmail.com>
|
||||
Bolt
|
||||
Brady Catherman <brady@gmail.com>
|
||||
Brady Sullivan <brady@bsull.com>
|
||||
Brendan Daniel Tracey <tracey.brendan@gmail.com>
|
||||
Brett Cannon <bcannon@gmail.com>
|
||||
Brian Dellisanti <briandellisanti@gmail.com>
|
||||
Brian G. Merrell <bgmerrell@gmail.com>
|
||||
Brian Gitonga Marete <marete@toshnix.com> <bgmarete@gmail.com>
|
||||
Brian Kennedy <btkennedy@gmail.com>
|
||||
Brian Ketelsen <bketelsen@gmail.com>
|
||||
Brian Smith <ohohvi@gmail.com>
|
||||
Bryan Alexander <Kozical@msn.com>
|
||||
Bryan Ford <brynosaurus@gmail.com>
|
||||
Caine Tighe <arctanofyourface@gmail.com>
|
||||
Caleb Spare <cespare@gmail.com>
|
||||
Carl Chatfield <carlchatfield@gmail.com>
|
||||
Carl Johnson <me@carlmjohnson.net>
|
||||
Carlos Castillo <cookieo9@gmail.com>
|
||||
Carlos Cirello <uldericofilho@gmail.com>
|
||||
Case Nelson <case.nelson@gmail.com>
|
||||
Casey Marshall <casey.marshall@gmail.com>
|
||||
Cezar Sá Espinola <cezarsa@gmail.com>
|
||||
ChaiShushan <chaishushan@gmail.com>
|
||||
Charles L. Dorian <cldorian@gmail.com>
|
||||
Charles Lee <zombie.fml@gmail.com>
|
||||
Chris Dollin <ehog.hedge@gmail.com>
|
||||
Chris Farmiloe <chrisfarms@gmail.com>
|
||||
Chris Hines <chris.cs.guy@gmail.com>
|
||||
Chris Howey <howeyc@gmail.com>
|
||||
Chris Jones <chris@cjones.org>
|
||||
Chris Kastorff <encryptio@gmail.com>
|
||||
Chris Lennert <calennert@gmail.com>
|
||||
Chris McGee <sirnewton_01@yahoo.ca> <newton688@gmail.com>
|
||||
Christian Couder <chriscool@tuxfamily.org>
|
||||
Christian Himpel <chressie@googlemail.com>
|
||||
Christine Hansmann <chhansmann@gmail.com>
|
||||
Christoffer Buchholz <christoffer.buchholz@gmail.com>
|
||||
Christoph Hack <christoph@tux21b.org>
|
||||
Christopher Cahoon <chris.cahoon@gmail.com>
|
||||
Christopher Guiney <chris@guiney.net>
|
||||
Christopher Nelson <nadiasvertex@gmail.com>
|
||||
Christopher Nielsen <m4dh4tt3r@gmail.com>
|
||||
Christopher Redden <christopher.redden@gmail.com>
|
||||
Christopher Wedgwood <cw@f00f.org>
|
||||
CL Sung <clsung@gmail.com> <cl_sung@htc.com>
|
||||
Clement Skau <clementskau@gmail.com>
|
||||
CloudFlare Inc.
|
||||
Colin Edwards <colin@recursivepenguin.com>
|
||||
Colin Kennedy <moshen.colin@gmail.com>
|
||||
Conrad Irwin <conrad.irwin@gmail.com>
|
||||
Conrad Meyer <cemeyer@cs.washington.edu>
|
||||
CoreOS, Inc.
|
||||
Corey Thomasson <cthom.lists@gmail.com>
|
||||
Cristian Staretu <unclejacksons@gmail.com>
|
||||
Currant
|
||||
Cyrill Schumacher <cyrill@schumacher.fm>
|
||||
Damian Gryski <dgryski@gmail.com>
|
||||
Dan Caddigan <goldcaddy77@gmail.com>
|
||||
Dan Callahan <dan.callahan@gmail.com>
|
||||
Dan Peterson <dpiddy@gmail.com>
|
||||
Dan Sinclair <dan.sinclair@gmail.com>
|
||||
Daniel Fleischman <danielfleischman@gmail.com>
|
||||
Daniel Johansson <dajo2002@gmail.com>
|
||||
Daniel Kerwin <d.kerwin@gini.net>
|
||||
Daniel Krech <eikeon@eikeon.com>
|
||||
Daniel Lidén <daniel.liden.87@gmail.com>
|
||||
Daniel Martí <mvdan@mvdan.cc>
|
||||
Daniel Morsing <daniel.morsing@gmail.com>
|
||||
Daniel Ortiz Pereira da Silva <daniel.particular@gmail.com>
|
||||
Daniel Skinner <daniel@dasa.cc>
|
||||
Daniel Speichert <daniel@speichert.pl>
|
||||
Daniel Theophanes <kardianos@gmail.com>
|
||||
Darren Elwood <darren@textnode.com>
|
||||
Datong Sun <dndx@idndx.com>
|
||||
Dave Cheney <dave@cheney.net>
|
||||
David Brophy <dave@brophy.uk>
|
||||
David Bürgin <676c7473@gmail.com>
|
||||
David Calavera <david.calavera@gmail.com>
|
||||
David du Colombier <0intro@gmail.com>
|
||||
David Forsythe <dforsythe@gmail.com>
|
||||
David G. Andersen <dave.andersen@gmail.com>
|
||||
David Howden <dhowden@gmail.com>
|
||||
David Jakob Fritz <david.jakob.fritz@gmail.com>
|
||||
David Leon Gil <coruus@gmail.com>
|
||||
David R. Jenni <david.r.jenni@gmail.com>
|
||||
David Sansome <me@davidsansome.com>
|
||||
David Stainton <dstainton415@gmail.com>
|
||||
David Thomas <davidthomas426@gmail.com>
|
||||
David Titarenco <david.titarenco@gmail.com>
|
||||
Davies Liu <davies.liu@gmail.com>
|
||||
Dean Prichard <dean.prichard@gmail.com>
|
||||
Deepak Jois <deepak.jois@gmail.com>
|
||||
Denis Bernard <db047h@gmail.com>
|
||||
Denis Brandolini <denis.brandolini@gmail.com>
|
||||
Denys Honsiorovskyi <honsiorovskyi@gmail.com>
|
||||
Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
||||
Derek Parker <parkerderek86@gmail.com>
|
||||
Derek Shockey <derek.shockey@gmail.com>
|
||||
Develer SRL
|
||||
Devon H. O'Dell <devon.odell@gmail.com>
|
||||
Dhaivat Pandit <dhaivatpandit@gmail.com>
|
||||
Dhiru Kholia <dhiru.kholia@gmail.com>
|
||||
Didier Spezia <didier.06@gmail.com>
|
||||
Dimitri Tcaciuc <dtcaciuc@gmail.com>
|
||||
Dirk Gadsden <dirk@esherido.com>
|
||||
Diwaker Gupta <diwakergupta@gmail.com>
|
||||
Dmitri Popov <operator@cv.dp-net.com>
|
||||
Dmitri Shuralyov <shurcooL@gmail.com>
|
||||
Dmitriy Dudkin <dudkin.dmitriy@gmail.com>
|
||||
Dmitriy Shelenin <deemok@googlemail.com> <deemok@gmail.com>
|
||||
Dmitry Chestnykh <dchest@gmail.com>
|
||||
Dmitry Savintsev <dsavints@gmail.com>
|
||||
Dmitry Yakunin <nonamezeil@gmail.com>
|
||||
Dominik Honnef <dominik.honnef@gmail.com>
|
||||
Donald Huang <don.hcd@gmail.com>
|
||||
Donovan Hide <donovanhide@gmail.com>
|
||||
Dropbox, Inc.
|
||||
Duncan Holm <mail@frou.org>
|
||||
Dustin Herbison <djherbis@gmail.com>
|
||||
Dustin Sallings <dsallings@gmail.com>
|
||||
Dustin Shields-Cloues <dcloues@gmail.com>
|
||||
Dvir Volk <dvir@everything.me> <dvirsky@gmail.com>
|
||||
Eden Li <eden.li@gmail.com>
|
||||
Edward Muller <edwardam@interlix.com>
|
||||
Egon Elbre <egonelbre@gmail.com>
|
||||
Ehren Kret <ehren.kret@gmail.com>
|
||||
Eivind Uggedal <eivind@uggedal.com>
|
||||
Elias Naur <elias.naur@gmail.com>
|
||||
Emil Hessman <c.emil.hessman@gmail.com> <emil@hessman.se>
|
||||
Emmanuel Odeke <emm.odeke@gmail.com> <odeke@ualberta.ca>
|
||||
Empirical Interfaces Inc.
|
||||
Emil Hessman <c.emil.hessman@gmail.com>
|
||||
Eoghan Sherry <ejsherry@gmail.com>
|
||||
Eric Clark <zerohp@gmail.com>
|
||||
Eric Engestrom <eric@engestrom.ch>
|
||||
Eric Lagergren <ericscottlagergren@gmail.com>
|
||||
Eric Milliken <emilliken@gmail.com>
|
||||
Eric Roshan-Eisner <eric.d.eisner@gmail.com>
|
||||
Erik Aigner <aigner.erik@gmail.com>
|
||||
Erik Dubbelboer <erik@dubbelboer.com>
|
||||
Erik St. Martin <alakriti@gmail.com>
|
||||
Erik Westrup <erik.westrup@gmail.com>
|
||||
Ernest Chiang <ernest_chiang@htc.com>
|
||||
Eric Eisner <eric.d.eisner@gmail.com>
|
||||
Esko Luontola <esko.luontola@gmail.com>
|
||||
Evan Phoenix <evan@phx.io>
|
||||
Evan Shaw <chickencha@gmail.com>
|
||||
Ewan Chou <coocood@gmail.com>
|
||||
Fabian Wickborn <fabian@wickborn.net>
|
||||
Fabrizio Milo <mistobaan@gmail.com>
|
||||
Faiyaz Ahmed <ahmedf@vmware.com>
|
||||
Fan Hongjian <fan.howard@gmail.com>
|
||||
Fastly, Inc.
|
||||
Fatih Arslan <fatih@arslan.io>
|
||||
Fazlul Shahriar <fshahriar@gmail.com>
|
||||
Fedor Indutny <fedor@indutny.com>
|
||||
Felix Geisendörfer <haimuiba@gmail.com>
|
||||
Filippo Valsorda <hi@filippo.io>
|
||||
Firmansyah Adiputra <frm.adiputra@gmail.com>
|
||||
Florian Uekermann <florian@uekermann-online.de>
|
||||
Florian Weimer <fw@deneb.enyo.de>
|
||||
Florin Patan <florinpatan@gmail.com>
|
||||
Ford Hurley <ford.hurley@gmail.com>
|
||||
Francisco Claude <fclaude@recoded.cl>
|
||||
Francisco Souza <franciscossouza@gmail.com>
|
||||
Frederick Kelly Mayle III <frederickmayle@gmail.com>
|
||||
Fredrik Enestad <fredrik.enestad@soundtrackyourbrand.com>
|
||||
Frithjof Schulze <schulze@math.uni-hannover.de> <sfrithjof@gmail.com>
|
||||
Frits van Bommel <fvbommel@gmail.com>
|
||||
Gabriel Aszalos <gabriel.aszalos@gmail.com>
|
||||
Gabriel Russell <gabriel.russell@gmail.com>
|
||||
Gareth Paul Jones <gpj@foursquare.com>
|
||||
Gary Burd <gary@beagledreams.com>
|
||||
Gaurish Sharma <contact@gaurishsharma.com>
|
||||
Gautham Thambidorai <gautham.dorai@gmail.com>
|
||||
Geert-Johan Riemer <gjr19912@gmail.com>
|
||||
Geoffroy Lorieux <lorieux.g@gmail.com>
|
||||
Georg Reinke <guelfey@gmail.com>
|
||||
George Shammas <george@shamm.as> <georgyo@gmail.com>
|
||||
Gerasimos Dimitriadis <gedimitr@gmail.com>
|
||||
Gideon Jan-Wessel Redelinghuys <gjredelinghuys@gmail.com>
|
||||
Giles Lean <giles.lean@pobox.com>
|
||||
Giulio Iotti <dullgiulio@gmail.com>
|
||||
Gleb Stepanov <glebstepanov1992@gmail.com>
|
||||
Google Inc.
|
||||
Gordon Klaus <gordon.klaus@gmail.com>
|
||||
Graham King <graham4king@gmail.com>
|
||||
Graham Miller <graham.miller@gmail.com>
|
||||
Greg Ward <greg@gerg.ca>
|
||||
Guillaume J. Charmes <guillaume@charmes.net>
|
||||
Guobiao Mei <meiguobiao@gmail.com>
|
||||
Gustav Paul <gustav.paul@gmail.com>
|
||||
Gustavo Niemeyer <gustavo@niemeyer.net>
|
||||
Gwenael Treguier <gwenn.kahz@gmail.com>
|
||||
Gyu-Ho Lee <gyuhox@gmail.com>
|
||||
H. İbrahim Güngör <igungor@gmail.com>
|
||||
Hajime Hoshi <hajimehoshi@gmail.com>
|
||||
Hari haran <hariharan.uno@gmail.com>
|
||||
Hariharan Srinath <srinathh@gmail.com>
|
||||
Harley Laue <losinggeneration@gmail.com>
|
||||
Harshavardhana <hrshvardhana@gmail.com>
|
||||
Håvard Haugen <havard.haugen@gmail.com>
|
||||
Hector Chu <hectorchu@gmail.com>
|
||||
Hector Martin Cantero <hector@marcansoft.com>
|
||||
Henning Schmiedehausen <henning@schmiedehausen.org>
|
||||
Henrik Edwards <henrik.edwards@gmail.com>
|
||||
Henrik Hodne <henrik@hodne.io>
|
||||
Herbert Georg Fischer <herbert.fischer@gmail.com>
|
||||
Hironao OTSUBO <motemen@gmail.com>
|
||||
Hiroshi Ioka <hirochachacha@gmail.com>
|
||||
Hitoshi Mitake <mitake.hitoshi@gmail.com>
|
||||
Holden Huang <ttyh061@gmail.com>
|
||||
Hong Ruiqi <hongruiqi@gmail.com>
|
||||
Hsin-Ho Yeh <yhh92u@gmail.com>
|
||||
Hu Keping <hukeping@huawei.com>
|
||||
Ian Gudger <ian@loosescre.ws>
|
||||
IBM
|
||||
Icarus Sparry <golang@icarus.freeuk.com>
|
||||
Idora Shinatose <idora.shinatose@gmail.com>
|
||||
Igneous Systems, Inc.
|
||||
Igor Dolzhikov <bluesriverz@gmail.com>
|
||||
INADA Naoki <songofacandy@gmail.com>
|
||||
Ingo Krabbe <ikrabbe.ask@gmail.com>
|
||||
Ingo Oeser <nightlyone@googlemail.com>
|
||||
Intel Corporation
|
||||
Irieda Noboru <irieda@gmail.com>
|
||||
Isaac Wagner <ibw@isaacwagner.me>
|
||||
Ivan Babrou <ivan@cloudflare.com>
|
||||
Ivan Ukhov <ivan.ukhov@gmail.com>
|
||||
Jacob Hoffman-Andrews <github@hoffman-andrews.com>
|
||||
Jae Kwon <jae@tendermint.com>
|
||||
Jakob Borg <jakob@nym.se>
|
||||
Jakub Ryszard Czarnowicz <j.czarnowicz@gmail.com>
|
||||
James Bardin <j.bardin@gmail.com>
|
||||
James Clarke <jrtc27@jrtc27.com>
|
||||
James David Chalfant <james.chalfant@gmail.com>
|
||||
James Fysh <james.fysh@gmail.com>
|
||||
James Gray <james@james4k.com>
|
||||
James Meneghello <rawrz0r@gmail.com>
|
||||
James P. Cooper <jamespcooper@gmail.com>
|
||||
James Schofield <james@shoeboxapp.com>
|
||||
James Sweet <james.sweet88@googlemail.com>
|
||||
James Toy <nil@opensesame.st>
|
||||
James Whitehead <jnwhiteh@gmail.com>
|
||||
Jamie Beverly <jamie.r.beverly@gmail.com>
|
||||
Jamil Djadala <djadala@gmail.com>
|
||||
Jan H. Hosang <jan.hosang@gmail.com>
|
||||
Jan Mercl <0xjnml@gmail.com>
|
||||
Jan Mercl <befelemepeseveze@gmail.com>
|
||||
Jan Newmarch <jan.newmarch@gmail.com>
|
||||
Jan Ziak <0xe2.0x9a.0x9b@gmail.com>
|
||||
Jani Monoses <jani.monoses@ubuntu.com>
|
||||
Jaroslavas Počepko <jp@webmaster.ms>
|
||||
Jason Barnett <jason.w.barnett@gmail.com>
|
||||
Jason Del Ponte <delpontej@gmail.com>
|
||||
Jason Smale <jsmale@zendesk.com>
|
||||
Jason Travis <infomaniac7@gmail.com>
|
||||
Jay Weisskopf <jay@jayschwa.net>
|
||||
Jean-Nicolas Moal <jn.moal@gmail.com>
|
||||
Jeff Hodges <jeff@somethingsimilar.com>
|
||||
Jeff R. Allen <jra@nella.org>
|
||||
Jeff Sickel <jas@corpus-callosum.com>
|
||||
Jeff Wendling <jeff@spacemonkey.com>
|
||||
Jens Frederich <jfrederich@gmail.com>
|
||||
Jeremy Jackins <jeremyjackins@gmail.com>
|
||||
Jeroen Bobbeldijk <jerbob92@gmail.com>
|
||||
Jess Frazelle <me@jessfraz.com>
|
||||
Jihyun Yu <yjh0502@gmail.com>
|
||||
Jim McGrath <jimmc2@gmail.com>
|
||||
Jimmy Zelinskie <jimmyzelinskie@gmail.com>
|
||||
Jingcheng Zhang <diogin@gmail.com>
|
||||
Jingguo Yao <yaojingguo@gmail.com>
|
||||
Jiong Du <londevil@gmail.com>
|
||||
Jirka Daněk <dnk@mail.muni.cz>
|
||||
Joakim Sernbrant <serbaut@gmail.com>
|
||||
Joe Farrell <joe2farrell@gmail.com>
|
||||
Joe Harrison <joehazzers@gmail.com>
|
||||
Joe Henke <joed.henke@gmail.com>
|
||||
Joe Poirier <jdpoirier@gmail.com>
|
||||
Joe Shaw <joe@joeshaw.org>
|
||||
Joe Sylve <joe.sylve@gmail.com>
|
||||
Joe Tsai <joetsai@digital-static.net>
|
||||
Joel Stemmer <stemmertech@gmail.com>
|
||||
Johan Sageryd <j@1616.se>
|
||||
John Asmuth <jasmuth@gmail.com>
|
||||
John C Barstow <jbowtie@amathaine.com>
|
||||
John Graham-Cumming <jgc@jgc.org> <jgrahamc@gmail.com>
|
||||
John Howard Palevich <jack.palevich@gmail.com>
|
||||
John Jeffery <jjeffery@sp.com.au>
|
||||
John Jenkins <twodopeshaggy@gmail.com>
|
||||
John Potocny <johnp@vividcortex.com>
|
||||
John Schnake <schnake.john@gmail.com>
|
||||
John Shahid <jvshahid@gmail.com>
|
||||
John Tuley <john@tuley.org>
|
||||
Jonathan Boulle <jonathanboulle@gmail.com>
|
||||
Jonathan Gold <jgold.bg@gmail.com>
|
||||
Jonathan Mark <jhmark@xenops.com>
|
||||
Jonathan Rudenberg <jonathan@titanous.com>
|
||||
Jonathan Wills <runningwild@gmail.com>
|
||||
Jongmin Kim <atomaths@gmail.com>
|
||||
Joonas Kuorilehto <joneskoo@derbian.fi>
|
||||
Jose Luis Vázquez González <josvazg@gmail.com>
|
||||
Joseph Holsten <joseph@josephholsten.com>
|
||||
Josh Bleecher Snyder <josharian@gmail.com>
|
||||
Josh Chorlton <jchorlton@gmail.com>
|
||||
Josh Goebel <dreamer3@gmail.com>
|
||||
Josh Holland <jrh@joshh.co.uk>
|
||||
Joshua Chase <jcjoshuachase@gmail.com>
|
||||
Jostein Stuhaug <js@solidsystem.no>
|
||||
JT Olds <jtolds@xnet5.com>
|
||||
Jukka-Pekka Kekkonen <karatepekka@gmail.com>
|
||||
Julian Kornberger <jk+github@digineo.de>
|
||||
Julian Phillips <julian@quantumfyre.co.uk>
|
||||
Julien Schmidt <google@julienschmidt.com>
|
||||
Justin Nuß <nuss.justin@gmail.com>
|
||||
Justyn Temme <justyntemme@gmail.com>
|
||||
Kai Backman <kaib@golang.org>
|
||||
Kale Blankenship <kale@lemnisys.com>
|
||||
Kamil Kisiel <kamil@kamilkisiel.net> <kamil.kisiel@gmail.com>
|
||||
Kang Hu <hukangustc@gmail.com>
|
||||
Kato Kazuyoshi <kato.kazuyoshi@gmail.com>
|
||||
Katrina Owen <katrina.owen@gmail.com>
|
||||
Kei Son <hey.calmdown@gmail.com>
|
||||
Keith Ball <inflatablewoman@gmail.com>
|
||||
Keith Rarick <kr@xph.us>
|
||||
Kelsey Hightower <kelsey.hightower@gmail.com>
|
||||
Kelvin Foo Chuan Lyi <vmirage@gmail.com>
|
||||
Ken Friedenbach <kenliz@cruzio.com>
|
||||
Ken Rockot <ken@oz.gs>
|
||||
Ken Sedgwick <ken@bonsai.com>
|
||||
Kenji Kaneda <kenji.kaneda@gmail.com>
|
||||
Kenneth Shaw <kenshaw@gmail.com>
|
||||
Kenny Grant <kennygrant@gmail.com>
|
||||
Kevin Ballard <kevin@sb.org>
|
||||
Kevin Burke <kev@inburke.com>
|
||||
Kevin Kirsche <kev.kirsche@gmail.com>
|
||||
Kevin Vu <kevin.m.vu@gmail.com>
|
||||
Klaus Post <klauspost@gmail.com>
|
||||
Konstantin Shaposhnikov <k.shaposhnikov@gmail.com>
|
||||
KPCompass, Inc.
|
||||
Kristopher Watts <traetox@gmail.com>
|
||||
Kun Li <likunarmstrong@gmail.com>
|
||||
Kyle Consalus <consalus@gmail.com>
|
||||
Kyle Isom <kyle@gokyle.net>
|
||||
Kyle Lemons <kyle@kylelemons.net>
|
||||
L Campbell <unpantsu@gmail.com>
|
||||
Lai Jiangshan <eag0628@gmail.com>
|
||||
Larz Conwell <larzconwell@gmail.com>
|
||||
LE Manh Cuong <cuong.manhle.vn@gmail.com>
|
||||
Lee Hinman <hinman@gmail.com>
|
||||
Lee Packham <lpackham@gmail.com>
|
||||
Lewin Bormann <lewin.bormann@gmail.com>
|
||||
Liberty Fund Inc
|
||||
Linaro Limited
|
||||
Lloyd Dewolf <foolswisdom@gmail.com>
|
||||
Lorenzo Stoakes <lstoakes@gmail.com>
|
||||
Luan Santos <cfcluan@gmail.com>
|
||||
Luca Greco <luca.greco@alcacoop.it>
|
||||
Lucien Stuker <lucien.stuker@gmail.com>
|
||||
Lucio De Re <lucio.dere@gmail.com>
|
||||
Luigi Riefolo <luigi.riefolo@gmail.com>
|
||||
Luit van Drongelen <luitvd@gmail.com>
|
||||
Luka Zakrajšek <tr00.g33k@gmail.com>
|
||||
Luke Curley <qpingu@gmail.com>
|
||||
Mal Curtis <mal@mal.co.nz>
|
||||
Manfred Touron <m@42.am>
|
||||
Manu S Ajith <neo@codingarena.in>
|
||||
Manuel Mendez <mmendez534@gmail.com>
|
||||
Marc Weistroff <marc@weistroff.net>
|
||||
Marco Hennings <marco.hennings@freiheit.com>
|
||||
Mark Bucciarelli <mkbucc@gmail.com>
|
||||
Mark Severson <miquella@gmail.com>
|
||||
Mark Theunissen <mark.theunissen@gmail.com>
|
||||
Marko Juhani Silokunnas <marko.silokunnas@gmail.com>
|
||||
Marko Tiikkaja <marko@joh.to>
|
||||
Markover Inc. DBA Poptip
|
||||
Markus Duft <markus.duft@salomon.at>
|
||||
Markus Sonderegger <marraison@gmail.com>
|
||||
Markus Zimmermann <zimmski@gmail.com>
|
||||
Martin Bertschler <mbertschler@gmail.com>
|
||||
Martin Garton <garton@gmail.com>
|
||||
Martin Hamrle <martin.hamrle@gmail.com>
|
||||
Martin Möhrmann <martisch@uos.de>
|
||||
Martin Neubauer <m.ne@gmx.net>
|
||||
Martin Olsson <martin@minimum.se>
|
||||
Marvin Stenger <marvin.stenger94@gmail.com>
|
||||
Mateusz Czapliński <czapkofan@gmail.com>
|
||||
Mathias Beke <git@denbeke.be>
|
||||
Mathias Leppich <mleppich@muhqu.de>
|
||||
Mathieu Lonjaret <mathieu.lonjaret@gmail.com>
|
||||
Mats Lidell <mats.lidell@cag.se>
|
||||
Matt Aimonetti <mattaimonetti@gmail.com>
|
||||
Matt Bostock <matt@mattbostock.com>
|
||||
Matt Drollette <matt@drollette.com>
|
||||
Matt Jibson <matt.jibson@gmail.com>
|
||||
Matt Joiner <anacrolix@gmail.com>
|
||||
Matt Layher <mdlayher@gmail.com>
|
||||
Matt Reiferson <mreiferson@gmail.com>
|
||||
Matt Robenolt <matt@ydekproductions.com>
|
||||
Matt T. Proud <matt.proud@gmail.com>
|
||||
Matt Williams <gh@mattyw.net>
|
||||
Matthew Brennan <matty.brennan@gmail.com>
|
||||
Matthew Cottingham <mattcottingham@gmail.com>
|
||||
Matthew Denton <mdenton@skyportsystems.com>
|
||||
Matthew Holt <Matthew.Holt+git@gmail.com>
|
||||
Matthew Horsnell <matthew.horsnell@gmail.com>
|
||||
Matthieu Hauglustaine <matt.hauglustaine@gmail.com>
|
||||
Maxim Khitrov <max@mxcrypt.com>
|
||||
Maxwell Krohn <themax@gmail.com>
|
||||
MediaMath, Inc
|
||||
Meir Fischer <meirfischer@gmail.com>
|
||||
Meng Zhuo <mengzhuo1203@gmail.com>
|
||||
Meteor Development Group
|
||||
Mhd Sulhan <m.shulhan@gmail.com>
|
||||
Micah Stetson <micah.stetson@gmail.com>
|
||||
Michael Chaten <mchaten@gmail.com>
|
||||
Michael Elkins <michael.elkins@gmail.com>
|
||||
Michael Fraenkel <michael.fraenkel@gmail.com>
|
||||
Michael Gehring <mg@ebfe.org> <gnirheg.leahcim@gmail.com>
|
||||
Michael Hoisie <hoisie@gmail.com>
|
||||
Michael Käufl <golang@c.michael-kaeufl.de>
|
||||
Michael Lewis <mikelikespie@gmail.com>
|
||||
Michael MacInnis <Michael.P.MacInnis@gmail.com>
|
||||
Michael McConville <momcconville@gmail.com>
|
||||
Michael Pearson <mipearson@gmail.com>
|
||||
Michael Schaller <michael@5challer.de>
|
||||
Michael Stapelberg <michael@stapelberg.de>
|
||||
Michael Teichgräber <mteichgraeber@gmx.de>
|
||||
Michael Vetter <g.bluehut@gmail.com>
|
||||
Michal Bohuslávek <mbohuslavek@gmail.com>
|
||||
Michał Derkacz <ziutek@lnet.pl>
|
||||
Miek Gieben <miek@miek.nl>
|
||||
Miguel Mendez <stxmendez@gmail.com>
|
||||
Mihai Borobocea <MihaiBorobocea@gmail.com>
|
||||
Mikael Tillenius <mikti42@gmail.com>
|
||||
Mike Andrews <mra@xoba.com>
|
||||
Mike Appleby <mike@app.leby.org>
|
||||
Mike Houston <mike@kothar.net>
|
||||
Mike Rosset <mike.rosset@gmail.com>
|
||||
Mikhail Gusarov <dottedmag@dottedmag.net>
|
||||
Mikhail Panchenko <m@mihasya.com>
|
||||
Miki Tebeka <miki.tebeka@gmail.com>
|
||||
Mikio Hara <mikioh.mikioh@gmail.com>
|
||||
Mikkel Krautz <mikkel@krautz.dk>
|
||||
Miquel Sabaté Solà <mikisabate@gmail.com>
|
||||
Miroslav Genov <mgenov@gmail.com>
|
||||
Mohit Agarwal <mohit@sdf.org>
|
||||
Momchil Velikov <momchil.velikov@gmail.com>
|
||||
Monty Taylor <mordred@inaugust.com>
|
||||
Moov Corporation
|
||||
Moriyoshi Koizumi <mozo@mozo.jp>
|
||||
Morten Siebuhr <sbhr@sbhr.dk>
|
||||
Môshe van der Sterre <moshevds@gmail.com>
|
||||
Muhammed Uluyol <uluyol0@gmail.com>
|
||||
Nan Deng <monnand@gmail.com>
|
||||
Nathan John Youngman <nj@nathany.com>
|
||||
Nathan Otterness <otternes@cs.unc.edu>
|
||||
Nathan P Finch <nate.finch@gmail.com>
|
||||
Nathan VanBenschoten <nvanbenschoten@gmail.com>
|
||||
Nathan Youngman <git@nathany.com>
|
||||
Neelesh Chandola <neelesh.c98@gmail.com>
|
||||
Netflix, Inc.
|
||||
Nevins Bartolomeo <nevins.bartolomeo@gmail.com>
|
||||
ngmoco, LLC
|
||||
Niall Sheridan <nsheridan@gmail.com>
|
||||
Nic Day <nic.day@me.com>
|
||||
Nicholas Katsaros <nick@nickkatsaros.com>
|
||||
Nicholas Presta <nick@nickpresta.ca> <nick1presta@gmail.com>
|
||||
Nicholas Sullivan <nicholas.sullivan@gmail.com>
|
||||
Nicholas Waples <nwaples@gmail.com>
|
||||
Nick Craig-Wood <nick@craig-wood.com> <nickcw@gmail.com>
|
||||
Nick Patavalis <nick.patavalis@gmail.com>
|
||||
Nick Petroni <npetroni@cs.umd.edu>
|
||||
Nicolas Kaiser <nikai@nikai.net>
|
||||
Nicolas Owens <mischief@offblast.org>
|
||||
Nicolas S. Dade <nic.dade@gmail.com>
|
||||
Niels Widger <niels.widger@gmail.com>
|
||||
Nigel Kerr <nigel.kerr@gmail.com>
|
||||
Niko Dziemba <niko@dziemba.com>
|
||||
Nikolay Turpitko <nikolay@turpitko.com>
|
||||
Noah Campbell <noahcampbell@gmail.com>
|
||||
Norberto Lopes <nlopes.ml@gmail.com>
|
||||
Oleg Vakheta <helginet@gmail.com>
|
||||
Oleku Konko <oleku.konko@gmail.com>
|
||||
Oling Cat <olingcat@gmail.com>
|
||||
Oliver Hookins <ohookins@gmail.com>
|
||||
Olivier Antoine <olivier.antoine@gmail.com>
|
||||
Olivier Duperray <duperray.olivier@gmail.com>
|
||||
Olivier Poitrey <rs@dailymotion.com>
|
||||
Olivier Saingre <osaingre@gmail.com>
|
||||
Oracle
|
||||
Orange
|
||||
Özgür Kesim <oec-go@kesim.org>
|
||||
Padraig Kitterick <padraigkitterick@gmail.com>
|
||||
Palm Stone Games
|
||||
Paolo Giarrusso <p.giarrusso@gmail.com>
|
||||
Paolo Martini <mrtnpaolo@gmail.com>
|
||||
Parker Moore <parkrmoore@gmail.com>
|
||||
Pascal S. de Kloe <pascal@quies.net>
|
||||
Patrick Crosby <patrick@stathat.com>
|
||||
Patrick Gavlin <pgavlin@gmail.com>
|
||||
Patrick Higgins <patrick.allen.higgins@gmail.com>
|
||||
Patrick Mézard <patrick@mezard.eu>
|
||||
Patrick Mylund Nielsen <patrick@patrickmn.com>
|
||||
Patrick Smith <pat42smith@gmail.com>
|
||||
Paul A Querna <paul.querna@gmail.com>
|
||||
Paul Hammond <paul@paulhammond.org>
|
||||
Paul Lalonde <paul.a.lalonde@gmail.com>
|
||||
Paul Meyer <paul.meyer@microsoft.com>
|
||||
Paul Rosania <paul.rosania@gmail.com>
|
||||
Paul Sbarra <Sbarra.Paul@gmail.com>
|
||||
Paul Smith <paulsmith@pobox.com> <paulsmith@gmail.com>
|
||||
Paul van Brouwershaven <paul@vanbrouwershaven.com>
|
||||
Paulo Casaretto <pcasaretto@gmail.com>
|
||||
Pavel Paulau <pavel.paulau@gmail.com>
|
||||
Pavel Zinovkin <pavel.zinovkin@gmail.com>
|
||||
Pawel Knap <pawelknap88@gmail.com>
|
||||
Percy Wegmann <ox.to.a.cart@gmail.com>
|
||||
Perry Abbott <perry.j.abbott@gmail.com>
|
||||
Petar Maymounkov <petarm@gmail.com>
|
||||
Peter Armitage <peter.armitage@gmail.com>
|
||||
Peter Froehlich <peter.hans.froehlich@gmail.com>
|
||||
Peter Kleiweg <pkleiweg@xs4all.nl>
|
||||
Peter Moody <pmoody@uber.com>
|
||||
Peter Mundy <go.peter.90@gmail.com>
|
||||
Péter Surányi <speter.go1@gmail.com>
|
||||
Péter Szilágyi <peterke@gmail.com>
|
||||
Peter Waldschmidt <peter@waldschmidt.com>
|
||||
Peter Waller <peter.waller@gmail.com>
|
||||
Peter Williams <pwil3058@gmail.com>
|
||||
Philip Børgesen <philip.borgesen@gmail.com>
|
||||
Philip Hofer <phofer@umich.edu>
|
||||
Philip K. Warren <pkwarren@gmail.com>
|
||||
Pierre Durand <pierredurand@gmail.com>
|
||||
Pierre Roullon <pierre.roullon@gmail.com>
|
||||
Pieter Droogendijk <pieter@binky.org.uk>
|
||||
Pietro Gagliardi <pietro10@mac.com>
|
||||
Prashant Varanasi <prashant@prashantv.com>
|
||||
Preetam Jinka <pj@preet.am>
|
||||
Quan Tran <qeed.quan@gmail.com>
|
||||
Quan Yong Zhai <qyzhai@gmail.com>
|
||||
Quentin Perez <qperez@ocs.online.net>
|
||||
Quoc-Viet Nguyen <afelion@gmail.com>
|
||||
RackTop Systems Inc.
|
||||
Radu Berinde <radu@cockroachlabs.com>
|
||||
Raif S. Naffah <go@naffah-raif.name>
|
||||
Rajat Goel <rajat.goel2010@gmail.com>
|
||||
Ralph Corderoy <ralph@inputplus.co.uk>
|
||||
Red Hat, Inc.
|
||||
Reinaldo de Souza Jr <juniorz@gmail.com>
|
||||
Rémy Oudompheng <oudomphe@phare.normalesup.org>
|
||||
Ricardo Padilha <ricardospadilha@gmail.com>
|
||||
Richard Barnes <rlb@ipv.sx>
|
||||
Richard Crowley <r@rcrowley.org>
|
||||
Richard Eric Gavaletz <gavaletz@gmail.com>
|
||||
Richard Gibson <richard.gibson@gmail.com>
|
||||
Richard Miller <miller.research@gmail.com>
|
||||
Richard Musiol <mail@richard-musiol.de>
|
||||
Rick Arnold <rickarnoldjr@gmail.com>
|
||||
Risto Jaakko Saarelma <rsaarelm@gmail.com>
|
||||
Rob Norman <rob.norman@infinitycloud.com>
|
||||
Robert Daniel Kortschak <dan.kortschak@adelaide.edu.au>
|
||||
Robert Dinu <r@varp.se>
|
||||
Robert Figueiredo <robfig@gmail.com>
|
||||
Robert Hencke <robert.hencke@gmail.com>
|
||||
Robert Obryk <robryk@gmail.com>
|
||||
Robert Stepanek <robert.stepanek@gmail.com>
|
||||
Robin Eklind <r.eklind.87@gmail.com>
|
||||
Rodrigo Moraes de Oliveira <rodrigo.moraes@gmail.com>
|
||||
Rodrigo Rafael Monti Kochenburger <divoxx@gmail.com>
|
||||
Roger Pau Monné <royger@gmail.com>
|
||||
Roger Peppe <rogpeppe@gmail.com>
|
||||
Roland Shoemaker <rolandshoemaker@gmail.com>
|
||||
Ron Hashimoto <mail@h2so5.net>
|
||||
Ron Minnich <rminnich@gmail.com>
|
||||
Ross Light <rlight2@gmail.com>
|
||||
Rowan Worth <sqweek@gmail.com>
|
||||
Russell Haering <russellhaering@gmail.com>
|
||||
Ryan Hitchman <hitchmanr@gmail.com>
|
||||
Ryan Lower <rpjlower@gmail.com>
|
||||
Ryan Seys <ryan@ryanseys.com>
|
||||
Ryan Slade <ryanslade@gmail.com>
|
||||
S.Çağlar Onur <caglar@10ur.org>
|
||||
Salmān Aljammāz <s@0x65.net>
|
||||
Sam Hug <samuel.b.hug@gmail.com>
|
||||
Sam Whited <sam@samwhited.com>
|
||||
Samuele Pedroni <pedronis@lucediurna.net>
|
||||
Sanjay Menakuru <balasanjay@gmail.com>
|
||||
Sasha Sobol <sasha@scaledinference.com>
|
||||
Scott Barron <scott.barron@github.com>
|
||||
Scott Bell <scott@sctsm.com>
|
||||
Scott Ferguson <scottwferg@gmail.com>
|
||||
Scott Lawrence <bytbox@gmail.com>
|
||||
Sean Rees <sean@erifax.org>
|
||||
Sebastien Binet <seb.binet@gmail.com>
|
||||
Sebastien Binet <seb.binet@gmail.com>
|
||||
Sébastien Paolacci <sebastien.paolacci@gmail.com>
|
||||
Sergei Skorobogatov <skorobo@rambler.ru>
|
||||
Sergey 'SnakE' Gromov <snake.scaly@gmail.com>
|
||||
Sergio Luis O. B. Correia <sergio@correia.cc>
|
||||
Seth Hoenig <seth.a.hoenig@gmail.com>
|
||||
Seth Vargo <sethvargo@gmail.com>
|
||||
Shahar Kohanim <skohanim@gmail.com>
|
||||
Shane Hansen <shanemhansen@gmail.com>
|
||||
Shaozhen Ding <dsz0111@gmail.com>
|
||||
Shawn Smith <shawn.p.smith@gmail.com>
|
||||
Sergio Luis O. B. Correia <sergio@larces.uece.br>
|
||||
Shenghou Ma <minux.ma@gmail.com>
|
||||
Shinji Tanaka <shinji.tanaka@gmail.com>
|
||||
Shivakumar GN <shivakumar.gn@gmail.com>
|
||||
Silvan Jegen <s.jegen@gmail.com>
|
||||
Simon Jefford <simon.jefford@gmail.com>
|
||||
Simon Rawet <simon@rawet.se>
|
||||
Simon Thulbourn <simon+github@thulbourn.com>
|
||||
Simon Whitehead <chemnova@gmail.com>
|
||||
Sina Siadat <siadat@gmail.com>
|
||||
Sokolov Yura <funny.falcon@gmail.com>
|
||||
Song Gao <song@gao.io>
|
||||
Spencer Nelson <s@spenczar.com>
|
||||
Spring Mc <heresy.mc@gmail.com>
|
||||
Square, Inc.
|
||||
Sridhar Venkatakrishnan <sridhar@laddoo.net>
|
||||
StalkR <stalkr@stalkr.net>
|
||||
Stan Schwertly <stan@schwertly.com>
|
||||
Stefan Nilsson <snilsson@nada.kth.se> <trolleriprofessorn@gmail.com>
|
||||
Stéphane Travostino <stephane.travostino@gmail.com>
|
||||
Stephen McQuay <stephen@mcquay.me>
|
||||
Stephen Weinberg <stephen@q5comm.com>
|
||||
Steve McCoy <mccoyst@gmail.com>
|
||||
Steve Phillips <elimisteve@gmail.com>
|
||||
Steve Streeting <steve@stevestreeting.com>
|
||||
Steven Elliot Harris <seharris@gmail.com>
|
||||
Steven Hartland <steven.hartland@multiplay.co.uk>
|
||||
Stripe, Inc.
|
||||
Suyash <dextrous93@gmail.com>
|
||||
Sven Almgren <sven@tras.se>
|
||||
Syohei YOSHIDA <syohex@gmail.com>
|
||||
Szabolcs Nagy <nsz@port70.net>
|
||||
Tad Glines <tad.glines@gmail.com>
|
||||
Taj Khattra <taj.khattra@gmail.com>
|
||||
Takeshi YAMANASHI <9.nashi@gmail.com>
|
||||
Tal Shprecher <tshprecher@gmail.com>
|
||||
Tamir Duberstein <tamird@gmail.com>
|
||||
Tarmigan Casebolt <tarmigan@gmail.com>
|
||||
Taru Karttunen <taruti@taruti.net>
|
||||
Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
Terrel Shumway <gopher@shumway.us>
|
||||
Tetsuo Kiso <tetsuokiso9@gmail.com>
|
||||
Thiago Fransosi Farina <thiago.farina@gmail.com>
|
||||
Thomas Alan Copeland <talan.copeland@gmail.com>
|
||||
Thomas de Zeeuw <thomasdezeeuw@gmail.com>
|
||||
Thomas Desrosiers <thomasdesr@gmail.com>
|
||||
Thomas Kappler <tkappler@gmail.com>
|
||||
Thorben Krueger <thorben.krueger@gmail.com>
|
||||
Tilman Dilo <tilman.dilo@gmail.com>
|
||||
Tim Cooijmans <timcooijmans@gmail.com>
|
||||
Tim Ebringer <tim.ebringer@gmail.com>
|
||||
Tim Henderson <tim.tadh@gmail.com>
|
||||
Timo Savola <timo.savola@gmail.com>
|
||||
Timo Truyts <alkaloid.btx@gmail.com>
|
||||
Timothy Studd <tim@timstudd.com>
|
||||
Tobias Columbus <tobias.columbus@gmail.com>
|
||||
Todd Neal <todd@tneal.org>
|
||||
Tom Heng <zhm20070928@gmail.com>
|
||||
Tom Linford <tomlinford@gmail.com>
|
||||
Tommy Schaefer <tommy.schaefer@teecom.com>
|
||||
Tor Andersson <tor.andersson@gmail.com>
|
||||
Tormod Erevik Lea <tormodlea@gmail.com>
|
||||
Totoro W <tw19881113@gmail.com>
|
||||
Travis Cline <travis.cline@gmail.com>
|
||||
Trey Lawrence <lawrence.trey@gmail.com>
|
||||
Trey Tacon <ttacon@gmail.com>
|
||||
Tristan Ooohry <ooohry@gmail.com>
|
||||
Tudor Golubenco <tudor.g@gmail.com>
|
||||
Tuo Shan <sturbo89@gmail.com>
|
||||
Tyler Bunnell <tylerbunnell@gmail.com>
|
||||
Tyler Treat <ttreat31@gmail.com>
|
||||
Ugorji Nwoke <ugorji@gmail.com>
|
||||
Ulf Holm Nielsen <doktor@dyregod.dk>
|
||||
Ulrich Kunitz <uli.kunitz@gmail.com>
|
||||
Upthere, Inc.
|
||||
Uriel Mangado <uriel@berlinblue.org>
|
||||
Vadim Grek <vadimprog@gmail.com>
|
||||
Vadim Vygonets <unixdj@gmail.com>
|
||||
Vendasta
|
||||
Vincent Ambo <tazjin@googlemail.com>
|
||||
Vincent Batts <vbatts@hashbangbash.com> <vbatts@gmail.com>
|
||||
Vincent Vanackere <vincent.vanackere@gmail.com>
|
||||
Vinu Rajashekhar <vinutheraj@gmail.com>
|
||||
Vishvananda Ishaya <vishvananda@gmail.com>
|
||||
Vitor De Mario <vitordemario@gmail.com>
|
||||
Vladimir Mihailenco <vladimir.webdev@gmail.com>
|
||||
Vladimir Nikishenko <vova616@gmail.com>
|
||||
Vladimir Stefanovic <vladimir.stefanovic@imgtec.com>
|
||||
Volker Dobler <dr.volker.dobler@gmail.com>
|
||||
Weaveworks
|
||||
Wei Guangjing <vcc.163@gmail.com>
|
||||
Willem van der Schyff <willemvds@gmail.com>
|
||||
William Josephson <wjosephson@gmail.com>
|
||||
William Orr <will@worrbase.com> <ay1244@gmail.com>
|
||||
Wisdom Omuya <deafgoat@gmail.com>
|
||||
Xia Bin <snyh@snyh.org>
|
||||
Xing Xing <mikespook@gmail.com>
|
||||
Xudong Zhang <felixmelon@gmail.com>
|
||||
Xuyang Kang <xuyangkang@gmail.com>
|
||||
Yahoo Inc.
|
||||
Yann Kerhervé <yann.kerherve@gmail.com>
|
||||
Yao Zhang <lunaria21@gmail.com>
|
||||
Yasuharu Goto <matope.ono@gmail.com>
|
||||
Yasuhiro Matsumoto <mattn.jp@gmail.com>
|
||||
Yesudeep Mangalapilly <yesudeep@google.com>
|
||||
Yissakhar Z. Beck <yissakhar.beck@gmail.com>
|
||||
Yo-An Lin <yoanlin93@gmail.com>
|
||||
Yongjian Xu <i3dmaster@gmail.com>
|
||||
Yorman Arias <cixtords@gmail.com>
|
||||
Yoshiyuki Kanno <nekotaroh@gmail.com> <yoshiyuki.kanno@stoic.co.jp>
|
||||
Yusuke Kagiwada <block.rxckin.beats@gmail.com>
|
||||
Yuusei Kuwana <kuwana@kumama.org>
|
||||
Yuval Pavel Zholkover <paulzhol@gmail.com>
|
||||
Zemanta d.o.o.
|
||||
Zev Goldstein <zev.goldstein@gmail.com>
|
||||
Ziad Hatahet <hatahet@gmail.com>
|
||||
Zorion Arrizabalaga <zorionk@gmail.com>
|
||||
申习之 <bronze1man@gmail.com>
|
||||
|
||||
@@ -1,34 +0,0 @@
|
||||
# Contributing to Go
|
||||
|
||||
Go is an open source project.
|
||||
|
||||
It is the work of hundreds of contributors. We appreciate your help!
|
||||
|
||||
|
||||
## Filing issues
|
||||
|
||||
When filing an issue, make sure to answer these five questions:
|
||||
|
||||
1. What version of Go are you using (`go version`)?
|
||||
2. What operating system and processor architecture are you using?
|
||||
3. What did you do?
|
||||
4. What did you expect to see?
|
||||
5. What did you see instead?
|
||||
|
||||
General questions should go to the [golang-nuts mailing list](https://groups.google.com/group/golang-nuts) instead of the issue tracker.
|
||||
The gophers there will answer or ask you to file an issue if you've tripped over a bug.
|
||||
|
||||
Sensitive security-related issues should be reported to [security@golang.org](mailto:security@golang.org).
|
||||
|
||||
## Contributing code
|
||||
|
||||
Please read the [Contribution Guidelines](https://golang.org/doc/contribute.html)
|
||||
before sending patches.
|
||||
|
||||
**We do not accept GitHub pull requests**
|
||||
(we use [an instance](https://go-review.googlesource.com/) of the
|
||||
[Gerrit](https://www.gerritcodereview.com/) code review system instead).
|
||||
|
||||
Unless otherwise noted, the Go source files are distributed under
|
||||
the BSD-style license found in the LICENSE file.
|
||||
|
||||
872
CONTRIBUTORS
872
CONTRIBUTORS
File diff suppressed because it is too large
Load Diff
2
LICENSE
2
LICENSE
@@ -1,4 +1,4 @@
|
||||
Copyright (c) 2009 The Go Authors. All rights reserved.
|
||||
Copyright (c) 2012 The Go Authors. All rights reserved.
|
||||
|
||||
Redistribution and use in source and binary forms, with or without
|
||||
modification, are permitted provided that the following conditions are
|
||||
|
||||
31
README
Normal file
31
README
Normal file
@@ -0,0 +1,31 @@
|
||||
This is the source code repository for the Go programming language.
|
||||
|
||||
For documentation about how to install and use Go,
|
||||
visit http://golang.org/ or load doc/install.html in your web browser.
|
||||
|
||||
After installing Go, you can view a nicely formatted
|
||||
doc/install.html by running godoc --http=:6060
|
||||
and then visiting http://localhost:6060/doc/install.html.
|
||||
|
||||
Unless otherwise noted, the Go source files are distributed
|
||||
under the BSD-style license found in the LICENSE file.
|
||||
|
||||
--
|
||||
|
||||
Binary Distribution Notes
|
||||
|
||||
If you have just untarred a binary Go distribution, you need to set
|
||||
the environment variable $GOROOT to the full path of the go
|
||||
directory (the one containing this README). You can omit the
|
||||
variable if you unpack it into /usr/local/go, or if you rebuild
|
||||
from sources by running all.bash (see doc/install.html).
|
||||
You should also add the Go binary directory $GOROOT/bin
|
||||
to your shell's path.
|
||||
|
||||
For example, if you extracted the tar file into $HOME/go, you might
|
||||
put the following in your .profile:
|
||||
|
||||
export GOROOT=$HOME/go
|
||||
export PATH=$PATH:$GOROOT/bin
|
||||
|
||||
See doc/install.html for more details.
|
||||
43
README.md
43
README.md
@@ -1,43 +0,0 @@
|
||||
# The Go Programming Language
|
||||
|
||||
Go is an open source programming language that makes it easy to build simple,
|
||||
reliable, and efficient software.
|
||||
|
||||
|
||||
|
||||
For documentation about how to install and use Go,
|
||||
visit https://golang.org/ or load doc/install-source.html
|
||||
in your web browser.
|
||||
|
||||
Our canonical Git repository is located at https://go.googlesource.com/go.
|
||||
There is a mirror of the repository at https://github.com/golang/go.
|
||||
|
||||
Go is the work of hundreds of contributors. We appreciate your help!
|
||||
|
||||
To contribute, please read the contribution guidelines:
|
||||
https://golang.org/doc/contribute.html
|
||||
|
||||
##### Note that we do not accept pull requests and that we use the issue tracker for bug reports and proposals only. Please ask questions on https://forum.golangbridge.org or https://groups.google.com/forum/#!forum/golang-nuts.
|
||||
|
||||
Unless otherwise noted, the Go source files are distributed
|
||||
under the BSD-style license found in the LICENSE file.
|
||||
|
||||
--
|
||||
|
||||
## Binary Distribution Notes
|
||||
|
||||
If you have just untarred a binary Go distribution, you need to set
|
||||
the environment variable $GOROOT to the full path of the go
|
||||
directory (the one containing this file). You can omit the
|
||||
variable if you unpack it into /usr/local/go, or if you rebuild
|
||||
from sources by running all.bash (see doc/install-source.html).
|
||||
You should also add the Go binary directory $GOROOT/bin
|
||||
to your shell's path.
|
||||
|
||||
For example, if you extracted the tar file into $HOME/go, you might
|
||||
put the following in your .profile:
|
||||
|
||||
export GOROOT=$HOME/go
|
||||
export PATH=$PATH:$GOROOT/bin
|
||||
|
||||
See https://golang.org/doc/install or doc/install.html for more details.
|
||||
14
api/README
14
api/README
@@ -1,14 +0,0 @@
|
||||
Files in this directory are data for Go's API checker ("go tool api", in src/cmd/api).
|
||||
|
||||
Each file is a list of API features, one per line.
|
||||
|
||||
go1.txt (and similarly named files) are frozen once a version has been
|
||||
shipped. Each file adds new lines but does not remove any.
|
||||
|
||||
except.txt lists features that may disappear without breaking true
|
||||
compatibility.
|
||||
|
||||
next.txt is the only file intended to be mutated. It's a list of
|
||||
features that may be added to the next version. It only affects
|
||||
warning output from the go api tool.
|
||||
|
||||
340
api/except.txt
340
api/except.txt
@@ -1,340 +0,0 @@
|
||||
pkg encoding/json, method (*RawMessage) MarshalJSON() ([]uint8, error)
|
||||
pkg net, func ListenUnixgram(string, *UnixAddr) (*UDPConn, error)
|
||||
pkg os (linux-arm), const O_SYNC = 4096
|
||||
pkg os (linux-arm-cgo), const O_SYNC = 4096
|
||||
pkg syscall (darwin-386), const ImplementsGetwd = false
|
||||
pkg syscall (darwin-386), func Fchflags(string, int) error
|
||||
pkg syscall (darwin-386-cgo), const ImplementsGetwd = false
|
||||
pkg syscall (darwin-386-cgo), func Fchflags(string, int) error
|
||||
pkg syscall (darwin-amd64), const ImplementsGetwd = false
|
||||
pkg syscall (darwin-amd64), func Fchflags(string, int) error
|
||||
pkg syscall (darwin-amd64-cgo), const ImplementsGetwd = false
|
||||
pkg syscall (darwin-amd64-cgo), func Fchflags(string, int) error
|
||||
pkg syscall (freebsd-386), const AF_MAX = 38
|
||||
pkg syscall (freebsd-386), const DLT_MATCHING_MAX = 242
|
||||
pkg syscall (freebsd-386), const ELAST = 94
|
||||
pkg syscall (freebsd-386), const O_CLOEXEC = 0
|
||||
pkg syscall (freebsd-386), func Fchflags(string, int) error
|
||||
pkg syscall (freebsd-386-cgo), const AF_MAX = 38
|
||||
pkg syscall (freebsd-386-cgo), const DLT_MATCHING_MAX = 242
|
||||
pkg syscall (freebsd-386-cgo), const ELAST = 94
|
||||
pkg syscall (freebsd-386-cgo), const O_CLOEXEC = 0
|
||||
pkg syscall (freebsd-amd64), const AF_MAX = 38
|
||||
pkg syscall (freebsd-amd64), const DLT_MATCHING_MAX = 242
|
||||
pkg syscall (freebsd-amd64), const ELAST = 94
|
||||
pkg syscall (freebsd-amd64), const O_CLOEXEC = 0
|
||||
pkg syscall (freebsd-amd64), func Fchflags(string, int) error
|
||||
pkg syscall (freebsd-amd64-cgo), const AF_MAX = 38
|
||||
pkg syscall (freebsd-amd64-cgo), const DLT_MATCHING_MAX = 242
|
||||
pkg syscall (freebsd-amd64-cgo), const ELAST = 94
|
||||
pkg syscall (freebsd-amd64-cgo), const O_CLOEXEC = 0
|
||||
pkg syscall (freebsd-arm), const AF_MAX = 38
|
||||
pkg syscall (freebsd-arm), const BIOCGRTIMEOUT = 1074545262
|
||||
pkg syscall (freebsd-arm), const BIOCSRTIMEOUT = 2148287085
|
||||
pkg syscall (freebsd-arm), const ELAST = 94
|
||||
pkg syscall (freebsd-arm), const O_CLOEXEC = 0
|
||||
pkg syscall (freebsd-arm), const SIOCAIFADDR = 2151967019
|
||||
pkg syscall (freebsd-arm), const SIOCGIFSTATUS = 3274991931
|
||||
pkg syscall (freebsd-arm), const SIOCSIFPHYADDR = 2151967046
|
||||
pkg syscall (freebsd-arm), const SYS_CAP_FCNTLS_GET = 537
|
||||
pkg syscall (freebsd-arm), const SYS_CAP_FCNTLS_GET ideal-int
|
||||
pkg syscall (freebsd-arm), const SYS_CAP_FCNTLS_LIMIT = 536
|
||||
pkg syscall (freebsd-arm), const SYS_CAP_FCNTLS_LIMIT ideal-int
|
||||
pkg syscall (freebsd-arm), const SYS_CAP_IOCTLS_GET = 535
|
||||
pkg syscall (freebsd-arm), const SYS_CAP_IOCTLS_GET ideal-int
|
||||
pkg syscall (freebsd-arm), const SYS_CAP_IOCTLS_LIMIT = 534
|
||||
pkg syscall (freebsd-arm), const SYS_CAP_IOCTLS_LIMIT ideal-int
|
||||
pkg syscall (freebsd-arm), const SYS_CAP_RIGHTS_GET = 515
|
||||
pkg syscall (freebsd-arm), const SYS_CAP_RIGHTS_GET ideal-int
|
||||
pkg syscall (freebsd-arm), const SYS_CAP_RIGHTS_LIMIT = 533
|
||||
pkg syscall (freebsd-arm), const SYS_CAP_RIGHTS_LIMIT ideal-int
|
||||
pkg syscall (freebsd-arm), const SizeofBpfHdr = 24
|
||||
pkg syscall (freebsd-arm), const SizeofIfData = 88
|
||||
pkg syscall (freebsd-arm), const SizeofIfMsghdr = 104
|
||||
pkg syscall (freebsd-arm), const SizeofSockaddrDatalink = 56
|
||||
pkg syscall (freebsd-arm), const SizeofSockaddrUnix = 108
|
||||
pkg syscall (freebsd-arm), const TIOCTIMESTAMP = 1074558041
|
||||
pkg syscall (freebsd-arm), func Fchflags(string, int) error
|
||||
pkg syscall (freebsd-arm), type BpfHdr struct, Pad_cgo_0 [2]uint8
|
||||
pkg syscall (freebsd-arm), type RawSockaddrDatalink struct, Pad_cgo_0 [2]uint8
|
||||
pkg syscall (freebsd-arm), type RawSockaddrUnix struct, Pad_cgo_0 [2]uint8
|
||||
pkg syscall (freebsd-arm), type Stat_t struct, Pad_cgo_0 [4]uint8
|
||||
pkg syscall (freebsd-arm-cgo), const AF_MAX = 38
|
||||
pkg syscall (freebsd-arm-cgo), const BIOCGRTIMEOUT = 1074545262
|
||||
pkg syscall (freebsd-arm-cgo), const BIOCSRTIMEOUT = 2148287085
|
||||
pkg syscall (freebsd-arm-cgo), const ELAST = 94
|
||||
pkg syscall (freebsd-arm-cgo), const O_CLOEXEC = 0
|
||||
pkg syscall (freebsd-arm-cgo), const SIOCAIFADDR = 2151967019
|
||||
pkg syscall (freebsd-arm-cgo), const SIOCGIFSTATUS = 3274991931
|
||||
pkg syscall (freebsd-arm-cgo), const SIOCSIFPHYADDR = 2151967046
|
||||
pkg syscall (freebsd-arm-cgo), const SYS_CAP_FCNTLS_GET = 537
|
||||
pkg syscall (freebsd-arm-cgo), const SYS_CAP_FCNTLS_GET ideal-int
|
||||
pkg syscall (freebsd-arm-cgo), const SYS_CAP_FCNTLS_LIMIT = 536
|
||||
pkg syscall (freebsd-arm-cgo), const SYS_CAP_FCNTLS_LIMIT ideal-int
|
||||
pkg syscall (freebsd-arm-cgo), const SYS_CAP_IOCTLS_GET = 535
|
||||
pkg syscall (freebsd-arm-cgo), const SYS_CAP_IOCTLS_GET ideal-int
|
||||
pkg syscall (freebsd-arm-cgo), const SYS_CAP_IOCTLS_LIMIT = 534
|
||||
pkg syscall (freebsd-arm-cgo), const SYS_CAP_IOCTLS_LIMIT ideal-int
|
||||
pkg syscall (freebsd-arm-cgo), const SYS_CAP_RIGHTS_GET = 515
|
||||
pkg syscall (freebsd-arm-cgo), const SYS_CAP_RIGHTS_GET ideal-int
|
||||
pkg syscall (freebsd-arm-cgo), const SYS_CAP_RIGHTS_LIMIT = 533
|
||||
pkg syscall (freebsd-arm-cgo), const SYS_CAP_RIGHTS_LIMIT ideal-int
|
||||
pkg syscall (freebsd-arm-cgo), const SizeofBpfHdr = 24
|
||||
pkg syscall (freebsd-arm-cgo), const SizeofIfData = 88
|
||||
pkg syscall (freebsd-arm-cgo), const SizeofIfMsghdr = 104
|
||||
pkg syscall (freebsd-arm-cgo), const SizeofSockaddrDatalink = 56
|
||||
pkg syscall (freebsd-arm-cgo), const SizeofSockaddrUnix = 108
|
||||
pkg syscall (freebsd-arm-cgo), const TIOCTIMESTAMP = 1074558041
|
||||
pkg syscall (freebsd-arm-cgo), func Fchflags(string, int) error
|
||||
pkg syscall (freebsd-arm-cgo), type BpfHdr struct, Pad_cgo_0 [2]uint8
|
||||
pkg syscall (freebsd-arm-cgo), type RawSockaddrDatalink struct, Pad_cgo_0 [2]uint8
|
||||
pkg syscall (freebsd-arm-cgo), type RawSockaddrUnix struct, Pad_cgo_0 [2]uint8
|
||||
pkg syscall (freebsd-arm-cgo), type Stat_t struct, Pad_cgo_0 [4]uint8
|
||||
pkg syscall (linux-386), type Cmsghdr struct, X__cmsg_data [0]uint8
|
||||
pkg syscall (linux-386-cgo), type Cmsghdr struct, X__cmsg_data [0]uint8
|
||||
pkg syscall (linux-amd64), type Cmsghdr struct, X__cmsg_data [0]uint8
|
||||
pkg syscall (linux-amd64-cgo), type Cmsghdr struct, X__cmsg_data [0]uint8
|
||||
pkg syscall (linux-arm), type Cmsghdr struct, X__cmsg_data [0]uint8
|
||||
pkg syscall (linux-arm-cgo), type Cmsghdr struct, X__cmsg_data [0]uint8
|
||||
pkg syscall (netbsd-arm), const SizeofIfData = 132
|
||||
pkg syscall (netbsd-arm), func Fchflags(string, int) error
|
||||
pkg syscall (netbsd-arm), type IfMsghdr struct, Pad_cgo_1 [4]uint8
|
||||
pkg syscall (netbsd-arm-cgo), const SizeofIfData = 132
|
||||
pkg syscall (netbsd-arm-cgo), func Fchflags(string, int) error
|
||||
pkg syscall (netbsd-arm-cgo), type IfMsghdr struct, Pad_cgo_1 [4]uint8
|
||||
pkg syscall (openbsd-386), const BIOCGRTIMEOUT = 1074283118
|
||||
pkg syscall (openbsd-386), const BIOCSRTIMEOUT = 2148024941
|
||||
pkg syscall (openbsd-386), const RTF_FMASK = 63496
|
||||
pkg syscall (openbsd-386), const RTM_VERSION = 4
|
||||
pkg syscall (openbsd-386), const SIOCBRDGDADDR = 2150132039
|
||||
pkg syscall (openbsd-386), const SIOCBRDGGPARAM = 3224922456
|
||||
pkg syscall (openbsd-386), const SIOCBRDGSADDR = 3223873860
|
||||
pkg syscall (openbsd-386), const SYS_CLOCK_GETRES = 234
|
||||
pkg syscall (openbsd-386), const SYS_CLOCK_GETTIME = 232
|
||||
pkg syscall (openbsd-386), const SYS_CLOCK_SETTIME = 233
|
||||
pkg syscall (openbsd-386), const SYS_FHSTATFS = 309
|
||||
pkg syscall (openbsd-386), const SYS_FSTAT = 292
|
||||
pkg syscall (openbsd-386), const SYS_FSTATAT = 316
|
||||
pkg syscall (openbsd-386), const SYS_FSTATFS = 308
|
||||
pkg syscall (openbsd-386), const SYS_FUTIMENS = 327
|
||||
pkg syscall (openbsd-386), const SYS_FUTIMES = 206
|
||||
pkg syscall (openbsd-386), const SYS_GETDIRENTRIES = 312
|
||||
pkg syscall (openbsd-386), const SYS_GETDIRENTRIES ideal-int
|
||||
pkg syscall (openbsd-386), const SYS_GETFSSTAT = 306
|
||||
pkg syscall (openbsd-386), const SYS_GETITIMER = 86
|
||||
pkg syscall (openbsd-386), const SYS_GETRUSAGE = 117
|
||||
pkg syscall (openbsd-386), const SYS_GETTIMEOFDAY = 116
|
||||
pkg syscall (openbsd-386), const SYS_KEVENT = 270
|
||||
pkg syscall (openbsd-386), const SYS_LSTAT = 293
|
||||
pkg syscall (openbsd-386), const SYS_NANOSLEEP = 240
|
||||
pkg syscall (openbsd-386), const SYS_SELECT = 93
|
||||
pkg syscall (openbsd-386), const SYS_SETITIMER = 83
|
||||
pkg syscall (openbsd-386), const SYS_SETTIMEOFDAY = 122
|
||||
pkg syscall (openbsd-386), const SYS_STAT = 291
|
||||
pkg syscall (openbsd-386), const SYS_STATFS = 307
|
||||
pkg syscall (openbsd-386), const SYS_UTIMENSAT = 326
|
||||
pkg syscall (openbsd-386), const SYS_UTIMES = 138
|
||||
pkg syscall (openbsd-386), const SYS_WAIT4 = 7
|
||||
pkg syscall (openbsd-386), const SYS___THRSLEEP = 300
|
||||
pkg syscall (openbsd-386), const SizeofIfData = 208
|
||||
pkg syscall (openbsd-386), const SizeofIfMsghdr = 232
|
||||
pkg syscall (openbsd-386), const SizeofRtMetrics = 48
|
||||
pkg syscall (openbsd-386), const SizeofRtMsghdr = 88
|
||||
pkg syscall (openbsd-386), const TIOCGTSTAMP = 1074295899
|
||||
pkg syscall (openbsd-386), type Dirent struct, Fileno uint32
|
||||
pkg syscall (openbsd-386), type FdSet struct, Bits [32]int32
|
||||
pkg syscall (openbsd-386), type Kevent_t struct, Data int32
|
||||
pkg syscall (openbsd-386), type Mclpool struct, Grown uint32
|
||||
pkg syscall (openbsd-386), type RtMetrics struct, Expire uint32
|
||||
pkg syscall (openbsd-386), type Stat_t struct, Ino uint32
|
||||
pkg syscall (openbsd-386), type Stat_t struct, Lspare0 int32
|
||||
pkg syscall (openbsd-386), type Stat_t struct, Lspare1 int32
|
||||
pkg syscall (openbsd-386), type Stat_t struct, Qspare [2]int64
|
||||
pkg syscall (openbsd-386), type Statfs_t struct, F_ctime uint32
|
||||
pkg syscall (openbsd-386), type Statfs_t struct, F_spare [3]uint32
|
||||
pkg syscall (openbsd-386), type Timespec struct, Sec int32
|
||||
pkg syscall (openbsd-386), type Timeval struct, Sec int32
|
||||
pkg syscall (openbsd-386-cgo), const BIOCGRTIMEOUT = 1074283118
|
||||
pkg syscall (openbsd-386-cgo), const BIOCSRTIMEOUT = 2148024941
|
||||
pkg syscall (openbsd-386-cgo), const RTF_FMASK = 63496
|
||||
pkg syscall (openbsd-386-cgo), const RTM_VERSION = 4
|
||||
pkg syscall (openbsd-386-cgo), const SIOCBRDGDADDR = 2150132039
|
||||
pkg syscall (openbsd-386-cgo), const SIOCBRDGGPARAM = 3224922456
|
||||
pkg syscall (openbsd-386-cgo), const SIOCBRDGSADDR = 3223873860
|
||||
pkg syscall (openbsd-386-cgo), const SYS_CLOCK_GETRES = 234
|
||||
pkg syscall (openbsd-386-cgo), const SYS_CLOCK_GETTIME = 232
|
||||
pkg syscall (openbsd-386-cgo), const SYS_CLOCK_SETTIME = 233
|
||||
pkg syscall (openbsd-386-cgo), const SYS_FHSTATFS = 309
|
||||
pkg syscall (openbsd-386-cgo), const SYS_FSTAT = 292
|
||||
pkg syscall (openbsd-386-cgo), const SYS_FSTATAT = 316
|
||||
pkg syscall (openbsd-386-cgo), const SYS_FSTATFS = 308
|
||||
pkg syscall (openbsd-386-cgo), const SYS_FUTIMENS = 327
|
||||
pkg syscall (openbsd-386-cgo), const SYS_FUTIMES = 206
|
||||
pkg syscall (openbsd-386-cgo), const SYS_GETDIRENTRIES = 312
|
||||
pkg syscall (openbsd-386-cgo), const SYS_GETDIRENTRIES ideal-int
|
||||
pkg syscall (openbsd-386-cgo), const SYS_GETFSSTAT = 306
|
||||
pkg syscall (openbsd-386-cgo), const SYS_GETITIMER = 86
|
||||
pkg syscall (openbsd-386-cgo), const SYS_GETRUSAGE = 117
|
||||
pkg syscall (openbsd-386-cgo), const SYS_GETTIMEOFDAY = 116
|
||||
pkg syscall (openbsd-386-cgo), const SYS_KEVENT = 270
|
||||
pkg syscall (openbsd-386-cgo), const SYS_LSTAT = 293
|
||||
pkg syscall (openbsd-386-cgo), const SYS_NANOSLEEP = 240
|
||||
pkg syscall (openbsd-386-cgo), const SYS_SELECT = 93
|
||||
pkg syscall (openbsd-386-cgo), const SYS_SETITIMER = 83
|
||||
pkg syscall (openbsd-386-cgo), const SYS_SETTIMEOFDAY = 122
|
||||
pkg syscall (openbsd-386-cgo), const SYS_STAT = 291
|
||||
pkg syscall (openbsd-386-cgo), const SYS_STATFS = 307
|
||||
pkg syscall (openbsd-386-cgo), const SYS_UTIMENSAT = 326
|
||||
pkg syscall (openbsd-386-cgo), const SYS_UTIMES = 138
|
||||
pkg syscall (openbsd-386-cgo), const SYS_WAIT4 = 7
|
||||
pkg syscall (openbsd-386-cgo), const SYS___THRSLEEP = 300
|
||||
pkg syscall (openbsd-386-cgo), const SizeofIfData = 208
|
||||
pkg syscall (openbsd-386-cgo), const SizeofIfMsghdr = 232
|
||||
pkg syscall (openbsd-386-cgo), const SizeofRtMetrics = 48
|
||||
pkg syscall (openbsd-386-cgo), const SizeofRtMsghdr = 88
|
||||
pkg syscall (openbsd-386-cgo), const TIOCGTSTAMP = 1074295899
|
||||
pkg syscall (openbsd-386-cgo), type Dirent struct, Fileno uint32
|
||||
pkg syscall (openbsd-386-cgo), type FdSet struct, Bits [32]int32
|
||||
pkg syscall (openbsd-386-cgo), type Kevent_t struct, Data int32
|
||||
pkg syscall (openbsd-386-cgo), type Mclpool struct, Grown uint32
|
||||
pkg syscall (openbsd-386-cgo), type RtMetrics struct, Expire uint32
|
||||
pkg syscall (openbsd-386-cgo), type Stat_t struct, Ino uint32
|
||||
pkg syscall (openbsd-386-cgo), type Stat_t struct, Lspare0 int32
|
||||
pkg syscall (openbsd-386-cgo), type Stat_t struct, Lspare1 int32
|
||||
pkg syscall (openbsd-386-cgo), type Stat_t struct, Qspare [2]int64
|
||||
pkg syscall (openbsd-386-cgo), type Statfs_t struct, F_ctime uint32
|
||||
pkg syscall (openbsd-386-cgo), type Statfs_t struct, F_spare [3]uint32
|
||||
pkg syscall (openbsd-386-cgo), type Timespec struct, Sec int32
|
||||
pkg syscall (openbsd-386-cgo), type Timeval struct, Sec int32
|
||||
pkg syscall (openbsd-amd64), const CCR0_FLUSH = 16
|
||||
pkg syscall (openbsd-amd64), const CCR0_FLUSH ideal-int
|
||||
pkg syscall (openbsd-amd64), const CPUID_CFLUSH = 524288
|
||||
pkg syscall (openbsd-amd64), const CPUID_CFLUSH ideal-int
|
||||
pkg syscall (openbsd-amd64), const EFER_LMA = 1024
|
||||
pkg syscall (openbsd-amd64), const EFER_LMA ideal-int
|
||||
pkg syscall (openbsd-amd64), const EFER_LME = 256
|
||||
pkg syscall (openbsd-amd64), const EFER_LME ideal-int
|
||||
pkg syscall (openbsd-amd64), const EFER_NXE = 2048
|
||||
pkg syscall (openbsd-amd64), const EFER_NXE ideal-int
|
||||
pkg syscall (openbsd-amd64), const EFER_SCE = 1
|
||||
pkg syscall (openbsd-amd64), const EFER_SCE ideal-int
|
||||
pkg syscall (openbsd-amd64), const PMC5_PIPELINE_FLUSH = 21
|
||||
pkg syscall (openbsd-amd64), const PMC5_PIPELINE_FLUSH ideal-int
|
||||
pkg syscall (openbsd-amd64), const RTF_FMASK = 63496
|
||||
pkg syscall (openbsd-amd64), const RTM_VERSION = 4
|
||||
pkg syscall (openbsd-amd64), const SIOCBRDGDADDR = 2150132039
|
||||
pkg syscall (openbsd-amd64), const SIOCBRDGSADDR = 3223873860
|
||||
pkg syscall (openbsd-amd64), const SYS_CLOCK_GETRES = 234
|
||||
pkg syscall (openbsd-amd64), const SYS_CLOCK_GETTIME = 232
|
||||
pkg syscall (openbsd-amd64), const SYS_CLOCK_SETTIME = 233
|
||||
pkg syscall (openbsd-amd64), const SYS_FHSTATFS = 309
|
||||
pkg syscall (openbsd-amd64), const SYS_FSTAT = 292
|
||||
pkg syscall (openbsd-amd64), const SYS_FSTATAT = 316
|
||||
pkg syscall (openbsd-amd64), const SYS_FSTATFS = 308
|
||||
pkg syscall (openbsd-amd64), const SYS_FUTIMENS = 327
|
||||
pkg syscall (openbsd-amd64), const SYS_FUTIMES = 206
|
||||
pkg syscall (openbsd-amd64), const SYS_GETDIRENTRIES = 312
|
||||
pkg syscall (openbsd-amd64), const SYS_GETDIRENTRIES ideal-int
|
||||
pkg syscall (openbsd-amd64), const SYS_GETFSSTAT = 306
|
||||
pkg syscall (openbsd-amd64), const SYS_GETITIMER = 86
|
||||
pkg syscall (openbsd-amd64), const SYS_GETRUSAGE = 117
|
||||
pkg syscall (openbsd-amd64), const SYS_GETTIMEOFDAY = 116
|
||||
pkg syscall (openbsd-amd64), const SYS_KEVENT = 270
|
||||
pkg syscall (openbsd-amd64), const SYS_LSTAT = 293
|
||||
pkg syscall (openbsd-amd64), const SYS_NANOSLEEP = 240
|
||||
pkg syscall (openbsd-amd64), const SYS_SELECT = 93
|
||||
pkg syscall (openbsd-amd64), const SYS_SETITIMER = 83
|
||||
pkg syscall (openbsd-amd64), const SYS_SETTIMEOFDAY = 122
|
||||
pkg syscall (openbsd-amd64), const SYS_STAT = 291
|
||||
pkg syscall (openbsd-amd64), const SYS_STATFS = 307
|
||||
pkg syscall (openbsd-amd64), const SYS_UTIMENSAT = 326
|
||||
pkg syscall (openbsd-amd64), const SYS_UTIMES = 138
|
||||
pkg syscall (openbsd-amd64), const SYS_WAIT4 = 7
|
||||
pkg syscall (openbsd-amd64), const SYS___THRSLEEP = 300
|
||||
pkg syscall (openbsd-amd64), const SizeofRtMetrics = 48
|
||||
pkg syscall (openbsd-amd64), const SizeofRtMsghdr = 88
|
||||
pkg syscall (openbsd-amd64), type Dirent struct, Fileno uint32
|
||||
pkg syscall (openbsd-amd64), type FdSet struct, Bits [32]int32
|
||||
pkg syscall (openbsd-amd64), type Kevent_t struct, Data int32
|
||||
pkg syscall (openbsd-amd64), type Kevent_t struct, Ident uint32
|
||||
pkg syscall (openbsd-amd64), type Mclpool struct, Grown uint32
|
||||
pkg syscall (openbsd-amd64), type RtMetrics struct, Expire uint32
|
||||
pkg syscall (openbsd-amd64), type Stat_t struct, Ino uint32
|
||||
pkg syscall (openbsd-amd64), type Stat_t struct, Lspare0 int32
|
||||
pkg syscall (openbsd-amd64), type Stat_t struct, Lspare1 int32
|
||||
pkg syscall (openbsd-amd64), type Stat_t struct, Qspare [2]int64
|
||||
pkg syscall (openbsd-amd64), type Statfs_t struct, F_ctime uint32
|
||||
pkg syscall (openbsd-amd64), type Statfs_t struct, F_spare [3]uint32
|
||||
pkg syscall (openbsd-amd64), type Statfs_t struct, Pad_cgo_1 [4]uint8
|
||||
pkg syscall (openbsd-amd64), type Timespec struct, Pad_cgo_0 [4]uint8
|
||||
pkg syscall (openbsd-amd64), type Timespec struct, Sec int32
|
||||
pkg syscall (openbsd-amd64-cgo), const CCR0_FLUSH = 16
|
||||
pkg syscall (openbsd-amd64-cgo), const CCR0_FLUSH ideal-int
|
||||
pkg syscall (openbsd-amd64-cgo), const CPUID_CFLUSH = 524288
|
||||
pkg syscall (openbsd-amd64-cgo), const CPUID_CFLUSH ideal-int
|
||||
pkg syscall (openbsd-amd64-cgo), const EFER_LMA = 1024
|
||||
pkg syscall (openbsd-amd64-cgo), const EFER_LMA ideal-int
|
||||
pkg syscall (openbsd-amd64-cgo), const EFER_LME = 256
|
||||
pkg syscall (openbsd-amd64-cgo), const EFER_LME ideal-int
|
||||
pkg syscall (openbsd-amd64-cgo), const EFER_NXE = 2048
|
||||
pkg syscall (openbsd-amd64-cgo), const EFER_NXE ideal-int
|
||||
pkg syscall (openbsd-amd64-cgo), const EFER_SCE = 1
|
||||
pkg syscall (openbsd-amd64-cgo), const EFER_SCE ideal-int
|
||||
pkg syscall (openbsd-amd64-cgo), const PMC5_PIPELINE_FLUSH = 21
|
||||
pkg syscall (openbsd-amd64-cgo), const PMC5_PIPELINE_FLUSH ideal-int
|
||||
pkg syscall (openbsd-amd64-cgo), const RTF_FMASK = 63496
|
||||
pkg syscall (openbsd-amd64-cgo), const RTM_VERSION = 4
|
||||
pkg syscall (openbsd-amd64-cgo), const SIOCBRDGDADDR = 2150132039
|
||||
pkg syscall (openbsd-amd64-cgo), const SIOCBRDGSADDR = 3223873860
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_CLOCK_GETRES = 234
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_CLOCK_GETTIME = 232
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_CLOCK_SETTIME = 233
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_FHSTATFS = 309
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_FSTAT = 292
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_FSTATAT = 316
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_FSTATFS = 308
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_FUTIMENS = 327
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_FUTIMES = 206
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_GETDIRENTRIES = 312
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_GETDIRENTRIES ideal-int
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_GETFSSTAT = 306
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_GETITIMER = 86
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_GETRUSAGE = 117
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_GETTIMEOFDAY = 116
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_KEVENT = 270
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_LSTAT = 293
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_NANOSLEEP = 240
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_SELECT = 93
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_SETITIMER = 83
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_SETTIMEOFDAY = 122
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_STAT = 291
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_STATFS = 307
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_UTIMENSAT = 326
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_UTIMES = 138
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS_WAIT4 = 7
|
||||
pkg syscall (openbsd-amd64-cgo), const SYS___THRSLEEP = 300
|
||||
pkg syscall (openbsd-amd64-cgo), const SizeofRtMetrics = 48
|
||||
pkg syscall (openbsd-amd64-cgo), const SizeofRtMsghdr = 88
|
||||
pkg syscall (openbsd-amd64-cgo), type Dirent struct, Fileno uint32
|
||||
pkg syscall (openbsd-amd64-cgo), type FdSet struct, Bits [32]int32
|
||||
pkg syscall (openbsd-amd64-cgo), type Kevent_t struct, Data int32
|
||||
pkg syscall (openbsd-amd64-cgo), type Kevent_t struct, Ident uint32
|
||||
pkg syscall (openbsd-amd64-cgo), type Mclpool struct, Grown uint32
|
||||
pkg syscall (openbsd-amd64-cgo), type RtMetrics struct, Expire uint32
|
||||
pkg syscall (openbsd-amd64-cgo), type Stat_t struct, Ino uint32
|
||||
pkg syscall (openbsd-amd64-cgo), type Stat_t struct, Lspare0 int32
|
||||
pkg syscall (openbsd-amd64-cgo), type Stat_t struct, Lspare1 int32
|
||||
pkg syscall (openbsd-amd64-cgo), type Stat_t struct, Qspare [2]int64
|
||||
pkg syscall (openbsd-amd64-cgo), type Statfs_t struct, F_ctime uint32
|
||||
pkg syscall (openbsd-amd64-cgo), type Statfs_t struct, F_spare [3]uint32
|
||||
pkg syscall (openbsd-amd64-cgo), type Statfs_t struct, Pad_cgo_1 [4]uint8
|
||||
pkg syscall (openbsd-amd64-cgo), type Timespec struct, Pad_cgo_0 [4]uint8
|
||||
pkg syscall (openbsd-amd64-cgo), type Timespec struct, Sec int32
|
||||
pkg testing, func RegisterCover(Cover)
|
||||
pkg testing, func MainStart(func(string, string) (bool, error), []InternalTest, []InternalBenchmark, []InternalExample) *M
|
||||
pkg text/template/parse, type DotNode bool
|
||||
pkg text/template/parse, type Node interface { Copy, String, Type }
|
||||
pkg unicode, const Version = "6.2.0"
|
||||
pkg unicode, const Version = "6.3.0"
|
||||
pkg unicode, const Version = "7.0.0"
|
||||
pkg unicode, const Version = "8.0.0"
|
||||
50427
api/go1.1.txt
50427
api/go1.1.txt
File diff suppressed because it is too large
Load Diff
32484
api/go1.2.txt
32484
api/go1.2.txt
File diff suppressed because it is too large
Load Diff
2053
api/go1.3.txt
2053
api/go1.3.txt
File diff suppressed because it is too large
Load Diff
604
api/go1.4.txt
604
api/go1.4.txt
@@ -1,604 +0,0 @@
|
||||
# CL 134210043 archive/zip: add Writer.Flush, Brad Fitzpatrick <bradfitz@golang.org>
|
||||
pkg archive/zip, method (*Writer) Flush() error
|
||||
|
||||
# CL 97140043 compress/flate: add Reset() to allow reusing large buffers to compress multiple buffers, James Robinson <jamesr@google.com>
|
||||
pkg compress/flate, type Resetter interface { Reset }
|
||||
pkg compress/flate, type Resetter interface, Reset(io.Reader, []uint8) error
|
||||
pkg compress/zlib, type Resetter interface { Reset }
|
||||
pkg compress/zlib, type Resetter interface, Reset(io.Reader, []uint8) error
|
||||
|
||||
# CL 159120044 compress/gzip: allow stopping at end of first stream, Russ Cox <rsc@golang.org>
|
||||
pkg compress/gzip, method (*Reader) Multistream(bool)
|
||||
|
||||
# CL 138800043 crypto: Add SHA3 functions in go.crypto/sha3 to the Hash enum., David Leon Gil <coruus@gmail.com>
|
||||
pkg crypto, const SHA3_224 = 10
|
||||
pkg crypto, const SHA3_224 Hash
|
||||
pkg crypto, const SHA3_256 = 11
|
||||
pkg crypto, const SHA3_256 Hash
|
||||
pkg crypto, const SHA3_384 = 12
|
||||
pkg crypto, const SHA3_384 Hash
|
||||
pkg crypto, const SHA3_512 = 13
|
||||
pkg crypto, const SHA3_512 Hash
|
||||
|
||||
# CL 114680043 crypto: add Signer, Adam Langley <agl@golang.org>
|
||||
pkg crypto, method (Hash) HashFunc() Hash
|
||||
pkg crypto, type Signer interface { Public, Sign }
|
||||
pkg crypto, type Signer interface, Public() PublicKey
|
||||
pkg crypto, type Signer interface, Sign(io.Reader, []uint8, SignerOpts) ([]uint8, error)
|
||||
pkg crypto, type SignerOpts interface { HashFunc }
|
||||
pkg crypto, type SignerOpts interface, HashFunc() Hash
|
||||
pkg crypto/ecdsa, method (*PrivateKey) Public() crypto.PublicKey
|
||||
pkg crypto/ecdsa, method (*PrivateKey) Sign(io.Reader, []uint8, crypto.SignerOpts) ([]uint8, error)
|
||||
pkg crypto/rsa, method (*PSSOptions) HashFunc() crypto.Hash
|
||||
pkg crypto/rsa, method (*PrivateKey) Public() crypto.PublicKey
|
||||
pkg crypto/rsa, method (*PrivateKey) Sign(io.Reader, []uint8, crypto.SignerOpts) ([]uint8, error)
|
||||
pkg crypto/rsa, type PSSOptions struct, Hash crypto.Hash
|
||||
|
||||
# CL 157090043 crypto/tls: support TLS_FALLBACK_SCSV as a server., Adam Langley <agl@golang.org>
|
||||
pkg crypto/tls, const TLS_FALLBACK_SCSV = 22016
|
||||
pkg crypto/tls, const TLS_FALLBACK_SCSV uint16
|
||||
|
||||
# CL 107400043 crypto/tls: Added dynamic alternative to NameToCertificate map for SNI, Percy Wegmann <ox.to.a.cart@gmail.com>
|
||||
pkg crypto/tls, type ClientHelloInfo struct
|
||||
pkg crypto/tls, type ClientHelloInfo struct, CipherSuites []uint16
|
||||
pkg crypto/tls, type ClientHelloInfo struct, ServerName string
|
||||
pkg crypto/tls, type ClientHelloInfo struct, SupportedCurves []CurveID
|
||||
pkg crypto/tls, type ClientHelloInfo struct, SupportedPoints []uint8
|
||||
pkg crypto/tls, type Config struct, GetCertificate func(*ClientHelloInfo) (*Certificate, error)
|
||||
pkg crypto/tls, type ConnectionState struct, TLSUnique []uint8
|
||||
|
||||
# CL 153420045 crypto/x509: continue to recognise MaxPathLen of zero as "no value"., Adam Langley <agl@golang.org>
|
||||
pkg crypto/x509, type Certificate struct, MaxPathLenZero bool
|
||||
|
||||
# CL 158950043 database/sql: add Drivers, returning list of registered drivers, Russ Cox <rsc@golang.org>
|
||||
pkg database/sql, func Drivers() []string
|
||||
|
||||
# CL 117280043 debug/dwarf: fix Reader panic on DW_TAG_unspecified_type, Derek Parker <parkerderek86@gmail.com>
|
||||
pkg debug/dwarf, method (*UnspecifiedType) Basic() *BasicType
|
||||
pkg debug/dwarf, method (*UnspecifiedType) Common() *CommonType
|
||||
pkg debug/dwarf, method (*UnspecifiedType) Size() int64
|
||||
pkg debug/dwarf, method (*UnspecifiedType) String() string
|
||||
pkg debug/dwarf, type UnspecifiedType struct
|
||||
pkg debug/dwarf, type UnspecifiedType struct, embedded BasicType
|
||||
|
||||
# CL 132000043 debug/elf: support arm64 relocations, Michael Hudson-Doyle <michael.hudson@linaro.org>
|
||||
pkg debug/elf, const EM_AARCH64 = 183
|
||||
pkg debug/elf, const EM_AARCH64 Machine
|
||||
pkg debug/elf, const R_AARCH64_ABS16 = 259
|
||||
pkg debug/elf, const R_AARCH64_ABS16 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_ABS32 = 258
|
||||
pkg debug/elf, const R_AARCH64_ABS32 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_ABS64 = 257
|
||||
pkg debug/elf, const R_AARCH64_ABS64 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_ADD_ABS_LO12_NC = 277
|
||||
pkg debug/elf, const R_AARCH64_ADD_ABS_LO12_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_ADR_GOT_PAGE = 311
|
||||
pkg debug/elf, const R_AARCH64_ADR_GOT_PAGE R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_ADR_PREL_LO21 = 274
|
||||
pkg debug/elf, const R_AARCH64_ADR_PREL_LO21 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_ADR_PREL_PG_HI21 = 275
|
||||
pkg debug/elf, const R_AARCH64_ADR_PREL_PG_HI21 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_ADR_PREL_PG_HI21_NC = 276
|
||||
pkg debug/elf, const R_AARCH64_ADR_PREL_PG_HI21_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_CALL26 = 283
|
||||
pkg debug/elf, const R_AARCH64_CALL26 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_CONDBR19 = 280
|
||||
pkg debug/elf, const R_AARCH64_CONDBR19 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_COPY = 1024
|
||||
pkg debug/elf, const R_AARCH64_COPY R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_GLOB_DAT = 1025
|
||||
pkg debug/elf, const R_AARCH64_GLOB_DAT R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_GOT_LD_PREL19 = 309
|
||||
pkg debug/elf, const R_AARCH64_GOT_LD_PREL19 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_IRELATIVE = 1032
|
||||
pkg debug/elf, const R_AARCH64_IRELATIVE R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_JUMP26 = 282
|
||||
pkg debug/elf, const R_AARCH64_JUMP26 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_JUMP_SLOT = 1026
|
||||
pkg debug/elf, const R_AARCH64_JUMP_SLOT R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_LD64_GOT_LO12_NC = 312
|
||||
pkg debug/elf, const R_AARCH64_LD64_GOT_LO12_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_LDST128_ABS_LO12_NC = 299
|
||||
pkg debug/elf, const R_AARCH64_LDST128_ABS_LO12_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_LDST16_ABS_LO12_NC = 284
|
||||
pkg debug/elf, const R_AARCH64_LDST16_ABS_LO12_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_LDST32_ABS_LO12_NC = 285
|
||||
pkg debug/elf, const R_AARCH64_LDST32_ABS_LO12_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_LDST64_ABS_LO12_NC = 286
|
||||
pkg debug/elf, const R_AARCH64_LDST64_ABS_LO12_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_LDST8_ABS_LO12_NC = 278
|
||||
pkg debug/elf, const R_AARCH64_LDST8_ABS_LO12_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_LD_PREL_LO19 = 273
|
||||
pkg debug/elf, const R_AARCH64_LD_PREL_LO19 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_MOVW_SABS_G0 = 270
|
||||
pkg debug/elf, const R_AARCH64_MOVW_SABS_G0 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_MOVW_SABS_G1 = 271
|
||||
pkg debug/elf, const R_AARCH64_MOVW_SABS_G1 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_MOVW_SABS_G2 = 272
|
||||
pkg debug/elf, const R_AARCH64_MOVW_SABS_G2 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_MOVW_UABS_G0 = 263
|
||||
pkg debug/elf, const R_AARCH64_MOVW_UABS_G0 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_MOVW_UABS_G0_NC = 264
|
||||
pkg debug/elf, const R_AARCH64_MOVW_UABS_G0_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_MOVW_UABS_G1 = 265
|
||||
pkg debug/elf, const R_AARCH64_MOVW_UABS_G1 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_MOVW_UABS_G1_NC = 266
|
||||
pkg debug/elf, const R_AARCH64_MOVW_UABS_G1_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_MOVW_UABS_G2 = 267
|
||||
pkg debug/elf, const R_AARCH64_MOVW_UABS_G2 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_MOVW_UABS_G2_NC = 268
|
||||
pkg debug/elf, const R_AARCH64_MOVW_UABS_G2_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_MOVW_UABS_G3 = 269
|
||||
pkg debug/elf, const R_AARCH64_MOVW_UABS_G3 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_NONE = 0
|
||||
pkg debug/elf, const R_AARCH64_NONE R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_NULL = 256
|
||||
pkg debug/elf, const R_AARCH64_NULL R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_ABS16 = 2
|
||||
pkg debug/elf, const R_AARCH64_P32_ABS16 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_ABS32 = 1
|
||||
pkg debug/elf, const R_AARCH64_P32_ABS32 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_ADD_ABS_LO12_NC = 12
|
||||
pkg debug/elf, const R_AARCH64_P32_ADD_ABS_LO12_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_ADR_GOT_PAGE = 26
|
||||
pkg debug/elf, const R_AARCH64_P32_ADR_GOT_PAGE R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_ADR_PREL_LO21 = 10
|
||||
pkg debug/elf, const R_AARCH64_P32_ADR_PREL_LO21 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_ADR_PREL_PG_HI21 = 11
|
||||
pkg debug/elf, const R_AARCH64_P32_ADR_PREL_PG_HI21 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_CALL26 = 21
|
||||
pkg debug/elf, const R_AARCH64_P32_CALL26 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_CONDBR19 = 19
|
||||
pkg debug/elf, const R_AARCH64_P32_CONDBR19 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_COPY = 180
|
||||
pkg debug/elf, const R_AARCH64_P32_COPY R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_GLOB_DAT = 181
|
||||
pkg debug/elf, const R_AARCH64_P32_GLOB_DAT R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_GOT_LD_PREL19 = 25
|
||||
pkg debug/elf, const R_AARCH64_P32_GOT_LD_PREL19 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_IRELATIVE = 188
|
||||
pkg debug/elf, const R_AARCH64_P32_IRELATIVE R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_JUMP26 = 20
|
||||
pkg debug/elf, const R_AARCH64_P32_JUMP26 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_JUMP_SLOT = 182
|
||||
pkg debug/elf, const R_AARCH64_P32_JUMP_SLOT R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_LD32_GOT_LO12_NC = 27
|
||||
pkg debug/elf, const R_AARCH64_P32_LD32_GOT_LO12_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_LDST128_ABS_LO12_NC = 17
|
||||
pkg debug/elf, const R_AARCH64_P32_LDST128_ABS_LO12_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_LDST16_ABS_LO12_NC = 14
|
||||
pkg debug/elf, const R_AARCH64_P32_LDST16_ABS_LO12_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_LDST32_ABS_LO12_NC = 15
|
||||
pkg debug/elf, const R_AARCH64_P32_LDST32_ABS_LO12_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_LDST64_ABS_LO12_NC = 16
|
||||
pkg debug/elf, const R_AARCH64_P32_LDST64_ABS_LO12_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_LDST8_ABS_LO12_NC = 13
|
||||
pkg debug/elf, const R_AARCH64_P32_LDST8_ABS_LO12_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_LD_PREL_LO19 = 9
|
||||
pkg debug/elf, const R_AARCH64_P32_LD_PREL_LO19 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_MOVW_SABS_G0 = 8
|
||||
pkg debug/elf, const R_AARCH64_P32_MOVW_SABS_G0 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_MOVW_UABS_G0 = 5
|
||||
pkg debug/elf, const R_AARCH64_P32_MOVW_UABS_G0 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_MOVW_UABS_G0_NC = 6
|
||||
pkg debug/elf, const R_AARCH64_P32_MOVW_UABS_G0_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_MOVW_UABS_G1 = 7
|
||||
pkg debug/elf, const R_AARCH64_P32_MOVW_UABS_G1 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_PREL16 = 4
|
||||
pkg debug/elf, const R_AARCH64_P32_PREL16 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_PREL32 = 3
|
||||
pkg debug/elf, const R_AARCH64_P32_PREL32 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_RELATIVE = 183
|
||||
pkg debug/elf, const R_AARCH64_P32_RELATIVE R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSDESC = 187
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSDESC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSDESC_ADD_LO12_NC = 126
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSDESC_ADD_LO12_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSDESC_ADR_PAGE21 = 124
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSDESC_ADR_PAGE21 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSDESC_ADR_PREL21 = 123
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSDESC_ADR_PREL21 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSDESC_CALL = 127
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSDESC_CALL R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSDESC_LD32_LO12_NC = 125
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSDESC_LD32_LO12_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSDESC_LD_PREL19 = 122
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSDESC_LD_PREL19 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSGD_ADD_LO12_NC = 82
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSGD_ADD_LO12_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSGD_ADR_PAGE21 = 81
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSGD_ADR_PAGE21 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSIE_ADR_GOTTPREL_PAGE21 = 103
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSIE_ADR_GOTTPREL_PAGE21 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSIE_LD32_GOTTPREL_LO12_NC = 104
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSIE_LD32_GOTTPREL_LO12_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSIE_LD_GOTTPREL_PREL19 = 105
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSIE_LD_GOTTPREL_PREL19 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSLE_ADD_TPREL_HI12 = 109
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSLE_ADD_TPREL_HI12 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSLE_ADD_TPREL_LO12 = 110
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSLE_ADD_TPREL_LO12 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSLE_ADD_TPREL_LO12_NC = 111
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSLE_ADD_TPREL_LO12_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSLE_MOVW_TPREL_G0 = 107
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSLE_MOVW_TPREL_G0 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSLE_MOVW_TPREL_G0_NC = 108
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSLE_MOVW_TPREL_G0_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSLE_MOVW_TPREL_G1 = 106
|
||||
pkg debug/elf, const R_AARCH64_P32_TLSLE_MOVW_TPREL_G1 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_TLS_DTPMOD = 184
|
||||
pkg debug/elf, const R_AARCH64_P32_TLS_DTPMOD R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_TLS_DTPREL = 185
|
||||
pkg debug/elf, const R_AARCH64_P32_TLS_DTPREL R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_TLS_TPREL = 186
|
||||
pkg debug/elf, const R_AARCH64_P32_TLS_TPREL R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_P32_TSTBR14 = 18
|
||||
pkg debug/elf, const R_AARCH64_P32_TSTBR14 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_PREL16 = 262
|
||||
pkg debug/elf, const R_AARCH64_PREL16 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_PREL32 = 261
|
||||
pkg debug/elf, const R_AARCH64_PREL32 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_PREL64 = 260
|
||||
pkg debug/elf, const R_AARCH64_PREL64 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_RELATIVE = 1027
|
||||
pkg debug/elf, const R_AARCH64_RELATIVE R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSDESC = 1031
|
||||
pkg debug/elf, const R_AARCH64_TLSDESC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSDESC_ADD = 568
|
||||
pkg debug/elf, const R_AARCH64_TLSDESC_ADD R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSDESC_ADD_LO12_NC = 564
|
||||
pkg debug/elf, const R_AARCH64_TLSDESC_ADD_LO12_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSDESC_ADR_PAGE21 = 562
|
||||
pkg debug/elf, const R_AARCH64_TLSDESC_ADR_PAGE21 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSDESC_ADR_PREL21 = 561
|
||||
pkg debug/elf, const R_AARCH64_TLSDESC_ADR_PREL21 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSDESC_CALL = 569
|
||||
pkg debug/elf, const R_AARCH64_TLSDESC_CALL R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSDESC_LD64_LO12_NC = 563
|
||||
pkg debug/elf, const R_AARCH64_TLSDESC_LD64_LO12_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSDESC_LDR = 567
|
||||
pkg debug/elf, const R_AARCH64_TLSDESC_LDR R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSDESC_LD_PREL19 = 560
|
||||
pkg debug/elf, const R_AARCH64_TLSDESC_LD_PREL19 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSDESC_OFF_G0_NC = 566
|
||||
pkg debug/elf, const R_AARCH64_TLSDESC_OFF_G0_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSDESC_OFF_G1 = 565
|
||||
pkg debug/elf, const R_AARCH64_TLSDESC_OFF_G1 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSGD_ADD_LO12_NC = 514
|
||||
pkg debug/elf, const R_AARCH64_TLSGD_ADD_LO12_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSGD_ADR_PAGE21 = 513
|
||||
pkg debug/elf, const R_AARCH64_TLSGD_ADR_PAGE21 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21 = 541
|
||||
pkg debug/elf, const R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC = 542
|
||||
pkg debug/elf, const R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSIE_LD_GOTTPREL_PREL19 = 543
|
||||
pkg debug/elf, const R_AARCH64_TLSIE_LD_GOTTPREL_PREL19 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSIE_MOVW_GOTTPREL_G0_NC = 540
|
||||
pkg debug/elf, const R_AARCH64_TLSIE_MOVW_GOTTPREL_G0_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSIE_MOVW_GOTTPREL_G1 = 539
|
||||
pkg debug/elf, const R_AARCH64_TLSIE_MOVW_GOTTPREL_G1 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSLE_ADD_TPREL_HI12 = 549
|
||||
pkg debug/elf, const R_AARCH64_TLSLE_ADD_TPREL_HI12 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSLE_ADD_TPREL_LO12 = 550
|
||||
pkg debug/elf, const R_AARCH64_TLSLE_ADD_TPREL_LO12 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSLE_ADD_TPREL_LO12_NC = 551
|
||||
pkg debug/elf, const R_AARCH64_TLSLE_ADD_TPREL_LO12_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G0 = 547
|
||||
pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G0 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G0_NC = 548
|
||||
pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G0_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G1 = 545
|
||||
pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G1 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G1_NC = 546
|
||||
pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G1_NC R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G2 = 544
|
||||
pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G2 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLS_DTPMOD64 = 1028
|
||||
pkg debug/elf, const R_AARCH64_TLS_DTPMOD64 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLS_DTPREL64 = 1029
|
||||
pkg debug/elf, const R_AARCH64_TLS_DTPREL64 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TLS_TPREL64 = 1030
|
||||
pkg debug/elf, const R_AARCH64_TLS_TPREL64 R_AARCH64
|
||||
pkg debug/elf, const R_AARCH64_TSTBR14 = 279
|
||||
pkg debug/elf, const R_AARCH64_TSTBR14 R_AARCH64
|
||||
pkg debug/elf, method (R_AARCH64) GoString() string
|
||||
pkg debug/elf, method (R_AARCH64) String() string
|
||||
pkg debug/elf, type R_AARCH64 int
|
||||
|
||||
# CL 107530043 debug/elf: add (*File).DynamicSymbols, ErrNoSymbols, and tests for (*File).Symbols and (*File).DynamicSymbols, and formalize symbol order., Pietro Gagliardi <pietro10@mac.com>
|
||||
pkg debug/elf, method (*File) DynamicSymbols() ([]Symbol, error)
|
||||
pkg debug/elf, var ErrNoSymbols error
|
||||
|
||||
# CL 106460044 debug/plan9obj, cmd/addr2line: on Plan 9 use a.out header, Aram Hăvărneanu <aram@mgk.ro>
|
||||
pkg debug/plan9obj, type FileHeader struct, HdrSize uint64
|
||||
pkg debug/plan9obj, type FileHeader struct, LoadAddress uint64
|
||||
|
||||
# CL 122960043 encoding/xml: add InputOffset method to Decoder, Russ Cox <rsc@golang.org>
|
||||
pkg encoding/xml, method (*Decoder) InputOffset() int64
|
||||
|
||||
# CL 124940043 cmd/go, go/build: implement import comment checking, Russ Cox <rsc@golang.org>
|
||||
pkg go/build, const ImportComment = 4
|
||||
pkg go/build, const ImportComment ImportMode
|
||||
pkg go/build, type Package struct, ImportComment string
|
||||
|
||||
# CL 155050043 go/build: Return MultiplePackageError on importing a dir containing multiple packages, Jens Frederich <jfrederich@gmail.com>
|
||||
pkg go/build, method (*MultiplePackageError) Error() string
|
||||
pkg go/build, type MultiplePackageError struct
|
||||
pkg go/build, type MultiplePackageError struct, Dir string
|
||||
pkg go/build, type MultiplePackageError struct, Files []string
|
||||
pkg go/build, type MultiplePackageError struct, Packages []string
|
||||
|
||||
# CL 135110044 go/token: implement PositionFor accessors, Robert Griesemer <gri@golang.org>
|
||||
pkg go/token, method (*File) PositionFor(Pos, bool) Position
|
||||
pkg go/token, method (*FileSet) PositionFor(Pos, bool) Position
|
||||
|
||||
# CL 109000049 image: add RGBAAt, Gray16At, etc., ChaiShushan <chaishushan@gmail.com>
|
||||
pkg image, method (*Alpha) AlphaAt(int, int) color.Alpha
|
||||
pkg image, method (*Alpha16) Alpha16At(int, int) color.Alpha16
|
||||
pkg image, method (*Gray) GrayAt(int, int) color.Gray
|
||||
pkg image, method (*Gray16) Gray16At(int, int) color.Gray16
|
||||
pkg image, method (*NRGBA) NRGBAAt(int, int) color.NRGBA
|
||||
pkg image, method (*NRGBA64) NRGBA64At(int, int) color.NRGBA64
|
||||
pkg image, method (*RGBA) RGBAAt(int, int) color.RGBA
|
||||
pkg image, method (*RGBA64) RGBA64At(int, int) color.RGBA64
|
||||
pkg image, method (*YCbCr) YCbCrAt(int, int) color.YCbCr
|
||||
|
||||
# CL 129190043 png: make the encoder configurable, Jeff R. Allen <jra@nella.org>
|
||||
pkg image/png, const BestCompression = -3
|
||||
pkg image/png, const BestCompression CompressionLevel
|
||||
pkg image/png, const BestSpeed = -2
|
||||
pkg image/png, const BestSpeed CompressionLevel
|
||||
pkg image/png, const DefaultCompression = 0
|
||||
pkg image/png, const DefaultCompression CompressionLevel
|
||||
pkg image/png, const NoCompression = -1
|
||||
pkg image/png, const NoCompression CompressionLevel
|
||||
pkg image/png, method (*Encoder) Encode(io.Writer, image.Image) error
|
||||
pkg image/png, type CompressionLevel int
|
||||
pkg image/png, type Encoder struct
|
||||
pkg image/png, type Encoder struct, CompressionLevel CompressionLevel
|
||||
|
||||
# CL 101750048 math: implement Nextafter32, Robert Griesemer <gri@golang.org>
|
||||
pkg math, func Nextafter32(float32, float32) float32
|
||||
|
||||
# CL 93550043 math/big: implement Rat.Float32, Robert Griesemer <gri@golang.org>
|
||||
pkg math/big, method (*Rat) Float32() (float32, bool)
|
||||
|
||||
# CL 76540043 net/http: add BasicAuth method to *http.Request, Kelsey Hightower <kelsey.hightower@gmail.com>
|
||||
pkg net/http, method (*Request) BasicAuth() (string, string, bool)
|
||||
|
||||
# CL 137940043 net/http: add Transport.DialTLS hook, Brad Fitzpatrick <bradfitz@golang.org>
|
||||
pkg net/http, type Transport struct, DialTLS func(string, string) (net.Conn, error)
|
||||
|
||||
# CL 132750043 net/http/httputil: Pass a Logger to ReverseProxy, allowing the user to control logging., Mark Theunissen <mark.theunissen@gmail.com>
|
||||
pkg net/http/httputil, type ReverseProxy struct, ErrorLog *log.Logger
|
||||
|
||||
# CL 148370043 os, syscall: add Unsetenv, Brad Fitzpatrick <bradfitz@golang.org>
|
||||
pkg os, func Unsetenv(string) error
|
||||
pkg syscall, func Unsetenv(string) error
|
||||
|
||||
# CL 144020043 reflect: add Type.Comparable, Russ Cox <rsc@golang.org>
|
||||
pkg reflect, type Type interface, Comparable() bool
|
||||
|
||||
# CL 153670043 runtime: add PauseEnd array to MemStats and GCStats, Jens Frederich <jfrederich@gmail.com>
|
||||
pkg runtime, type MemStats struct, PauseEnd [256]uint64
|
||||
pkg runtime/debug, type GCStats struct, PauseEnd []time.Time
|
||||
|
||||
# CL 136710045 sync/atomic: add Value, Dmitriy Vyukov <dvyukov@google.com>
|
||||
pkg sync/atomic, method (*Value) Load() interface{}
|
||||
pkg sync/atomic, method (*Value) Store(interface{})
|
||||
pkg sync/atomic, type Value struct
|
||||
|
||||
# CL 126190043 syscall: support UID/GID map files for Linux user namespaces, Mrunal Patel <mrunalp@gmail.com>
|
||||
pkg syscall (linux-386), type SysProcAttr struct, GidMappings []SysProcIDMap
|
||||
pkg syscall (linux-386), type SysProcAttr struct, UidMappings []SysProcIDMap
|
||||
pkg syscall (linux-386), type SysProcIDMap struct
|
||||
pkg syscall (linux-386), type SysProcIDMap struct, ContainerID int
|
||||
pkg syscall (linux-386), type SysProcIDMap struct, HostID int
|
||||
pkg syscall (linux-386), type SysProcIDMap struct, Size int
|
||||
pkg syscall (linux-386-cgo), type SysProcAttr struct, GidMappings []SysProcIDMap
|
||||
pkg syscall (linux-386-cgo), type SysProcAttr struct, UidMappings []SysProcIDMap
|
||||
pkg syscall (linux-386-cgo), type SysProcIDMap struct
|
||||
pkg syscall (linux-386-cgo), type SysProcIDMap struct, ContainerID int
|
||||
pkg syscall (linux-386-cgo), type SysProcIDMap struct, HostID int
|
||||
pkg syscall (linux-386-cgo), type SysProcIDMap struct, Size int
|
||||
pkg syscall (linux-amd64), type SysProcAttr struct, GidMappings []SysProcIDMap
|
||||
pkg syscall (linux-amd64), type SysProcAttr struct, UidMappings []SysProcIDMap
|
||||
pkg syscall (linux-amd64), type SysProcIDMap struct
|
||||
pkg syscall (linux-amd64), type SysProcIDMap struct, ContainerID int
|
||||
pkg syscall (linux-amd64), type SysProcIDMap struct, HostID int
|
||||
pkg syscall (linux-amd64), type SysProcIDMap struct, Size int
|
||||
pkg syscall (linux-amd64-cgo), type SysProcAttr struct, GidMappings []SysProcIDMap
|
||||
pkg syscall (linux-amd64-cgo), type SysProcAttr struct, UidMappings []SysProcIDMap
|
||||
pkg syscall (linux-amd64-cgo), type SysProcIDMap struct
|
||||
pkg syscall (linux-amd64-cgo), type SysProcIDMap struct, ContainerID int
|
||||
pkg syscall (linux-amd64-cgo), type SysProcIDMap struct, HostID int
|
||||
pkg syscall (linux-amd64-cgo), type SysProcIDMap struct, Size int
|
||||
pkg syscall (linux-arm), type SysProcAttr struct, GidMappings []SysProcIDMap
|
||||
pkg syscall (linux-arm), type SysProcAttr struct, UidMappings []SysProcIDMap
|
||||
pkg syscall (linux-arm), type SysProcIDMap struct
|
||||
pkg syscall (linux-arm), type SysProcIDMap struct, ContainerID int
|
||||
pkg syscall (linux-arm), type SysProcIDMap struct, HostID int
|
||||
pkg syscall (linux-arm), type SysProcIDMap struct, Size int
|
||||
pkg syscall (linux-arm-cgo), type SysProcAttr struct, GidMappings []SysProcIDMap
|
||||
pkg syscall (linux-arm-cgo), type SysProcAttr struct, UidMappings []SysProcIDMap
|
||||
pkg syscall (linux-arm-cgo), type SysProcIDMap struct
|
||||
pkg syscall (linux-arm-cgo), type SysProcIDMap struct, ContainerID int
|
||||
pkg syscall (linux-arm-cgo), type SysProcIDMap struct, HostID int
|
||||
pkg syscall (linux-arm-cgo), type SysProcIDMap struct, Size int
|
||||
|
||||
# CL 122200043 net: fix CNAME resolving on Windows, Egon Elbre <egonelbre@gmail.com>
|
||||
pkg syscall (windows-386), const DNS_INFO_NO_RECORDS = 9501
|
||||
pkg syscall (windows-386), const DNS_INFO_NO_RECORDS ideal-int
|
||||
pkg syscall (windows-386), const DnsSectionAdditional = 3
|
||||
pkg syscall (windows-386), const DnsSectionAdditional ideal-int
|
||||
pkg syscall (windows-386), const DnsSectionAnswer = 1
|
||||
pkg syscall (windows-386), const DnsSectionAnswer ideal-int
|
||||
pkg syscall (windows-386), const DnsSectionAuthority = 2
|
||||
pkg syscall (windows-386), const DnsSectionAuthority ideal-int
|
||||
pkg syscall (windows-386), const DnsSectionQuestion = 0
|
||||
pkg syscall (windows-386), const DnsSectionQuestion ideal-int
|
||||
pkg syscall (windows-386), func DnsNameCompare(*uint16, *uint16) bool
|
||||
pkg syscall (windows-amd64), const DNS_INFO_NO_RECORDS = 9501
|
||||
pkg syscall (windows-amd64), const DNS_INFO_NO_RECORDS ideal-int
|
||||
pkg syscall (windows-amd64), const DnsSectionAdditional = 3
|
||||
pkg syscall (windows-amd64), const DnsSectionAdditional ideal-int
|
||||
pkg syscall (windows-amd64), const DnsSectionAnswer = 1
|
||||
pkg syscall (windows-amd64), const DnsSectionAnswer ideal-int
|
||||
pkg syscall (windows-amd64), const DnsSectionAuthority = 2
|
||||
pkg syscall (windows-amd64), const DnsSectionAuthority ideal-int
|
||||
pkg syscall (windows-amd64), const DnsSectionQuestion = 0
|
||||
pkg syscall (windows-amd64), const DnsSectionQuestion ideal-int
|
||||
pkg syscall (windows-amd64), func DnsNameCompare(*uint16, *uint16) bool
|
||||
|
||||
# CL 86160044 os: Implement symlink support for Windows, Michael Fraenkel <michael.fraenkel@gmail.com>
|
||||
pkg syscall (windows-386), const ERROR_PRIVILEGE_NOT_HELD = 1314
|
||||
pkg syscall (windows-386), const ERROR_PRIVILEGE_NOT_HELD Errno
|
||||
pkg syscall (windows-amd64), const ERROR_PRIVILEGE_NOT_HELD = 1314
|
||||
pkg syscall (windows-amd64), const ERROR_PRIVILEGE_NOT_HELD Errno
|
||||
|
||||
# CL 86160044 os: Implement symlink support for Windows, Michael Fraenkel <michael.fraenkel@gmail.com>
|
||||
pkg syscall (windows-386), const FILE_ATTRIBUTE_REPARSE_POINT = 1024
|
||||
pkg syscall (windows-386), const FILE_ATTRIBUTE_REPARSE_POINT ideal-int
|
||||
pkg syscall (windows-386), const FILE_FLAG_OPEN_REPARSE_POINT = 2097152
|
||||
pkg syscall (windows-386), const FILE_FLAG_OPEN_REPARSE_POINT ideal-int
|
||||
pkg syscall (windows-386), const FSCTL_GET_REPARSE_POINT = 589992
|
||||
pkg syscall (windows-386), const FSCTL_GET_REPARSE_POINT ideal-int
|
||||
pkg syscall (windows-386), const IO_REPARSE_TAG_SYMLINK = 2684354572
|
||||
pkg syscall (windows-386), const IO_REPARSE_TAG_SYMLINK ideal-int
|
||||
pkg syscall (windows-386), const MAXIMUM_REPARSE_DATA_BUFFER_SIZE = 16384
|
||||
pkg syscall (windows-386), const MAXIMUM_REPARSE_DATA_BUFFER_SIZE ideal-int
|
||||
pkg syscall (windows-386), const SYMBOLIC_LINK_FLAG_DIRECTORY = 1
|
||||
pkg syscall (windows-386), const SYMBOLIC_LINK_FLAG_DIRECTORY ideal-int
|
||||
pkg syscall (windows-386), func CreateHardLink(*uint16, *uint16, uintptr) error
|
||||
pkg syscall (windows-386), func CreateSymbolicLink(*uint16, *uint16, uint32) error
|
||||
pkg syscall (windows-386), func DeviceIoControl(Handle, uint32, *uint8, uint32, *uint8, uint32, *uint32, *Overlapped) error
|
||||
pkg syscall (windows-386), func LoadCreateSymbolicLink() error
|
||||
pkg syscall (windows-amd64), const FILE_ATTRIBUTE_REPARSE_POINT = 1024
|
||||
pkg syscall (windows-amd64), const FILE_ATTRIBUTE_REPARSE_POINT ideal-int
|
||||
pkg syscall (windows-amd64), const FILE_FLAG_OPEN_REPARSE_POINT = 2097152
|
||||
pkg syscall (windows-amd64), const FILE_FLAG_OPEN_REPARSE_POINT ideal-int
|
||||
pkg syscall (windows-amd64), const FSCTL_GET_REPARSE_POINT = 589992
|
||||
pkg syscall (windows-amd64), const FSCTL_GET_REPARSE_POINT ideal-int
|
||||
pkg syscall (windows-amd64), const IO_REPARSE_TAG_SYMLINK = 2684354572
|
||||
pkg syscall (windows-amd64), const IO_REPARSE_TAG_SYMLINK ideal-int
|
||||
pkg syscall (windows-amd64), const MAXIMUM_REPARSE_DATA_BUFFER_SIZE = 16384
|
||||
pkg syscall (windows-amd64), const MAXIMUM_REPARSE_DATA_BUFFER_SIZE ideal-int
|
||||
pkg syscall (windows-amd64), const SYMBOLIC_LINK_FLAG_DIRECTORY = 1
|
||||
pkg syscall (windows-amd64), const SYMBOLIC_LINK_FLAG_DIRECTORY ideal-int
|
||||
pkg syscall (windows-amd64), func CreateHardLink(*uint16, *uint16, uintptr) error
|
||||
pkg syscall (windows-amd64), func CreateSymbolicLink(*uint16, *uint16, uint32) error
|
||||
pkg syscall (windows-amd64), func DeviceIoControl(Handle, uint32, *uint8, uint32, *uint8, uint32, *uint32, *Overlapped) error
|
||||
pkg syscall (windows-amd64), func LoadCreateSymbolicLink() error
|
||||
|
||||
# CL 149510043 net: disable SIO_UDP_CONNRESET behavior on windows., Ron Hashimoto <mail@h2so5.net>
|
||||
pkg syscall (windows-386), const SIO_UDP_CONNRESET = 2550136844
|
||||
pkg syscall (windows-386), const SIO_UDP_CONNRESET ideal-int
|
||||
pkg syscall (windows-amd64), const SIO_UDP_CONNRESET = 2550136844
|
||||
pkg syscall (windows-amd64), const SIO_UDP_CONNRESET ideal-int
|
||||
|
||||
# CL 102320044 syscall: implement syscall.Getppid() on Windows, Alan Shreve <alan@inconshreveable.com>
|
||||
pkg syscall (windows-386), const TH32CS_INHERIT = 2147483648
|
||||
pkg syscall (windows-386), const TH32CS_INHERIT ideal-int
|
||||
pkg syscall (windows-386), const TH32CS_SNAPALL = 15
|
||||
pkg syscall (windows-386), const TH32CS_SNAPALL ideal-int
|
||||
pkg syscall (windows-386), const TH32CS_SNAPHEAPLIST = 1
|
||||
pkg syscall (windows-386), const TH32CS_SNAPHEAPLIST ideal-int
|
||||
pkg syscall (windows-386), const TH32CS_SNAPMODULE = 8
|
||||
pkg syscall (windows-386), const TH32CS_SNAPMODULE ideal-int
|
||||
pkg syscall (windows-386), const TH32CS_SNAPMODULE32 = 16
|
||||
pkg syscall (windows-386), const TH32CS_SNAPMODULE32 ideal-int
|
||||
pkg syscall (windows-386), const TH32CS_SNAPPROCESS = 2
|
||||
pkg syscall (windows-386), const TH32CS_SNAPPROCESS ideal-int
|
||||
pkg syscall (windows-386), const TH32CS_SNAPTHREAD = 4
|
||||
pkg syscall (windows-386), const TH32CS_SNAPTHREAD ideal-int
|
||||
pkg syscall (windows-386), func CreateToolhelp32Snapshot(uint32, uint32) (Handle, error)
|
||||
pkg syscall (windows-386), func Process32First(Handle, *ProcessEntry32) error
|
||||
pkg syscall (windows-386), func Process32Next(Handle, *ProcessEntry32) error
|
||||
pkg syscall (windows-386), type ProcessEntry32 struct
|
||||
pkg syscall (windows-386), type ProcessEntry32 struct, DefaultHeapID uintptr
|
||||
pkg syscall (windows-386), type ProcessEntry32 struct, ExeFile [260]uint16
|
||||
pkg syscall (windows-386), type ProcessEntry32 struct, Flags uint32
|
||||
pkg syscall (windows-386), type ProcessEntry32 struct, ModuleID uint32
|
||||
pkg syscall (windows-386), type ProcessEntry32 struct, ParentProcessID uint32
|
||||
pkg syscall (windows-386), type ProcessEntry32 struct, PriClassBase int32
|
||||
pkg syscall (windows-386), type ProcessEntry32 struct, ProcessID uint32
|
||||
pkg syscall (windows-386), type ProcessEntry32 struct, Size uint32
|
||||
pkg syscall (windows-386), type ProcessEntry32 struct, Threads uint32
|
||||
pkg syscall (windows-386), type ProcessEntry32 struct, Usage uint32
|
||||
pkg syscall (windows-amd64), const TH32CS_INHERIT = 2147483648
|
||||
pkg syscall (windows-amd64), const TH32CS_INHERIT ideal-int
|
||||
pkg syscall (windows-amd64), const TH32CS_SNAPALL = 15
|
||||
pkg syscall (windows-amd64), const TH32CS_SNAPALL ideal-int
|
||||
pkg syscall (windows-amd64), const TH32CS_SNAPHEAPLIST = 1
|
||||
pkg syscall (windows-amd64), const TH32CS_SNAPHEAPLIST ideal-int
|
||||
pkg syscall (windows-amd64), const TH32CS_SNAPMODULE = 8
|
||||
pkg syscall (windows-amd64), const TH32CS_SNAPMODULE ideal-int
|
||||
pkg syscall (windows-amd64), const TH32CS_SNAPMODULE32 = 16
|
||||
pkg syscall (windows-amd64), const TH32CS_SNAPMODULE32 ideal-int
|
||||
pkg syscall (windows-amd64), const TH32CS_SNAPPROCESS = 2
|
||||
pkg syscall (windows-amd64), const TH32CS_SNAPPROCESS ideal-int
|
||||
pkg syscall (windows-amd64), const TH32CS_SNAPTHREAD = 4
|
||||
pkg syscall (windows-amd64), const TH32CS_SNAPTHREAD ideal-int
|
||||
pkg syscall (windows-amd64), func CreateToolhelp32Snapshot(uint32, uint32) (Handle, error)
|
||||
pkg syscall (windows-amd64), func Process32First(Handle, *ProcessEntry32) error
|
||||
pkg syscall (windows-amd64), func Process32Next(Handle, *ProcessEntry32) error
|
||||
pkg syscall (windows-amd64), type ProcessEntry32 struct
|
||||
pkg syscall (windows-amd64), type ProcessEntry32 struct, DefaultHeapID uintptr
|
||||
pkg syscall (windows-amd64), type ProcessEntry32 struct, ExeFile [260]uint16
|
||||
pkg syscall (windows-amd64), type ProcessEntry32 struct, Flags uint32
|
||||
pkg syscall (windows-amd64), type ProcessEntry32 struct, ModuleID uint32
|
||||
pkg syscall (windows-amd64), type ProcessEntry32 struct, ParentProcessID uint32
|
||||
pkg syscall (windows-amd64), type ProcessEntry32 struct, PriClassBase int32
|
||||
pkg syscall (windows-amd64), type ProcessEntry32 struct, ProcessID uint32
|
||||
pkg syscall (windows-amd64), type ProcessEntry32 struct, Size uint32
|
||||
pkg syscall (windows-amd64), type ProcessEntry32 struct, Threads uint32
|
||||
pkg syscall (windows-amd64), type ProcessEntry32 struct, Usage uint32
|
||||
|
||||
# CL 127740043 os: make SameFile handle paths like c:a.txt properly, Alex Brainman <alex.brainman@gmail.com>
|
||||
pkg syscall (windows-386), func FullPath(string) (string, error)
|
||||
pkg syscall (windows-amd64), func FullPath(string) (string, error)
|
||||
|
||||
# CL 98150043 testing: add Coverage function, Russ Cox <rsc@golang.org>
|
||||
pkg testing, func Coverage() float64
|
||||
|
||||
# CL 148770043 cmd/go, testing: add TestMain support, Russ Cox <rsc@golang.org>
|
||||
pkg testing, func MainStart(func(string, string) (bool, error), []InternalTest, []InternalBenchmark, []InternalExample) *M
|
||||
pkg testing, method (*M) Run() int
|
||||
pkg testing, type M struct
|
||||
|
||||
# CL 108030044 text/scanner: provide facility for custom identifiers, Robert Griesemer <gri@golang.org>
|
||||
pkg text/scanner, type Scanner struct, IsIdentRune func(int32, int) bool
|
||||
|
||||
# CL 130620043 text/template: add back pointer to Nodes for better error generation, Rob Pike <r@golang.org>
|
||||
pkg text/template/parse, type DotNode struct, embedded NodeType
|
||||
pkg text/template/parse, type NilNode struct, embedded NodeType
|
||||
pkg text/template/parse, method (*BranchNode) Copy() Node
|
||||
pkg text/template/parse, method (*IdentifierNode) SetTree(*Tree) *IdentifierNode
|
||||
pkg html/template, type Error struct, Node parse.Node
|
||||
|
||||
# CL 127470043 unicode: strconv: regexp: Upgrade to Unicode 7.0.0., Marcel van Lohuizen <mpvl@golang.org>
|
||||
pkg unicode, const Version = "7.0.0"
|
||||
pkg unicode, var Bassa_Vah *RangeTable
|
||||
pkg unicode, var Caucasian_Albanian *RangeTable
|
||||
pkg unicode, var Duployan *RangeTable
|
||||
pkg unicode, var Elbasan *RangeTable
|
||||
pkg unicode, var Grantha *RangeTable
|
||||
pkg unicode, var Khojki *RangeTable
|
||||
pkg unicode, var Khudawadi *RangeTable
|
||||
pkg unicode, var Linear_A *RangeTable
|
||||
pkg unicode, var Mahajani *RangeTable
|
||||
pkg unicode, var Manichaean *RangeTable
|
||||
pkg unicode, var Mende_Kikakui *RangeTable
|
||||
pkg unicode, var Modi *RangeTable
|
||||
pkg unicode, var Mro *RangeTable
|
||||
pkg unicode, var Nabataean *RangeTable
|
||||
pkg unicode, var Old_North_Arabian *RangeTable
|
||||
pkg unicode, var Old_Permic *RangeTable
|
||||
pkg unicode, var Pahawh_Hmong *RangeTable
|
||||
pkg unicode, var Palmyrene *RangeTable
|
||||
pkg unicode, var Pau_Cin_Hau *RangeTable
|
||||
pkg unicode, var Psalter_Pahlavi *RangeTable
|
||||
pkg unicode, var Siddham *RangeTable
|
||||
pkg unicode, var Tirhuta *RangeTable
|
||||
pkg unicode, var Warang_Citi *RangeTable
|
||||
975
api/go1.5.txt
975
api/go1.5.txt
@@ -1,975 +0,0 @@
|
||||
pkg archive/zip, method (*Writer) SetOffset(int64)
|
||||
pkg bufio, method (*Reader) Discard(int) (int, error)
|
||||
pkg bufio, method (ReadWriter) Discard(int) (int, error)
|
||||
pkg bytes, func LastIndexByte([]uint8, uint8) int
|
||||
pkg bytes, method (*Buffer) Cap() int
|
||||
pkg bytes, method (*Reader) Size() int64
|
||||
pkg crypto, const SHA512_224 = 14
|
||||
pkg crypto, const SHA512_224 Hash
|
||||
pkg crypto, const SHA512_256 = 15
|
||||
pkg crypto, const SHA512_256 Hash
|
||||
pkg crypto, type Decrypter interface { Decrypt, Public }
|
||||
pkg crypto, type Decrypter interface, Decrypt(io.Reader, []uint8, DecrypterOpts) ([]uint8, error)
|
||||
pkg crypto, type Decrypter interface, Public() PublicKey
|
||||
pkg crypto, type DecrypterOpts interface {}
|
||||
pkg crypto/cipher, func NewGCMWithNonceSize(Block, int) (AEAD, error)
|
||||
pkg crypto/elliptic, type CurveParams struct, Name string
|
||||
pkg crypto/rsa, method (*PrivateKey) Decrypt(io.Reader, []uint8, crypto.DecrypterOpts) ([]uint8, error)
|
||||
pkg crypto/rsa, type OAEPOptions struct
|
||||
pkg crypto/rsa, type OAEPOptions struct, Hash crypto.Hash
|
||||
pkg crypto/rsa, type OAEPOptions struct, Label []uint8
|
||||
pkg crypto/rsa, type PKCS1v15DecryptOptions struct
|
||||
pkg crypto/rsa, type PKCS1v15DecryptOptions struct, SessionKeyLen int
|
||||
pkg crypto/sha512, const Size224 = 28
|
||||
pkg crypto/sha512, const Size224 ideal-int
|
||||
pkg crypto/sha512, const Size256 = 32
|
||||
pkg crypto/sha512, const Size256 ideal-int
|
||||
pkg crypto/sha512, func New512_224() hash.Hash
|
||||
pkg crypto/sha512, func New512_256() hash.Hash
|
||||
pkg crypto/sha512, func Sum512_224([]uint8) [28]uint8
|
||||
pkg crypto/sha512, func Sum512_256([]uint8) [32]uint8
|
||||
pkg crypto/tls, const TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 = 49196
|
||||
pkg crypto/tls, const TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 uint16
|
||||
pkg crypto/tls, const TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 = 49200
|
||||
pkg crypto/tls, const TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 uint16
|
||||
pkg crypto/tls, method (*Config) SetSessionTicketKeys([][32]uint8)
|
||||
pkg crypto/tls, type Certificate struct, SignedCertificateTimestamps [][]uint8
|
||||
pkg crypto/tls, type ConnectionState struct, OCSPResponse []uint8
|
||||
pkg crypto/tls, type ConnectionState struct, SignedCertificateTimestamps [][]uint8
|
||||
pkg crypto/x509, method (*CertificateRequest) CheckSignature() error
|
||||
pkg crypto/x509, type Certificate struct, UnhandledCriticalExtensions []asn1.ObjectIdentifier
|
||||
pkg crypto/x509/pkix, type Name struct, ExtraNames []AttributeTypeAndValue
|
||||
pkg database/sql, method (*DB) Stats() DBStats
|
||||
pkg database/sql, type DBStats struct
|
||||
pkg database/sql, type DBStats struct, OpenConnections int
|
||||
pkg debug/dwarf, const ClassAddress = 1
|
||||
pkg debug/dwarf, const ClassAddress Class
|
||||
pkg debug/dwarf, const ClassBlock = 2
|
||||
pkg debug/dwarf, const ClassBlock Class
|
||||
pkg debug/dwarf, const ClassConstant = 3
|
||||
pkg debug/dwarf, const ClassConstant Class
|
||||
pkg debug/dwarf, const ClassExprLoc = 4
|
||||
pkg debug/dwarf, const ClassExprLoc Class
|
||||
pkg debug/dwarf, const ClassFlag = 5
|
||||
pkg debug/dwarf, const ClassFlag Class
|
||||
pkg debug/dwarf, const ClassLinePtr = 6
|
||||
pkg debug/dwarf, const ClassLinePtr Class
|
||||
pkg debug/dwarf, const ClassLocListPtr = 7
|
||||
pkg debug/dwarf, const ClassLocListPtr Class
|
||||
pkg debug/dwarf, const ClassMacPtr = 8
|
||||
pkg debug/dwarf, const ClassMacPtr Class
|
||||
pkg debug/dwarf, const ClassRangeListPtr = 9
|
||||
pkg debug/dwarf, const ClassRangeListPtr Class
|
||||
pkg debug/dwarf, const ClassReference = 10
|
||||
pkg debug/dwarf, const ClassReference Class
|
||||
pkg debug/dwarf, const ClassReferenceAlt = 13
|
||||
pkg debug/dwarf, const ClassReferenceAlt Class
|
||||
pkg debug/dwarf, const ClassReferenceSig = 11
|
||||
pkg debug/dwarf, const ClassReferenceSig Class
|
||||
pkg debug/dwarf, const ClassString = 12
|
||||
pkg debug/dwarf, const ClassString Class
|
||||
pkg debug/dwarf, const ClassStringAlt = 14
|
||||
pkg debug/dwarf, const ClassStringAlt Class
|
||||
pkg debug/dwarf, method (*Data) LineReader(*Entry) (*LineReader, error)
|
||||
pkg debug/dwarf, method (*Entry) AttrField(Attr) *Field
|
||||
pkg debug/dwarf, method (*LineReader) Next(*LineEntry) error
|
||||
pkg debug/dwarf, method (*LineReader) Reset()
|
||||
pkg debug/dwarf, method (*LineReader) Seek(LineReaderPos)
|
||||
pkg debug/dwarf, method (*LineReader) SeekPC(uint64, *LineEntry) error
|
||||
pkg debug/dwarf, method (*LineReader) Tell() LineReaderPos
|
||||
pkg debug/dwarf, method (*Reader) AddressSize() int
|
||||
pkg debug/dwarf, method (Class) GoString() string
|
||||
pkg debug/dwarf, method (Class) String() string
|
||||
pkg debug/dwarf, type Class int
|
||||
pkg debug/dwarf, type Field struct, Class Class
|
||||
pkg debug/dwarf, type LineEntry struct
|
||||
pkg debug/dwarf, type LineEntry struct, Address uint64
|
||||
pkg debug/dwarf, type LineEntry struct, BasicBlock bool
|
||||
pkg debug/dwarf, type LineEntry struct, Column int
|
||||
pkg debug/dwarf, type LineEntry struct, Discriminator int
|
||||
pkg debug/dwarf, type LineEntry struct, EndSequence bool
|
||||
pkg debug/dwarf, type LineEntry struct, EpilogueBegin bool
|
||||
pkg debug/dwarf, type LineEntry struct, File *LineFile
|
||||
pkg debug/dwarf, type LineEntry struct, ISA int
|
||||
pkg debug/dwarf, type LineEntry struct, IsStmt bool
|
||||
pkg debug/dwarf, type LineEntry struct, Line int
|
||||
pkg debug/dwarf, type LineEntry struct, OpIndex int
|
||||
pkg debug/dwarf, type LineEntry struct, PrologueEnd bool
|
||||
pkg debug/dwarf, type LineFile struct
|
||||
pkg debug/dwarf, type LineFile struct, Length int
|
||||
pkg debug/dwarf, type LineFile struct, Mtime uint64
|
||||
pkg debug/dwarf, type LineFile struct, Name string
|
||||
pkg debug/dwarf, type LineReader struct
|
||||
pkg debug/dwarf, type LineReaderPos struct
|
||||
pkg debug/dwarf, var ErrUnknownPC error
|
||||
pkg debug/elf, const R_PPC64_ADDR14 = 7
|
||||
pkg debug/elf, const R_PPC64_ADDR14 R_PPC64
|
||||
pkg debug/elf, const R_PPC64_ADDR14_BRNTAKEN = 9
|
||||
pkg debug/elf, const R_PPC64_ADDR14_BRNTAKEN R_PPC64
|
||||
pkg debug/elf, const R_PPC64_ADDR14_BRTAKEN = 8
|
||||
pkg debug/elf, const R_PPC64_ADDR14_BRTAKEN R_PPC64
|
||||
pkg debug/elf, const R_PPC64_ADDR16 = 3
|
||||
pkg debug/elf, const R_PPC64_ADDR16 R_PPC64
|
||||
pkg debug/elf, const R_PPC64_ADDR16_DS = 56
|
||||
pkg debug/elf, const R_PPC64_ADDR16_DS R_PPC64
|
||||
pkg debug/elf, const R_PPC64_ADDR16_HA = 6
|
||||
pkg debug/elf, const R_PPC64_ADDR16_HA R_PPC64
|
||||
pkg debug/elf, const R_PPC64_ADDR16_HI = 5
|
||||
pkg debug/elf, const R_PPC64_ADDR16_HI R_PPC64
|
||||
pkg debug/elf, const R_PPC64_ADDR16_HIGHER = 39
|
||||
pkg debug/elf, const R_PPC64_ADDR16_HIGHER R_PPC64
|
||||
pkg debug/elf, const R_PPC64_ADDR16_HIGHERA = 40
|
||||
pkg debug/elf, const R_PPC64_ADDR16_HIGHERA R_PPC64
|
||||
pkg debug/elf, const R_PPC64_ADDR16_HIGHEST = 41
|
||||
pkg debug/elf, const R_PPC64_ADDR16_HIGHEST R_PPC64
|
||||
pkg debug/elf, const R_PPC64_ADDR16_HIGHESTA = 42
|
||||
pkg debug/elf, const R_PPC64_ADDR16_HIGHESTA R_PPC64
|
||||
pkg debug/elf, const R_PPC64_ADDR16_LO = 4
|
||||
pkg debug/elf, const R_PPC64_ADDR16_LO R_PPC64
|
||||
pkg debug/elf, const R_PPC64_ADDR16_LO_DS = 57
|
||||
pkg debug/elf, const R_PPC64_ADDR16_LO_DS R_PPC64
|
||||
pkg debug/elf, const R_PPC64_ADDR24 = 2
|
||||
pkg debug/elf, const R_PPC64_ADDR24 R_PPC64
|
||||
pkg debug/elf, const R_PPC64_ADDR32 = 1
|
||||
pkg debug/elf, const R_PPC64_ADDR32 R_PPC64
|
||||
pkg debug/elf, const R_PPC64_ADDR64 = 38
|
||||
pkg debug/elf, const R_PPC64_ADDR64 R_PPC64
|
||||
pkg debug/elf, const R_PPC64_DTPMOD64 = 68
|
||||
pkg debug/elf, const R_PPC64_DTPMOD64 R_PPC64
|
||||
pkg debug/elf, const R_PPC64_DTPREL16 = 74
|
||||
pkg debug/elf, const R_PPC64_DTPREL16 R_PPC64
|
||||
pkg debug/elf, const R_PPC64_DTPREL16_DS = 101
|
||||
pkg debug/elf, const R_PPC64_DTPREL16_DS R_PPC64
|
||||
pkg debug/elf, const R_PPC64_DTPREL16_HA = 77
|
||||
pkg debug/elf, const R_PPC64_DTPREL16_HA R_PPC64
|
||||
pkg debug/elf, const R_PPC64_DTPREL16_HI = 76
|
||||
pkg debug/elf, const R_PPC64_DTPREL16_HI R_PPC64
|
||||
pkg debug/elf, const R_PPC64_DTPREL16_HIGHER = 103
|
||||
pkg debug/elf, const R_PPC64_DTPREL16_HIGHER R_PPC64
|
||||
pkg debug/elf, const R_PPC64_DTPREL16_HIGHERA = 104
|
||||
pkg debug/elf, const R_PPC64_DTPREL16_HIGHERA R_PPC64
|
||||
pkg debug/elf, const R_PPC64_DTPREL16_HIGHEST = 105
|
||||
pkg debug/elf, const R_PPC64_DTPREL16_HIGHEST R_PPC64
|
||||
pkg debug/elf, const R_PPC64_DTPREL16_HIGHESTA = 106
|
||||
pkg debug/elf, const R_PPC64_DTPREL16_HIGHESTA R_PPC64
|
||||
pkg debug/elf, const R_PPC64_DTPREL16_LO = 75
|
||||
pkg debug/elf, const R_PPC64_DTPREL16_LO R_PPC64
|
||||
pkg debug/elf, const R_PPC64_DTPREL16_LO_DS = 102
|
||||
pkg debug/elf, const R_PPC64_DTPREL16_LO_DS R_PPC64
|
||||
pkg debug/elf, const R_PPC64_DTPREL64 = 78
|
||||
pkg debug/elf, const R_PPC64_DTPREL64 R_PPC64
|
||||
pkg debug/elf, const R_PPC64_GOT16 = 14
|
||||
pkg debug/elf, const R_PPC64_GOT16 R_PPC64
|
||||
pkg debug/elf, const R_PPC64_GOT16_DS = 58
|
||||
pkg debug/elf, const R_PPC64_GOT16_DS R_PPC64
|
||||
pkg debug/elf, const R_PPC64_GOT16_HA = 17
|
||||
pkg debug/elf, const R_PPC64_GOT16_HA R_PPC64
|
||||
pkg debug/elf, const R_PPC64_GOT16_HI = 16
|
||||
pkg debug/elf, const R_PPC64_GOT16_HI R_PPC64
|
||||
pkg debug/elf, const R_PPC64_GOT16_LO = 15
|
||||
pkg debug/elf, const R_PPC64_GOT16_LO R_PPC64
|
||||
pkg debug/elf, const R_PPC64_GOT16_LO_DS = 59
|
||||
pkg debug/elf, const R_PPC64_GOT16_LO_DS R_PPC64
|
||||
pkg debug/elf, const R_PPC64_GOT_DTPREL16_DS = 91
|
||||
pkg debug/elf, const R_PPC64_GOT_DTPREL16_DS R_PPC64
|
||||
pkg debug/elf, const R_PPC64_GOT_DTPREL16_HA = 94
|
||||
pkg debug/elf, const R_PPC64_GOT_DTPREL16_HA R_PPC64
|
||||
pkg debug/elf, const R_PPC64_GOT_DTPREL16_HI = 93
|
||||
pkg debug/elf, const R_PPC64_GOT_DTPREL16_HI R_PPC64
|
||||
pkg debug/elf, const R_PPC64_GOT_DTPREL16_LO_DS = 92
|
||||
pkg debug/elf, const R_PPC64_GOT_DTPREL16_LO_DS R_PPC64
|
||||
pkg debug/elf, const R_PPC64_GOT_TLSGD16 = 79
|
||||
pkg debug/elf, const R_PPC64_GOT_TLSGD16 R_PPC64
|
||||
pkg debug/elf, const R_PPC64_GOT_TLSGD16_HA = 82
|
||||
pkg debug/elf, const R_PPC64_GOT_TLSGD16_HA R_PPC64
|
||||
pkg debug/elf, const R_PPC64_GOT_TLSGD16_HI = 81
|
||||
pkg debug/elf, const R_PPC64_GOT_TLSGD16_HI R_PPC64
|
||||
pkg debug/elf, const R_PPC64_GOT_TLSGD16_LO = 80
|
||||
pkg debug/elf, const R_PPC64_GOT_TLSGD16_LO R_PPC64
|
||||
pkg debug/elf, const R_PPC64_GOT_TLSLD16 = 83
|
||||
pkg debug/elf, const R_PPC64_GOT_TLSLD16 R_PPC64
|
||||
pkg debug/elf, const R_PPC64_GOT_TLSLD16_HA = 86
|
||||
pkg debug/elf, const R_PPC64_GOT_TLSLD16_HA R_PPC64
|
||||
pkg debug/elf, const R_PPC64_GOT_TLSLD16_HI = 85
|
||||
pkg debug/elf, const R_PPC64_GOT_TLSLD16_HI R_PPC64
|
||||
pkg debug/elf, const R_PPC64_GOT_TLSLD16_LO = 84
|
||||
pkg debug/elf, const R_PPC64_GOT_TLSLD16_LO R_PPC64
|
||||
pkg debug/elf, const R_PPC64_GOT_TPREL16_DS = 87
|
||||
pkg debug/elf, const R_PPC64_GOT_TPREL16_DS R_PPC64
|
||||
pkg debug/elf, const R_PPC64_GOT_TPREL16_HA = 90
|
||||
pkg debug/elf, const R_PPC64_GOT_TPREL16_HA R_PPC64
|
||||
pkg debug/elf, const R_PPC64_GOT_TPREL16_HI = 89
|
||||
pkg debug/elf, const R_PPC64_GOT_TPREL16_HI R_PPC64
|
||||
pkg debug/elf, const R_PPC64_GOT_TPREL16_LO_DS = 88
|
||||
pkg debug/elf, const R_PPC64_GOT_TPREL16_LO_DS R_PPC64
|
||||
pkg debug/elf, const R_PPC64_JMP_SLOT = 21
|
||||
pkg debug/elf, const R_PPC64_JMP_SLOT R_PPC64
|
||||
pkg debug/elf, const R_PPC64_NONE = 0
|
||||
pkg debug/elf, const R_PPC64_NONE R_PPC64
|
||||
pkg debug/elf, const R_PPC64_REL14 = 11
|
||||
pkg debug/elf, const R_PPC64_REL14 R_PPC64
|
||||
pkg debug/elf, const R_PPC64_REL14_BRNTAKEN = 13
|
||||
pkg debug/elf, const R_PPC64_REL14_BRNTAKEN R_PPC64
|
||||
pkg debug/elf, const R_PPC64_REL14_BRTAKEN = 12
|
||||
pkg debug/elf, const R_PPC64_REL14_BRTAKEN R_PPC64
|
||||
pkg debug/elf, const R_PPC64_REL16 = 249
|
||||
pkg debug/elf, const R_PPC64_REL16 R_PPC64
|
||||
pkg debug/elf, const R_PPC64_REL16_HA = 252
|
||||
pkg debug/elf, const R_PPC64_REL16_HA R_PPC64
|
||||
pkg debug/elf, const R_PPC64_REL16_HI = 251
|
||||
pkg debug/elf, const R_PPC64_REL16_HI R_PPC64
|
||||
pkg debug/elf, const R_PPC64_REL16_LO = 250
|
||||
pkg debug/elf, const R_PPC64_REL16_LO R_PPC64
|
||||
pkg debug/elf, const R_PPC64_REL24 = 10
|
||||
pkg debug/elf, const R_PPC64_REL24 R_PPC64
|
||||
pkg debug/elf, const R_PPC64_REL32 = 26
|
||||
pkg debug/elf, const R_PPC64_REL32 R_PPC64
|
||||
pkg debug/elf, const R_PPC64_REL64 = 44
|
||||
pkg debug/elf, const R_PPC64_REL64 R_PPC64
|
||||
pkg debug/elf, const R_PPC64_TLS = 67
|
||||
pkg debug/elf, const R_PPC64_TLS R_PPC64
|
||||
pkg debug/elf, const R_PPC64_TLSGD = 107
|
||||
pkg debug/elf, const R_PPC64_TLSGD R_PPC64
|
||||
pkg debug/elf, const R_PPC64_TLSLD = 108
|
||||
pkg debug/elf, const R_PPC64_TLSLD R_PPC64
|
||||
pkg debug/elf, const R_PPC64_TOC = 51
|
||||
pkg debug/elf, const R_PPC64_TOC R_PPC64
|
||||
pkg debug/elf, const R_PPC64_TOC16 = 47
|
||||
pkg debug/elf, const R_PPC64_TOC16 R_PPC64
|
||||
pkg debug/elf, const R_PPC64_TOC16_DS = 63
|
||||
pkg debug/elf, const R_PPC64_TOC16_DS R_PPC64
|
||||
pkg debug/elf, const R_PPC64_TOC16_HA = 50
|
||||
pkg debug/elf, const R_PPC64_TOC16_HA R_PPC64
|
||||
pkg debug/elf, const R_PPC64_TOC16_HI = 49
|
||||
pkg debug/elf, const R_PPC64_TOC16_HI R_PPC64
|
||||
pkg debug/elf, const R_PPC64_TOC16_LO = 48
|
||||
pkg debug/elf, const R_PPC64_TOC16_LO R_PPC64
|
||||
pkg debug/elf, const R_PPC64_TOC16_LO_DS = 64
|
||||
pkg debug/elf, const R_PPC64_TOC16_LO_DS R_PPC64
|
||||
pkg debug/elf, const R_PPC64_TPREL16 = 69
|
||||
pkg debug/elf, const R_PPC64_TPREL16 R_PPC64
|
||||
pkg debug/elf, const R_PPC64_TPREL16_DS = 95
|
||||
pkg debug/elf, const R_PPC64_TPREL16_DS R_PPC64
|
||||
pkg debug/elf, const R_PPC64_TPREL16_HA = 72
|
||||
pkg debug/elf, const R_PPC64_TPREL16_HA R_PPC64
|
||||
pkg debug/elf, const R_PPC64_TPREL16_HI = 71
|
||||
pkg debug/elf, const R_PPC64_TPREL16_HI R_PPC64
|
||||
pkg debug/elf, const R_PPC64_TPREL16_HIGHER = 97
|
||||
pkg debug/elf, const R_PPC64_TPREL16_HIGHER R_PPC64
|
||||
pkg debug/elf, const R_PPC64_TPREL16_HIGHERA = 98
|
||||
pkg debug/elf, const R_PPC64_TPREL16_HIGHERA R_PPC64
|
||||
pkg debug/elf, const R_PPC64_TPREL16_HIGHEST = 99
|
||||
pkg debug/elf, const R_PPC64_TPREL16_HIGHEST R_PPC64
|
||||
pkg debug/elf, const R_PPC64_TPREL16_HIGHESTA = 100
|
||||
pkg debug/elf, const R_PPC64_TPREL16_HIGHESTA R_PPC64
|
||||
pkg debug/elf, const R_PPC64_TPREL16_LO = 70
|
||||
pkg debug/elf, const R_PPC64_TPREL16_LO R_PPC64
|
||||
pkg debug/elf, const R_PPC64_TPREL16_LO_DS = 96
|
||||
pkg debug/elf, const R_PPC64_TPREL16_LO_DS R_PPC64
|
||||
pkg debug/elf, const R_PPC64_TPREL64 = 73
|
||||
pkg debug/elf, const R_PPC64_TPREL64 R_PPC64
|
||||
pkg debug/elf, method (R_PPC64) GoString() string
|
||||
pkg debug/elf, method (R_PPC64) String() string
|
||||
pkg debug/elf, type R_PPC64 int
|
||||
pkg encoding/base64, const NoPadding = -1
|
||||
pkg encoding/base64, const NoPadding int32
|
||||
pkg encoding/base64, const StdPadding = 61
|
||||
pkg encoding/base64, const StdPadding int32
|
||||
pkg encoding/base64, method (Encoding) WithPadding(int32) *Encoding
|
||||
pkg encoding/base64, var RawStdEncoding *Encoding
|
||||
pkg encoding/base64, var RawURLEncoding *Encoding
|
||||
pkg encoding/json, method (*Decoder) More() bool
|
||||
pkg encoding/json, method (*Decoder) Token() (Token, error)
|
||||
pkg encoding/json, method (Delim) String() string
|
||||
pkg encoding/json, type Delim int32
|
||||
pkg encoding/json, type Token interface {}
|
||||
pkg encoding/json, type UnmarshalTypeError struct, Offset int64
|
||||
pkg flag, func UnquoteUsage(*Flag) (string, string)
|
||||
pkg go/ast, type EmptyStmt struct, Implicit bool
|
||||
pkg go/build, type Package struct, PkgTargetRoot string
|
||||
pkg go/constant, const Bool = 1
|
||||
pkg go/constant, const Bool Kind
|
||||
pkg go/constant, const Complex = 5
|
||||
pkg go/constant, const Complex Kind
|
||||
pkg go/constant, const Float = 4
|
||||
pkg go/constant, const Float Kind
|
||||
pkg go/constant, const Int = 3
|
||||
pkg go/constant, const Int Kind
|
||||
pkg go/constant, const String = 2
|
||||
pkg go/constant, const String Kind
|
||||
pkg go/constant, const Unknown = 0
|
||||
pkg go/constant, const Unknown Kind
|
||||
pkg go/constant, func BinaryOp(Value, token.Token, Value) Value
|
||||
pkg go/constant, func BitLen(Value) int
|
||||
pkg go/constant, func BoolVal(Value) bool
|
||||
pkg go/constant, func Bytes(Value) []uint8
|
||||
pkg go/constant, func Compare(Value, token.Token, Value) bool
|
||||
pkg go/constant, func Denom(Value) Value
|
||||
pkg go/constant, func Float32Val(Value) (float32, bool)
|
||||
pkg go/constant, func Float64Val(Value) (float64, bool)
|
||||
pkg go/constant, func Imag(Value) Value
|
||||
pkg go/constant, func Int64Val(Value) (int64, bool)
|
||||
pkg go/constant, func MakeBool(bool) Value
|
||||
pkg go/constant, func MakeFloat64(float64) Value
|
||||
pkg go/constant, func MakeFromBytes([]uint8) Value
|
||||
pkg go/constant, func MakeFromLiteral(string, token.Token, uint) Value
|
||||
pkg go/constant, func MakeImag(Value) Value
|
||||
pkg go/constant, func MakeInt64(int64) Value
|
||||
pkg go/constant, func MakeString(string) Value
|
||||
pkg go/constant, func MakeUint64(uint64) Value
|
||||
pkg go/constant, func MakeUnknown() Value
|
||||
pkg go/constant, func Num(Value) Value
|
||||
pkg go/constant, func Real(Value) Value
|
||||
pkg go/constant, func Shift(Value, token.Token, uint) Value
|
||||
pkg go/constant, func Sign(Value) int
|
||||
pkg go/constant, func StringVal(Value) string
|
||||
pkg go/constant, func Uint64Val(Value) (uint64, bool)
|
||||
pkg go/constant, func UnaryOp(token.Token, Value, uint) Value
|
||||
pkg go/constant, type Kind int
|
||||
pkg go/constant, type Value interface, Kind() Kind
|
||||
pkg go/constant, type Value interface, String() string
|
||||
pkg go/constant, type Value interface, unexported methods
|
||||
pkg go/importer, func Default() types.Importer
|
||||
pkg go/importer, func For(string, Lookup) types.Importer
|
||||
pkg go/importer, type Lookup func(string) (io.ReadCloser, error)
|
||||
pkg go/parser, func ParseExprFrom(*token.FileSet, string, interface{}, Mode) (ast.Expr, error)
|
||||
pkg go/types, const Bool = 1
|
||||
pkg go/types, const Bool BasicKind
|
||||
pkg go/types, const Byte = 8
|
||||
pkg go/types, const Byte BasicKind
|
||||
pkg go/types, const Complex128 = 16
|
||||
pkg go/types, const Complex128 BasicKind
|
||||
pkg go/types, const Complex64 = 15
|
||||
pkg go/types, const Complex64 BasicKind
|
||||
pkg go/types, const FieldVal = 0
|
||||
pkg go/types, const FieldVal SelectionKind
|
||||
pkg go/types, const Float32 = 13
|
||||
pkg go/types, const Float32 BasicKind
|
||||
pkg go/types, const Float64 = 14
|
||||
pkg go/types, const Float64 BasicKind
|
||||
pkg go/types, const Int = 2
|
||||
pkg go/types, const Int BasicKind
|
||||
pkg go/types, const Int16 = 4
|
||||
pkg go/types, const Int16 BasicKind
|
||||
pkg go/types, const Int32 = 5
|
||||
pkg go/types, const Int32 BasicKind
|
||||
pkg go/types, const Int64 = 6
|
||||
pkg go/types, const Int64 BasicKind
|
||||
pkg go/types, const Int8 = 3
|
||||
pkg go/types, const Int8 BasicKind
|
||||
pkg go/types, const Invalid = 0
|
||||
pkg go/types, const Invalid BasicKind
|
||||
pkg go/types, const IsBoolean = 1
|
||||
pkg go/types, const IsBoolean BasicInfo
|
||||
pkg go/types, const IsComplex = 16
|
||||
pkg go/types, const IsComplex BasicInfo
|
||||
pkg go/types, const IsConstType = 59
|
||||
pkg go/types, const IsConstType BasicInfo
|
||||
pkg go/types, const IsFloat = 8
|
||||
pkg go/types, const IsFloat BasicInfo
|
||||
pkg go/types, const IsInteger = 2
|
||||
pkg go/types, const IsInteger BasicInfo
|
||||
pkg go/types, const IsNumeric = 26
|
||||
pkg go/types, const IsNumeric BasicInfo
|
||||
pkg go/types, const IsOrdered = 42
|
||||
pkg go/types, const IsOrdered BasicInfo
|
||||
pkg go/types, const IsString = 32
|
||||
pkg go/types, const IsString BasicInfo
|
||||
pkg go/types, const IsUnsigned = 4
|
||||
pkg go/types, const IsUnsigned BasicInfo
|
||||
pkg go/types, const IsUntyped = 64
|
||||
pkg go/types, const IsUntyped BasicInfo
|
||||
pkg go/types, const MethodExpr = 2
|
||||
pkg go/types, const MethodExpr SelectionKind
|
||||
pkg go/types, const MethodVal = 1
|
||||
pkg go/types, const MethodVal SelectionKind
|
||||
pkg go/types, const RecvOnly = 2
|
||||
pkg go/types, const RecvOnly ChanDir
|
||||
pkg go/types, const Rune = 5
|
||||
pkg go/types, const Rune BasicKind
|
||||
pkg go/types, const SendOnly = 1
|
||||
pkg go/types, const SendOnly ChanDir
|
||||
pkg go/types, const SendRecv = 0
|
||||
pkg go/types, const SendRecv ChanDir
|
||||
pkg go/types, const String = 17
|
||||
pkg go/types, const String BasicKind
|
||||
pkg go/types, const Uint = 7
|
||||
pkg go/types, const Uint BasicKind
|
||||
pkg go/types, const Uint16 = 9
|
||||
pkg go/types, const Uint16 BasicKind
|
||||
pkg go/types, const Uint32 = 10
|
||||
pkg go/types, const Uint32 BasicKind
|
||||
pkg go/types, const Uint64 = 11
|
||||
pkg go/types, const Uint64 BasicKind
|
||||
pkg go/types, const Uint8 = 8
|
||||
pkg go/types, const Uint8 BasicKind
|
||||
pkg go/types, const Uintptr = 12
|
||||
pkg go/types, const Uintptr BasicKind
|
||||
pkg go/types, const UnsafePointer = 18
|
||||
pkg go/types, const UnsafePointer BasicKind
|
||||
pkg go/types, const UntypedBool = 19
|
||||
pkg go/types, const UntypedBool BasicKind
|
||||
pkg go/types, const UntypedComplex = 23
|
||||
pkg go/types, const UntypedComplex BasicKind
|
||||
pkg go/types, const UntypedFloat = 22
|
||||
pkg go/types, const UntypedFloat BasicKind
|
||||
pkg go/types, const UntypedInt = 20
|
||||
pkg go/types, const UntypedInt BasicKind
|
||||
pkg go/types, const UntypedNil = 25
|
||||
pkg go/types, const UntypedNil BasicKind
|
||||
pkg go/types, const UntypedRune = 21
|
||||
pkg go/types, const UntypedRune BasicKind
|
||||
pkg go/types, const UntypedString = 24
|
||||
pkg go/types, const UntypedString BasicKind
|
||||
pkg go/types, func AssertableTo(*Interface, Type) bool
|
||||
pkg go/types, func AssignableTo(Type, Type) bool
|
||||
pkg go/types, func Comparable(Type) bool
|
||||
pkg go/types, func ConvertibleTo(Type, Type) bool
|
||||
pkg go/types, func DefPredeclaredTestFuncs()
|
||||
pkg go/types, func Eval(*token.FileSet, *Package, token.Pos, string) (TypeAndValue, error)
|
||||
pkg go/types, func ExprString(ast.Expr) string
|
||||
pkg go/types, func Id(*Package, string) string
|
||||
pkg go/types, func Identical(Type, Type) bool
|
||||
pkg go/types, func Implements(Type, *Interface) bool
|
||||
pkg go/types, func IsInterface(Type) bool
|
||||
pkg go/types, func LookupFieldOrMethod(Type, bool, *Package, string) (Object, []int, bool)
|
||||
pkg go/types, func MissingMethod(Type, *Interface, bool) (*Func, bool)
|
||||
pkg go/types, func NewArray(Type, int64) *Array
|
||||
pkg go/types, func NewChan(ChanDir, Type) *Chan
|
||||
pkg go/types, func NewChecker(*Config, *token.FileSet, *Package, *Info) *Checker
|
||||
pkg go/types, func NewConst(token.Pos, *Package, string, Type, constant.Value) *Const
|
||||
pkg go/types, func NewField(token.Pos, *Package, string, Type, bool) *Var
|
||||
pkg go/types, func NewFunc(token.Pos, *Package, string, *Signature) *Func
|
||||
pkg go/types, func NewInterface([]*Func, []*Named) *Interface
|
||||
pkg go/types, func NewLabel(token.Pos, *Package, string) *Label
|
||||
pkg go/types, func NewMap(Type, Type) *Map
|
||||
pkg go/types, func NewMethodSet(Type) *MethodSet
|
||||
pkg go/types, func NewNamed(*TypeName, Type, []*Func) *Named
|
||||
pkg go/types, func NewPackage(string, string) *Package
|
||||
pkg go/types, func NewParam(token.Pos, *Package, string, Type) *Var
|
||||
pkg go/types, func NewPkgName(token.Pos, *Package, string, *Package) *PkgName
|
||||
pkg go/types, func NewPointer(Type) *Pointer
|
||||
pkg go/types, func NewScope(*Scope, token.Pos, token.Pos, string) *Scope
|
||||
pkg go/types, func NewSignature(*Var, *Tuple, *Tuple, bool) *Signature
|
||||
pkg go/types, func NewSlice(Type) *Slice
|
||||
pkg go/types, func NewStruct([]*Var, []string) *Struct
|
||||
pkg go/types, func NewTuple(...*Var) *Tuple
|
||||
pkg go/types, func NewTypeName(token.Pos, *Package, string, Type) *TypeName
|
||||
pkg go/types, func NewVar(token.Pos, *Package, string, Type) *Var
|
||||
pkg go/types, func ObjectString(Object, Qualifier) string
|
||||
pkg go/types, func RelativeTo(*Package) Qualifier
|
||||
pkg go/types, func SelectionString(*Selection, Qualifier) string
|
||||
pkg go/types, func TypeString(Type, Qualifier) string
|
||||
pkg go/types, func WriteExpr(*bytes.Buffer, ast.Expr)
|
||||
pkg go/types, func WriteSignature(*bytes.Buffer, *Signature, Qualifier)
|
||||
pkg go/types, func WriteType(*bytes.Buffer, Type, Qualifier)
|
||||
pkg go/types, method (*Array) Elem() Type
|
||||
pkg go/types, method (*Array) Len() int64
|
||||
pkg go/types, method (*Array) String() string
|
||||
pkg go/types, method (*Array) Underlying() Type
|
||||
pkg go/types, method (*Basic) Info() BasicInfo
|
||||
pkg go/types, method (*Basic) Kind() BasicKind
|
||||
pkg go/types, method (*Basic) Name() string
|
||||
pkg go/types, method (*Basic) String() string
|
||||
pkg go/types, method (*Basic) Underlying() Type
|
||||
pkg go/types, method (*Builtin) Exported() bool
|
||||
pkg go/types, method (*Builtin) Id() string
|
||||
pkg go/types, method (*Builtin) Name() string
|
||||
pkg go/types, method (*Builtin) Parent() *Scope
|
||||
pkg go/types, method (*Builtin) Pkg() *Package
|
||||
pkg go/types, method (*Builtin) Pos() token.Pos
|
||||
pkg go/types, method (*Builtin) String() string
|
||||
pkg go/types, method (*Builtin) Type() Type
|
||||
pkg go/types, method (*Chan) Dir() ChanDir
|
||||
pkg go/types, method (*Chan) Elem() Type
|
||||
pkg go/types, method (*Chan) String() string
|
||||
pkg go/types, method (*Chan) Underlying() Type
|
||||
pkg go/types, method (*Checker) Files([]*ast.File) error
|
||||
pkg go/types, method (*Config) Check(string, *token.FileSet, []*ast.File, *Info) (*Package, error)
|
||||
pkg go/types, method (*Const) Exported() bool
|
||||
pkg go/types, method (*Const) Id() string
|
||||
pkg go/types, method (*Const) Name() string
|
||||
pkg go/types, method (*Const) Parent() *Scope
|
||||
pkg go/types, method (*Const) Pkg() *Package
|
||||
pkg go/types, method (*Const) Pos() token.Pos
|
||||
pkg go/types, method (*Const) String() string
|
||||
pkg go/types, method (*Const) Type() Type
|
||||
pkg go/types, method (*Const) Val() constant.Value
|
||||
pkg go/types, method (*Func) Exported() bool
|
||||
pkg go/types, method (*Func) FullName() string
|
||||
pkg go/types, method (*Func) Id() string
|
||||
pkg go/types, method (*Func) Name() string
|
||||
pkg go/types, method (*Func) Parent() *Scope
|
||||
pkg go/types, method (*Func) Pkg() *Package
|
||||
pkg go/types, method (*Func) Pos() token.Pos
|
||||
pkg go/types, method (*Func) Scope() *Scope
|
||||
pkg go/types, method (*Func) String() string
|
||||
pkg go/types, method (*Func) Type() Type
|
||||
pkg go/types, method (*Info) ObjectOf(*ast.Ident) Object
|
||||
pkg go/types, method (*Info) TypeOf(ast.Expr) Type
|
||||
pkg go/types, method (*Initializer) String() string
|
||||
pkg go/types, method (*Interface) Complete() *Interface
|
||||
pkg go/types, method (*Interface) Embedded(int) *Named
|
||||
pkg go/types, method (*Interface) Empty() bool
|
||||
pkg go/types, method (*Interface) ExplicitMethod(int) *Func
|
||||
pkg go/types, method (*Interface) Method(int) *Func
|
||||
pkg go/types, method (*Interface) NumEmbeddeds() int
|
||||
pkg go/types, method (*Interface) NumExplicitMethods() int
|
||||
pkg go/types, method (*Interface) NumMethods() int
|
||||
pkg go/types, method (*Interface) String() string
|
||||
pkg go/types, method (*Interface) Underlying() Type
|
||||
pkg go/types, method (*Label) Exported() bool
|
||||
pkg go/types, method (*Label) Id() string
|
||||
pkg go/types, method (*Label) Name() string
|
||||
pkg go/types, method (*Label) Parent() *Scope
|
||||
pkg go/types, method (*Label) Pkg() *Package
|
||||
pkg go/types, method (*Label) Pos() token.Pos
|
||||
pkg go/types, method (*Label) String() string
|
||||
pkg go/types, method (*Label) Type() Type
|
||||
pkg go/types, method (*Map) Elem() Type
|
||||
pkg go/types, method (*Map) Key() Type
|
||||
pkg go/types, method (*Map) String() string
|
||||
pkg go/types, method (*Map) Underlying() Type
|
||||
pkg go/types, method (*MethodSet) At(int) *Selection
|
||||
pkg go/types, method (*MethodSet) Len() int
|
||||
pkg go/types, method (*MethodSet) Lookup(*Package, string) *Selection
|
||||
pkg go/types, method (*MethodSet) String() string
|
||||
pkg go/types, method (*Named) AddMethod(*Func)
|
||||
pkg go/types, method (*Named) Method(int) *Func
|
||||
pkg go/types, method (*Named) NumMethods() int
|
||||
pkg go/types, method (*Named) Obj() *TypeName
|
||||
pkg go/types, method (*Named) SetUnderlying(Type)
|
||||
pkg go/types, method (*Named) String() string
|
||||
pkg go/types, method (*Named) Underlying() Type
|
||||
pkg go/types, method (*Nil) Exported() bool
|
||||
pkg go/types, method (*Nil) Id() string
|
||||
pkg go/types, method (*Nil) Name() string
|
||||
pkg go/types, method (*Nil) Parent() *Scope
|
||||
pkg go/types, method (*Nil) Pkg() *Package
|
||||
pkg go/types, method (*Nil) Pos() token.Pos
|
||||
pkg go/types, method (*Nil) String() string
|
||||
pkg go/types, method (*Nil) Type() Type
|
||||
pkg go/types, method (*Package) Complete() bool
|
||||
pkg go/types, method (*Package) Imports() []*Package
|
||||
pkg go/types, method (*Package) MarkComplete()
|
||||
pkg go/types, method (*Package) Name() string
|
||||
pkg go/types, method (*Package) Path() string
|
||||
pkg go/types, method (*Package) Scope() *Scope
|
||||
pkg go/types, method (*Package) SetImports([]*Package)
|
||||
pkg go/types, method (*Package) String() string
|
||||
pkg go/types, method (*PkgName) Exported() bool
|
||||
pkg go/types, method (*PkgName) Id() string
|
||||
pkg go/types, method (*PkgName) Imported() *Package
|
||||
pkg go/types, method (*PkgName) Name() string
|
||||
pkg go/types, method (*PkgName) Parent() *Scope
|
||||
pkg go/types, method (*PkgName) Pkg() *Package
|
||||
pkg go/types, method (*PkgName) Pos() token.Pos
|
||||
pkg go/types, method (*PkgName) String() string
|
||||
pkg go/types, method (*PkgName) Type() Type
|
||||
pkg go/types, method (*Pointer) Elem() Type
|
||||
pkg go/types, method (*Pointer) String() string
|
||||
pkg go/types, method (*Pointer) Underlying() Type
|
||||
pkg go/types, method (*Scope) Child(int) *Scope
|
||||
pkg go/types, method (*Scope) Contains(token.Pos) bool
|
||||
pkg go/types, method (*Scope) End() token.Pos
|
||||
pkg go/types, method (*Scope) Innermost(token.Pos) *Scope
|
||||
pkg go/types, method (*Scope) Insert(Object) Object
|
||||
pkg go/types, method (*Scope) Len() int
|
||||
pkg go/types, method (*Scope) Lookup(string) Object
|
||||
pkg go/types, method (*Scope) LookupParent(string, token.Pos) (*Scope, Object)
|
||||
pkg go/types, method (*Scope) Names() []string
|
||||
pkg go/types, method (*Scope) NumChildren() int
|
||||
pkg go/types, method (*Scope) Parent() *Scope
|
||||
pkg go/types, method (*Scope) Pos() token.Pos
|
||||
pkg go/types, method (*Scope) String() string
|
||||
pkg go/types, method (*Scope) WriteTo(io.Writer, int, bool)
|
||||
pkg go/types, method (*Selection) Index() []int
|
||||
pkg go/types, method (*Selection) Indirect() bool
|
||||
pkg go/types, method (*Selection) Kind() SelectionKind
|
||||
pkg go/types, method (*Selection) Obj() Object
|
||||
pkg go/types, method (*Selection) Recv() Type
|
||||
pkg go/types, method (*Selection) String() string
|
||||
pkg go/types, method (*Selection) Type() Type
|
||||
pkg go/types, method (*Signature) Params() *Tuple
|
||||
pkg go/types, method (*Signature) Recv() *Var
|
||||
pkg go/types, method (*Signature) Results() *Tuple
|
||||
pkg go/types, method (*Signature) String() string
|
||||
pkg go/types, method (*Signature) Underlying() Type
|
||||
pkg go/types, method (*Signature) Variadic() bool
|
||||
pkg go/types, method (*Slice) Elem() Type
|
||||
pkg go/types, method (*Slice) String() string
|
||||
pkg go/types, method (*Slice) Underlying() Type
|
||||
pkg go/types, method (*StdSizes) Alignof(Type) int64
|
||||
pkg go/types, method (*StdSizes) Offsetsof([]*Var) []int64
|
||||
pkg go/types, method (*StdSizes) Sizeof(Type) int64
|
||||
pkg go/types, method (*Struct) Field(int) *Var
|
||||
pkg go/types, method (*Struct) NumFields() int
|
||||
pkg go/types, method (*Struct) String() string
|
||||
pkg go/types, method (*Struct) Tag(int) string
|
||||
pkg go/types, method (*Struct) Underlying() Type
|
||||
pkg go/types, method (*Tuple) At(int) *Var
|
||||
pkg go/types, method (*Tuple) Len() int
|
||||
pkg go/types, method (*Tuple) String() string
|
||||
pkg go/types, method (*Tuple) Underlying() Type
|
||||
pkg go/types, method (*TypeName) Exported() bool
|
||||
pkg go/types, method (*TypeName) Id() string
|
||||
pkg go/types, method (*TypeName) Name() string
|
||||
pkg go/types, method (*TypeName) Parent() *Scope
|
||||
pkg go/types, method (*TypeName) Pkg() *Package
|
||||
pkg go/types, method (*TypeName) Pos() token.Pos
|
||||
pkg go/types, method (*TypeName) String() string
|
||||
pkg go/types, method (*TypeName) Type() Type
|
||||
pkg go/types, method (*Var) Anonymous() bool
|
||||
pkg go/types, method (*Var) Exported() bool
|
||||
pkg go/types, method (*Var) Id() string
|
||||
pkg go/types, method (*Var) IsField() bool
|
||||
pkg go/types, method (*Var) Name() string
|
||||
pkg go/types, method (*Var) Parent() *Scope
|
||||
pkg go/types, method (*Var) Pkg() *Package
|
||||
pkg go/types, method (*Var) Pos() token.Pos
|
||||
pkg go/types, method (*Var) String() string
|
||||
pkg go/types, method (*Var) Type() Type
|
||||
pkg go/types, method (Checker) ObjectOf(*ast.Ident) Object
|
||||
pkg go/types, method (Checker) TypeOf(ast.Expr) Type
|
||||
pkg go/types, method (Error) Error() string
|
||||
pkg go/types, method (TypeAndValue) Addressable() bool
|
||||
pkg go/types, method (TypeAndValue) Assignable() bool
|
||||
pkg go/types, method (TypeAndValue) HasOk() bool
|
||||
pkg go/types, method (TypeAndValue) IsBuiltin() bool
|
||||
pkg go/types, method (TypeAndValue) IsNil() bool
|
||||
pkg go/types, method (TypeAndValue) IsType() bool
|
||||
pkg go/types, method (TypeAndValue) IsValue() bool
|
||||
pkg go/types, method (TypeAndValue) IsVoid() bool
|
||||
pkg go/types, type Array struct
|
||||
pkg go/types, type Basic struct
|
||||
pkg go/types, type BasicInfo int
|
||||
pkg go/types, type BasicKind int
|
||||
pkg go/types, type Builtin struct
|
||||
pkg go/types, type Chan struct
|
||||
pkg go/types, type ChanDir int
|
||||
pkg go/types, type Checker struct
|
||||
pkg go/types, type Checker struct, embedded *Info
|
||||
pkg go/types, type Config struct
|
||||
pkg go/types, type Config struct, DisableUnusedImportCheck bool
|
||||
pkg go/types, type Config struct, Error func(error)
|
||||
pkg go/types, type Config struct, FakeImportC bool
|
||||
pkg go/types, type Config struct, IgnoreFuncBodies bool
|
||||
pkg go/types, type Config struct, Importer Importer
|
||||
pkg go/types, type Config struct, Sizes Sizes
|
||||
pkg go/types, type Const struct
|
||||
pkg go/types, type Error struct
|
||||
pkg go/types, type Error struct, Fset *token.FileSet
|
||||
pkg go/types, type Error struct, Msg string
|
||||
pkg go/types, type Error struct, Pos token.Pos
|
||||
pkg go/types, type Error struct, Soft bool
|
||||
pkg go/types, type Func struct
|
||||
pkg go/types, type Importer interface { Import }
|
||||
pkg go/types, type Importer interface, Import(string) (*Package, error)
|
||||
pkg go/types, type Info struct
|
||||
pkg go/types, type Info struct, Defs map[*ast.Ident]Object
|
||||
pkg go/types, type Info struct, Implicits map[ast.Node]Object
|
||||
pkg go/types, type Info struct, InitOrder []*Initializer
|
||||
pkg go/types, type Info struct, Scopes map[ast.Node]*Scope
|
||||
pkg go/types, type Info struct, Selections map[*ast.SelectorExpr]*Selection
|
||||
pkg go/types, type Info struct, Types map[ast.Expr]TypeAndValue
|
||||
pkg go/types, type Info struct, Uses map[*ast.Ident]Object
|
||||
pkg go/types, type Initializer struct
|
||||
pkg go/types, type Initializer struct, Lhs []*Var
|
||||
pkg go/types, type Initializer struct, Rhs ast.Expr
|
||||
pkg go/types, type Interface struct
|
||||
pkg go/types, type Label struct
|
||||
pkg go/types, type Map struct
|
||||
pkg go/types, type MethodSet struct
|
||||
pkg go/types, type Named struct
|
||||
pkg go/types, type Nil struct
|
||||
pkg go/types, type Object interface, Exported() bool
|
||||
pkg go/types, type Object interface, Id() string
|
||||
pkg go/types, type Object interface, Name() string
|
||||
pkg go/types, type Object interface, Parent() *Scope
|
||||
pkg go/types, type Object interface, Pkg() *Package
|
||||
pkg go/types, type Object interface, Pos() token.Pos
|
||||
pkg go/types, type Object interface, String() string
|
||||
pkg go/types, type Object interface, Type() Type
|
||||
pkg go/types, type Object interface, unexported methods
|
||||
pkg go/types, type Package struct
|
||||
pkg go/types, type PkgName struct
|
||||
pkg go/types, type Pointer struct
|
||||
pkg go/types, type Qualifier func(*Package) string
|
||||
pkg go/types, type Scope struct
|
||||
pkg go/types, type Selection struct
|
||||
pkg go/types, type SelectionKind int
|
||||
pkg go/types, type Signature struct
|
||||
pkg go/types, type Sizes interface { Alignof, Offsetsof, Sizeof }
|
||||
pkg go/types, type Sizes interface, Alignof(Type) int64
|
||||
pkg go/types, type Sizes interface, Offsetsof([]*Var) []int64
|
||||
pkg go/types, type Sizes interface, Sizeof(Type) int64
|
||||
pkg go/types, type Slice struct
|
||||
pkg go/types, type StdSizes struct
|
||||
pkg go/types, type StdSizes struct, MaxAlign int64
|
||||
pkg go/types, type StdSizes struct, WordSize int64
|
||||
pkg go/types, type Struct struct
|
||||
pkg go/types, type Tuple struct
|
||||
pkg go/types, type Type interface { String, Underlying }
|
||||
pkg go/types, type Type interface, String() string
|
||||
pkg go/types, type Type interface, Underlying() Type
|
||||
pkg go/types, type TypeAndValue struct
|
||||
pkg go/types, type TypeAndValue struct, Type Type
|
||||
pkg go/types, type TypeAndValue struct, Value constant.Value
|
||||
pkg go/types, type TypeName struct
|
||||
pkg go/types, type Var struct
|
||||
pkg go/types, var Typ []*Basic
|
||||
pkg go/types, var Universe *Scope
|
||||
pkg go/types, var Unsafe *Package
|
||||
pkg html/template, method (*Template) Option(...string) *Template
|
||||
pkg image, const YCbCrSubsampleRatio410 = 5
|
||||
pkg image, const YCbCrSubsampleRatio410 YCbCrSubsampleRatio
|
||||
pkg image, const YCbCrSubsampleRatio411 = 4
|
||||
pkg image, const YCbCrSubsampleRatio411 YCbCrSubsampleRatio
|
||||
pkg image, func NewCMYK(Rectangle) *CMYK
|
||||
pkg image, method (*CMYK) At(int, int) color.Color
|
||||
pkg image, method (*CMYK) Bounds() Rectangle
|
||||
pkg image, method (*CMYK) CMYKAt(int, int) color.CMYK
|
||||
pkg image, method (*CMYK) ColorModel() color.Model
|
||||
pkg image, method (*CMYK) Opaque() bool
|
||||
pkg image, method (*CMYK) PixOffset(int, int) int
|
||||
pkg image, method (*CMYK) Set(int, int, color.Color)
|
||||
pkg image, method (*CMYK) SetCMYK(int, int, color.CMYK)
|
||||
pkg image, method (*CMYK) SubImage(Rectangle) Image
|
||||
pkg image, method (Rectangle) At(int, int) color.Color
|
||||
pkg image, method (Rectangle) Bounds() Rectangle
|
||||
pkg image, method (Rectangle) ColorModel() color.Model
|
||||
pkg image, type CMYK struct
|
||||
pkg image, type CMYK struct, Pix []uint8
|
||||
pkg image, type CMYK struct, Rect Rectangle
|
||||
pkg image, type CMYK struct, Stride int
|
||||
pkg image/color, func CMYKToRGB(uint8, uint8, uint8, uint8) (uint8, uint8, uint8)
|
||||
pkg image/color, func RGBToCMYK(uint8, uint8, uint8) (uint8, uint8, uint8, uint8)
|
||||
pkg image/color, method (CMYK) RGBA() (uint32, uint32, uint32, uint32)
|
||||
pkg image/color, type CMYK struct
|
||||
pkg image/color, type CMYK struct, C uint8
|
||||
pkg image/color, type CMYK struct, K uint8
|
||||
pkg image/color, type CMYK struct, M uint8
|
||||
pkg image/color, type CMYK struct, Y uint8
|
||||
pkg image/color, var CMYKModel Model
|
||||
pkg image/gif, const DisposalBackground = 2
|
||||
pkg image/gif, const DisposalBackground ideal-int
|
||||
pkg image/gif, const DisposalNone = 1
|
||||
pkg image/gif, const DisposalNone ideal-int
|
||||
pkg image/gif, const DisposalPrevious = 3
|
||||
pkg image/gif, const DisposalPrevious ideal-int
|
||||
pkg image/gif, type GIF struct, BackgroundIndex uint8
|
||||
pkg image/gif, type GIF struct, Config image.Config
|
||||
pkg image/gif, type GIF struct, Disposal []uint8
|
||||
pkg io, func CopyBuffer(Writer, Reader, []uint8) (int64, error)
|
||||
pkg log, const LUTC = 32
|
||||
pkg log, const LUTC ideal-int
|
||||
pkg log, func Output(int, string) error
|
||||
pkg log, method (*Logger) SetOutput(io.Writer)
|
||||
pkg math/big, const Above = 1
|
||||
pkg math/big, const Above Accuracy
|
||||
pkg math/big, const AwayFromZero = 3
|
||||
pkg math/big, const AwayFromZero RoundingMode
|
||||
pkg math/big, const Below = -1
|
||||
pkg math/big, const Below Accuracy
|
||||
pkg math/big, const Exact = 0
|
||||
pkg math/big, const Exact Accuracy
|
||||
pkg math/big, const MaxExp = 2147483647
|
||||
pkg math/big, const MaxExp ideal-int
|
||||
pkg math/big, const MaxPrec = 4294967295
|
||||
pkg math/big, const MaxPrec ideal-int
|
||||
pkg math/big, const MinExp = -2147483648
|
||||
pkg math/big, const MinExp ideal-int
|
||||
pkg math/big, const ToNearestAway = 1
|
||||
pkg math/big, const ToNearestAway RoundingMode
|
||||
pkg math/big, const ToNearestEven = 0
|
||||
pkg math/big, const ToNearestEven RoundingMode
|
||||
pkg math/big, const ToNegativeInf = 4
|
||||
pkg math/big, const ToNegativeInf RoundingMode
|
||||
pkg math/big, const ToPositiveInf = 5
|
||||
pkg math/big, const ToPositiveInf RoundingMode
|
||||
pkg math/big, const ToZero = 2
|
||||
pkg math/big, const ToZero RoundingMode
|
||||
pkg math/big, func Jacobi(*Int, *Int) int
|
||||
pkg math/big, func NewFloat(float64) *Float
|
||||
pkg math/big, func ParseFloat(string, int, uint, RoundingMode) (*Float, int, error)
|
||||
pkg math/big, method (*Float) Abs(*Float) *Float
|
||||
pkg math/big, method (*Float) Acc() Accuracy
|
||||
pkg math/big, method (*Float) Add(*Float, *Float) *Float
|
||||
pkg math/big, method (*Float) Append([]uint8, uint8, int) []uint8
|
||||
pkg math/big, method (*Float) Cmp(*Float) int
|
||||
pkg math/big, method (*Float) Copy(*Float) *Float
|
||||
pkg math/big, method (*Float) Float32() (float32, Accuracy)
|
||||
pkg math/big, method (*Float) Float64() (float64, Accuracy)
|
||||
pkg math/big, method (*Float) Format(fmt.State, int32)
|
||||
pkg math/big, method (*Float) Int(*Int) (*Int, Accuracy)
|
||||
pkg math/big, method (*Float) Int64() (int64, Accuracy)
|
||||
pkg math/big, method (*Float) IsInf() bool
|
||||
pkg math/big, method (*Float) IsInt() bool
|
||||
pkg math/big, method (*Float) MantExp(*Float) int
|
||||
pkg math/big, method (*Float) MinPrec() uint
|
||||
pkg math/big, method (*Float) Mode() RoundingMode
|
||||
pkg math/big, method (*Float) Mul(*Float, *Float) *Float
|
||||
pkg math/big, method (*Float) Neg(*Float) *Float
|
||||
pkg math/big, method (*Float) Parse(string, int) (*Float, int, error)
|
||||
pkg math/big, method (*Float) Prec() uint
|
||||
pkg math/big, method (*Float) Quo(*Float, *Float) *Float
|
||||
pkg math/big, method (*Float) Rat(*Rat) (*Rat, Accuracy)
|
||||
pkg math/big, method (*Float) Set(*Float) *Float
|
||||
pkg math/big, method (*Float) SetFloat64(float64) *Float
|
||||
pkg math/big, method (*Float) SetInf(bool) *Float
|
||||
pkg math/big, method (*Float) SetInt(*Int) *Float
|
||||
pkg math/big, method (*Float) SetInt64(int64) *Float
|
||||
pkg math/big, method (*Float) SetMantExp(*Float, int) *Float
|
||||
pkg math/big, method (*Float) SetMode(RoundingMode) *Float
|
||||
pkg math/big, method (*Float) SetPrec(uint) *Float
|
||||
pkg math/big, method (*Float) SetRat(*Rat) *Float
|
||||
pkg math/big, method (*Float) SetString(string) (*Float, bool)
|
||||
pkg math/big, method (*Float) SetUint64(uint64) *Float
|
||||
pkg math/big, method (*Float) Sign() int
|
||||
pkg math/big, method (*Float) Signbit() bool
|
||||
pkg math/big, method (*Float) String() string
|
||||
pkg math/big, method (*Float) Sub(*Float, *Float) *Float
|
||||
pkg math/big, method (*Float) Text(uint8, int) string
|
||||
pkg math/big, method (*Float) Uint64() (uint64, Accuracy)
|
||||
pkg math/big, method (*Int) ModSqrt(*Int, *Int) *Int
|
||||
pkg math/big, method (Accuracy) String() string
|
||||
pkg math/big, method (ErrNaN) Error() string
|
||||
pkg math/big, method (RoundingMode) String() string
|
||||
pkg math/big, type Accuracy int8
|
||||
pkg math/big, type ErrNaN struct
|
||||
pkg math/big, type Float struct
|
||||
pkg math/big, type RoundingMode uint8
|
||||
pkg mime, const BEncoding = 98
|
||||
pkg mime, const BEncoding WordEncoder
|
||||
pkg mime, const QEncoding = 113
|
||||
pkg mime, const QEncoding WordEncoder
|
||||
pkg mime, func ExtensionsByType(string) ([]string, error)
|
||||
pkg mime, method (*WordDecoder) Decode(string) (string, error)
|
||||
pkg mime, method (*WordDecoder) DecodeHeader(string) (string, error)
|
||||
pkg mime, method (WordEncoder) Encode(string, string) string
|
||||
pkg mime, type WordDecoder struct
|
||||
pkg mime, type WordDecoder struct, CharsetReader func(string, io.Reader) (io.Reader, error)
|
||||
pkg mime, type WordEncoder uint8
|
||||
pkg mime/quotedprintable, func NewReader(io.Reader) *Reader
|
||||
pkg mime/quotedprintable, func NewWriter(io.Writer) *Writer
|
||||
pkg mime/quotedprintable, method (*Reader) Read([]uint8) (int, error)
|
||||
pkg mime/quotedprintable, method (*Writer) Close() error
|
||||
pkg mime/quotedprintable, method (*Writer) Write([]uint8) (int, error)
|
||||
pkg mime/quotedprintable, type Reader struct
|
||||
pkg mime/quotedprintable, type Writer struct
|
||||
pkg mime/quotedprintable, type Writer struct, Binary bool
|
||||
pkg net, type Dialer struct, FallbackDelay time.Duration
|
||||
pkg net, type OpError struct, Source Addr
|
||||
pkg net/http, type Request struct, Cancel <-chan struct
|
||||
pkg net/http/fcgi, var ErrConnClosed error
|
||||
pkg net/http/fcgi, var ErrRequestAborted error
|
||||
pkg net/http/pprof, func Trace(http.ResponseWriter, *http.Request)
|
||||
pkg net/mail, method (*AddressParser) Parse(string) (*Address, error)
|
||||
pkg net/mail, method (*AddressParser) ParseList(string) ([]*Address, error)
|
||||
pkg net/mail, type AddressParser struct
|
||||
pkg net/mail, type AddressParser struct, WordDecoder *mime.WordDecoder
|
||||
pkg net/smtp, method (*Client) TLSConnectionState() (tls.ConnectionState, bool)
|
||||
pkg net/url, method (*URL) EscapedPath() string
|
||||
pkg net/url, type URL struct, RawPath string
|
||||
pkg os, func LookupEnv(string) (string, bool)
|
||||
pkg os/signal, func Ignore(...os.Signal)
|
||||
pkg os/signal, func Reset(...os.Signal)
|
||||
pkg reflect, func ArrayOf(int, Type) Type
|
||||
pkg reflect, func FuncOf([]Type, []Type, bool) Type
|
||||
pkg runtime, func ReadTrace() []uint8
|
||||
pkg runtime, func StartTrace() error
|
||||
pkg runtime, func StopTrace()
|
||||
pkg runtime, type MemStats struct, GCCPUFraction float64
|
||||
pkg runtime/trace, func Start(io.Writer) error
|
||||
pkg runtime/trace, func Stop()
|
||||
pkg strings, func Compare(string, string) int
|
||||
pkg strings, func LastIndexByte(string, uint8) int
|
||||
pkg strings, method (*Reader) Size() int64
|
||||
pkg syscall (darwin-386), type SysProcAttr struct, Ctty int
|
||||
pkg syscall (darwin-386), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (darwin-386), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (darwin-386-cgo), type SysProcAttr struct, Ctty int
|
||||
pkg syscall (darwin-386-cgo), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (darwin-386-cgo), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (darwin-amd64), type SysProcAttr struct, Ctty int
|
||||
pkg syscall (darwin-amd64), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (darwin-amd64), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (darwin-amd64-cgo), type SysProcAttr struct, Ctty int
|
||||
pkg syscall (darwin-amd64-cgo), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (darwin-amd64-cgo), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (freebsd-386), type SysProcAttr struct, Ctty int
|
||||
pkg syscall (freebsd-386), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (freebsd-386), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (freebsd-386-cgo), type SysProcAttr struct, Ctty int
|
||||
pkg syscall (freebsd-386-cgo), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (freebsd-386-cgo), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (freebsd-amd64), type SysProcAttr struct, Ctty int
|
||||
pkg syscall (freebsd-amd64), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (freebsd-amd64), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (freebsd-amd64-cgo), type SysProcAttr struct, Ctty int
|
||||
pkg syscall (freebsd-amd64-cgo), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (freebsd-amd64-cgo), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (freebsd-arm), type SysProcAttr struct, Ctty int
|
||||
pkg syscall (freebsd-arm), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (freebsd-arm), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (freebsd-arm-cgo), type SysProcAttr struct, Ctty int
|
||||
pkg syscall (freebsd-arm-cgo), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (freebsd-arm-cgo), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (linux-386), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (linux-386), type SysProcAttr struct, GidMappingsEnableSetgroups bool
|
||||
pkg syscall (linux-386), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (linux-386-cgo), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (linux-386-cgo), type SysProcAttr struct, GidMappingsEnableSetgroups bool
|
||||
pkg syscall (linux-386-cgo), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (linux-amd64), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (linux-amd64), type SysProcAttr struct, GidMappingsEnableSetgroups bool
|
||||
pkg syscall (linux-amd64), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (linux-amd64-cgo), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (linux-amd64-cgo), type SysProcAttr struct, GidMappingsEnableSetgroups bool
|
||||
pkg syscall (linux-amd64-cgo), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (linux-arm), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (linux-arm), type SysProcAttr struct, GidMappingsEnableSetgroups bool
|
||||
pkg syscall (linux-arm), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (linux-arm-cgo), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (linux-arm-cgo), type SysProcAttr struct, GidMappingsEnableSetgroups bool
|
||||
pkg syscall (linux-arm-cgo), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (netbsd-386), type SysProcAttr struct, Ctty int
|
||||
pkg syscall (netbsd-386), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (netbsd-386), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (netbsd-386-cgo), type SysProcAttr struct, Ctty int
|
||||
pkg syscall (netbsd-386-cgo), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (netbsd-386-cgo), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (netbsd-amd64), type SysProcAttr struct, Ctty int
|
||||
pkg syscall (netbsd-amd64), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (netbsd-amd64), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (netbsd-amd64-cgo), type SysProcAttr struct, Ctty int
|
||||
pkg syscall (netbsd-amd64-cgo), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (netbsd-amd64-cgo), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (netbsd-arm), type SysProcAttr struct, Ctty int
|
||||
pkg syscall (netbsd-arm), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (netbsd-arm), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (netbsd-arm-cgo), type SysProcAttr struct, Ctty int
|
||||
pkg syscall (netbsd-arm-cgo), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (netbsd-arm-cgo), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (openbsd-386), type SysProcAttr struct, Ctty int
|
||||
pkg syscall (openbsd-386), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (openbsd-386), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (openbsd-386-cgo), type SysProcAttr struct, Ctty int
|
||||
pkg syscall (openbsd-386-cgo), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (openbsd-386-cgo), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (openbsd-amd64), type SysProcAttr struct, Ctty int
|
||||
pkg syscall (openbsd-amd64), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (openbsd-amd64), type SysProcAttr struct, Pgid int
|
||||
pkg syscall (openbsd-amd64-cgo), type SysProcAttr struct, Ctty int
|
||||
pkg syscall (openbsd-amd64-cgo), type SysProcAttr struct, Foreground bool
|
||||
pkg syscall (openbsd-amd64-cgo), type SysProcAttr struct, Pgid int
|
||||
pkg text/template, method (*Template) DefinedTemplates() string
|
||||
pkg text/template, method (*Template) Option(...string) *Template
|
||||
pkg time, method (Time) AppendFormat([]uint8, string) []uint8
|
||||
pkg unicode, const Version = "8.0.0"
|
||||
pkg unicode, var Ahom *RangeTable
|
||||
pkg unicode, var Anatolian_Hieroglyphs *RangeTable
|
||||
pkg unicode, var Hatran *RangeTable
|
||||
pkg unicode, var Multani *RangeTable
|
||||
pkg unicode, var Old_Hungarian *RangeTable
|
||||
pkg unicode, var SignWriting *RangeTable
|
||||
275
api/go1.6.txt
275
api/go1.6.txt
@@ -1,275 +0,0 @@
|
||||
pkg archive/zip, method (*ReadCloser) RegisterDecompressor(uint16, Decompressor)
|
||||
pkg archive/zip, method (*Reader) RegisterDecompressor(uint16, Decompressor)
|
||||
pkg archive/zip, method (*Writer) RegisterCompressor(uint16, Compressor)
|
||||
pkg bufio, method (*Scanner) Buffer([]uint8, int)
|
||||
pkg bufio, var ErrFinalToken error
|
||||
pkg crypto/tls, const TLS_RSA_WITH_AES_128_GCM_SHA256 = 156
|
||||
pkg crypto/tls, const TLS_RSA_WITH_AES_128_GCM_SHA256 uint16
|
||||
pkg crypto/tls, const TLS_RSA_WITH_AES_256_GCM_SHA384 = 157
|
||||
pkg crypto/tls, const TLS_RSA_WITH_AES_256_GCM_SHA384 uint16
|
||||
pkg crypto/tls, method (RecordHeaderError) Error() string
|
||||
pkg crypto/tls, type RecordHeaderError struct
|
||||
pkg crypto/tls, type RecordHeaderError struct, Msg string
|
||||
pkg crypto/tls, type RecordHeaderError struct, RecordHeader [5]uint8
|
||||
pkg crypto/x509, method (InsecureAlgorithmError) Error() string
|
||||
pkg crypto/x509, method (SignatureAlgorithm) String() string
|
||||
pkg crypto/x509, type InsecureAlgorithmError int
|
||||
pkg database/sql, method (*DB) SetConnMaxLifetime(time.Duration)
|
||||
pkg debug/dwarf, const ClassUnknown = 0
|
||||
pkg debug/dwarf, const ClassUnknown Class
|
||||
pkg debug/elf, const COMPRESS_HIOS = 1879048191
|
||||
pkg debug/elf, const COMPRESS_HIOS CompressionType
|
||||
pkg debug/elf, const COMPRESS_HIPROC = 2147483647
|
||||
pkg debug/elf, const COMPRESS_HIPROC CompressionType
|
||||
pkg debug/elf, const COMPRESS_LOOS = 1610612736
|
||||
pkg debug/elf, const COMPRESS_LOOS CompressionType
|
||||
pkg debug/elf, const COMPRESS_LOPROC = 1879048192
|
||||
pkg debug/elf, const COMPRESS_LOPROC CompressionType
|
||||
pkg debug/elf, const COMPRESS_ZLIB = 1
|
||||
pkg debug/elf, const COMPRESS_ZLIB CompressionType
|
||||
pkg debug/elf, const R_MIPS_16 = 1
|
||||
pkg debug/elf, const R_MIPS_16 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_26 = 4
|
||||
pkg debug/elf, const R_MIPS_26 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_32 = 2
|
||||
pkg debug/elf, const R_MIPS_32 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_64 = 18
|
||||
pkg debug/elf, const R_MIPS_64 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_ADD_IMMEDIATE = 34
|
||||
pkg debug/elf, const R_MIPS_ADD_IMMEDIATE R_MIPS
|
||||
pkg debug/elf, const R_MIPS_CALL16 = 11
|
||||
pkg debug/elf, const R_MIPS_CALL16 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_CALL_HI16 = 30
|
||||
pkg debug/elf, const R_MIPS_CALL_HI16 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_CALL_LO16 = 31
|
||||
pkg debug/elf, const R_MIPS_CALL_LO16 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_DELETE = 27
|
||||
pkg debug/elf, const R_MIPS_DELETE R_MIPS
|
||||
pkg debug/elf, const R_MIPS_GOT16 = 9
|
||||
pkg debug/elf, const R_MIPS_GOT16 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_GOT_DISP = 19
|
||||
pkg debug/elf, const R_MIPS_GOT_DISP R_MIPS
|
||||
pkg debug/elf, const R_MIPS_GOT_HI16 = 22
|
||||
pkg debug/elf, const R_MIPS_GOT_HI16 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_GOT_LO16 = 23
|
||||
pkg debug/elf, const R_MIPS_GOT_LO16 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_GOT_OFST = 21
|
||||
pkg debug/elf, const R_MIPS_GOT_OFST R_MIPS
|
||||
pkg debug/elf, const R_MIPS_GOT_PAGE = 20
|
||||
pkg debug/elf, const R_MIPS_GOT_PAGE R_MIPS
|
||||
pkg debug/elf, const R_MIPS_GPREL16 = 7
|
||||
pkg debug/elf, const R_MIPS_GPREL16 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_GPREL32 = 12
|
||||
pkg debug/elf, const R_MIPS_GPREL32 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_HI16 = 5
|
||||
pkg debug/elf, const R_MIPS_HI16 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_HIGHER = 28
|
||||
pkg debug/elf, const R_MIPS_HIGHER R_MIPS
|
||||
pkg debug/elf, const R_MIPS_HIGHEST = 29
|
||||
pkg debug/elf, const R_MIPS_HIGHEST R_MIPS
|
||||
pkg debug/elf, const R_MIPS_INSERT_A = 25
|
||||
pkg debug/elf, const R_MIPS_INSERT_A R_MIPS
|
||||
pkg debug/elf, const R_MIPS_INSERT_B = 26
|
||||
pkg debug/elf, const R_MIPS_INSERT_B R_MIPS
|
||||
pkg debug/elf, const R_MIPS_JALR = 37
|
||||
pkg debug/elf, const R_MIPS_JALR R_MIPS
|
||||
pkg debug/elf, const R_MIPS_LITERAL = 8
|
||||
pkg debug/elf, const R_MIPS_LITERAL R_MIPS
|
||||
pkg debug/elf, const R_MIPS_LO16 = 6
|
||||
pkg debug/elf, const R_MIPS_LO16 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_NONE = 0
|
||||
pkg debug/elf, const R_MIPS_NONE R_MIPS
|
||||
pkg debug/elf, const R_MIPS_PC16 = 10
|
||||
pkg debug/elf, const R_MIPS_PC16 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_PJUMP = 35
|
||||
pkg debug/elf, const R_MIPS_PJUMP R_MIPS
|
||||
pkg debug/elf, const R_MIPS_REL16 = 33
|
||||
pkg debug/elf, const R_MIPS_REL16 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_REL32 = 3
|
||||
pkg debug/elf, const R_MIPS_REL32 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_RELGOT = 36
|
||||
pkg debug/elf, const R_MIPS_RELGOT R_MIPS
|
||||
pkg debug/elf, const R_MIPS_SCN_DISP = 32
|
||||
pkg debug/elf, const R_MIPS_SCN_DISP R_MIPS
|
||||
pkg debug/elf, const R_MIPS_SHIFT5 = 16
|
||||
pkg debug/elf, const R_MIPS_SHIFT5 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_SHIFT6 = 17
|
||||
pkg debug/elf, const R_MIPS_SHIFT6 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_SUB = 24
|
||||
pkg debug/elf, const R_MIPS_SUB R_MIPS
|
||||
pkg debug/elf, const R_MIPS_TLS_DTPMOD32 = 38
|
||||
pkg debug/elf, const R_MIPS_TLS_DTPMOD32 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_TLS_DTPMOD64 = 40
|
||||
pkg debug/elf, const R_MIPS_TLS_DTPMOD64 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_TLS_DTPREL32 = 39
|
||||
pkg debug/elf, const R_MIPS_TLS_DTPREL32 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_TLS_DTPREL64 = 41
|
||||
pkg debug/elf, const R_MIPS_TLS_DTPREL64 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_TLS_DTPREL_HI16 = 44
|
||||
pkg debug/elf, const R_MIPS_TLS_DTPREL_HI16 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_TLS_DTPREL_LO16 = 45
|
||||
pkg debug/elf, const R_MIPS_TLS_DTPREL_LO16 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_TLS_GD = 42
|
||||
pkg debug/elf, const R_MIPS_TLS_GD R_MIPS
|
||||
pkg debug/elf, const R_MIPS_TLS_GOTTPREL = 46
|
||||
pkg debug/elf, const R_MIPS_TLS_GOTTPREL R_MIPS
|
||||
pkg debug/elf, const R_MIPS_TLS_LDM = 43
|
||||
pkg debug/elf, const R_MIPS_TLS_LDM R_MIPS
|
||||
pkg debug/elf, const R_MIPS_TLS_TPREL32 = 47
|
||||
pkg debug/elf, const R_MIPS_TLS_TPREL32 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_TLS_TPREL64 = 48
|
||||
pkg debug/elf, const R_MIPS_TLS_TPREL64 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_TLS_TPREL_HI16 = 49
|
||||
pkg debug/elf, const R_MIPS_TLS_TPREL_HI16 R_MIPS
|
||||
pkg debug/elf, const R_MIPS_TLS_TPREL_LO16 = 50
|
||||
pkg debug/elf, const R_MIPS_TLS_TPREL_LO16 R_MIPS
|
||||
pkg debug/elf, const SHF_COMPRESSED = 2048
|
||||
pkg debug/elf, const SHF_COMPRESSED SectionFlag
|
||||
pkg debug/elf, method (CompressionType) GoString() string
|
||||
pkg debug/elf, method (CompressionType) String() string
|
||||
pkg debug/elf, method (R_MIPS) GoString() string
|
||||
pkg debug/elf, method (R_MIPS) String() string
|
||||
pkg debug/elf, type Chdr32 struct
|
||||
pkg debug/elf, type Chdr32 struct, Addralign uint32
|
||||
pkg debug/elf, type Chdr32 struct, Size uint32
|
||||
pkg debug/elf, type Chdr32 struct, Type uint32
|
||||
pkg debug/elf, type Chdr64 struct
|
||||
pkg debug/elf, type Chdr64 struct, Addralign uint64
|
||||
pkg debug/elf, type Chdr64 struct, Size uint64
|
||||
pkg debug/elf, type Chdr64 struct, Type uint32
|
||||
pkg debug/elf, type CompressionType int
|
||||
pkg debug/elf, type R_MIPS int
|
||||
pkg debug/elf, type SectionHeader struct, FileSize uint64
|
||||
pkg encoding/asn1, const ClassApplication = 1
|
||||
pkg encoding/asn1, const ClassApplication ideal-int
|
||||
pkg encoding/asn1, const ClassContextSpecific = 2
|
||||
pkg encoding/asn1, const ClassContextSpecific ideal-int
|
||||
pkg encoding/asn1, const ClassPrivate = 3
|
||||
pkg encoding/asn1, const ClassPrivate ideal-int
|
||||
pkg encoding/asn1, const ClassUniversal = 0
|
||||
pkg encoding/asn1, const ClassUniversal ideal-int
|
||||
pkg encoding/asn1, const TagBitString = 3
|
||||
pkg encoding/asn1, const TagBitString ideal-int
|
||||
pkg encoding/asn1, const TagBoolean = 1
|
||||
pkg encoding/asn1, const TagBoolean ideal-int
|
||||
pkg encoding/asn1, const TagEnum = 10
|
||||
pkg encoding/asn1, const TagEnum ideal-int
|
||||
pkg encoding/asn1, const TagGeneralString = 27
|
||||
pkg encoding/asn1, const TagGeneralString ideal-int
|
||||
pkg encoding/asn1, const TagGeneralizedTime = 24
|
||||
pkg encoding/asn1, const TagGeneralizedTime ideal-int
|
||||
pkg encoding/asn1, const TagIA5String = 22
|
||||
pkg encoding/asn1, const TagIA5String ideal-int
|
||||
pkg encoding/asn1, const TagInteger = 2
|
||||
pkg encoding/asn1, const TagInteger ideal-int
|
||||
pkg encoding/asn1, const TagOID = 6
|
||||
pkg encoding/asn1, const TagOID ideal-int
|
||||
pkg encoding/asn1, const TagOctetString = 4
|
||||
pkg encoding/asn1, const TagOctetString ideal-int
|
||||
pkg encoding/asn1, const TagPrintableString = 19
|
||||
pkg encoding/asn1, const TagPrintableString ideal-int
|
||||
pkg encoding/asn1, const TagSequence = 16
|
||||
pkg encoding/asn1, const TagSequence ideal-int
|
||||
pkg encoding/asn1, const TagSet = 17
|
||||
pkg encoding/asn1, const TagSet ideal-int
|
||||
pkg encoding/asn1, const TagT61String = 20
|
||||
pkg encoding/asn1, const TagT61String ideal-int
|
||||
pkg encoding/asn1, const TagUTCTime = 23
|
||||
pkg encoding/asn1, const TagUTCTime ideal-int
|
||||
pkg encoding/asn1, const TagUTF8String = 12
|
||||
pkg encoding/asn1, const TagUTF8String ideal-int
|
||||
pkg go/build, const IgnoreVendor = 8
|
||||
pkg go/build, const IgnoreVendor ImportMode
|
||||
pkg go/build, type Package struct, InvalidGoFiles []string
|
||||
pkg go/constant, func ToComplex(Value) Value
|
||||
pkg go/constant, func ToFloat(Value) Value
|
||||
pkg go/constant, func ToInt(Value) Value
|
||||
pkg go/constant, type Value interface, ExactString() string
|
||||
pkg go/types, method (*Package) SetName(string)
|
||||
pkg go/types, type ImportMode int
|
||||
pkg go/types, type ImporterFrom interface { Import, ImportFrom }
|
||||
pkg go/types, type ImporterFrom interface, Import(string) (*Package, error)
|
||||
pkg go/types, type ImporterFrom interface, ImportFrom(string, string, ImportMode) (*Package, error)
|
||||
pkg html/template, func IsTrue(interface{}) (bool, bool)
|
||||
pkg html/template, method (*Template) DefinedTemplates() string
|
||||
pkg image, func NewNYCbCrA(Rectangle, YCbCrSubsampleRatio) *NYCbCrA
|
||||
pkg image, method (*NYCbCrA) AOffset(int, int) int
|
||||
pkg image, method (*NYCbCrA) At(int, int) color.Color
|
||||
pkg image, method (*NYCbCrA) Bounds() Rectangle
|
||||
pkg image, method (*NYCbCrA) COffset(int, int) int
|
||||
pkg image, method (*NYCbCrA) ColorModel() color.Model
|
||||
pkg image, method (*NYCbCrA) NYCbCrAAt(int, int) color.NYCbCrA
|
||||
pkg image, method (*NYCbCrA) Opaque() bool
|
||||
pkg image, method (*NYCbCrA) SubImage(Rectangle) Image
|
||||
pkg image, method (*NYCbCrA) YCbCrAt(int, int) color.YCbCr
|
||||
pkg image, method (*NYCbCrA) YOffset(int, int) int
|
||||
pkg image, type NYCbCrA struct
|
||||
pkg image, type NYCbCrA struct, A []uint8
|
||||
pkg image, type NYCbCrA struct, AStride int
|
||||
pkg image, type NYCbCrA struct, embedded YCbCr
|
||||
pkg image/color, method (NYCbCrA) RGBA() (uint32, uint32, uint32, uint32)
|
||||
pkg image/color, type NYCbCrA struct
|
||||
pkg image/color, type NYCbCrA struct, A uint8
|
||||
pkg image/color, type NYCbCrA struct, embedded YCbCr
|
||||
pkg image/color, var NYCbCrAModel Model
|
||||
pkg math/big, method (*Float) MarshalText() ([]uint8, error)
|
||||
pkg math/big, method (*Float) UnmarshalText([]uint8) error
|
||||
pkg math/big, method (*Int) Append([]uint8, int) []uint8
|
||||
pkg math/big, method (*Int) Text(int) string
|
||||
pkg math/rand, func Read([]uint8) (int, error)
|
||||
pkg math/rand, method (*Rand) Read([]uint8) (int, error)
|
||||
pkg net, type DNSError struct, IsTemporary bool
|
||||
pkg net, type Dialer struct, Cancel <-chan struct
|
||||
pkg net/http, const MethodConnect = "CONNECT"
|
||||
pkg net/http, const MethodConnect ideal-string
|
||||
pkg net/http, const MethodDelete = "DELETE"
|
||||
pkg net/http, const MethodDelete ideal-string
|
||||
pkg net/http, const MethodGet = "GET"
|
||||
pkg net/http, const MethodGet ideal-string
|
||||
pkg net/http, const MethodHead = "HEAD"
|
||||
pkg net/http, const MethodHead ideal-string
|
||||
pkg net/http, const MethodOptions = "OPTIONS"
|
||||
pkg net/http, const MethodOptions ideal-string
|
||||
pkg net/http, const MethodPatch = "PATCH"
|
||||
pkg net/http, const MethodPatch ideal-string
|
||||
pkg net/http, const MethodPost = "POST"
|
||||
pkg net/http, const MethodPost ideal-string
|
||||
pkg net/http, const MethodPut = "PUT"
|
||||
pkg net/http, const MethodPut ideal-string
|
||||
pkg net/http, const MethodTrace = "TRACE"
|
||||
pkg net/http, const MethodTrace ideal-string
|
||||
pkg net/http, const StatusNetworkAuthenticationRequired = 511
|
||||
pkg net/http, const StatusNetworkAuthenticationRequired ideal-int
|
||||
pkg net/http, const StatusPreconditionRequired = 428
|
||||
pkg net/http, const StatusPreconditionRequired ideal-int
|
||||
pkg net/http, const StatusRequestHeaderFieldsTooLarge = 431
|
||||
pkg net/http, const StatusRequestHeaderFieldsTooLarge ideal-int
|
||||
pkg net/http, const StatusTooManyRequests = 429
|
||||
pkg net/http, const StatusTooManyRequests ideal-int
|
||||
pkg net/http, const StatusUnavailableForLegalReasons = 451
|
||||
pkg net/http, const StatusUnavailableForLegalReasons ideal-int
|
||||
pkg net/http, type Transport struct, ExpectContinueTimeout time.Duration
|
||||
pkg net/http, type Transport struct, TLSNextProto map[string]func(string, *tls.Conn) RoundTripper
|
||||
pkg net/http, var ErrSkipAltProtocol error
|
||||
pkg net/http/httptest, method (*ResponseRecorder) WriteString(string) (int, error)
|
||||
pkg net/http/httputil, type BufferPool interface { Get, Put }
|
||||
pkg net/http/httputil, type BufferPool interface, Get() []uint8
|
||||
pkg net/http/httputil, type BufferPool interface, Put([]uint8)
|
||||
pkg net/http/httputil, type ReverseProxy struct, BufferPool BufferPool
|
||||
pkg net/url, method (*Error) Temporary() bool
|
||||
pkg net/url, method (*Error) Timeout() bool
|
||||
pkg net/url, method (InvalidHostError) Error() string
|
||||
pkg net/url, type InvalidHostError string
|
||||
pkg os/exec, type ExitError struct, Stderr []uint8
|
||||
pkg regexp, method (*Regexp) Copy() *Regexp
|
||||
pkg runtime/debug, func SetTraceback(string)
|
||||
pkg strconv, func AppendQuoteRuneToGraphic([]uint8, int32) []uint8
|
||||
pkg strconv, func AppendQuoteToGraphic([]uint8, string) []uint8
|
||||
pkg strconv, func IsGraphic(int32) bool
|
||||
pkg strconv, func QuoteRuneToGraphic(int32) string
|
||||
pkg strconv, func QuoteToGraphic(string) string
|
||||
pkg text/template, func IsTrue(interface{}) (bool, bool)
|
||||
pkg text/template, method (ExecError) Error() string
|
||||
pkg text/template, type ExecError struct
|
||||
pkg text/template, type ExecError struct, Err error
|
||||
pkg text/template, type ExecError struct, Name string
|
||||
285
api/go1.7.txt
285
api/go1.7.txt
@@ -1,285 +0,0 @@
|
||||
pkg bytes, func ContainsAny([]uint8, string) bool
|
||||
pkg bytes, func ContainsRune([]uint8, int32) bool
|
||||
pkg bytes, method (*Reader) Reset([]uint8)
|
||||
pkg compress/flate, const HuffmanOnly = -2
|
||||
pkg compress/flate, const HuffmanOnly ideal-int
|
||||
pkg context, func Background() Context
|
||||
pkg context, func TODO() Context
|
||||
pkg context, func WithCancel(Context) (Context, CancelFunc)
|
||||
pkg context, func WithDeadline(Context, time.Time) (Context, CancelFunc)
|
||||
pkg context, func WithTimeout(Context, time.Duration) (Context, CancelFunc)
|
||||
pkg context, func WithValue(Context, interface{}, interface{}) Context
|
||||
pkg context, type CancelFunc func()
|
||||
pkg context, type Context interface { Deadline, Done, Err, Value }
|
||||
pkg context, type Context interface, Deadline() (time.Time, bool)
|
||||
pkg context, type Context interface, Done() <-chan struct
|
||||
pkg context, type Context interface, Err() error
|
||||
pkg context, type Context interface, Value(interface{}) interface{}
|
||||
pkg context, var Canceled error
|
||||
pkg context, var DeadlineExceeded error
|
||||
pkg crypto/tls, const RenegotiateFreelyAsClient = 2
|
||||
pkg crypto/tls, const RenegotiateFreelyAsClient RenegotiationSupport
|
||||
pkg crypto/tls, const RenegotiateNever = 0
|
||||
pkg crypto/tls, const RenegotiateNever RenegotiationSupport
|
||||
pkg crypto/tls, const RenegotiateOnceAsClient = 1
|
||||
pkg crypto/tls, const RenegotiateOnceAsClient RenegotiationSupport
|
||||
pkg crypto/tls, type Config struct, DynamicRecordSizingDisabled bool
|
||||
pkg crypto/tls, type Config struct, Renegotiation RenegotiationSupport
|
||||
pkg crypto/tls, type RenegotiationSupport int
|
||||
pkg crypto/x509, func SystemCertPool() (*CertPool, error)
|
||||
pkg crypto/x509, type SystemRootsError struct, Err error
|
||||
pkg debug/dwarf, method (*Data) Ranges(*Entry) ([][2]uint64, error)
|
||||
pkg debug/dwarf, method (*Reader) SeekPC(uint64) (*Entry, error)
|
||||
pkg debug/elf, const R_390_12 = 2
|
||||
pkg debug/elf, const R_390_12 R_390
|
||||
pkg debug/elf, const R_390_16 = 3
|
||||
pkg debug/elf, const R_390_16 R_390
|
||||
pkg debug/elf, const R_390_20 = 57
|
||||
pkg debug/elf, const R_390_20 R_390
|
||||
pkg debug/elf, const R_390_32 = 4
|
||||
pkg debug/elf, const R_390_32 R_390
|
||||
pkg debug/elf, const R_390_64 = 22
|
||||
pkg debug/elf, const R_390_64 R_390
|
||||
pkg debug/elf, const R_390_8 = 1
|
||||
pkg debug/elf, const R_390_8 R_390
|
||||
pkg debug/elf, const R_390_COPY = 9
|
||||
pkg debug/elf, const R_390_COPY R_390
|
||||
pkg debug/elf, const R_390_GLOB_DAT = 10
|
||||
pkg debug/elf, const R_390_GLOB_DAT R_390
|
||||
pkg debug/elf, const R_390_GOT12 = 6
|
||||
pkg debug/elf, const R_390_GOT12 R_390
|
||||
pkg debug/elf, const R_390_GOT16 = 15
|
||||
pkg debug/elf, const R_390_GOT16 R_390
|
||||
pkg debug/elf, const R_390_GOT20 = 58
|
||||
pkg debug/elf, const R_390_GOT20 R_390
|
||||
pkg debug/elf, const R_390_GOT32 = 7
|
||||
pkg debug/elf, const R_390_GOT32 R_390
|
||||
pkg debug/elf, const R_390_GOT64 = 24
|
||||
pkg debug/elf, const R_390_GOT64 R_390
|
||||
pkg debug/elf, const R_390_GOTENT = 26
|
||||
pkg debug/elf, const R_390_GOTENT R_390
|
||||
pkg debug/elf, const R_390_GOTOFF = 13
|
||||
pkg debug/elf, const R_390_GOTOFF R_390
|
||||
pkg debug/elf, const R_390_GOTOFF16 = 27
|
||||
pkg debug/elf, const R_390_GOTOFF16 R_390
|
||||
pkg debug/elf, const R_390_GOTOFF64 = 28
|
||||
pkg debug/elf, const R_390_GOTOFF64 R_390
|
||||
pkg debug/elf, const R_390_GOTPC = 14
|
||||
pkg debug/elf, const R_390_GOTPC R_390
|
||||
pkg debug/elf, const R_390_GOTPCDBL = 21
|
||||
pkg debug/elf, const R_390_GOTPCDBL R_390
|
||||
pkg debug/elf, const R_390_GOTPLT12 = 29
|
||||
pkg debug/elf, const R_390_GOTPLT12 R_390
|
||||
pkg debug/elf, const R_390_GOTPLT16 = 30
|
||||
pkg debug/elf, const R_390_GOTPLT16 R_390
|
||||
pkg debug/elf, const R_390_GOTPLT20 = 59
|
||||
pkg debug/elf, const R_390_GOTPLT20 R_390
|
||||
pkg debug/elf, const R_390_GOTPLT32 = 31
|
||||
pkg debug/elf, const R_390_GOTPLT32 R_390
|
||||
pkg debug/elf, const R_390_GOTPLT64 = 32
|
||||
pkg debug/elf, const R_390_GOTPLT64 R_390
|
||||
pkg debug/elf, const R_390_GOTPLTENT = 33
|
||||
pkg debug/elf, const R_390_GOTPLTENT R_390
|
||||
pkg debug/elf, const R_390_GOTPLTOFF16 = 34
|
||||
pkg debug/elf, const R_390_GOTPLTOFF16 R_390
|
||||
pkg debug/elf, const R_390_GOTPLTOFF32 = 35
|
||||
pkg debug/elf, const R_390_GOTPLTOFF32 R_390
|
||||
pkg debug/elf, const R_390_GOTPLTOFF64 = 36
|
||||
pkg debug/elf, const R_390_GOTPLTOFF64 R_390
|
||||
pkg debug/elf, const R_390_JMP_SLOT = 11
|
||||
pkg debug/elf, const R_390_JMP_SLOT R_390
|
||||
pkg debug/elf, const R_390_NONE = 0
|
||||
pkg debug/elf, const R_390_NONE R_390
|
||||
pkg debug/elf, const R_390_PC16 = 16
|
||||
pkg debug/elf, const R_390_PC16 R_390
|
||||
pkg debug/elf, const R_390_PC16DBL = 17
|
||||
pkg debug/elf, const R_390_PC16DBL R_390
|
||||
pkg debug/elf, const R_390_PC32 = 5
|
||||
pkg debug/elf, const R_390_PC32 R_390
|
||||
pkg debug/elf, const R_390_PC32DBL = 19
|
||||
pkg debug/elf, const R_390_PC32DBL R_390
|
||||
pkg debug/elf, const R_390_PC64 = 23
|
||||
pkg debug/elf, const R_390_PC64 R_390
|
||||
pkg debug/elf, const R_390_PLT16DBL = 18
|
||||
pkg debug/elf, const R_390_PLT16DBL R_390
|
||||
pkg debug/elf, const R_390_PLT32 = 8
|
||||
pkg debug/elf, const R_390_PLT32 R_390
|
||||
pkg debug/elf, const R_390_PLT32DBL = 20
|
||||
pkg debug/elf, const R_390_PLT32DBL R_390
|
||||
pkg debug/elf, const R_390_PLT64 = 25
|
||||
pkg debug/elf, const R_390_PLT64 R_390
|
||||
pkg debug/elf, const R_390_RELATIVE = 12
|
||||
pkg debug/elf, const R_390_RELATIVE R_390
|
||||
pkg debug/elf, const R_390_TLS_DTPMOD = 54
|
||||
pkg debug/elf, const R_390_TLS_DTPMOD R_390
|
||||
pkg debug/elf, const R_390_TLS_DTPOFF = 55
|
||||
pkg debug/elf, const R_390_TLS_DTPOFF R_390
|
||||
pkg debug/elf, const R_390_TLS_GD32 = 40
|
||||
pkg debug/elf, const R_390_TLS_GD32 R_390
|
||||
pkg debug/elf, const R_390_TLS_GD64 = 41
|
||||
pkg debug/elf, const R_390_TLS_GD64 R_390
|
||||
pkg debug/elf, const R_390_TLS_GDCALL = 38
|
||||
pkg debug/elf, const R_390_TLS_GDCALL R_390
|
||||
pkg debug/elf, const R_390_TLS_GOTIE12 = 42
|
||||
pkg debug/elf, const R_390_TLS_GOTIE12 R_390
|
||||
pkg debug/elf, const R_390_TLS_GOTIE20 = 60
|
||||
pkg debug/elf, const R_390_TLS_GOTIE20 R_390
|
||||
pkg debug/elf, const R_390_TLS_GOTIE32 = 43
|
||||
pkg debug/elf, const R_390_TLS_GOTIE32 R_390
|
||||
pkg debug/elf, const R_390_TLS_GOTIE64 = 44
|
||||
pkg debug/elf, const R_390_TLS_GOTIE64 R_390
|
||||
pkg debug/elf, const R_390_TLS_IE32 = 47
|
||||
pkg debug/elf, const R_390_TLS_IE32 R_390
|
||||
pkg debug/elf, const R_390_TLS_IE64 = 48
|
||||
pkg debug/elf, const R_390_TLS_IE64 R_390
|
||||
pkg debug/elf, const R_390_TLS_IEENT = 49
|
||||
pkg debug/elf, const R_390_TLS_IEENT R_390
|
||||
pkg debug/elf, const R_390_TLS_LDCALL = 39
|
||||
pkg debug/elf, const R_390_TLS_LDCALL R_390
|
||||
pkg debug/elf, const R_390_TLS_LDM32 = 45
|
||||
pkg debug/elf, const R_390_TLS_LDM32 R_390
|
||||
pkg debug/elf, const R_390_TLS_LDM64 = 46
|
||||
pkg debug/elf, const R_390_TLS_LDM64 R_390
|
||||
pkg debug/elf, const R_390_TLS_LDO32 = 52
|
||||
pkg debug/elf, const R_390_TLS_LDO32 R_390
|
||||
pkg debug/elf, const R_390_TLS_LDO64 = 53
|
||||
pkg debug/elf, const R_390_TLS_LDO64 R_390
|
||||
pkg debug/elf, const R_390_TLS_LE32 = 50
|
||||
pkg debug/elf, const R_390_TLS_LE32 R_390
|
||||
pkg debug/elf, const R_390_TLS_LE64 = 51
|
||||
pkg debug/elf, const R_390_TLS_LE64 R_390
|
||||
pkg debug/elf, const R_390_TLS_LOAD = 37
|
||||
pkg debug/elf, const R_390_TLS_LOAD R_390
|
||||
pkg debug/elf, const R_390_TLS_TPOFF = 56
|
||||
pkg debug/elf, const R_390_TLS_TPOFF R_390
|
||||
pkg debug/elf, method (R_390) GoString() string
|
||||
pkg debug/elf, method (R_390) String() string
|
||||
pkg debug/elf, type R_390 int
|
||||
pkg encoding/json, method (*Encoder) SetEscapeHTML(bool)
|
||||
pkg encoding/json, method (*Encoder) SetIndent(string, string)
|
||||
pkg go/build, type Package struct, BinaryOnly bool
|
||||
pkg go/build, type Package struct, CgoFFLAGS []string
|
||||
pkg go/build, type Package struct, FFiles []string
|
||||
pkg go/doc, type Example struct, Unordered bool
|
||||
pkg io, const SeekCurrent = 1
|
||||
pkg io, const SeekCurrent ideal-int
|
||||
pkg io, const SeekEnd = 2
|
||||
pkg io, const SeekEnd ideal-int
|
||||
pkg io, const SeekStart = 0
|
||||
pkg io, const SeekStart ideal-int
|
||||
pkg math/big, method (*Float) GobDecode([]uint8) error
|
||||
pkg math/big, method (*Float) GobEncode() ([]uint8, error)
|
||||
pkg net, method (*Dialer) DialContext(context.Context, string, string) (Conn, error)
|
||||
pkg net/http, const StatusAlreadyReported = 208
|
||||
pkg net/http, const StatusAlreadyReported ideal-int
|
||||
pkg net/http, const StatusFailedDependency = 424
|
||||
pkg net/http, const StatusFailedDependency ideal-int
|
||||
pkg net/http, const StatusIMUsed = 226
|
||||
pkg net/http, const StatusIMUsed ideal-int
|
||||
pkg net/http, const StatusInsufficientStorage = 507
|
||||
pkg net/http, const StatusInsufficientStorage ideal-int
|
||||
pkg net/http, const StatusLocked = 423
|
||||
pkg net/http, const StatusLocked ideal-int
|
||||
pkg net/http, const StatusLoopDetected = 508
|
||||
pkg net/http, const StatusLoopDetected ideal-int
|
||||
pkg net/http, const StatusMultiStatus = 207
|
||||
pkg net/http, const StatusMultiStatus ideal-int
|
||||
pkg net/http, const StatusNotExtended = 510
|
||||
pkg net/http, const StatusNotExtended ideal-int
|
||||
pkg net/http, const StatusPermanentRedirect = 308
|
||||
pkg net/http, const StatusPermanentRedirect ideal-int
|
||||
pkg net/http, const StatusProcessing = 102
|
||||
pkg net/http, const StatusProcessing ideal-int
|
||||
pkg net/http, const StatusUnprocessableEntity = 422
|
||||
pkg net/http, const StatusUnprocessableEntity ideal-int
|
||||
pkg net/http, const StatusUpgradeRequired = 426
|
||||
pkg net/http, const StatusUpgradeRequired ideal-int
|
||||
pkg net/http, const StatusVariantAlsoNegotiates = 506
|
||||
pkg net/http, const StatusVariantAlsoNegotiates ideal-int
|
||||
pkg net/http, method (*Request) Context() context.Context
|
||||
pkg net/http, method (*Request) WithContext(context.Context) *Request
|
||||
pkg net/http, type Request struct, Response *Response
|
||||
pkg net/http, type Response struct, Uncompressed bool
|
||||
pkg net/http, type Transport struct, DialContext func(context.Context, string, string) (net.Conn, error)
|
||||
pkg net/http, type Transport struct, IdleConnTimeout time.Duration
|
||||
pkg net/http, type Transport struct, MaxIdleConns int
|
||||
pkg net/http, type Transport struct, MaxResponseHeaderBytes int64
|
||||
pkg net/http, var ErrUseLastResponse error
|
||||
pkg net/http, var LocalAddrContextKey *contextKey
|
||||
pkg net/http, var ServerContextKey *contextKey
|
||||
pkg net/http/cgi, type Handler struct, Stderr io.Writer
|
||||
pkg net/http/httptest, func NewRequest(string, string, io.Reader) *http.Request
|
||||
pkg net/http/httptest, method (*ResponseRecorder) Result() *http.Response
|
||||
pkg net/http/httptrace, func ContextClientTrace(context.Context) *ClientTrace
|
||||
pkg net/http/httptrace, func WithClientTrace(context.Context, *ClientTrace) context.Context
|
||||
pkg net/http/httptrace, type ClientTrace struct
|
||||
pkg net/http/httptrace, type ClientTrace struct, ConnectDone func(string, string, error)
|
||||
pkg net/http/httptrace, type ClientTrace struct, ConnectStart func(string, string)
|
||||
pkg net/http/httptrace, type ClientTrace struct, DNSDone func(DNSDoneInfo)
|
||||
pkg net/http/httptrace, type ClientTrace struct, DNSStart func(DNSStartInfo)
|
||||
pkg net/http/httptrace, type ClientTrace struct, GetConn func(string)
|
||||
pkg net/http/httptrace, type ClientTrace struct, Got100Continue func()
|
||||
pkg net/http/httptrace, type ClientTrace struct, GotConn func(GotConnInfo)
|
||||
pkg net/http/httptrace, type ClientTrace struct, GotFirstResponseByte func()
|
||||
pkg net/http/httptrace, type ClientTrace struct, PutIdleConn func(error)
|
||||
pkg net/http/httptrace, type ClientTrace struct, Wait100Continue func()
|
||||
pkg net/http/httptrace, type ClientTrace struct, WroteHeaders func()
|
||||
pkg net/http/httptrace, type ClientTrace struct, WroteRequest func(WroteRequestInfo)
|
||||
pkg net/http/httptrace, type DNSDoneInfo struct
|
||||
pkg net/http/httptrace, type DNSDoneInfo struct, Addrs []net.IPAddr
|
||||
pkg net/http/httptrace, type DNSDoneInfo struct, Coalesced bool
|
||||
pkg net/http/httptrace, type DNSDoneInfo struct, Err error
|
||||
pkg net/http/httptrace, type DNSStartInfo struct
|
||||
pkg net/http/httptrace, type DNSStartInfo struct, Host string
|
||||
pkg net/http/httptrace, type GotConnInfo struct
|
||||
pkg net/http/httptrace, type GotConnInfo struct, Conn net.Conn
|
||||
pkg net/http/httptrace, type GotConnInfo struct, IdleTime time.Duration
|
||||
pkg net/http/httptrace, type GotConnInfo struct, Reused bool
|
||||
pkg net/http/httptrace, type GotConnInfo struct, WasIdle bool
|
||||
pkg net/http/httptrace, type WroteRequestInfo struct
|
||||
pkg net/http/httptrace, type WroteRequestInfo struct, Err error
|
||||
pkg net/url, type URL struct, ForceQuery bool
|
||||
pkg os/exec, func CommandContext(context.Context, string, ...string) *Cmd
|
||||
pkg os/user, func LookupGroup(string) (*Group, error)
|
||||
pkg os/user, func LookupGroupId(string) (*Group, error)
|
||||
pkg os/user, method (*User) GroupIds() ([]string, error)
|
||||
pkg os/user, method (UnknownGroupError) Error() string
|
||||
pkg os/user, method (UnknownGroupIdError) Error() string
|
||||
pkg os/user, type Group struct
|
||||
pkg os/user, type Group struct, Gid string
|
||||
pkg os/user, type Group struct, Name string
|
||||
pkg os/user, type UnknownGroupError string
|
||||
pkg os/user, type UnknownGroupIdError string
|
||||
pkg reflect, func StructOf([]StructField) Type
|
||||
pkg reflect, method (StructTag) Lookup(string) (string, bool)
|
||||
pkg runtime, func CallersFrames([]uintptr) *Frames
|
||||
pkg runtime, func KeepAlive(interface{})
|
||||
pkg runtime, func SetCgoTraceback(int, unsafe.Pointer, unsafe.Pointer, unsafe.Pointer)
|
||||
pkg runtime, method (*Frames) Next() (Frame, bool)
|
||||
pkg runtime, type Frame struct
|
||||
pkg runtime, type Frame struct, Entry uintptr
|
||||
pkg runtime, type Frame struct, File string
|
||||
pkg runtime, type Frame struct, Func *Func
|
||||
pkg runtime, type Frame struct, Function string
|
||||
pkg runtime, type Frame struct, Line int
|
||||
pkg runtime, type Frame struct, PC uintptr
|
||||
pkg runtime, type Frames struct
|
||||
pkg strings, method (*Reader) Reset(string)
|
||||
pkg syscall (linux-386), type SysProcAttr struct, Unshareflags uintptr
|
||||
pkg syscall (linux-386-cgo), type SysProcAttr struct, Unshareflags uintptr
|
||||
pkg syscall (linux-amd64), type SysProcAttr struct, Unshareflags uintptr
|
||||
pkg syscall (linux-amd64-cgo), type SysProcAttr struct, Unshareflags uintptr
|
||||
pkg syscall (linux-arm), type SysProcAttr struct, Unshareflags uintptr
|
||||
pkg syscall (linux-arm-cgo), type SysProcAttr struct, Unshareflags uintptr
|
||||
pkg testing, method (*B) Run(string, func(*B)) bool
|
||||
pkg testing, method (*T) Run(string, func(*T)) bool
|
||||
pkg testing, type InternalExample struct, Unordered bool
|
||||
pkg unicode, const Version = "9.0.0"
|
||||
pkg unicode, var Adlam *RangeTable
|
||||
pkg unicode, var Bhaiksuki *RangeTable
|
||||
pkg unicode, var Marchen *RangeTable
|
||||
pkg unicode, var Newa *RangeTable
|
||||
pkg unicode, var Osage *RangeTable
|
||||
pkg unicode, var Prepended_Concatenation_Mark *RangeTable
|
||||
pkg unicode, var Sentence_Terminal *RangeTable
|
||||
pkg unicode, var Tangut *RangeTable
|
||||
9383
api/go1.txt
9383
api/go1.txt
File diff suppressed because it is too large
Load Diff
193
api/next.txt
193
api/next.txt
@@ -1,193 +0,0 @@
|
||||
pkg compress/gzip, const HuffmanOnly = -2
|
||||
pkg compress/gzip, const HuffmanOnly ideal-int
|
||||
pkg compress/zlib, const HuffmanOnly = -2
|
||||
pkg compress/zlib, const HuffmanOnly ideal-int
|
||||
pkg crypto/tls, const TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 = 49187
|
||||
pkg crypto/tls, const TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 uint16
|
||||
pkg crypto/tls, const TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 = 52393
|
||||
pkg crypto/tls, const TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 uint16
|
||||
pkg crypto/tls, const TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 = 49191
|
||||
pkg crypto/tls, const TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 uint16
|
||||
pkg crypto/tls, const TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 = 52392
|
||||
pkg crypto/tls, const TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 uint16
|
||||
pkg crypto/tls, const TLS_RSA_WITH_AES_128_CBC_SHA256 = 60
|
||||
pkg crypto/tls, const TLS_RSA_WITH_AES_128_CBC_SHA256 uint16
|
||||
pkg crypto/tls, const X25519 = 29
|
||||
pkg crypto/tls, const X25519 CurveID
|
||||
pkg crypto/tls, method (*Config) Clone() *Config
|
||||
pkg crypto/tls, type ClientHelloInfo struct, Conn net.Conn
|
||||
pkg crypto/tls, type ClientHelloInfo struct, SignatureSchemes []uint16
|
||||
pkg crypto/tls, type ClientHelloInfo struct, SupportedProtos []string
|
||||
pkg crypto/tls, type ClientHelloInfo struct, SupportedVersions []uint16
|
||||
pkg crypto/tls, type Config struct, GetConfigForClient func(*ClientHelloInfo) (*Config, error)
|
||||
pkg crypto/tls, type Config struct, KeyLogWriter io.Writer
|
||||
pkg crypto/tls, type Config struct, VerifyPeerCertificate func([][]uint8, [][]*x509.Certificate) error
|
||||
pkg crypto/x509, const NameMismatch = 5
|
||||
pkg crypto/x509, const NameMismatch InvalidReason
|
||||
pkg crypto/x509, const SHA256WithRSAPSS = 13
|
||||
pkg crypto/x509, const SHA256WithRSAPSS SignatureAlgorithm
|
||||
pkg crypto/x509, const SHA384WithRSAPSS = 14
|
||||
pkg crypto/x509, const SHA384WithRSAPSS SignatureAlgorithm
|
||||
pkg crypto/x509, const SHA512WithRSAPSS = 15
|
||||
pkg crypto/x509, const SHA512WithRSAPSS SignatureAlgorithm
|
||||
pkg database/sql, func Param(string, interface{}) NamedParam
|
||||
pkg database/sql, method (*ColumnType) DatabaseTypeName() string
|
||||
pkg database/sql, method (*ColumnType) DecimalSize() (int64, int64, bool)
|
||||
pkg database/sql, method (*ColumnType) Length() (int64, bool)
|
||||
pkg database/sql, method (*ColumnType) Name() string
|
||||
pkg database/sql, method (*ColumnType) Nullable() (bool, bool)
|
||||
pkg database/sql, method (*ColumnType) ScanType() reflect.Type
|
||||
pkg database/sql, method (*DB) BeginContext(context.Context) (*Tx, error)
|
||||
pkg database/sql, method (*DB) ExecContext(context.Context, string, ...interface{}) (Result, error)
|
||||
pkg database/sql, method (*DB) PingContext(context.Context) error
|
||||
pkg database/sql, method (*DB) PrepareContext(context.Context, string) (*Stmt, error)
|
||||
pkg database/sql, method (*DB) QueryContext(context.Context, string, ...interface{}) (*Rows, error)
|
||||
pkg database/sql, method (*DB) QueryRowContext(context.Context, string, ...interface{}) *Row
|
||||
pkg database/sql, method (*Rows) ColumnTypes() ([]*ColumnType, error)
|
||||
pkg database/sql, method (*Rows) NextResultSet() bool
|
||||
pkg database/sql, method (*Stmt) ExecContext(context.Context, ...interface{}) (Result, error)
|
||||
pkg database/sql, method (*Stmt) QueryContext(context.Context, ...interface{}) (*Rows, error)
|
||||
pkg database/sql, method (*Stmt) QueryRowContext(context.Context, ...interface{}) *Row
|
||||
pkg database/sql, method (*Tx) ExecContext(context.Context, string, ...interface{}) (Result, error)
|
||||
pkg database/sql, method (*Tx) PrepareContext(context.Context, string) (*Stmt, error)
|
||||
pkg database/sql, method (*Tx) QueryContext(context.Context, string, ...interface{}) (*Rows, error)
|
||||
pkg database/sql, method (*Tx) QueryRowContext(context.Context, string, ...interface{}) *Row
|
||||
pkg database/sql, method (*Tx) StmtContext(context.Context, *Stmt) *Stmt
|
||||
pkg database/sql, type ColumnType struct
|
||||
pkg database/sql, type NamedParam struct
|
||||
pkg database/sql, type NamedParam struct, Name string
|
||||
pkg database/sql, type NamedParam struct, Value interface{}
|
||||
pkg database/sql/driver, type ConnBeginContext interface { BeginContext }
|
||||
pkg database/sql/driver, type ConnBeginContext interface, BeginContext(context.Context) (Tx, error)
|
||||
pkg database/sql/driver, type ConnPrepareContext interface { PrepareContext }
|
||||
pkg database/sql/driver, type ConnPrepareContext interface, PrepareContext(context.Context, string) (Stmt, error)
|
||||
pkg database/sql/driver, type ExecerContext interface { ExecContext }
|
||||
pkg database/sql/driver, type ExecerContext interface, ExecContext(context.Context, string, []NamedValue) (Result, error)
|
||||
pkg database/sql/driver, type NamedValue struct
|
||||
pkg database/sql/driver, type NamedValue struct, Name string
|
||||
pkg database/sql/driver, type NamedValue struct, Ordinal int
|
||||
pkg database/sql/driver, type NamedValue struct, Value Value
|
||||
pkg database/sql/driver, type QueryerContext interface { QueryContext }
|
||||
pkg database/sql/driver, type QueryerContext interface, QueryContext(context.Context, string, []NamedValue) (Rows, error)
|
||||
pkg database/sql/driver, type RowsColumnTypeDatabaseTypeName interface { Close, ColumnTypeDatabaseTypeName, Columns, Next }
|
||||
pkg database/sql/driver, type RowsColumnTypeDatabaseTypeName interface, Close() error
|
||||
pkg database/sql/driver, type RowsColumnTypeDatabaseTypeName interface, ColumnTypeDatabaseTypeName(int) string
|
||||
pkg database/sql/driver, type RowsColumnTypeDatabaseTypeName interface, Columns() []string
|
||||
pkg database/sql/driver, type RowsColumnTypeDatabaseTypeName interface, Next([]Value) error
|
||||
pkg database/sql/driver, type RowsColumnTypeLength interface { Close, ColumnTypeLength, Columns, Next }
|
||||
pkg database/sql/driver, type RowsColumnTypeLength interface, Close() error
|
||||
pkg database/sql/driver, type RowsColumnTypeLength interface, ColumnTypeLength(int) (int64, bool)
|
||||
pkg database/sql/driver, type RowsColumnTypeLength interface, Columns() []string
|
||||
pkg database/sql/driver, type RowsColumnTypeLength interface, Next([]Value) error
|
||||
pkg database/sql/driver, type RowsColumnTypeNullable interface { Close, ColumnTypeNullable, Columns, Next }
|
||||
pkg database/sql/driver, type RowsColumnTypeNullable interface, Close() error
|
||||
pkg database/sql/driver, type RowsColumnTypeNullable interface, ColumnTypeNullable(int) (bool, bool)
|
||||
pkg database/sql/driver, type RowsColumnTypeNullable interface, Columns() []string
|
||||
pkg database/sql/driver, type RowsColumnTypeNullable interface, Next([]Value) error
|
||||
pkg database/sql/driver, type RowsColumnTypePrecisionScale interface { Close, ColumnTypePrecisionScale, Columns, Next }
|
||||
pkg database/sql/driver, type RowsColumnTypePrecisionScale interface, Close() error
|
||||
pkg database/sql/driver, type RowsColumnTypePrecisionScale interface, ColumnTypePrecisionScale(int) (int64, int64, bool)
|
||||
pkg database/sql/driver, type RowsColumnTypePrecisionScale interface, Columns() []string
|
||||
pkg database/sql/driver, type RowsColumnTypePrecisionScale interface, Next([]Value) error
|
||||
pkg database/sql/driver, type RowsColumnTypeScanType interface { Close, ColumnTypeScanType, Columns, Next }
|
||||
pkg database/sql/driver, type RowsColumnTypeScanType interface, Close() error
|
||||
pkg database/sql/driver, type RowsColumnTypeScanType interface, ColumnTypeScanType(int) reflect.Type
|
||||
pkg database/sql/driver, type RowsColumnTypeScanType interface, Columns() []string
|
||||
pkg database/sql/driver, type RowsColumnTypeScanType interface, Next([]Value) error
|
||||
pkg database/sql/driver, type RowsNextResultSet interface { Close, Columns, HasNextResultSet, Next, NextResultSet }
|
||||
pkg database/sql/driver, type RowsNextResultSet interface, Close() error
|
||||
pkg database/sql/driver, type RowsNextResultSet interface, Columns() []string
|
||||
pkg database/sql/driver, type RowsNextResultSet interface, HasNextResultSet() bool
|
||||
pkg database/sql/driver, type RowsNextResultSet interface, Next([]Value) error
|
||||
pkg database/sql/driver, type RowsNextResultSet interface, NextResultSet() error
|
||||
pkg database/sql/driver, type StmtExecContext interface { ExecContext }
|
||||
pkg database/sql/driver, type StmtExecContext interface, ExecContext(context.Context, []NamedValue) (Result, error)
|
||||
pkg database/sql/driver, type StmtQueryContext interface { QueryContext }
|
||||
pkg database/sql/driver, type StmtQueryContext interface, QueryContext(context.Context, []NamedValue) (Rows, error)
|
||||
pkg debug/gosym, func PCValue([]uint8, uint64, int) int
|
||||
pkg debug/pe, method (*COFFSymbol) FullName(StringTable) (string, error)
|
||||
pkg debug/pe, method (StringTable) String(uint32) (string, error)
|
||||
pkg debug/pe, type File struct, COFFSymbols []COFFSymbol
|
||||
pkg debug/pe, type File struct, StringTable StringTable
|
||||
pkg debug/pe, type Reloc struct
|
||||
pkg debug/pe, type Reloc struct, SymbolTableIndex uint32
|
||||
pkg debug/pe, type Reloc struct, Type uint16
|
||||
pkg debug/pe, type Reloc struct, VirtualAddress uint32
|
||||
pkg debug/pe, type Section struct, Relocs []Reloc
|
||||
pkg debug/pe, type StringTable []uint8
|
||||
pkg encoding/base64, method (Encoding) Strict() *Encoding
|
||||
pkg encoding/json, type UnmarshalTypeError struct, Field string
|
||||
pkg encoding/json, type UnmarshalTypeError struct, Struct string
|
||||
pkg expvar, func Handler() http.Handler
|
||||
pkg expvar, method (*Float) Value() float64
|
||||
pkg expvar, method (*Int) Value() int64
|
||||
pkg expvar, method (*String) Value() string
|
||||
pkg expvar, method (Func) Value() interface{}
|
||||
pkg go/ast, method (*AliasSpec) End() token.Pos
|
||||
pkg go/ast, method (*AliasSpec) Pos() token.Pos
|
||||
pkg go/ast, type AliasSpec struct
|
||||
pkg go/ast, type AliasSpec struct, Comment *CommentGroup
|
||||
pkg go/ast, type AliasSpec struct, Doc *CommentGroup
|
||||
pkg go/ast, type AliasSpec struct, Name *Ident
|
||||
pkg go/ast, type AliasSpec struct, Orig Expr
|
||||
pkg go/build, type NoGoError struct, Ignored bool
|
||||
pkg go/doc, func IsPredeclared(string) bool
|
||||
pkg go/token, const ALIAS = 87
|
||||
pkg go/token, const ALIAS Token
|
||||
pkg go/types, func Default(Type) Type
|
||||
pkg go/types, func IdenticalIgnoreTags(Type, Type) bool
|
||||
pkg math/big, method (*Float) Scan(fmt.ScanState, int32) error
|
||||
pkg math/big, method (*Int) Sqrt(*Int) *Int
|
||||
pkg math/rand, func Uint64() uint64
|
||||
pkg math/rand, method (*Rand) Uint64() uint64
|
||||
pkg net, method (*Buffers) Read([]uint8) (int, error)
|
||||
pkg net, method (*Buffers) WriteTo(io.Writer) (int64, error)
|
||||
pkg net, method (*Resolver) LookupAddr(context.Context, string) ([]string, error)
|
||||
pkg net, method (*Resolver) LookupCNAME(context.Context, string) (string, error)
|
||||
pkg net, method (*Resolver) LookupHost(context.Context, string) ([]string, error)
|
||||
pkg net, method (*Resolver) LookupIPAddr(context.Context, string) ([]IPAddr, error)
|
||||
pkg net, method (*Resolver) LookupMX(context.Context, string) ([]*MX, error)
|
||||
pkg net, method (*Resolver) LookupNS(context.Context, string) ([]*NS, error)
|
||||
pkg net, method (*Resolver) LookupPort(context.Context, string, string) (int, error)
|
||||
pkg net, method (*Resolver) LookupSRV(context.Context, string, string, string) (string, []*SRV, error)
|
||||
pkg net, method (*Resolver) LookupTXT(context.Context, string) ([]string, error)
|
||||
pkg net, type Buffers [][]uint8
|
||||
pkg net, type Dialer struct, Resolver *Resolver
|
||||
pkg net, type Resolver struct
|
||||
pkg net, type Resolver struct, PreferGo bool
|
||||
pkg net, var DefaultResolver *Resolver
|
||||
pkg net/http, type PushOptions struct
|
||||
pkg net/http, type PushOptions struct, Header Header
|
||||
pkg net/http, type PushOptions struct, Method string
|
||||
pkg net/http, type Pusher interface { Push }
|
||||
pkg net/http, type Pusher interface, Push(string, *PushOptions) error
|
||||
pkg net/http, type Request struct, GetBody func() (io.ReadCloser, error)
|
||||
pkg net/http, var NoBody noBody
|
||||
pkg net/http/httptrace, type ClientTrace struct, TLSHandshakeDone func(tls.ConnectionState, error)
|
||||
pkg net/http/httptrace, type ClientTrace struct, TLSHandshakeStart func()
|
||||
pkg net/mail, func ParseDate(string) (time.Time, error)
|
||||
pkg net/url, func PathEscape(string) string
|
||||
pkg net/url, func PathUnescape(string) (string, error)
|
||||
pkg net/url, method (*URL) Hostname() string
|
||||
pkg net/url, method (*URL) MarshalBinary() ([]uint8, error)
|
||||
pkg net/url, method (*URL) Port() string
|
||||
pkg net/url, method (*URL) UnmarshalBinary([]uint8) error
|
||||
pkg os, var ErrClosed error
|
||||
pkg plugin, func Open(string) (*Plugin, error)
|
||||
pkg plugin, method (*Plugin) Lookup(string) (Symbol, error)
|
||||
pkg plugin, type Plugin struct
|
||||
pkg plugin, type Symbol interface {}
|
||||
pkg reflect, func Swapper(interface{}) func(int, int)
|
||||
pkg sort, func Slice(interface{}, func(int, int) bool)
|
||||
pkg sort, func SliceIsSorted(interface{}, func(int, int) bool) bool
|
||||
pkg sort, func SliceStable(interface{}, func(int, int) bool)
|
||||
pkg syscall (linux-arm), func TimevalToNsec(Timeval) int64
|
||||
pkg syscall (linux-arm-cgo), func TimevalToNsec(Timeval) int64
|
||||
pkg syscall (windows-386), const ERROR_DIR_NOT_EMPTY = 145
|
||||
pkg syscall (windows-386), const ERROR_DIR_NOT_EMPTY Errno
|
||||
pkg syscall (windows-amd64), const ERROR_DIR_NOT_EMPTY = 145
|
||||
pkg syscall (windows-amd64), const ERROR_DIR_NOT_EMPTY Errno
|
||||
pkg testing, method (*B) Name() string
|
||||
pkg testing, method (*T) Name() string
|
||||
pkg testing, type TB interface, Name() string
|
||||
pkg time, func Until(Time) Duration
|
||||
BIN
doc/ExpressivenessOfGo.pdf
Normal file
BIN
doc/ExpressivenessOfGo.pdf
Normal file
Binary file not shown.
27
doc/Makefile
Normal file
27
doc/Makefile
Normal file
@@ -0,0 +1,27 @@
|
||||
# Copyright 2009 The Go Authors. All rights reserved.
|
||||
# Use of this source code is governed by a BSD-style
|
||||
# license that can be found in the LICENSE file.
|
||||
|
||||
RAWHTML=\
|
||||
articles/defer_panic_recover.rawhtml\
|
||||
articles/error_handling.rawhtml\
|
||||
articles/slices_usage_and_internals.rawhtml\
|
||||
articles/laws_of_reflection.rawhtml\
|
||||
articles/c_go_cgo.rawhtml\
|
||||
articles/concurrency_patterns.rawhtml\
|
||||
articles/godoc_documenting_go_code.rawhtml\
|
||||
articles/gobs_of_data.rawhtml\
|
||||
articles/json_and_go.rawhtml\
|
||||
articles/json_rpc_tale_of_interfaces.rawhtml\
|
||||
articles/image_draw.rawhtml\
|
||||
articles/image_package.rawhtml\
|
||||
effective_go.rawhtml\
|
||||
go1.rawhtml\
|
||||
|
||||
all: $(RAWHTML)
|
||||
|
||||
%.rawhtml: %.html
|
||||
godoc -url /doc/$< >$@
|
||||
|
||||
clean:
|
||||
rm -f $(RAWHTML)
|
||||
180
doc/articles/c_go_cgo.html
Normal file
180
doc/articles/c_go_cgo.html
Normal file
@@ -0,0 +1,180 @@
|
||||
<!--{
|
||||
"Title": "C? Go? Cgo!",
|
||||
"Template": true
|
||||
}-->
|
||||
|
||||
<p>
|
||||
Cgo lets Go packages call C code. Given a Go source file written with some
|
||||
special features, cgo outputs Go and C files that can be combined into a
|
||||
single Go package.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To lead with an example, here's a Go package that provides two functions -
|
||||
<code>Random</code> and <code>Seed</code> - that wrap C's <code>random</code>
|
||||
and <code>srandom</code> functions.
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/cgo1.go" `/package rand/` `/END/`}}
|
||||
|
||||
<p>
|
||||
Let's look at what's happening here, starting with the import statement.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <code>rand</code> package imports <code>"C"</code>, but you'll find there's
|
||||
no such package in the standard Go library. That's because <code>C</code> is a
|
||||
"pseudo-package", a special name interpreted by cgo as a reference to C's
|
||||
name space.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <code>rand</code> package contains four references to the <code>C</code>
|
||||
package: the calls to <code>C.random</code> and <code>C.srandom</code>, the
|
||||
conversion <code>C.uint(i)</code>, and the <code>import</code> statement.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <code>Random</code> function calls the standard C library's <code>random</code>
|
||||
function and returns the result. In C, <code>random</code> returns a value of the
|
||||
C type <code>long</code>, which cgo represents as the type <code>C.long</code>.
|
||||
It must be converted to a Go type before it can be used by Go code outside this
|
||||
package, using an ordinary Go type conversion:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/cgo1.go" `/func Random/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
Here's an equivalent function that uses a temporary variable to illustrate
|
||||
the type conversion more explicitly:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/cgo2.go" `/func Random/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
The <code>Seed</code> function does the reverse, in a way. It takes a
|
||||
regular Go <code>int</code>, converts it to the C <code>unsigned int</code>
|
||||
type, and passes it to the C function <code>srandom</code>.
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/cgo1.go" `/func Seed/` `/END/`}}
|
||||
|
||||
<p>
|
||||
Note that cgo knows the <code>unsigned int</code> type as <code>C.uint</code>;
|
||||
see the <a href="/cmd/cgo">cgo documentation</a> for a complete list of
|
||||
these numeric type names.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The one detail of this example we haven't examined yet is the comment
|
||||
above the <code>import</code> statement.
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/cgo1.go" `/\/\*/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
Cgo recognizes this comment. Any lines starting
|
||||
with <code>#cgo</code>
|
||||
followed
|
||||
by a space character are removed; these become directives for cgo.
|
||||
The remaining lines are used as a header when compiling the C parts of
|
||||
the package. In this case those lines are just a
|
||||
single <code>#include</code>
|
||||
statement, but they can be almost any C code. The <code>#cgo</code>
|
||||
directives are
|
||||
used to provide flags for the compiler and linker when building the C
|
||||
parts of the package.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
There is a limitation: if your program uses any <code>//export</code>
|
||||
directives, then the C code in the comment may only include declarations
|
||||
(<code>extern int f();</code>), not definitions (<code>int f() {
|
||||
return 1; }</code>). You can use <code>//export</code> directives to
|
||||
make Go functions accessible to C code.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <code>#cgo</code> and <code>//export</code> directives are
|
||||
documented in
|
||||
the <a href="/cmd/cgo/">cgo documentation</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Strings and things</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Unlike Go, C doesn't have an explicit string type. Strings in C are
|
||||
represented by a zero-terminated array of chars.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Conversion between Go and C strings is done with the
|
||||
<code>C.CString</code>, <code>C.GoString</code>, and
|
||||
<code>C.GoStringN</code> functions. These conversions make a copy of the
|
||||
string data.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
This next example implements a <code>Print</code> function that writes a
|
||||
string to standard output using C's <code>fputs</code> function from the
|
||||
<code>stdio</code> library:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/cgo3.go" `/package print/` `/END/`}}
|
||||
|
||||
<p>
|
||||
Memory allocations made by C code are not known to Go's memory manager.
|
||||
When you create a C string with <code>C.CString</code> (or any C memory
|
||||
allocation) you must remember to free the memory when you're done with it
|
||||
by calling <code>C.free</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The call to <code>C.CString</code> returns a pointer to the start of the
|
||||
char array, so before the function exits we convert it to an
|
||||
<a href="/pkg/unsafe/#Pointer"><code>unsafe.Pointer</code></a> and release
|
||||
the memory allocation with <code>C.free</code>. A common idiom in cgo programs
|
||||
is to <a href="/doc/articles/defer_panic_recover.html"><code>defer</code></a>
|
||||
the free immediately after allocating (especially when the code that follows
|
||||
is more complex than a single function call), as in this rewrite of
|
||||
<code>Print</code>:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/cgo4.go" `/func Print/` `/END/`}}
|
||||
|
||||
<p>
|
||||
<b>Building cgo packages</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To build cgo packages, just use <a href="/cmd/go/#Compile_packages_and_dependencies">"
|
||||
<code>go build</code>"</a> or
|
||||
<a href="/cmd/go/#Compile_and_install_packages_and_dependencies">"<code>go install</code>
|
||||
"</a> as usual. The go tool recognizes the special <code>"C"</code> import and automatically
|
||||
uses cgo for those files.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>More cgo resources</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <a href="/cmd/cgo/">cgo command</a> documentation has more detail about
|
||||
the C pseudo-package and the build process. The <a href="/misc/cgo/">cgo examples</a>
|
||||
in the Go tree demonstrate more advanced concepts.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For a simple, idiomatic example of a cgo-based package, see Russ Cox's <a
|
||||
href="http://code.google.com/p/gosqlite/source/browse/sqlite/sqlite.go">gosqlite</a>.
|
||||
Also, the Go Project Dashboard lists <a
|
||||
href="https://godashboard.appspot.com/project?tag=cgo">several other
|
||||
cgo packages</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Finally, if you're curious as to how all this works internally, take a look
|
||||
at the introductory comment of the runtime package's <a href="/src/pkg/runtime/cgocall.c">cgocall.c</a>.
|
||||
</p>
|
||||
79
doc/articles/concurrency_patterns.html
Normal file
79
doc/articles/concurrency_patterns.html
Normal file
@@ -0,0 +1,79 @@
|
||||
<!--{
|
||||
"Title": "Go Concurrency Patterns: Timing out, moving on",
|
||||
"Template": true
|
||||
}-->
|
||||
|
||||
<p>
|
||||
Concurrent programming has its own idioms. A good example is timeouts. Although
|
||||
Go's channels do not support them directly, they are easy to implement. Say we
|
||||
want to receive from the channel <code>ch</code>, but want to wait at most one
|
||||
second for the value to arrive. We would start by creating a signalling channel
|
||||
and launching a goroutine that sleeps before sending on the channel:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/timeout1.go" `/timeout :=/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
We can then use a <code>select</code> statement to receive from either
|
||||
<code>ch</code> or <code>timeout</code>. If nothing arrives on <code>ch</code>
|
||||
after one second, the timeout case is selected and the attempt to read from
|
||||
<cde>ch</cde> is abandoned.
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/timeout1.go" `/select {/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
The <code>timeout</code> channel is buffered with space for 1 value, allowing
|
||||
the timeout goroutine to send to the channel and then exit. The goroutine
|
||||
doesn't know (or care) whether the value is received. This means the goroutine
|
||||
won't hang around forever if the <code>ch</code> receive happens before the
|
||||
timeout is reached. The <code>timeout</code> channel will eventually be
|
||||
deallocated by the garbage collector.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
(In this example we used <code>time.Sleep</code> to demonstrate the mechanics
|
||||
of goroutines and channels. In real programs you should use <code>
|
||||
<a href="/pkg/time/#After">time.After</a></code>, a function that returns
|
||||
a channel and sends on that channel after the specified duration.)
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Let's look at another variation of this pattern. In this example we have a
|
||||
program that reads from multiple replicated databases simultaneously. The
|
||||
program needs only one of the answers, and it should accept the answer that
|
||||
arrives first.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The function <code>Query</code> takes a slice of database connections and a
|
||||
<code>query</code> string. It queries each of the databases in parallel and
|
||||
returns the first response it receives:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/timeout2.go" `/func Query/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
In this example, the closure does a non-blocking send, which it achieves by
|
||||
using the send operation in <code>select</code> statement with a
|
||||
<code>default</code> case. If the send cannot go through immediately the
|
||||
default case will be selected. Making the send non-blocking guarantees that
|
||||
none of the goroutines launched in the loop will hang around. However, if the
|
||||
result arrives before the main function has made it to the receive, the send
|
||||
could fail since no one is ready.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
This problem is a textbook of example of what is known as a
|
||||
<a href="https://en.wikipedia.org/wiki/Race_condition">race condition</a>, but
|
||||
the fix is trivial. We just make sure to buffer the channel <code>ch</code> (by
|
||||
adding the buffer length as the second argument to <a href="/pkg/builtin/#make">make</a>),
|
||||
guaranteeing that the first send has a place to put the value. This ensures the
|
||||
send will always succeed, and the first value to arrive will be retrieved
|
||||
regardless of the order of execution.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
These two examples demonstrate the simplicity with which Go can express complex
|
||||
interactions between goroutines.
|
||||
</p>
|
||||
197
doc/articles/defer_panic_recover.html
Normal file
197
doc/articles/defer_panic_recover.html
Normal file
@@ -0,0 +1,197 @@
|
||||
<!--{
|
||||
"Title": "Defer, Panic, and Recover",
|
||||
"Template": true
|
||||
}-->
|
||||
|
||||
<p>
|
||||
Go has the usual mechanisms for control flow: if, for, switch, goto. It also
|
||||
has the go statement to run code in a separate goroutine. Here I'd like to
|
||||
discuss some of the less common ones: defer, panic, and recover.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A <b>defer statement</b> pushes a function call onto a list. The list of saved
|
||||
calls is executed after the surrounding function returns. Defer is commonly
|
||||
used to simplify functions that perform various clean-up actions.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For example, let's look at a function that opens two files and copies the
|
||||
contents of one file to the other:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/defer.go" `/func CopyFile/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
This works, but there is a bug. If the call to os.Create fails, the
|
||||
function will return without closing the source file. This can be easily
|
||||
remedied by putting a call to src.Close before the second return statement,
|
||||
but if the function were more complex the problem might not be so easily
|
||||
noticed and resolved. By introducing defer statements we can ensure that the
|
||||
files are always closed:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/defer2.go" `/func CopyFile/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
Defer statements allow us to think about closing each file right after opening
|
||||
it, guaranteeing that, regardless of the number of return statements in the
|
||||
function, the files <i>will</i> be closed.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The behavior of defer statements is straightforward and predictable. There are
|
||||
three simple rules:
|
||||
</p>
|
||||
|
||||
<p>
|
||||
1. <i>A deferred function's arguments are evaluated when the defer statement is
|
||||
evaluated.</i>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In this example, the expression "i" is evaluated when the Println call is
|
||||
deferred. The deferred call will print "0" after the function returns.
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/defer.go" `/func a/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
2. <i>Deferred function calls are executed in Last In First Out order
|
||||
</i>after<i> the surrounding function returns.</i>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
This function prints "3210":
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/defer.go" `/func b/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
3. <i>Deferred functions may read and assign to the returning function's named
|
||||
return values.</i>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In this example, a deferred function increments the return value i <i>after</i>
|
||||
the surrounding function returns. Thus, this function returns 2:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/defer.go" `/func c/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
This is convenient for modifying the error return value of a function; we will
|
||||
see an example of this shortly.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Panic</b> is a built-in function that stops the ordinary flow of control and
|
||||
begins <i>panicking</i>. When the function F calls panic, execution of F stops,
|
||||
any deferred functions in F are executed normally, and then F returns to its
|
||||
caller. To the caller, F then behaves like a call to panic. The process
|
||||
continues up the stack until all functions in the current goroutine have
|
||||
returned, at which point the program crashes. Panics can be initiated by
|
||||
invoking panic directly. They can also be caused by runtime errors, such as
|
||||
out-of-bounds array accesses.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Recover</b> is a built-in function that regains control of a panicking
|
||||
goroutine. Recover is only useful inside deferred functions. During normal
|
||||
execution, a call to recover will return nil and have no other effect. If the
|
||||
current goroutine is panicking, a call to recover will capture the value given
|
||||
to panic and resume normal execution.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Here's an example program that demonstrates the mechanics of panic and defer:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/defer2.go" `/package main/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
The function g takes the int i, and panics if i is greater than 3, or else it
|
||||
calls itself with the argument i+1. The function f defers a function that calls
|
||||
recover and prints the recovered value (if it is non-nil). Try to picture what
|
||||
the output of this program might be before reading on.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The program will output:
|
||||
</p>
|
||||
|
||||
<pre>Calling g.
|
||||
Printing in g 0
|
||||
Printing in g 1
|
||||
Printing in g 2
|
||||
Printing in g 3
|
||||
Panicking!
|
||||
Defer in g 3
|
||||
Defer in g 2
|
||||
Defer in g 1
|
||||
Defer in g 0
|
||||
Recovered in f 4
|
||||
Returned normally from f.</pre>
|
||||
|
||||
<p>
|
||||
If we remove the deferred function from f the panic is not recovered and
|
||||
reaches the top of the goroutine's call stack, terminating the program. This
|
||||
modified program will output:
|
||||
</p>
|
||||
|
||||
<pre>Calling g.
|
||||
Printing in g 0
|
||||
Printing in g 1
|
||||
Printing in g 2
|
||||
Printing in g 3
|
||||
Panicking!
|
||||
Defer in g 3
|
||||
Defer in g 2
|
||||
Defer in g 1
|
||||
Defer in g 0
|
||||
panic: 4
|
||||
|
||||
panic PC=0x2a9cd8
|
||||
[stack trace omitted]</pre>
|
||||
|
||||
<p>
|
||||
For a real-world example of <b>panic</b> and <b>recover</b>, see the
|
||||
<a href="/pkg/encoding/json/">json package</a> from the Go standard library.
|
||||
It decodes JSON-encoded data with a set of recursive functions.
|
||||
When malformed JSON is encountered, the parser calls panic to unwind the
|
||||
stack to the top-level function call, which recovers from the panic and returns
|
||||
an appropriate error value (see the 'error' and 'unmarshal' methods of
|
||||
the decodeState type in
|
||||
<a href="/src/pkg/encoding/json/decode.go">decode.go</a>).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The convention in the Go libraries is that even when a package uses panic
|
||||
internally, its external API still presents explicit error return values.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Other uses of <b>defer</b> (beyond the file.Close example given earlier)
|
||||
include releasing a mutex:
|
||||
</p>
|
||||
|
||||
<pre>mu.Lock()
|
||||
defer mu.Unlock()</pre>
|
||||
|
||||
<p>
|
||||
printing a footer:
|
||||
</p>
|
||||
|
||||
<pre>printHeader()
|
||||
defer printFooter()</pre>
|
||||
|
||||
<p>
|
||||
and more.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In summary, the defer statement (with or without panic and recover) provides an
|
||||
unusual and powerful mechanism for control flow. It can be used to model a
|
||||
number of features implemented by special-purpose structures in other
|
||||
programming languages. Try it out.
|
||||
</p>
|
||||
316
doc/articles/error_handling.html
Normal file
316
doc/articles/error_handling.html
Normal file
@@ -0,0 +1,316 @@
|
||||
<!--{
|
||||
"Title": "Error Handling and Go",
|
||||
"Template": true
|
||||
}-->
|
||||
|
||||
<p>
|
||||
If you have written any Go code you have probably encountered the built-in
|
||||
<code>error</code> type. Go code uses <code>error</code> values to
|
||||
indicate an abnormal state. For example, the <code>os.Open</code> function
|
||||
returns a non-nil <code>error</code> value when it fails to open a file.
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/error.go" `/func Open/`}}
|
||||
|
||||
<p>
|
||||
The following code uses <code>os.Open</code> to open a file. If an error
|
||||
occurs it calls <code>log.Fatal</code> to print the error message and stop.
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/error.go" `/func openFile/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
You can get a lot done in Go knowing just this about the <code>error</code>
|
||||
type, but in this article we'll take a closer look at <code>error</code> and
|
||||
discuss some good practices for error handling in Go.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>The error type</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <code>error</code> type is an interface type. An <code>error</code>
|
||||
variable represents any value that can describe itself as a string. Here is the
|
||||
interface's declaration:
|
||||
</p>
|
||||
|
||||
<pre>type error interface {
|
||||
Error() string
|
||||
}</pre>
|
||||
|
||||
<p>
|
||||
The <code>error</code> type, as with all built in types, is
|
||||
<a href="/doc/go_spec.html#Predeclared_identifiers">predeclared</a> in the
|
||||
<a href="/doc/go_spec.html#Blocks">universe block</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The most commonly-used <code>error</code> implementation is the
|
||||
<a href="/pkg/errors/">errors</a> package's unexported <code>errorString</code> type.
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/error.go" `/errorString/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
You can construct one of these values with the <code>errors.New</code>
|
||||
function. It takes a string that it converts to an <code>errors.errorString</code>
|
||||
and returns as an <code>error</code> value.
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/error.go" `/New/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
Here's how you might use <code>errors.New</code>:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/error.go" `/func Sqrt/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
A caller passing a negative argument to <code>Sqrt</code> receives a non-nil
|
||||
<code>error</code> value (whose concrete representation is an
|
||||
<code>errors.errorString</code> value). The caller can access the error string
|
||||
("math: square root of...") by calling the <code>error</code>'s
|
||||
<code>Error</code> method, or by just printing it:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/error.go" `/func printErr/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
The <a href="/pkg/fmt/">fmt</a> package formats an <code>error</code> value
|
||||
by calling its <code>Error() string</code> method.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
It is the error implementation's responsibility to summarize the context.
|
||||
The error returned by <code>os.Open</code> formats as "open /etc/passwd:
|
||||
permission denied," not just "permission denied." The error returned by our
|
||||
<code>Sqrt</code> is missing information about the invalid argument.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To add that information, a useful function is the <code>fmt</code> package's
|
||||
<code>Errorf</code>. It formats a string according to <code>Printf</code>'s
|
||||
rules and returns it as an <code>error</code> created by
|
||||
<code>errors.New</code>.
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/error.go" `/fmtError/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
In many cases <code>fmt.Errorf</code> is good enough, but since
|
||||
<code>error</code> is an interface, you can use arbitrary data structures as
|
||||
error values, to allow callers to inspect the details of the error.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For instance, our hypothetical callers might want to recover the invalid
|
||||
argument passed to <code>Sqrt</code>. We can enable that by defining a new
|
||||
error implementation instead of using <code>errors.errorString</code>:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/error.go" `/type NegativeSqrtError/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
A sophisticated caller can then use a
|
||||
<a href="/doc/go_spec.html#Type_assertions">type assertion</a> to check for a
|
||||
<code>NegativeSqrtError</code> and handle it specially, while callers that just
|
||||
pass the error to <code>fmt.Println</code> or <code>log.Fatal</code> will see
|
||||
no change in behavior.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
As another example, the <a href="/pkg/encoding/json/">json</a> package specifies a
|
||||
<code>SyntaxError</code> type that the <code>json.Decode</code> function
|
||||
returns when it encounters a syntax error parsing a JSON blob.
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/error.go" `/type SyntaxError/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
The <code>Offset</code> field isn't even shown in the default formatting of the
|
||||
error, but callers can use it to add file and line information to their error
|
||||
messages:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/error.go" `/func decodeError/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
(This is a slightly simplified version of some
|
||||
<a href="http://camlistore.org/code/?p=camlistore.git;a=blob;f=lib/go/camli/jsonconfig/eval.go#l68">actual code</a>
|
||||
from the <a href="http://camlistore.org">Camlistore</a> project.)
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <code>error</code> interface requires only a <code>Error</code> method;
|
||||
specific error implementations might have additional methods. For instance, the
|
||||
<a href="/pkg/net/">net</a> package returns errors of type
|
||||
<code>error</code>, following the usual convention, but some of the error
|
||||
implementations have additional methods defined by the <code>net.Error</code>
|
||||
interface:
|
||||
</p>
|
||||
|
||||
<pre>package net
|
||||
|
||||
type Error interface {
|
||||
error
|
||||
Timeout() bool // Is the error a timeout?
|
||||
Temporary() bool // Is the error temporary?
|
||||
}</pre>
|
||||
|
||||
<p>
|
||||
Client code can test for a <code>net.Error</code> with a type assertion and
|
||||
then distinguish transient network errors from permanent ones. For instance, a
|
||||
web crawler might sleep and retry when it encounters a temporary error and give
|
||||
up otherwise.
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/error.go" `/func netError/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
<b>Simplifying repetitive error handling</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In Go, error handling is important. The language's design and conventions
|
||||
encourage you to explicitly check for errors where they occur (as distinct from
|
||||
the convention in other languages of throwing exceptions and sometimes catching
|
||||
them). In some cases this makes Go code verbose, but fortunately there are some
|
||||
techniques you can use to minimize repetitive error handling.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Consider an <a href="http://code.google.com/appengine/docs/go/">App Engine</a>
|
||||
application with an HTTP handler that retrieves a record from the datastore and
|
||||
formats it with a template.
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/error2.go" `/func init/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
This function handles errors returned by the <code>datastore.Get</code>
|
||||
function and <code>viewTemplate</code>'s <code>Execute</code> method. In both
|
||||
cases, it presents a simple error message to the user with the HTTP status code
|
||||
500 ("Internal Server Error"). This looks like a manageable amount of code, but
|
||||
add some more HTTP handlers and you quickly end up with many copies of
|
||||
identical error handling code.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To reduce the repetition we can define our own HTTP <code>appHandler</code>
|
||||
type that includes an <code>error</code> return value:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/error3.go" `/type appHandler/`}}
|
||||
|
||||
<p>
|
||||
Then we can change our <code>viewRecord</code> function to return errors:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/error3.go" `/func viewRecord/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
This is simpler than the original version, but the <a
|
||||
href="/pkg/net/http/">http</a> package doesn't understand functions that return
|
||||
<code>error</code>.
|
||||
To fix this we can implement the <code>http.Handler</code> interface's
|
||||
<code>ServeHTTP</code> method on <code>appHandler</code>:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/error3.go" `/ServeHTTP/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
The <code>ServeHTTP</code> method calls the <code>appHandler</code> function
|
||||
and displays the returned error (if any) to the user. Notice that the method's
|
||||
receiver, <code>fn</code>, is a function. (Go can do that!) The method invokes
|
||||
the function by calling the receiver in the expression <code>fn(w, r)</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Now when registering <code>viewRecord</code> with the http package we use the
|
||||
<code>Handle</code> function (instead of <code>HandleFunc</code>) as
|
||||
<code>appHandler</code> is an <code>http.Handler</code> (not an
|
||||
<code>http.HandlerFunc</code>).
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/error3.go" `/func init/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
With this basic error handling infrastructure in place, we can make it more
|
||||
user friendly. Rather than just displaying the error string, it would be better
|
||||
to give the user a simple error message with an appropriate HTTP status code,
|
||||
while logging the full error to the App Engine developer console for debugging
|
||||
purposes.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To do this we create an <code>appError</code> struct containing an
|
||||
<code>error</code> and some other fields:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/error4.go" `/type appError/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
Next we modify the appHandler type to return <code>*appError</code> values:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/error4.go" `/type appHandler/`}}
|
||||
|
||||
<p>
|
||||
(It's usually a mistake to pass back the concrete type of an error rather than
|
||||
<code>error</code>,
|
||||
for reasons discussed in <a href="/doc/go_faq.html#nil_error">the Go FAQ</a>,
|
||||
but it's the right thing to do here because <code>ServeHTTP</code> is the only
|
||||
place that sees the value and uses its contents.)
|
||||
</p>
|
||||
|
||||
<p>
|
||||
And make <code>appHandler</code>'s <code>ServeHTTP</code> method display the
|
||||
<code>appError</code>'s <code>Message</code> to the user with the correct HTTP
|
||||
status <code>Code</code> and log the full <code>Error</code> to the developer
|
||||
console:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/error4.go" `/ServeHTTP/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
Finally, we update <code>viewRecord</code> to the new function signature and
|
||||
have it return more context when it encounters an error:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/error4.go" `/func viewRecord/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
This version of <code>viewRecord</code> is the same length as the original, but
|
||||
now each of those lines has specific meaning and we are providing a friendlier
|
||||
user experience.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
It doesn't end there; we can further improve the error handling in our
|
||||
application. Some ideas:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>give the error handler a pretty HTML template,
|
||||
<li>make debugging easier by writing the stack trace to the HTTP response when
|
||||
the user is an administrator,
|
||||
<li>write a constructor function for <code>appError</code> that stores the
|
||||
stack trace for easier debugging,
|
||||
<li>recover from panics inside the <code>appHandler</code>, logging the error
|
||||
to the console as "Critical," while telling the user "a serious error
|
||||
has occurred." This is a nice touch to avoid exposing the user to inscrutable
|
||||
error messages caused by programming errors.
|
||||
See the <a href="defer_panic_recover.html">Defer, Panic, and Recover</a>
|
||||
article for more details.
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
<b>Conclusion</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Proper error handling is an essential requirement of good software. By
|
||||
employing the techniques described in this post you should be able to write
|
||||
more reliable and succinct Go code.
|
||||
</p>
|
||||
@@ -48,9 +48,9 @@ had to be installed in certain places, under certain names, using certain build
|
||||
tools, in order to be used. That's understandable: that's the way it works in
|
||||
most other languages. Over the last few years we consistently reminded people
|
||||
about the <code>goinstall</code> command
|
||||
(now replaced by <a href="/cmd/go/#hdr-Download_and_install_packages_and_dependencies"><code>go get</code></a>)
|
||||
(now replaced by <a href="/cmd/go/#Download_and_install_packages_and_dependencies"><code>go get</code></a>)
|
||||
and its conventions: first, that the import path is derived in a known way from
|
||||
the URL of the source code; second, that the place to store the sources in
|
||||
the URL of the source code; second, that that the place to store the sources in
|
||||
the local file system is derived in a known way from the import path; third,
|
||||
that each directory in a source tree corresponds to a single package; and
|
||||
fourth, that the package is built using only information in the source code.
|
||||
@@ -78,18 +78,17 @@ well-established conventions.</p>
|
||||
source code. For Bitbucket, GitHub, Google Code, and Launchpad, the
|
||||
root directory of the repository is identified by the repository's
|
||||
main URL, without the <code>http://</code> prefix. Subdirectories are named by
|
||||
adding to that path.
|
||||
For example, the Go example programs are obtained by running</p>
|
||||
adding to that path. For example, the supplemental networking
|
||||
libraries for Go are obtained by running</p>
|
||||
|
||||
<pre>
|
||||
git clone https://github.com/golang/example
|
||||
hg clone http://code.google.com/p/go.net
|
||||
</pre>
|
||||
|
||||
<p>and thus the import path for the root directory of that repository is
|
||||
"<code>github.com/golang/example</code>".
|
||||
The <a href="https://godoc.org/github.com/golang/example/stringutil">stringutil</a>
|
||||
package is stored in a subdirectory, so its import path is
|
||||
"<code>github.com/golang/example/stringutil</code>".</p>
|
||||
"<code>code.google.com/p/go.net</code>". The websocket package is stored in a
|
||||
subdirectory, so its import path is
|
||||
"<code>code.google.com/p/go.net/websocket</code>".</p>
|
||||
|
||||
<p>These paths are on the long side, but in exchange we get an
|
||||
automatically managed name space for import paths and the ability for
|
||||
@@ -100,7 +99,7 @@ deduce where to obtain the source code.</p>
|
||||
in a known way from the import path. Specifically, the first choice
|
||||
is <code>$GOPATH/src/<import-path></code>. If <code>$GOPATH</code> is
|
||||
unset, the go command will fall back to storing source code alongside the
|
||||
standard Go packages, in <code>$GOROOT/src/<import-path></code>.
|
||||
standard Go packages, in <code>$GOROOT/src/pkg/<import-path></code>.
|
||||
If <code>$GOPATH</code> is set to a list of paths, the go command tries
|
||||
<code><dir>/src/<import-path></code> for each of the directories in
|
||||
that list.</p>
|
||||
@@ -164,14 +163,14 @@ red-black tree. We can install both with the "<code>go get</code>"
|
||||
subcommand:</p>
|
||||
|
||||
<pre>
|
||||
$ go get github.com/google/codesearch/index
|
||||
$ go get code.google.com/p/codesearch/index
|
||||
$ go get github.com/petar/GoLLRB/llrb
|
||||
$
|
||||
</pre>
|
||||
|
||||
<p>Both of these projects are now downloaded and installed into our
|
||||
<code>$GOPATH</code> directory. The one tree now contains the two directories
|
||||
<code>src/github.com/google/codesearch/index/</code> and
|
||||
<code>src/code.google.com/p/codesearch/index/</code> and
|
||||
<code>src/github.com/petar/GoLLRB/llrb/</code>, along with the compiled
|
||||
packages (in <code>pkg/</code>) for those libraries and their dependencies.</p>
|
||||
|
||||
@@ -185,12 +184,12 @@ the pattern "<code>./...</code>" means start in the current directory
|
||||
|
||||
<pre>
|
||||
$ go list ./...
|
||||
github.com/google/codesearch/cmd/cgrep
|
||||
github.com/google/codesearch/cmd/cindex
|
||||
github.com/google/codesearch/cmd/csearch
|
||||
github.com/google/codesearch/index
|
||||
github.com/google/codesearch/regexp
|
||||
github.com/google/codesearch/sparse
|
||||
code.google.com/p/codesearch/cmd/cgrep
|
||||
code.google.com/p/codesearch/cmd/cindex
|
||||
code.google.com/p/codesearch/cmd/csearch
|
||||
code.google.com/p/codesearch/index
|
||||
code.google.com/p/codesearch/regexp
|
||||
code.google.com/p/codesearch/sparse
|
||||
github.com/petar/GoLLRB/example
|
||||
github.com/petar/GoLLRB/llrb
|
||||
$
|
||||
@@ -200,12 +199,12 @@ $
|
||||
|
||||
<pre>
|
||||
$ go test ./...
|
||||
? github.com/google/codesearch/cmd/cgrep [no test files]
|
||||
? github.com/google/codesearch/cmd/cindex [no test files]
|
||||
? github.com/google/codesearch/cmd/csearch [no test files]
|
||||
ok github.com/google/codesearch/index 0.203s
|
||||
ok github.com/google/codesearch/regexp 0.017s
|
||||
? github.com/google/codesearch/sparse [no test files]
|
||||
? code.google.com/p/codesearch/cmd/cgrep [no test files]
|
||||
? code.google.com/p/codesearch/cmd/cindex [no test files]
|
||||
? code.google.com/p/codesearch/cmd/csearch [no test files]
|
||||
ok code.google.com/p/codesearch/index 0.239s
|
||||
ok code.google.com/p/codesearch/regexp 0.021s
|
||||
? code.google.com/p/codesearch/sparse [no test files]
|
||||
? github.com/petar/GoLLRB/example [no test files]
|
||||
ok github.com/petar/GoLLRB/llrb 0.231s
|
||||
$
|
||||
@@ -215,18 +214,18 @@ $
|
||||
current directory:</p>
|
||||
|
||||
<pre>
|
||||
$ cd $GOPATH/src/github.com/google/codesearch/regexp
|
||||
$ cd $GOPATH/src/code.google.com/p/codesearch/regexp
|
||||
$ go list
|
||||
github.com/google/codesearch/regexp
|
||||
code.google.com/p/codesearch/regexp
|
||||
$ go test -v
|
||||
=== RUN TestNstateEnc
|
||||
--- PASS: TestNstateEnc (0.00s)
|
||||
=== RUN TestMatch
|
||||
--- PASS: TestMatch (0.00s)
|
||||
=== RUN TestGrep
|
||||
--- PASS: TestGrep (0.00s)
|
||||
=== RUN TestNstateEnc
|
||||
--- PASS: TestNstateEnc (0.00 seconds)
|
||||
=== RUN TestMatch
|
||||
--- PASS: TestMatch (0.01 seconds)
|
||||
=== RUN TestGrep
|
||||
--- PASS: TestGrep (0.00 seconds)
|
||||
PASS
|
||||
ok github.com/google/codesearch/regexp 0.018s
|
||||
ok code.google.com/p/codesearch/regexp 0.021s
|
||||
$ go install
|
||||
$
|
||||
</pre>
|
||||
@@ -250,15 +249,11 @@ projects at once within a single <code>$GOPATH</code> root directory.</p>
|
||||
<h2>Limitations</h2>
|
||||
|
||||
<p>As mentioned above, the go command is not a general-purpose build
|
||||
tool.
|
||||
In particular, it does not have any facility for generating Go
|
||||
source files <em>during</em> a build, although it does provide
|
||||
<a href="/cmd/go/#hdr-Generate_Go_files_by_processing_source"><code>go</code>
|
||||
<code>generate</code></a>,
|
||||
which can automate the creation of Go files <em>before</em> the build.
|
||||
For more advanced build setups, you may need to write a
|
||||
tool. In particular, it does not have any facility for generating Go
|
||||
source files during a build. Instead, if you want to use a tool like
|
||||
yacc or the protocol buffer compiler, you will need to write a
|
||||
makefile (or a configuration file for the build tool of your choice)
|
||||
to run whatever tool creates the Go files and then check those generated source files
|
||||
to generate the Go files and then check those generated source files
|
||||
into your repository. This is more work for you, the package author,
|
||||
but it is significantly less work for your users, who can use
|
||||
"<code>go get</code>" without needing to obtain and build
|
||||
|
||||
315
doc/articles/gobs_of_data.html
Normal file
315
doc/articles/gobs_of_data.html
Normal file
@@ -0,0 +1,315 @@
|
||||
<!--{
|
||||
"Title": "Gobs of data",
|
||||
"Template": true
|
||||
}-->
|
||||
|
||||
<p>
|
||||
To transmit a data structure across a network or to store it in a file, it must
|
||||
be encoded and then decoded again. There are many encodings available, of
|
||||
course: <a href="http://www.json.org/">JSON</a>,
|
||||
<a href="http://www.w3.org/XML/">XML</a>, Google's
|
||||
<a href="http://code.google.com/p/protobuf">protocol buffers</a>, and more.
|
||||
And now there's another, provided by Go's <a href="/pkg/encoding/gob/">gob</a>
|
||||
package.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Why define a new encoding? It's a lot of work and redundant at that. Why not
|
||||
just use one of the existing formats? Well, for one thing, we do! Go has
|
||||
<a href="/pkg/">packages</a> supporting all the encodings just mentioned (the
|
||||
<a href="http://code.google.com/p/goprotobuf">protocol buffer package</a> is in
|
||||
a separate repository but it's one of the most frequently downloaded). And for
|
||||
many purposes, including communicating with tools and systems written in other
|
||||
languages, they're the right choice.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
But for a Go-specific environment, such as communicating between two servers
|
||||
written in Go, there's an opportunity to build something much easier to use and
|
||||
possibly more efficient.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Gobs work with the language in a way that an externally-defined,
|
||||
language-independent encoding cannot. At the same time, there are lessons to be
|
||||
learned from the existing systems.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Goals</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The gob package was designed with a number of goals in mind.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
First, and most obvious, it had to be very easy to use. First, because Go has
|
||||
reflection, there is no need for a separate interface definition language or
|
||||
"protocol compiler". The data structure itself is all the package should need
|
||||
to figure out how to encode and decode it. On the other hand, this approach
|
||||
means that gobs will never work as well with other languages, but that's OK:
|
||||
gobs are unashamedly Go-centric.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Efficiency is also important. Textual representations, exemplified by XML and
|
||||
JSON, are too slow to put at the center of an efficient communications network.
|
||||
A binary encoding is necessary.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Gob streams must be self-describing. Each gob stream, read from the beginning,
|
||||
contains sufficient information that the entire stream can be parsed by an
|
||||
agent that knows nothing a priori about its contents. This property means that
|
||||
you will always be able to decode a gob stream stored in a file, even long
|
||||
after you've forgotten what data it represents.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
There were also some things to learn from our experiences with Google protocol
|
||||
buffers.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Protocol buffer misfeatures</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Protocol buffers had a major effect on the design of gobs, but have three
|
||||
features that were deliberately avoided. (Leaving aside the property that
|
||||
protocol buffers aren't self-describing: if you don't know the data definition
|
||||
used to encode a protocol buffer, you might not be able to parse it.)
|
||||
</p>
|
||||
|
||||
<p>
|
||||
First, protocol buffers only work on the data type we call a struct in Go. You
|
||||
can't encode an integer or array at the top level, only a struct with fields
|
||||
inside it. That seems a pointless restriction, at least in Go. If all you want
|
||||
to send is an array of integers, why should you have to put it into a
|
||||
struct first?
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Next, a protocol buffer definition may specify that fields <code>T.x</code> and
|
||||
<code>T.y</code> are required to be present whenever a value of type
|
||||
<code>T</code> is encoded or decoded. Although such required fields may seem
|
||||
like a good idea, they are costly to implement because the codec must maintain a
|
||||
separate data structure while encoding and decoding, to be able to report when
|
||||
required fields are missing. They're also a maintenance problem. Over time, one
|
||||
may want to modify the data definition to remove a required field, but that may
|
||||
cause existing clients of the data to crash. It's better not to have them in the
|
||||
encoding at all. (Protocol buffers also have optional fields. But if we don't
|
||||
have required fields, all fields are optional and that's that. There will be
|
||||
more to say about optional fields a little later.)
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The third protocol buffer misfeature is default values. If a protocol buffer
|
||||
omits the value for a "defaulted" field, then the decoded structure behaves as
|
||||
if the field were set to that value. This idea works nicely when you have
|
||||
getter and setter methods to control access to the field, but is harder to
|
||||
handle cleanly when the container is just a plain idiomatic struct. Required
|
||||
fields are also tricky to implement: where does one define the default values,
|
||||
what types do they have (is text UTF-8? uninterpreted bytes? how many bits in a
|
||||
float?) and despite the apparent simplicity, there were a number of
|
||||
complications in their design and implementation for protocol buffers. We
|
||||
decided to leave them out of gobs and fall back to Go's trivial but effective
|
||||
defaulting rule: unless you set something otherwise, it has the "zero value"
|
||||
for that type - and it doesn't need to be transmitted.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
So gobs end up looking like a sort of generalized, simplified protocol buffer.
|
||||
How do they work?
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Values</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The encoded gob data isn't about <code>int8</code>s and <code>uint16</code>s.
|
||||
Instead, somewhat analogous to constants in Go, its integer values are abstract,
|
||||
sizeless numbers, either signed or unsigned. When you encode an
|
||||
<code>int8</code>, its value is transmitted as an unsized, variable-length
|
||||
integer. When you encode an <code>int64</code>, its value is also transmitted as
|
||||
an unsized, variable-length integer. (Signed and unsigned are treated
|
||||
distinctly, but the same unsized-ness applies to unsigned values too.) If both
|
||||
have the value 7, the bits sent on the wire will be identical. When the receiver
|
||||
decodes that value, it puts it into the receiver's variable, which may be of
|
||||
arbitrary integer type. Thus an encoder may send a 7 that came from an
|
||||
<code>int8</code>, but the receiver may store it in an <code>int64</code>. This
|
||||
is fine: the value is an integer and as a long as it fits, everything works. (If
|
||||
it doesn't fit, an error results.) This decoupling from the size of the variable
|
||||
gives some flexibility to the encoding: we can expand the type of the integer
|
||||
variable as the software evolves, but still be able to decode old data.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
This flexibility also applies to pointers. Before transmission, all pointers are
|
||||
flattened. Values of type <code>int8</code>, <code>*int8</code>,
|
||||
<code>**int8</code>, <code>****int8</code>, etc. are all transmitted as an
|
||||
integer value, which may then be stored in <code>int</code> of any size, or
|
||||
<code>*int</code>, or <code>******int</code>, etc. Again, this allows for
|
||||
flexibility.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Flexibility also happens because, when decoding a struct, only those fields
|
||||
that are sent by the encoder are stored in the destination. Given the value
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/gobs1.go" `/type T/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
the encoding of <code>t</code> sends only the 7 and 8. Because it's zero, the
|
||||
value of <code>Y</code> isn't even sent; there's no need to send a zero value.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The receiver could instead decode the value into this structure:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/gobs1.go" `/type U/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
and acquire a value of <code>u</code> with only <code>X</code> set (to the
|
||||
address of an <code>int8</code> variable set to 7); the <code>Z</code> field is
|
||||
ignored - where would you put it? When decoding structs, fields are matched by
|
||||
name and compatible type, and only fields that exist in both are affected. This
|
||||
simple approach finesses the "optional field" problem: as the type
|
||||
<code>T</code> evolves by adding fields, out of date receivers will still
|
||||
function with the part of the type they recognize. Thus gobs provide the
|
||||
important result of optional fields - extensibility - without any additional
|
||||
mechanism or notation.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
From integers we can build all the other types: bytes, strings, arrays, slices,
|
||||
maps, even floats. Floating-point values are represented by their IEEE 754
|
||||
floating-point bit pattern, stored as an integer, which works fine as long as
|
||||
you know their type, which we always do. By the way, that integer is sent in
|
||||
byte-reversed order because common values of floating-point numbers, such as
|
||||
small integers, have a lot of zeros at the low end that we can avoid
|
||||
transmitting.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
One nice feature of gobs that Go makes possible is that they allow you to define
|
||||
your own encoding by having your type satisfy the
|
||||
<a href="/pkg/encoding/gob/#GobEncoder">GobEncoder</a> and
|
||||
<a href="/pkg/encoding/gob/#GobDecoder">GobDecoder</a> interfaces, in a manner
|
||||
analogous to the <a href="/pkg/encoding/json/">JSON</a> package's
|
||||
<a href="/pkg/encoding/json/#Marshaler">Marshaler</a> and
|
||||
<a href="/pkg/encoding/json/#Unmarshaler">Unmarshaler</a> and also to the
|
||||
<a href="/pkg/fmt/#Stringer">Stringer</a> interface from
|
||||
<a href="/pkg/fmt/">package fmt</a>. This facility makes it possible to
|
||||
represent special features, enforce constraints, or hide secrets when you
|
||||
transmit data. See the <a href="/pkg/encoding/gob/">documentation</a> for
|
||||
details.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Types on the wire</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The first time you send a given type, the gob package includes in the data
|
||||
stream a description of that type. In fact, what happens is that the encoder is
|
||||
used to encode, in the standard gob encoding format, an internal struct that
|
||||
describes the type and gives it a unique number. (Basic types, plus the layout
|
||||
of the type description structure, are predefined by the software for
|
||||
bootstrapping.) After the type is described, it can be referenced by its type
|
||||
number.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Thus when we send our first type <code>T</code>, the gob encoder sends a
|
||||
description of <code>T</code> and tags it with a type number, say 127. All
|
||||
values, including the first, are then prefixed by that number, so a stream of
|
||||
<code>T</code> values looks like:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
("define type id" 127, definition of type T)(127, T value)(127, T value), ...
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
These type numbers make it possible to describe recursive types and send values
|
||||
of those types. Thus gobs can encode types such as trees:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/gobs1.go" `/type Node/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
(It's an exercise for the reader to discover how the zero-defaulting rule makes
|
||||
this work, even though gobs don't represent pointers.)
|
||||
</p>
|
||||
|
||||
<p>
|
||||
With the type information, a gob stream is fully self-describing except for the
|
||||
set of bootstrap types, which is a well-defined starting point.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Compiling a machine</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The first time you encode a value of a given type, the gob package builds a
|
||||
little interpreted machine specific to that data type. It uses reflection on
|
||||
the type to construct that machine, but once the machine is built it does not
|
||||
depend on reflection. The machine uses package unsafe and some trickery to
|
||||
convert the data into the encoded bytes at high speed. It could use reflection
|
||||
and avoid unsafe, but would be significantly slower. (A similar high-speed
|
||||
approach is taken by the protocol buffer support for Go, whose design was
|
||||
influenced by the implementation of gobs.) Subsequent values of the same type
|
||||
use the already-compiled machine, so they can be encoded right away.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Decoding is similar but harder. When you decode a value, the gob package holds
|
||||
a byte slice representing a value of a given encoder-defined type to decode,
|
||||
plus a Go value into which to decode it. The gob package builds a machine for
|
||||
that pair: the gob type sent on the wire crossed with the Go type provided for
|
||||
decoding. Once that decoding machine is built, though, it's again a
|
||||
reflectionless engine that uses unsafe methods to get maximum speed.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Use</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
There's a lot going on under the hood, but the result is an efficient,
|
||||
easy-to-use encoding system for transmitting data. Here's a complete example
|
||||
showing differing encoded and decoded types. Note how easy it is to send and
|
||||
receive values; all you need to do is present values and variables to the
|
||||
<a href="/pkg/encoding/gob/">gob package</a> and it does all the work.
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/gobs2.go" `/package main/` `$`}}
|
||||
|
||||
<p>
|
||||
You can compile and run this example code in the
|
||||
<a href="http://play.golang.org/p/_-OJV-rwMq">Go Playground</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <a href="/pkg/net/rpc/">rpc package</a> builds on gobs to turn this
|
||||
encode/decode automation into transport for method calls across the network.
|
||||
That's a subject for another article.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Details</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <a href="/pkg/encoding/gob/">gob package documentation</a>, especially the
|
||||
file <a href="/src/pkg/encoding/gob/doc.go">doc.go</a>, expands on many of the
|
||||
details described here and includes a full worked example showing how the
|
||||
encoding represents data. If you are interested in the innards of the gob
|
||||
implementation, that's a good place to start.
|
||||
</p>
|
||||
139
doc/articles/godoc_documenting_go_code.html
Normal file
139
doc/articles/godoc_documenting_go_code.html
Normal file
@@ -0,0 +1,139 @@
|
||||
<!--{
|
||||
"Title": "Godoc: documenting Go code",
|
||||
"Template": true
|
||||
}-->
|
||||
|
||||
<p>
|
||||
The Go project takes documentation seriously. Documentation is a huge part of
|
||||
making software accessible and maintainable. Of course it must be well-written
|
||||
and accurate, but it also must be easy to write and to maintain. Ideally, it
|
||||
should be coupled to the code itself so the documentation evolves along with the
|
||||
code. The easier it is for programmers to produce good documentation, the better
|
||||
for everyone.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To that end, we have developed the <a href="/cmd/godoc/">godoc</a> documentation
|
||||
tool. This article describes godoc's approach to documentation, and explains how
|
||||
you can use our conventions and tools to write good documentation for your own
|
||||
projects.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Godoc parses Go source code - including comments - and produces documentation as
|
||||
HTML or plain text. The end result is documentation tightly coupled with the
|
||||
code it documents. For example, through godoc's web interface you can navigate
|
||||
from a function's <a href="/pkg/strings/#HasPrefix">documentation</a> to its
|
||||
<a href="/src/pkg/strings/strings.go?#L312">implementation</a> with one click.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Godoc is conceptually related to Python's
|
||||
<a href="http://www.python.org/dev/peps/pep-0257/">Docstring</a> and Java's
|
||||
<a href="http://www.oracle.com/technetwork/java/javase/documentation/index-jsp-135444.html">Javadoc</a>,
|
||||
but its design is simpler. The comments read by godoc are not language
|
||||
constructs (as with Docstring) nor must they have their own machine-readable
|
||||
syntax (as with Javadoc). Godoc comments are just good comments, the sort you
|
||||
would want to read even if godoc didn't exist.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The convention is simple: to document a type, variable, constant, function, or
|
||||
even a package, write a regular comment directly preceding its declaration, with
|
||||
no intervening blank line. Godoc will then present that comment as text
|
||||
alongside the item it documents. For example, this is the documentation for the
|
||||
<code>fmt</code> package's <a href="/pkg/fmt/#Fprint"><code>Fprint</code></a>
|
||||
function:
|
||||
</p>
|
||||
|
||||
{{code "/src/pkg/fmt/print.go" `/Fprint formats using the default/` `/func Fprint/`}}
|
||||
|
||||
<p>
|
||||
Notice this comment is a complete sentence that begins with the name of the
|
||||
element it describes. This important convention allows us to generate
|
||||
documentation in a variety of formats, from plain text to HTML to UNIX man
|
||||
pages, and makes it read better when tools truncate it for brevity, such as when
|
||||
they extract the first line or sentence.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Comments on package declarations should provide general package documentation.
|
||||
These comments can be short, like the <a href="/pkg/sort/"><code>sort</code></a>
|
||||
package's brief description:
|
||||
</p>
|
||||
|
||||
{{code "/src/pkg/sort/sort.go" `/Package sort provides/` `/package sort/`}}
|
||||
|
||||
<p>
|
||||
They can also be detailed like the <a href="/pkg/encoding/gob/">gob package</a>'s
|
||||
overview. That package uses another convention for packages
|
||||
that need large amounts of introductory documentation: the package comment is
|
||||
placed in its own file, <a href="/src/pkg/encoding/gob/doc.go">doc.go</a>, which
|
||||
contains only those comments and a package clause.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
When writing package comments of any size, keep in mind that their first
|
||||
sentence will appear in godoc's <a href="/pkg/">package list</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Comments that are not adjacent to a top-level declaration are omitted from
|
||||
godoc's output, with one notable exception. Top-level comments that begin with
|
||||
the word <code>"BUG(who)”</code> are recognized as known bugs, and included in
|
||||
the "Bugs” section of the package documentation. The "who” part should be the
|
||||
user name of someone who could provide more information. For example, this is a
|
||||
known issue from the <a href="/pkg/bytes/#bugs">bytes package</a>:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
// BUG(r): The rule Title uses for word boundaries does not handle Unicode punctuation properly.
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Godoc treats executable commands somewhat differently. Instead of inspecting the
|
||||
command source code, it looks for a Go source file belonging to the special
|
||||
package "documentation”. The comment on the "package documentation” clause is
|
||||
used as the command's documentation. For example, see the
|
||||
<a href="/cmd/godoc/">godoc documentation</a> and its corresponding
|
||||
<a href="/src/cmd/godoc/doc.go">doc.go</a> file.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
There are a few formatting rules that Godoc uses when converting comments to
|
||||
HTML:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
Subsequent lines of text are considered part of the same paragraph; you must
|
||||
leave a blank line to separate paragraphs.
|
||||
</li>
|
||||
<li>
|
||||
Pre-formatted text must be indented relative to the surrounding comment text
|
||||
(see gob's <a href="/src/pkg/encoding/gob/doc.go">doc.go</a> for an example).
|
||||
</li>
|
||||
<li>
|
||||
URLs will be converted to HTML links; no special markup is necessary.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Note that none of these rules requires you to do anything out of the ordinary.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In fact, the best thing about godoc's minimal approach is how easy it is to use.
|
||||
As a result, a lot of Go code, including all of the standard library, already
|
||||
follows the conventions.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Your own code can present good documentation just by having comments as
|
||||
described above. Any Go packages installed inside <code>$GOROOT/src/pkg</code>
|
||||
and any <code>GOPATH</code> work spaces will already be accessible via godoc's
|
||||
command-line and HTTP interfaces, and you can specify additional paths for
|
||||
indexing via the <code>-path</code> flag or just by running <code>"godoc ."</code>
|
||||
in the source directory. See the <a href="/cmd/godoc/">godoc documentation</a>
|
||||
for more details.
|
||||
</p>
|
||||
348
doc/articles/gos_declaration_syntax.html
Normal file
348
doc/articles/gos_declaration_syntax.html
Normal file
@@ -0,0 +1,348 @@
|
||||
<!--{
|
||||
"Title": "Go's Declaration Syntax"
|
||||
}-->
|
||||
|
||||
<p>
|
||||
Newcomers to Go wonder why the declaration syntax is different from the
|
||||
tradition established in the C family. In this post we'll compare the
|
||||
two approaches and explain why Go's declarations look as they do.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>C syntax</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
First, let's talk about C syntax. C took an unusual and clever approach
|
||||
to declaration syntax. Instead of describing the types with special
|
||||
syntax, one writes an expression involving the item being declared, and
|
||||
states what type that expression will have. Thus
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
int x;
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
declares x to be an int: the expression 'x' will have type int. In
|
||||
general, to figure out how to write the type of a new variable, write an
|
||||
expression involving that variable that evaluates to a basic type, then
|
||||
put the basic type on the left and the expression on the right.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Thus, the declarations
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
int *p;
|
||||
int a[3];
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
state that p is a pointer to int because '*p' has type int, and that a
|
||||
is an array of ints because a[3] (ignoring the particular index value,
|
||||
which is punned to be the size of the array) has type int.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
What about functions? Originally, C's function declarations wrote the
|
||||
types of the arguments outside the parens, like this:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
int main(argc, argv)
|
||||
int argc;
|
||||
char *argv[];
|
||||
{ /* ... */ }
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Again, we see that main is a function because the expression main(argc,
|
||||
argv) returns an int. In modern notation we'd write
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
int main(int argc, char *argv[]) { /* ... */ }
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
but the basic structure is the same.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
This is a clever syntactic idea that works well for simple types but can
|
||||
get confusing fast. The famous example is declaring a function pointer.
|
||||
Follow the rules and you get this:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
int (*fp)(int a, int b);
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Here, fp is a pointer to a function because if you write the expression
|
||||
(*fp)(a, b) you'll call a function that returns int. What if one of fp's
|
||||
arguments is itself a function?
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
int (*fp)(int (*ff)(int x, int y), int b)
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
That's starting to get hard to read.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Of course, we can leave out the name of the parameters when we declare a
|
||||
function, so main can be declared
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
int main(int, char *[])
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Recall that argv is declared like this,
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
char *argv[]
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
so you drop the name from the <em>middle</em> of its declaration to construct
|
||||
its type. It's not obvious, though, that you declare something of type
|
||||
char *[] by putting its name in the middle.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
And look what happens to fp's declaration if you don't name the
|
||||
parameters:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
int (*fp)(int (*)(int, int), int)
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Not only is it not obvious where to put the name inside
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
int (*)(int, int)
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
it's not exactly clear that it's a function pointer declaration at all.
|
||||
And what if the return type is a function pointer?
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
int (*(*fp)(int (*)(int, int), int))(int, int)
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
It's hard even to see that this declaration is about fp.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
You can construct more elaborate examples but these should illustrate
|
||||
some of the difficulties that C's declaration syntax can introduce.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
There's one more point that needs to be made, though. Because type and
|
||||
declaration syntax are the same, it can be difficult to parse
|
||||
expressions with types in the middle. This is why, for instance, C casts
|
||||
always parenthesize the type, as in
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
(int)M_PI
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
<b>Go syntax</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Languages outside the C family usually use a distinct type syntax in
|
||||
declarations. Although it's a separate point, the name usually comes
|
||||
first, often followed by a colon. Thus our examples above become
|
||||
something like (in a fictional but illustrative language)
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
x: int
|
||||
p: pointer to int
|
||||
a: array[3] of int
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
These declarations are clear, if verbose - you just read them left to
|
||||
right. Go takes its cue from here, but in the interests of brevity it
|
||||
drops the colon and removes some of the keywords:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
x int
|
||||
p *int
|
||||
a [3]int
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
There is no direct correspondence between the look of [3]int and how to
|
||||
use a in an expression. (We'll come back to pointers in the next
|
||||
section.) You gain clarity at the cost of a separate syntax.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Now consider functions. Let's transcribe the declaration for main, even
|
||||
though the main function in Go takes no arguments:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
func main(argc int, argv *[]byte) int
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Superficially that's not much different from C, but it reads well from
|
||||
left to right:
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<em>function main takes an int and a pointer to a slice of bytes and returns an int.</em>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Drop the parameter names and it's just as clear - they're always first
|
||||
so there's no confusion.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
func main(int, *[]byte) int
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
One value of this left-to-right style is how well it works as the types
|
||||
become more complex. Here's a declaration of a function variable
|
||||
(analogous to a function pointer in C):
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
f func(func(int,int) int, int) int
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Or if f returns a function:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
f func(func(int,int) int, int) func(int, int) int
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
It still reads clearly, from left to right, and it's always obvious
|
||||
which name is being declared - the name comes first.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The distinction between type and expression syntax makes it easy to
|
||||
write and invoke closures in Go:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
sum := func(a, b int) int { return a+b } (3, 4)
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
<b>Pointers</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Pointers are the exception that proves the rule. Notice that in arrays
|
||||
and slices, for instance, Go's type syntax puts the brackets on the left
|
||||
of the type but the expression syntax puts them on the right of the
|
||||
expression:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
var a []int
|
||||
x = a[1]
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
For familiarity, Go's pointers use the * notation from C, but we could
|
||||
not bring ourselves to make a similar reversal for pointer types. Thus
|
||||
pointers work like this
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
var p *int
|
||||
x = *p
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
We couldn't say
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
var p *int
|
||||
x = p*
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
because that postfix * would conflate with multiplication. We could have
|
||||
used the Pascal ^, for example:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
var p ^int
|
||||
x = p^
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
and perhaps we should have (and chosen another operator for xor),
|
||||
because the prefix asterisk on both types and expressions complicates
|
||||
things in a number of ways. For instance, although one can write
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
[]int("hi")
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
as a conversion, one must parenthesize the type if it starts with a *:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
(*int)(nil)
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Had we been willing to give up * as pointer syntax, those parentheses
|
||||
would be unnecessary.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
So Go's pointer syntax is tied to the familiar C form, but those ties
|
||||
mean that we cannot break completely from using parentheses to
|
||||
disambiguate types and expressions in the grammar.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Overall, though, we believe Go's type syntax is easier to understand
|
||||
than C's, especially when things get complicated.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Notes</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Go's declarations read left to right. It's been pointed out that C's
|
||||
read in a spiral! See <a href="http://c-faq.com/decl/spiral.anderson.html">
|
||||
The "Clockwise/Spiral Rule"</a> by David Anderson.
|
||||
</p>
|
||||
BIN
doc/articles/image-20.png
Normal file
BIN
doc/articles/image-20.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 93 KiB |
BIN
doc/articles/image-2a.png
Normal file
BIN
doc/articles/image-2a.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 3.5 KiB |
BIN
doc/articles/image-2b.png
Normal file
BIN
doc/articles/image-2b.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 93 KiB |
BIN
doc/articles/image-2c.png
Normal file
BIN
doc/articles/image-2c.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 59 KiB |
BIN
doc/articles/image-2d.png
Normal file
BIN
doc/articles/image-2d.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 67 KiB |
BIN
doc/articles/image-2e.png
Normal file
BIN
doc/articles/image-2e.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 94 KiB |
BIN
doc/articles/image-2f.png
Normal file
BIN
doc/articles/image-2f.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 61 KiB |
BIN
doc/articles/image-package-01.png
Normal file
BIN
doc/articles/image-package-01.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.4 KiB |
BIN
doc/articles/image-package-02.png
Normal file
BIN
doc/articles/image-package-02.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.5 KiB |
BIN
doc/articles/image-package-03.png
Normal file
BIN
doc/articles/image-package-03.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.4 KiB |
BIN
doc/articles/image-package-04.png
Normal file
BIN
doc/articles/image-package-04.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.6 KiB |
BIN
doc/articles/image-package-05.png
Normal file
BIN
doc/articles/image-package-05.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.6 KiB |
222
doc/articles/image_draw.html
Normal file
222
doc/articles/image_draw.html
Normal file
@@ -0,0 +1,222 @@
|
||||
<!--{
|
||||
"Title": "The Go image/draw package",
|
||||
"Template": true
|
||||
}-->
|
||||
|
||||
<p>
|
||||
<a href="/pkg/image/draw/">Package image/draw</a> defines
|
||||
only one operation: drawing a source image onto a destination
|
||||
image, through an optional mask image. This one operation is
|
||||
surprisingly versatile and can perform a number of common image
|
||||
manipulation tasks elegantly and efficiently.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Composition is performed pixel by pixel in the style of the Plan 9
|
||||
graphics library and the X Render extension. The model is based on
|
||||
the classic "Compositing Digital Images" paper by Porter and Duff,
|
||||
with an additional mask parameter: <code>dst = (src IN mask) OP dst</code>.
|
||||
For a fully opaque mask, this reduces to the original Porter-Duff
|
||||
formula: <code>dst = src OP dst</code>. In Go, a nil mask image is equivalent
|
||||
to an infinitely sized, fully opaque mask image.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The Porter-Duff paper presented
|
||||
<a href="http://www.w3.org/TR/SVGCompositing/examples/compop-porterduff-examples.png">12 different composition operators</a>,
|
||||
but with an explicit mask, only 2 of these are needed in practice:
|
||||
source-over-destination and source. In Go, these operators are
|
||||
represented by the <code>Over</code> and <code>Src</code> constants. The <code>Over</code> operator
|
||||
performs the natural layering of a source image over a destination
|
||||
image: the change to the destination image is smaller where the
|
||||
source (after masking) is more transparent (that is, has lower
|
||||
alpha). The <code>Src</code> operator merely copies the source (after masking)
|
||||
with no regard for the destination image's original content. For
|
||||
fully opaque source and mask images, the two operators produce the
|
||||
same output, but the <code>Src</code> operator is usually faster.
|
||||
</p>
|
||||
|
||||
<p><b>Geometric Alignment</b></p>
|
||||
|
||||
<p>
|
||||
Composition requires associating destination pixels with source and
|
||||
mask pixels. Obviously, this requires destination, source and mask
|
||||
images, and a composition operator, but it also requires specifying
|
||||
what rectangle of each image to use. Not every drawing should write
|
||||
to the entire destination: when updating an animating image, it is
|
||||
more efficient to only draw the parts of the image that have
|
||||
changed. Not every drawing should read from the entire source: when
|
||||
using a sprite that combines many small images into one large one,
|
||||
only a part of the image is needed. Not every drawing should read
|
||||
from the entire mask: a mask image that collects a font's glyphs is
|
||||
similar to a sprite. Thus, drawing also needs to know three
|
||||
rectangles, one for each image. Since each rectangle has the same
|
||||
width and height, it suffices to pass a destination rectangle `r`
|
||||
and two points <code>sp</code> and <code>mp</code>: the source rectangle is equal to <code>r</code>
|
||||
translated so that <code>r.Min</code> in the destination image aligns with
|
||||
<code>sp</code> in the source image, and similarly for <code>mp</code>. The effective
|
||||
rectangle is also clipped to each image's bounds in their
|
||||
respective co-ordinate space.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<img src="image-20.png">
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <a href="/pkg/image/draw/#DrawMask"><code>DrawMask</code></a>
|
||||
function takes seven arguments, but an explicit mask and mask-point
|
||||
are usually unnecessary, so the
|
||||
<a href="/pkg/image/draw/#Draw"><code>Draw</code></a> function takes five:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
// Draw calls DrawMask with a nil mask.
|
||||
func Draw(dst Image, r image.Rectangle, src image.Image, sp image.Point, op Op)
|
||||
func DrawMask(dst Image, r image.Rectangle, src image.Image, sp image.Point,
|
||||
mask image.Image, mp image.Point, op Op)
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The destination image must be mutable, so the image/draw package
|
||||
defines a <a href="/pkg/image/draw/#Image"><code>draw.Image</code></a>
|
||||
interface which has a <code>Set</code> method.
|
||||
</p>
|
||||
|
||||
{{code "../src/pkg/image/draw/draw.go" `/type Image/` `/}/`}}
|
||||
|
||||
<p><b>Filling a Rectangle</b></p>
|
||||
|
||||
<p>
|
||||
To fill a rectangle with a solid color, use an <code>image.Uniform</code>
|
||||
source. The <code>ColorImage</code> type re-interprets a <code>Color</code> as a
|
||||
practically infinite-sized <code>Image</code> of that color. For those
|
||||
familiar with the design of Plan 9's draw library, there is no need
|
||||
for an explicit "repeat bit" in Go's slice-based image types; the
|
||||
concept is subsumed by <code>Uniform</code>.
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/image_draw.go" `/ZERO/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
To initialize a new image to all-blue:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/image_draw.go" `/BLUE/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
To reset an image to transparent (or black, if the destination
|
||||
image's color model cannot represent transparency), use
|
||||
<code>image.Transparent</code>, which is an <code>image.Uniform</code>:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/image_draw.go" `/RESET/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
<img src="image-2a.png">
|
||||
</p>
|
||||
|
||||
|
||||
<p><b>Copying an Image</b></p>
|
||||
|
||||
<p>
|
||||
To copy from a rectangle <code>sr</code> in the source image to a rectangle
|
||||
starting at a point <code>dp</code> in the destination, convert the source
|
||||
rectangle into the destination image's co-ordinate space:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/image_draw.go" `/RECT/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
Alternatively:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/image_draw.go" `/RECT2/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
To copy the entire source image, use <code>sr = src.Bounds()</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<img src="image-2b.png">
|
||||
</p>
|
||||
|
||||
<p><b>Scrolling an Image</b></p>
|
||||
|
||||
<p>
|
||||
Scrolling an image is just copying an image to itself, with
|
||||
different destination and source rectangles. Overlapping
|
||||
destination and source images are perfectly valid, just as Go's
|
||||
built-in copy function can handle overlapping destination and
|
||||
source slices. To scroll an image m by 20 pixels:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/image_draw.go" `/SCROLL/` `/STOP/`}}
|
||||
|
||||
<p><img src="image-2c.png"></p>
|
||||
|
||||
<p><b>Converting an Image to RGBA</b></p>
|
||||
|
||||
<p>
|
||||
The result of decoding an image format might not be an
|
||||
<code>image.RGBA</code>: decoding a GIF results in an <code>image.Paletted</code>,
|
||||
decoding a JPEG results in a <code>ycbcr.YCbCr</code>, and the result of
|
||||
decoding a PNG depends on the image data. To convert any image to
|
||||
an <code>image.RGBA</code>:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/image_draw.go" `/CONV/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
<img src="image-2d.png">
|
||||
</p>
|
||||
|
||||
<p><b>Drawing Through a Mask</b></p>
|
||||
|
||||
<p>
|
||||
To draw an image through a circular mask with center <code>p</code> and radius
|
||||
<code>r</code>:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/image_draw.go" `/CIRCLESTRUCT/` `/STOP/`}}
|
||||
{{code "/doc/progs/image_draw.go" `/CIRCLE2/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
<img src="image-2e.png">
|
||||
</p>
|
||||
|
||||
<p><b>Drawing Font Glyphs</b></p>
|
||||
|
||||
<p>
|
||||
To draw a font glyph in blue starting from a point <code>p</code>, draw with
|
||||
an <code>image.ColorImage</code> source and an <code>image.Alpha mask</code>. For
|
||||
simplicity, we aren't performing any sub-pixel positioning or
|
||||
rendering, or correcting for a font's height above a baseline.
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/image_draw.go" `/GLYPH/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
<img src="image-2f.png">
|
||||
</p>
|
||||
|
||||
<p><b>Performance</b></p>
|
||||
|
||||
<p>
|
||||
The image/draw package implementation demonstrates how to provide
|
||||
an image manipulation function that is both general purpose, yet
|
||||
efficient for common cases. The <code>DrawMask</code> function takes arguments
|
||||
of interface types, but immediately makes type assertions that its
|
||||
arguments are of specific struct types, corresponding to common
|
||||
operations like drawing one <code>image.RGBA</code> image onto another, or
|
||||
drawing an <code>image.Alpha</code> mask (such as a font glyph) onto an
|
||||
<code>image.RGBA</code> image. If a type assertion succeeds, that type
|
||||
information is used to run a specialized implementation of the
|
||||
general algorithm. If the assertions fail, the fallback code path
|
||||
uses the generic <code>At</code> and <code>Set</code> methods. The fast-paths are purely
|
||||
a performance optimization; the resultant destination image is the
|
||||
same either way. In practice, only a small number of special cases
|
||||
are necessary to support typical applications.
|
||||
</p>
|
||||
|
||||
|
||||
312
doc/articles/image_package.html
Normal file
312
doc/articles/image_package.html
Normal file
@@ -0,0 +1,312 @@
|
||||
<!--{
|
||||
"Title": "The Go image package",
|
||||
"Template": true
|
||||
}-->
|
||||
|
||||
<p>
|
||||
The <a href="/pkg/image/">image</a> and
|
||||
<a href="/pkg/image/color/">image/color</a> packages define a number of types:
|
||||
<code>color.Color</code> and <code>color.Model</code> describe colors,
|
||||
<code>image.Point</code> and <code>image.Rectangle</code> describe basic 2-D
|
||||
geometry, and <code>image.Image</code> brings the two concepts together to
|
||||
represent a rectangular grid of colors. A
|
||||
<a href="/doc/articles/image_draw.html">separate article</a> covers image
|
||||
composition with the <a href="/pkg/image/draw/">image/draw</a> package.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Colors and Color Models</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/image/color/#Color">Color</a> is an interface that defines the minimal
|
||||
method set of any type that can be considered a color: one that can be converted
|
||||
to red, green, blue and alpha values. The conversion may be lossy, such as
|
||||
converting from CMYK or YCbCr color spaces.
|
||||
</p>
|
||||
|
||||
{{code "/src/pkg/image/color/color.go" `/type Color interface/` `/^}/`}}
|
||||
|
||||
<p>
|
||||
There are three important subtleties about the return values. First, the red,
|
||||
green and blue are alpha-premultiplied: a fully saturated red that is also 25%
|
||||
transparent is represented by RGBA returning a 75% r. Second, the channels have
|
||||
a 16-bit effective range: 100% red is represented by RGBA returning an r of
|
||||
65535, not 255, so that converting from CMYK or YCbCr is not as lossy. Third,
|
||||
the type returned is <code>uint32</code>, even though the maximum value is 65535, to
|
||||
guarantee that multiplying two values together won't overflow. Such
|
||||
multiplications occur when blending two colors according to an alpha mask from a
|
||||
third color, in the style of
|
||||
<a href="https://en.wikipedia.org/wiki/Alpha_compositing">Porter and Duff's</a>
|
||||
classic algebra:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
dstr, dstg, dstb, dsta := dst.RGBA()
|
||||
srcr, srcg, srcb, srca := src.RGBA()
|
||||
_, _, _, m := mask.RGBA()
|
||||
const M = 1<<16 - 1
|
||||
// The resultant red value is a blend of dstr and srcr, and ranges in [0, M].
|
||||
// The calculation for green, blue and alpha is similar.
|
||||
dstr = (dstr*(M-m) + srcr*m) / M
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The last line of that code snippet would have been more complicated if we worked
|
||||
with non-alpha-premultiplied colors, which is why <code>Color</code> uses
|
||||
alpha-premultiplied values.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The image/color package also defines a number of concrete types that implement
|
||||
the <code>Color</code> interface. For example,
|
||||
<a href="/pkg/image/color/#RGBA"><code>RGBA</code></a> is a struct that represents
|
||||
the classic "8 bits per channel" color.
|
||||
</p>
|
||||
|
||||
{{code "/src/pkg/image/color/color.go" `/type RGBA struct/` `/^}/`}}
|
||||
|
||||
<p>
|
||||
Note that the <code>R</code> field of an <code>RGBA</code> is an 8-bit
|
||||
alpha-premultiplied color in the range [0, 255]. <code>RGBA</code> satisfies the
|
||||
<code>Color</code> interface by multiplying that value by 0x101 to generate a
|
||||
16-bit alpha-premultiplied color in the range [0, 65535]. Similarly, the
|
||||
<a href="/pkg/image/color/#NRGBA"><code>NRGBA</code></a> struct type represents
|
||||
an 8-bit non-alpha-premultiplied color, as used by the PNG image format. When
|
||||
manipulating an <code>NRGBA</code>'s fields directly, the values are
|
||||
non-alpha-premultiplied, but when calling the <code>RGBA</code> method, the
|
||||
return values are alpha-premultiplied.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A <a href="/pkg/image/color/#Model"><code>Model</code></a> is simply
|
||||
something that can convert <code>Color</code>s to other <code>Color</code>s, possibly lossily. For
|
||||
example, the <code>GrayModel</code> can convert any <code>Color</code> to a
|
||||
desaturated <a href="/pkg/image/color/#Gray"><code>Gray</code></a>. A
|
||||
<code>Palette</code> can convert any <code>Color</code> to one from a
|
||||
limited palette.
|
||||
</p>
|
||||
|
||||
{{code "/src/pkg/image/color/color.go" `/type Model interface/` `/^}/`}}
|
||||
|
||||
{{code "/src/pkg/image/color/color.go" `/type Palette \[\]Color/`}}
|
||||
|
||||
<p>
|
||||
<b>Points and Rectangles</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A <a href="/pkg/image/#Point"><code>Point</code></a> is an (x, y) co-ordinate
|
||||
on the integer grid, with axes increasing right and down. It is neither a pixel
|
||||
nor a grid square. A <code>Point</code> has no intrinsic width, height or
|
||||
color, but the visualizations below use a small colored square.
|
||||
</p>
|
||||
|
||||
{{code "/src/pkg/image/geom.go" `/type Point struct/` `/^}/`}}
|
||||
|
||||
<p>
|
||||
<img src="image-package-01.png" width="400" height="300">
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/image_package1.go" `/p := image.Point/`}}
|
||||
|
||||
<p>
|
||||
A <a href="/pkg/image/#Rectangle"><code>Rectangle</code></a> is an axis-aligned
|
||||
rectangle on the integer grid, defined by its top-left and bottom-right
|
||||
<code>Point</code>. A <code>Rectangle</code> also has no intrinsic color, but
|
||||
the visualizations below outline rectangles with a thin colored line, and call
|
||||
out their <code>Min</code> and <code>Max</code> <code>Point</code>s.
|
||||
</p>
|
||||
|
||||
{{code "/src/pkg/image/geom.go" `/type Rectangle struct/` `/^}/`}}
|
||||
|
||||
<p>
|
||||
For convenience, <code>image.Rect(x0, y0, x1, y1)</code> is equivalent to
|
||||
<code>image.Rectangle{image.Point{x0, y0}, image.Point{x1, y1}}</code>, but is
|
||||
much easier to type.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A <code>Rectangle</code> is inclusive at the top-left and exclusive at the
|
||||
bottom-right. For a <code>Point p</code> and a <code>Rectangle r</code>,
|
||||
<code>p.In(r)</code> if and only if
|
||||
<code>r.Min.X <= p.X && p.X < r.Max.X</code>, and similarly for <code>Y</code>. This is analagous to how
|
||||
a slice <code>s[i0:i1]</code> is inclusive at the low end and exclusive at the
|
||||
high end. (Unlike arrays and slices, a <code>Rectangle</code> often has a
|
||||
non-zero origin.)
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<img src="image-package-02.png" width="400" height="300">
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/image_package2.go" `/r := image.Rect/` `/fmt.Println/`}}
|
||||
|
||||
<p>
|
||||
Adding a <code>Point</code> to a <code>Rectangle</code> translates the
|
||||
<code>Rectangle</code>. Points and Rectangles are not restricted to be in the
|
||||
bottom-right quadrant.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<img src="image-package-03.png" width="400" height="300">
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/image_package3.go" `/r := image.Rect/` `/fmt.Println/`}}
|
||||
|
||||
<p>
|
||||
Intersecting two Rectangles yields another Rectangle, which may be empty.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<img src="image-package-04.png" width="400" height="300">
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/image_package4.go" `/r := image.Rect/` `/fmt.Printf/`}}
|
||||
|
||||
<p>
|
||||
Points and Rectangles are passed and returned by value. A function that takes a
|
||||
<code>Rectangle</code> argument will be as efficient as a function that takes
|
||||
two <code>Point</code> arguments, or four <code>int</code> arguments.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Images</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
An <a href="/pkg/image/#Image">Image</a> maps every grid square in a
|
||||
<code>Rectangle</code> to a <code>Color</code> from a <code>Model</code>.
|
||||
"The pixel at (x, y)" refers to the color of the grid square defined by the
|
||||
points (x, y), (x+1, y), (x+1, y+1) and (x, y+1).
|
||||
</p>
|
||||
|
||||
{{code "/src/pkg/image/image.go" `/type Image interface/` `/^}/`}}
|
||||
|
||||
<p>
|
||||
A common mistake is assuming that an <code>Image</code>'s bounds start at (0,
|
||||
0). For example, an animated GIF contains a sequence of Images, and each
|
||||
<code>Image</code> after the first typically only holds pixel data for the area
|
||||
that changed, and that area doesn't necessarily start at (0, 0). The correct
|
||||
way to iterate over an <code>Image</code> m's pixels looks like:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
b := m.Bounds()
|
||||
for y := b.Min.Y; y < b.Max.Y; y++ {
|
||||
for x := b.Min.X; y < b.Max.X; x++ {
|
||||
doStuffWith(m.At(x, y))
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
<code>Image</code> implementations do not have to be based on an in-memory
|
||||
slice of pixel data. For example, a
|
||||
<a href="/pkg/image/#Uniform"><code>Uniform</code></a> is an
|
||||
<code>Image</code> of enormous bounds and uniform color, whose in-memory
|
||||
representation is simply that color.
|
||||
</p>
|
||||
|
||||
{{code "/src/pkg/image/names.go" `/type Uniform struct/` `/^}/`}}
|
||||
|
||||
<p>
|
||||
Typically, though, programs will want an image based on a slice. Struct types
|
||||
like <a href="/pkg/image/#RGBA"><code>RGBA</code></a> and
|
||||
<a href="/pkg/image/#Gray"><code>Gray</code></a> (which other packages refer
|
||||
to as <code>image.RGBA</code> and <code>image.Gray</code>) hold slices of pixel
|
||||
data and implement the <code>Image</code> interface.
|
||||
</p>
|
||||
|
||||
{{code "/src/pkg/image/image.go" `/type RGBA struct/` `/^}/`}}
|
||||
|
||||
<p>
|
||||
These types also provide a <code>Set(x, y int, c color.Color)</code> method
|
||||
that allows modifying the image one pixel at a time.
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/image_package5.go" `/m := image.New/` `/m.Set/`}}
|
||||
|
||||
<p>
|
||||
If you're reading or writing a lot of pixel data, it can be more efficient, but
|
||||
more complicated, to access these struct type's <code>Pix</code> field directly.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The slice-based <code>Image</code> implementations also provide a
|
||||
<code>SubImage</code> method, which returns an <code>Image</code> backed by the
|
||||
same array. Modifying the pixels of a sub-image will affect the pixels of the
|
||||
original image, analagous to how modifying the contents of a sub-slice
|
||||
<code>s[i0:i1]</code> will affect the contents of the original slice
|
||||
<code>s</code>.
|
||||
</p>
|
||||
|
||||
<img src="image-package-05.png" width="400" height="300">
|
||||
|
||||
{{code "/doc/progs/image_package6.go" `/m0 := image.New/` `/fmt.Println\(m0.Stride/`}}
|
||||
|
||||
<p>
|
||||
For low-level code that works on an image's <code>Pix</code> field, be aware
|
||||
that ranging over <code>Pix</code> can affect pixels outside an image's bounds.
|
||||
In the example above, the pixels covered by <code>m1.Pix</code> are shaded in
|
||||
blue. Higher-level code, such as the <code>At</code> and <code>Set</code>
|
||||
methods or the <a href="/pkg/image/draw/">image/draw package</a>, will clip
|
||||
their operations to the image's bounds.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Image Formats</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The standard package library supports a number of common image formats, such as
|
||||
GIF, JPEG and PNG. If you know the format of a source image file, you can
|
||||
decode from an <a href="/pkg/io/#Reader"><code>io.Reader</code></a> directly.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
import (
|
||||
"image/jpeg"
|
||||
"image/png"
|
||||
"io"
|
||||
)
|
||||
|
||||
// convertJPEGToPNG converts from JPEG to PNG.
|
||||
func convertJPEGToPNG(w io.Writer, r io.Reader) error {
|
||||
img, err := jpeg.Decode(r)
|
||||
if err != nil {
|
||||
return err
|
||||
}
|
||||
return png.Encode(w, img)
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
If you have image data of unknown format, the
|
||||
<a href="/pkg/image/#Decode"><code>image.Decode</code></a> function can detect
|
||||
the format. The set of recognized formats is constructed at run time and is not
|
||||
limited to those in the standard package library. An image format package
|
||||
typically registers its format in an init function, and the main package will
|
||||
"underscore import" such a package solely for the side effect of format
|
||||
registration.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
import (
|
||||
"image"
|
||||
"image/png"
|
||||
"io"
|
||||
|
||||
_ "code.google.com/p/vp8-go/webp"
|
||||
_ "image/jpeg"
|
||||
)
|
||||
|
||||
// convertToPNG converts from any recognized format to PNG.
|
||||
func convertToPNG(w io.Writer, r io.Reader) error {
|
||||
img, _, err := image.Decode(r)
|
||||
if err != nil {
|
||||
return err
|
||||
}
|
||||
return png.Encode(w, img)
|
||||
}
|
||||
</pre>
|
||||
@@ -3,6 +3,5 @@
|
||||
}-->
|
||||
|
||||
<p>
|
||||
See the <a href="/doc/#articles">Documents page</a> and the
|
||||
<a href="/blog/index">Blog index</a> for a complete list of Go articles.
|
||||
See the <a href="/doc/#articles">Documents page</a> for a complete list of Go articles.
|
||||
</p>
|
||||
|
||||
356
doc/articles/json_and_go.html
Normal file
356
doc/articles/json_and_go.html
Normal file
@@ -0,0 +1,356 @@
|
||||
<!--{
|
||||
"Title": "JSON and Go",
|
||||
"Template": true
|
||||
}-->
|
||||
|
||||
<p>
|
||||
JSON (JavaScript Object Notation) is a simple data interchange format.
|
||||
Syntactically it resembles the objects and lists of JavaScript. It is most
|
||||
commonly used for communication between web back-ends and JavaScript programs
|
||||
running in the browser, but it is used in many other places, too. Its home page,
|
||||
<a href="http://json.org">json.org</a>, provides a wonderfully clear and concise
|
||||
definition of the standard.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
With the <a href="/pkg/encoding/json/">json package</a> it's a snap to read and
|
||||
write JSON data from your Go programs.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Encoding</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To encode JSON data we use the
|
||||
<a href="/pkg/encoding/json/#Marshal"><code>Marshal</code></a> function.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
func Marshal(v interface{}) ([]byte, error)
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Given the Go data structure, <code>Message</code>,
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/json1.go" `/type Message/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
and an instance of <code>Message</code>
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/json1.go" `/m :=/`}}
|
||||
|
||||
<p>
|
||||
we can marshal a JSON-encoded version of m using <code>json.Marshal</code>:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/json1.go" `/b, err :=/`}}
|
||||
|
||||
<p>
|
||||
If all is well, <code>err</code> will be <code>nil</code> and <code>b</code>
|
||||
will be a <code>[]byte</code> containing this JSON data:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
b == []byte(`{"Name":"Alice","Body":"Hello","Time":1294706395881547000}`)
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Only data structures that can be represented as valid JSON will be encoded:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
JSON objects only support strings as keys; to encode a Go map type it must be
|
||||
of the form <code>map[string]T</code> (where <code>T</code> is any Go type
|
||||
supported by the json package).
|
||||
</li>
|
||||
<li>
|
||||
Channel, complex, and function types cannot be encoded.
|
||||
</li>
|
||||
<li>
|
||||
Cyclic data structures are not supported; they will cause <code>Marshal</code>
|
||||
to go into an infinite loop.
|
||||
</li>
|
||||
<li>
|
||||
Pointers will be encoded as the values they point to (or 'null' if the pointer
|
||||
is <code>nil</code>).
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
The json package only accesses the exported fields of struct types (those that
|
||||
begin with an uppercase letter). Therefore only the the exported fields of a
|
||||
struct will be present in the JSON output.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Decoding</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To decode JSON data we use the
|
||||
<a href="/pkg/encoding/json/#Unmarshal"><code>Unmarshal</code></a> function.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
func Unmarshal(data []byte, v interface{}) error
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
We must first create a place where the decoded data will be stored
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/json1.go" `/var m Message/`}}
|
||||
|
||||
<p>
|
||||
and call <code>json.Unmarshal</code>, passing it a <code>[]byte</code> of JSON
|
||||
data and a pointer to <code>m</code>
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/json1.go" `/err := json.Unmarshal/`}}
|
||||
|
||||
<p>
|
||||
If <code>b</code> contains valid JSON that fits in <code>m</code>, after the
|
||||
call <code>err</code> will be <code>nil</code> and the data from <code>b</code>
|
||||
will have been stored in the struct <code>m</code>, as if by an assignment
|
||||
like:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/json1.go" `/m = Message/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
How does <code>Unmarshal</code> identify the fields in which to store the
|
||||
decoded data? For a given JSON key <code>"Foo"</code>, <code>Unmarshal</code>
|
||||
will look through the destination struct's fields to find (in order of
|
||||
preference):
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
An exported field with a tag of <code>"Foo"</code> (see the
|
||||
<a href="/ref/spec#Struct_types">Go spec</a> for more on struct tags),
|
||||
</li>
|
||||
<li>
|
||||
An exported field named <code>"Foo"</code>, or
|
||||
</li>
|
||||
<li>
|
||||
An exported field named <code>"FOO"</code> or <code>"FoO"</code> or some other
|
||||
case-insensitive match of <code>"Foo"</code>.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
What happens when the structure of the JSON data doesn't exactly match the Go
|
||||
type?
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/json1.go" `/"Food":"Pickle"/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
<code>Unmarshal</code> will decode only the fields that it can find in the
|
||||
destination type. In this case, only the Name field of m will be populated,
|
||||
and the Food field will be ignored. This behavior is particularly useful when
|
||||
you wish to pick only a few specific fields out of a large JSON blob. It also
|
||||
means that any unexported fields in the destination struct will be unaffected
|
||||
by <code>Unmarshal</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
But what if you don't know the structure of your JSON data beforehand?
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Generic JSON with interface{}</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <code>interface{}</code> (empty interface) type describes an interface with
|
||||
zero methods. Every Go type implements at least zero methods and therefore
|
||||
satisfies the empty interface.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The empty interface serves as a general container type:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/json2.go" `/var i interface{}/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
A type assertion accesses the underlying concrete type:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/json2.go" `/r := i/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
Or, if the underlying type is unknown, a type switch determines the type:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/json2.go" `/switch v/` `/STOP/`}}
|
||||
|
||||
|
||||
The json package uses <code>map[string]interface{}</code> and
|
||||
<code>[]interface{}</code> values to store arbitrary JSON objects and arrays;
|
||||
it will happily unmarshal any valid JSON blob into a plain
|
||||
<code>interface{}</code> value. The default concrete Go types are:
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<code>bool</code> for JSON booleans,
|
||||
</li>
|
||||
<li>
|
||||
<code>float64</code> for JSON numbers,
|
||||
</li>
|
||||
<li>
|
||||
<code>string</code> for JSON strings, and
|
||||
</li>
|
||||
<li>
|
||||
<code>nil</code> for JSON null.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
<b>Decoding arbitrary data</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Consider this JSON data, stored in the variable <code>b</code>:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/json3.go" `/b :=/`}}
|
||||
|
||||
<p>
|
||||
Without knowing this data's structure, we can decode it into an
|
||||
<code>interface{}</code> value with <code>Unmarshal</code>:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/json3.go" `/var f interface/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
At this point the Go value in <code>f</code> would be a map whose keys are
|
||||
strings and whose values are themselves stored as empty interface values:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/json3.go" `/f = map/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
To access this data we can use a type assertion to access <code>f</code>'s
|
||||
underlying <code>map[string]interface{}</code>:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/json3.go" `/m := f/`}}
|
||||
|
||||
<p>
|
||||
We can then iterate through the map with a range statement and use a type switch
|
||||
to access its values as their concrete types:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/json3.go" `/for k, v/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
In this way you can work with unknown JSON data while still enjoying the
|
||||
benefits of type safety.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Reference Types</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Let's define a Go type to contain the data from the previous example:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/json4.go" `/type FamilyMember/` `/STOP/`}}
|
||||
|
||||
{{code "/doc/progs/json4.go" `/var m FamilyMember/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
Unmarshaling that data into a <code>FamilyMember</code> value works as
|
||||
expected, but if we look closely we can see a remarkable thing has happened.
|
||||
With the var statement we allocated a <code>FamilyMember</code> struct, and
|
||||
then provided a pointer to that value to <code>Unmarshal</code>, but at that
|
||||
time the <code>Parents</code> field was a <code>nil</code> slice value. To
|
||||
populate the <code>Parents</code> field, <code>Unmarshal</code> allocated a new
|
||||
slice behind the scenes. This is typical of how <code>Unmarshal</code> works
|
||||
with the supported reference types (pointers, slices, and maps).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Consider unmarshaling into this data structure:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
type Foo struct {
|
||||
Bar *Bar
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
If there were a <code>Bar</code> field in the JSON object,
|
||||
<code>Unmarshal</code> would allocate a new <code>Bar</code> and populate it.
|
||||
If not, <code>Bar</code> would be left as a <code>nil</code> pointer.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
From this a useful pattern arises: if you have an application that receives a
|
||||
few distinct message types, you might define "receiver" structure like
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
type IncomingMessage struct {
|
||||
Cmd *Command
|
||||
Msg *Message
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
and the sending party can populate the <code>Cmd</code> field and/or the
|
||||
<code>Msg</code> field of the top-level JSON object, depending on the type of
|
||||
message they want to communicate. <code>Unmarshal</code>, when decoding the
|
||||
JSON into an <code>IncomingMessage</code> struct, will only allocate the data
|
||||
structures present in the JSON data. To know which messages to process, the
|
||||
programmer need simply test that either <code>Cmd</code> or <code>Msg</code> is
|
||||
not <code>nil</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Streaming Encoders and Decoders</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The json package provides <code>Decoder</code> and <code>Encoder</code> types
|
||||
to support the common operation of reading and writing streams of JSON data.
|
||||
The <code>NewDecoder</code> and <code>NewEncoder</code> functions wrap the
|
||||
<a href="/pkg/io/#Reader"><code>io.Reader</code></a> and
|
||||
<a href="/pkg/io/#Writer"><code>io.Writer</code></a> interface types.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
func NewDecoder(r io.Reader) *Decoder
|
||||
func NewEncoder(w io.Writer) *Encoder
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Here's an example program that reads a series of JSON objects from standard
|
||||
input, removes all but the <code>Name</code> field from each object, and then
|
||||
writes the objects to standard output:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/json5.go" `/package main/` `$`}}
|
||||
|
||||
<p>
|
||||
Due to the ubiquity of Readers and Writers, these <code>Encoder</code> and
|
||||
<code>Decoder</code> types can be used in a broad range of scenarios, such as
|
||||
reading and writing to HTTP connections, WebSockets, or files.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>References</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For more information see the <a href="/pkg/encoding/json/">json package documentation</a>. For an example usage of
|
||||
json see the source files of the <a href="/pkg/net/rpc/jsonrpc/">jsonrpc package</a>.
|
||||
</p>
|
||||
78
doc/articles/json_rpc_tale_of_interfaces.html
Normal file
78
doc/articles/json_rpc_tale_of_interfaces.html
Normal file
@@ -0,0 +1,78 @@
|
||||
<!--{
|
||||
"Title": "JSON-RPC: a tale of interfaces"
|
||||
}-->
|
||||
|
||||
<p>
|
||||
Here we present an example where Go's
|
||||
<a href="/doc/effective_go.html#interfaces_and_types">interfaces</a> made it
|
||||
easy to refactor some existing code to make it more flexible and extensible.
|
||||
Originally, the standard library's <a href="/pkg/net/rpc/">RPC package</a> used
|
||||
a custom wire format called <a href="/pkg/encoding/gob/">gob</a>. For a
|
||||
particular application, we wanted to use <a href="/pkg/encoding/json/">JSON</a>
|
||||
as an alternate wire format.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
We first defined a pair of interfaces to describe the functionality of the
|
||||
existing wire format, one for the client, and one for the server (depicted
|
||||
below).
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
type ServerCodec interface {
|
||||
ReadRequestHeader(*Request) error
|
||||
ReadRequestBody(interface{}) error
|
||||
WriteResponse(*Response, interface{}) error
|
||||
Close() error
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
On the server side, we then changed two internal function signatures to accept
|
||||
the <code>ServerCodec</code> interface instead of our existing
|
||||
<code>gob.Encoder</code>. Here's one of them:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
func sendResponse(sending *sync.Mutex, req *Request,
|
||||
reply interface{}, enc *gob.Encoder, errmsg string)
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
became
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
func sendResponse(sending *sync.Mutex, req *Request,
|
||||
reply interface{}, enc ServerCodec, errmsg string)
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
We then wrote a trivial <code>gobServerCodec</code> wrapper to reproduce the
|
||||
original functionality. From there it is simple to build a
|
||||
<code>jsonServerCodec</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
After some similar changes to the client side, this was the full extent of the
|
||||
work we needed to do on the RPC package. This whole exercise took about 20
|
||||
minutes! After tidying up and testing the new code, the
|
||||
<a href="http://code.google.com/p/go/source/diff?spec=svn9daf796ebf1cae97b2fcf760a4ab682f1f063f29&r=9daf796ebf1cae97b2fcf760a4ab682f1f063f29&format=side&path=/src/pkg/rpc/server.go">final changeset</a>
|
||||
was submitted.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In an inheritance-oriented language like Java or C++, the obvious path would be
|
||||
to generalize the RPC class, and create JsonRPC and GobRPC subclasses. However,
|
||||
this approach becomes tricky if you want to make a further generalization
|
||||
orthogonal to that hierarchy. (For example, if you were to implement an
|
||||
alternate RPC standard). In our Go package, we took a route that is both
|
||||
conceptually simpler and requires less code be written or changed.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A vital quality for any codebase is maintainability. As needs change, it is
|
||||
essential to adapt your code easily and cleanly, lest it become unwieldy to work
|
||||
with. We believe Go's lightweight, composition-oriented type system provides a
|
||||
means of structuring code that scales.
|
||||
</p>
|
||||
649
doc/articles/laws_of_reflection.html
Normal file
649
doc/articles/laws_of_reflection.html
Normal file
@@ -0,0 +1,649 @@
|
||||
<!--{
|
||||
"Title": "The Laws of Reflection",
|
||||
"Template": true
|
||||
}-->
|
||||
|
||||
<p>
|
||||
Reflection in computing is the
|
||||
ability of a program to examine its own structure, particularly
|
||||
through types; it's a form of metaprogramming. It's also a great
|
||||
source of confusion.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In this article we attempt to clarify things by explaining how
|
||||
reflection works in Go. Each language's reflection model is
|
||||
different (and many languages don't support it at all), but
|
||||
this article is about Go, so for the rest of this article the word
|
||||
"reflection" should be taken to mean "reflection in Go".
|
||||
</p>
|
||||
|
||||
<p><b>Types and interfaces</b></p>
|
||||
|
||||
<p>
|
||||
Because reflection builds on the type system, let's start with a
|
||||
refresher about types in Go.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Go is statically typed. Every variable has a static type, that is,
|
||||
exactly one type known and fixed at compile time: <code>int</code>,
|
||||
<code>float32</code>, <code>*MyType</code>, <code>[]byte</code>,
|
||||
and so on. If we declare
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/interface.go" `/type MyInt/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
then <code>i</code> has type <code>int</code> and <code>j</code>
|
||||
has type <code>MyInt</code>. The variables <code>i</code> and
|
||||
<code>j</code> have distinct static types and, although they have
|
||||
the same underlying type, they cannot be assigned to one another
|
||||
without a conversion.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
One important category of type is interface types, which represent
|
||||
fixed sets of methods. An interface variable can store any concrete
|
||||
(non-interface) value as long as that value implements the
|
||||
interface's methods. A well-known pair of examples is
|
||||
<code>io.Reader</code> and <code>io.Writer</code>, the types
|
||||
<code>Reader</code> and <code>Writer</code> from the
|
||||
<a href="/pkg/io/">io package</a>:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/interface.go" `/// Reader/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
Any type that implements a <code>Read</code> (or
|
||||
<code>Write</code>) method with this signature is said to implement
|
||||
<code>io.Reader</code> (or <code>io.Writer</code>). For the
|
||||
purposes of this discussion, that means that a variable of type
|
||||
<code>io.Reader</code> can hold any value whose type has a
|
||||
<code>Read</code> method:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/interface.go" `/func readers/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
It's important to be clear that whatever concrete value
|
||||
<code>r</code> may hold, <code>r</code>'s type is always
|
||||
<code>io.Reader</code>: Go is statically typed and the static type
|
||||
of <code>r</code> is <code>io.Reader</code>.</p>
|
||||
|
||||
<p>
|
||||
An extremely important example of an interface type is the empty
|
||||
interface:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
interface{}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
It represents the empty set of methods and is satisfied by any
|
||||
value at all, since any value has zero or more methods.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Some people say that Go's interfaces are dynamically typed, but
|
||||
that is misleading. They are statically typed: a variable of
|
||||
interface type always has the same static type, and even though at
|
||||
run time the value stored in the interface variable may change
|
||||
type, that value will always satisfy the interface.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
We need to be precise about all this because reflection and
|
||||
interfaces are closely related.
|
||||
</p>
|
||||
|
||||
<p><b>The representation of an interface</b></p>
|
||||
|
||||
<p>
|
||||
Russ Cox has written a
|
||||
<a href="http://research.swtch.com/2009/12/go-data-structures-interfaces.html">detailed blog post</a>
|
||||
about the representation of interface values in Go. It's not necessary to
|
||||
repeat the full story here, but a simplified summary is in order.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A variable of interface type stores a pair: the concrete value
|
||||
assigned to the variable, and that value's type descriptor.
|
||||
To be more precise, the value is the underlying concrete data item
|
||||
that implements the interface and the type describes the full type
|
||||
of that item. For instance, after
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/interface.go" `/func typeAssertions/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
<code>r</code> contains, schematically, the (value, type) pair,
|
||||
(<code>tty</code>, <code>*os.File</code>). Notice that the type
|
||||
<code>*os.File</code> implements methods other than
|
||||
<code>Read</code>; even though the interface value provides access
|
||||
only to the <code>Read</code> method, the value inside carries all
|
||||
the type information about that value. That's why we can do things
|
||||
like this:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/interface.go" `/var w io.Writer/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
The expression in this assignment is a type assertion; what it
|
||||
asserts is that the item inside <code>r</code> also implements
|
||||
<code>io.Writer</code>, and so we can assign it to <code>w</code>.
|
||||
After the assignment, <code>w</code> will contain the pair
|
||||
(<code>tty</code>, <code>*os.File</code>). That's the same pair as
|
||||
was held in <code>r</code>. The static type of the interface
|
||||
determines what methods may be invoked with an interface variable,
|
||||
even though the concrete value inside may have a larger set of
|
||||
methods.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Continuing, we can do this:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/interface.go" `/var empty interface{}/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
and our empty interface value <code>e</code> will again contain
|
||||
that same pair, (<code>tty</code>, <code>*os.File</code>). That's
|
||||
handy: an empty interface can hold any value and contains all the
|
||||
information we could ever need about that value.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
(We don't need a type assertion here because it's known statically
|
||||
that <code>w</code> satisfies the empty interface. In the example
|
||||
where we moved a value from a <code>Reader</code> to a
|
||||
<code>Writer</code>, we needed to be explicit and use a type
|
||||
assertion because <code>Writer</code>'s methods are not a
|
||||
subset of <code>Reader</code>'s.)
|
||||
</p>
|
||||
|
||||
<p>
|
||||
One important detail is that the pair inside an interface always
|
||||
has the form (value, concrete type) and cannot have the form
|
||||
(value, interface type). Interfaces do not hold interface
|
||||
values.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Now we're ready to reflect.
|
||||
</p>
|
||||
|
||||
<p><b>The first law of reflection</b></p>
|
||||
|
||||
<p><b>1. Reflection goes from interface value to reflection object.</b></p>
|
||||
|
||||
<p>
|
||||
At the basic level, reflection is just a mechanism to examine the
|
||||
type and value pair stored inside an interface variable. To get
|
||||
started, there are two types we need to know about in
|
||||
<a href="/pkg/reflect/">package reflect</a>:
|
||||
<a href="/pkg/reflect/#Type">Type</a> and
|
||||
<a href="/pkg/reflect/#Value">Value</a>. Those two types
|
||||
give access to the contents of an interface variable, and two
|
||||
simple functions, called <code>reflect.TypeOf</code> and
|
||||
<code>reflect.ValueOf</code>, retrieve <code>reflect.Type</code>
|
||||
and <code>reflect.Value</code> pieces out of an interface value.
|
||||
(Also, from the <code>reflect.Value</code> it's easy to get
|
||||
to the <code>reflect.Type</code>, but let's keep the
|
||||
<code>Value</code> and <code>Type</code> concepts separate for
|
||||
now.)
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Let's start with <code>TypeOf</code>:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/interface2.go" `/package main/` `/STOP main/`}}
|
||||
|
||||
<p>
|
||||
This program prints
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
type: float64
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
You might be wondering where the interface is here, since the program looks
|
||||
like it's passing the <code>float64</code> variable <code>x</code>, not an
|
||||
interface value, to <code>reflect.TypeOf</code>. But it's there; as
|
||||
<a href="/pkg/reflect/#Type.TypeOf">godoc reports</a>, the signature of
|
||||
<code>reflect.TypeOf</code> includes an empty interface:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
// TypeOf returns the reflection Type of the value in the interface{}.
|
||||
func TypeOf(i interface{}) Type
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
When we call <code>reflect.TypeOf(x)</code>, <code>x</code> is
|
||||
first stored in an empty interface, which is then passed as the
|
||||
argument; <code>reflect.TypeOf</code> unpacks that empty interface
|
||||
to recover the type information.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <code>reflect.ValueOf</code> function, of course, recovers the
|
||||
value (from here on we'll elide the boilerplate and focus just on
|
||||
the executable code):
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/interface2.go" `/START f9/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
prints
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
value: <float64 Value>
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Both <code>reflect.Type</code> and <code>reflect.Value</code> have
|
||||
lots of methods to let us examine and manipulate them. One
|
||||
important example is that <code>Value</code> has a
|
||||
<code>Type</code> method that returns the <code>Type</code> of a
|
||||
<code>reflect.Value</code>. Another is that both <code>Type</code>
|
||||
and <code>Value</code> have a <code>Kind</code> method that returns
|
||||
a constant indicating what sort of item is stored:
|
||||
<code>Uint</code>, <code>Float64</code>, <code>Slice</code>, and so
|
||||
on. Also methods on <code>Value</code> with names like
|
||||
<code>Int</code> and <code>Float</code> let us grab values (as
|
||||
<code>int64</code> and <code>float64</code>) stored inside:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/interface2.go" `/START f1/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
prints
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
type: float64
|
||||
kind is float64: true
|
||||
value: 3.4
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
There are also methods like <code>SetInt</code> and
|
||||
<code>SetFloat</code> but to use them we need to understand
|
||||
settability, the subject of the third law of reflection, discussed
|
||||
below.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The reflection library has a couple of properties worth singling
|
||||
out. First, to keep the API simple, the "getter" and "setter"
|
||||
methods of <code>Value</code> operate on the largest type that can
|
||||
hold the value: <code>int64</code> for all the signed integers, for
|
||||
instance. That is, the <code>Int</code> method of
|
||||
<code>Value</code> returns an <code>int64</code> and the
|
||||
<code>SetInt</code> value takes an <code>int64</code>; it may be
|
||||
necessary to convert to the actual type involved:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/interface2.go" `/START f2/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
The second property is that the <code>Kind</code> of a reflection
|
||||
object describes the underlying type, not the static type. If a
|
||||
reflection object contains a value of a user-defined integer type,
|
||||
as in
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/interface2.go" `/START f3/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
the <code>Kind</code> of <code>v</code> is still
|
||||
<code>reflect.Int</code>, even though the static type of
|
||||
<code>x</code> is <code>MyInt</code>, not <code>int</code>. In
|
||||
other words, the <code>Kind</code> cannot discriminate an int from
|
||||
a <code>MyInt</code> even though the <code>Type</code> can.
|
||||
</p>
|
||||
|
||||
<p><b>The second law of reflection</b></p>
|
||||
|
||||
<p><b>2. Reflection goes from reflection object to interface
|
||||
value.</b></p>
|
||||
|
||||
<p>
|
||||
Like physical reflection, reflection in Go generates its own
|
||||
inverse.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Given a <code>reflect.Value</code> we can recover an interface
|
||||
value using the <code>Interface</code> method; in effect the method
|
||||
packs the type and value information back into an interface
|
||||
representation and returns the result:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
// Interface returns v's value as an interface{}.
|
||||
func (v Value) Interface() interface{}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
As a consequence we can say
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/interface2.go" `/START f3b/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
to print the <code>float64</code> value represented by the
|
||||
reflection object <code>v</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
We can do even better, though. The arguments to
|
||||
<code>fmt.Println</code>, <code>fmt.Printf</code> and so on are all
|
||||
passed as empty interface values, which are then unpacked by the
|
||||
<code>fmt</code> package internally just as we have been doing in
|
||||
the previous examples. Therefore all it takes to print the contents
|
||||
of a <code>reflect.Value</code> correctly is to pass the result of
|
||||
the <code>Interface</code> method to the formatted print
|
||||
routine:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/interface2.go" `/START f3c/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
(Why not <code>fmt.Println(v)</code>? Because <code>v</code> is a
|
||||
<code>reflect.Value</code>; we want the concrete value it holds.)
|
||||
Since our value is a <code>float64</code>, we can even use a
|
||||
floating-point format if we want:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/interface2.go" `/START f3d/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
and get in this case
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
3.4e+00
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Again, there's no need to type-assert the result of
|
||||
<code>v.Interface()</code> to <code>float64</code>; the empty
|
||||
interface value has the concrete value's type information inside
|
||||
and <code>Printf</code> will recover it.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In short, the <code>Interface</code> method is the inverse of the
|
||||
<code>ValueOf</code> function, except that its result is always of
|
||||
static type <code>interface{}</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Reiterating: Reflection goes from interface values to reflection
|
||||
objects and back again.
|
||||
</p>
|
||||
|
||||
<p><b>The third law of reflection</b></p>
|
||||
|
||||
<p><b>3. To modify a reflection object, the value must be settable.</b></p>
|
||||
|
||||
<p>
|
||||
The third law is the most subtle and confusing, but it's easy
|
||||
enough to understand if we start from first principles.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Here is some code that does not work, but is worth studying.
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/interface2.go" `/START f4/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
If you run this code, it will panic with the cryptic message
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
panic: reflect.Value.SetFloat using unaddressable value
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The problem is not that the value <code>7.1</code> is not
|
||||
addressable; it's that <code>v</code> is not settable. Settability
|
||||
is a property of a reflection <code>Value</code>, and not all
|
||||
reflection <code>Values</code> have it.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <code>CanSet</code> method of <code>Value</code> reports the
|
||||
settability of a <code>Value</code>; in our case,
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/interface2.go" `/START f5/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
prints
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
settability of v: false
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
It is an error to call a <code>Set</code> method on an non-settable
|
||||
<code>Value</code>. But what is settability?
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Settability is a bit like addressability, but stricter. It's the
|
||||
property that a reflection object can modify the actual storage
|
||||
that was used to create the reflection object. Settability is
|
||||
determined by whether the reflection object holds the original
|
||||
item. When we say
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/interface2.go" `/START f6/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
we pass a <em>copy</em> of <code>x</code> to
|
||||
<code>reflect.ValueOf</code>, so the interface value created as the
|
||||
argument to <code>reflect.ValueOf</code> is a <em>copy</em> of
|
||||
<code>x</code>, not <code>x</code> itself. Thus, if the
|
||||
statement
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/interface2.go" `/START f6b/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
were allowed to succeed, it would not update <code>x</code>, even
|
||||
though <code>v</code> looks like it was created from
|
||||
<code>x</code>. Instead, it would update the copy of <code>x</code>
|
||||
stored inside the reflection value and <code>x</code> itself would
|
||||
be unaffected. That would be confusing and useless, so it is
|
||||
illegal, and settability is the property used to avoid this
|
||||
issue.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If this seems bizarre, it's not. It's actually a familiar situation
|
||||
in unusual garb. Think of passing <code>x</code> to a
|
||||
function:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
f(x)
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
We would not expect <code>f</code> to be able to modify
|
||||
<code>x</code> because we passed a copy of <code>x</code>'s value,
|
||||
not <code>x</code> itself. If we want <code>f</code> to modify
|
||||
<code>x</code> directly we must pass our function the address of
|
||||
<code>x</code> (that is, a pointer to <code>x</code>):</p>
|
||||
|
||||
<p>
|
||||
<code>f(&x)</code>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
This is straightforward and familiar, and reflection works the same
|
||||
way. If we want to modify <code>x</code> by reflection, we must
|
||||
give the reflection library a pointer to the value we want to
|
||||
modify.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Let's do that. First we initialize <code>x</code> as usual
|
||||
and then create a reflection value that points to it, called
|
||||
<code>p</code>.
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/interface2.go" `/START f7/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
The output so far is
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
type of p: *float64
|
||||
settability of p: false
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The reflection object <code>p</code> isn't settable, but it's not
|
||||
<code>p</code> we want to set, it's (in effect) <code>*p</code>. To
|
||||
get to what <code>p</code> points to, we call the <code>Elem</code>
|
||||
method of <code>Value</code>, which indirects through the pointer,
|
||||
and save the result in a reflection <code>Value</code> called
|
||||
<code>v</code>:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/interface2.go" `/START f7b/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
Now <code>v</code> is a settable reflection object, as the output
|
||||
demonstrates,
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
settability of v: true
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
and since it represents <code>x</code>, we are finally able to use
|
||||
<code>v.SetFloat</code> to modify the value of
|
||||
<code>x</code>:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/interface2.go" `/START f7c/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
The output, as expected, is
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
7.1
|
||||
7.1
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Reflection can be hard to understand but it's doing exactly what
|
||||
the language does, albeit through reflection <code>Types</code> and
|
||||
<code>Values</code> that can disguise what's going on. Just keep in
|
||||
mind that reflection Values need the address of something in order
|
||||
to modify what they represent.
|
||||
</p>
|
||||
|
||||
<p><b>Structs</b></p>
|
||||
|
||||
<p>
|
||||
In our previous example <code>v</code> wasn't a pointer itself, it
|
||||
was just derived from one. A common way for this situation to arise
|
||||
is when using reflection to modify the fields of a structure. As
|
||||
long as we have the address of the structure, we can modify its
|
||||
fields.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Here's a simple example that analyzes a struct value, <code>t</code>. We create
|
||||
the reflection object with the address of the struct because we'll want to
|
||||
modify it later. Then we set <code>typeOfT</code> to its type and iterate over
|
||||
the fields using straightforward method calls
|
||||
(see <a href="/pkg/reflect/">package reflect</a> for details).
|
||||
Note that we extract the names of the fields from the struct type, but the
|
||||
fields themselves are regular <code>reflect.Value</code> objects.
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/interface2.go" `/START f8/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
The output of this program is
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
0: A int = 23
|
||||
1: B string = skidoo
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
There's one more point about settability introduced in
|
||||
passing here: the field names of <code>T</code> are upper case
|
||||
(exported) because only exported fields of a struct are
|
||||
settable.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Because <code>s</code> contains a settable reflection object, we
|
||||
can modify the fields of the structure.
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/interface2.go" `/START f8b/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
And here's the result:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
t is now {77 Sunset Strip}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
If we modified the program so that <code>s</code> was created from
|
||||
<code>t</code>, not <code>&t</code>, the calls to
|
||||
<code>SetInt</code> and <code>SetString</code> would fail as the
|
||||
fields of <code>t</code> would not be settable.
|
||||
</p>
|
||||
|
||||
<p><b>Conclusion</b></p>
|
||||
|
||||
<p>
|
||||
Here again are the laws of reflection:
|
||||
</p>
|
||||
|
||||
<ol>
|
||||
<li>Reflection goes from interface value to reflection
|
||||
object.</li>
|
||||
<li>Reflection goes from reflection object to interface
|
||||
value.</li>
|
||||
<li>To modify a reflection object, the value must be settable.</li>
|
||||
</ol>
|
||||
|
||||
<p>
|
||||
Once you understand these laws reflection in Go becomes much easier
|
||||
to use, although it remains subtle. It's a powerful tool that
|
||||
should be used with care and avoided unless strictly
|
||||
necessary.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
There's plenty more to reflection that we haven't covered —
|
||||
sending and receiving on channels, allocating memory, using slices
|
||||
and maps, calling methods and functions — but this post is
|
||||
long enough. We'll cover some of those topics in a later
|
||||
article.
|
||||
</p>
|
||||
@@ -1,389 +0,0 @@
|
||||
<!--{
|
||||
"Title": "Data Race Detector",
|
||||
"Template": true
|
||||
}-->
|
||||
|
||||
<h2 id="Introduction">Introduction</h2>
|
||||
|
||||
<p>
|
||||
Data races are among the most common and hardest to debug types of bugs in concurrent systems.
|
||||
A data race occurs when two goroutines access the same variable concurrently and at least one of the accesses is a write.
|
||||
See the <a href="/ref/mem/">The Go Memory Model</a> for details.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Here is an example of a data race that can lead to crashes and memory corruption:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
func main() {
|
||||
c := make(chan bool)
|
||||
m := make(map[string]string)
|
||||
go func() {
|
||||
m["1"] = "a" // First conflicting access.
|
||||
c <- true
|
||||
}()
|
||||
m["2"] = "b" // Second conflicting access.
|
||||
<-c
|
||||
for k, v := range m {
|
||||
fmt.Println(k, v)
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
|
||||
<h2 id="Usage">Usage</h2>
|
||||
|
||||
<p>
|
||||
To help diagnose such bugs, Go includes a built-in data race detector.
|
||||
To use it, add the <code>-race</code> flag to the go command:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ go test -race mypkg // to test the package
|
||||
$ go run -race mysrc.go // to run the source file
|
||||
$ go build -race mycmd // to build the command
|
||||
$ go install -race mypkg // to install the package
|
||||
</pre>
|
||||
|
||||
<h2 id="Report_Format">Report Format</h2>
|
||||
|
||||
<p>
|
||||
When the race detector finds a data race in the program, it prints a report.
|
||||
The report contains stack traces for conflicting accesses, as well as stacks where the involved goroutines were created.
|
||||
Here is an example:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
WARNING: DATA RACE
|
||||
Read by goroutine 185:
|
||||
net.(*pollServer).AddFD()
|
||||
src/net/fd_unix.go:89 +0x398
|
||||
net.(*pollServer).WaitWrite()
|
||||
src/net/fd_unix.go:247 +0x45
|
||||
net.(*netFD).Write()
|
||||
src/net/fd_unix.go:540 +0x4d4
|
||||
net.(*conn).Write()
|
||||
src/net/net.go:129 +0x101
|
||||
net.func·060()
|
||||
src/net/timeout_test.go:603 +0xaf
|
||||
|
||||
Previous write by goroutine 184:
|
||||
net.setWriteDeadline()
|
||||
src/net/sockopt_posix.go:135 +0xdf
|
||||
net.setDeadline()
|
||||
src/net/sockopt_posix.go:144 +0x9c
|
||||
net.(*conn).SetDeadline()
|
||||
src/net/net.go:161 +0xe3
|
||||
net.func·061()
|
||||
src/net/timeout_test.go:616 +0x3ed
|
||||
|
||||
Goroutine 185 (running) created at:
|
||||
net.func·061()
|
||||
src/net/timeout_test.go:609 +0x288
|
||||
|
||||
Goroutine 184 (running) created at:
|
||||
net.TestProlongTimeout()
|
||||
src/net/timeout_test.go:618 +0x298
|
||||
testing.tRunner()
|
||||
src/testing/testing.go:301 +0xe8
|
||||
</pre>
|
||||
|
||||
<h2 id="Options">Options</h2>
|
||||
|
||||
<p>
|
||||
The <code>GORACE</code> environment variable sets race detector options.
|
||||
The format is:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
GORACE="option1=val1 option2=val2"
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The options are:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<code>log_path</code> (default <code>stderr</code>): The race detector writes
|
||||
its report to a file named <code>log_path.<em>pid</em></code>.
|
||||
The special names <code>stdout</code>
|
||||
and <code>stderr</code> cause reports to be written to standard output and
|
||||
standard error, respectively.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<code>exitcode</code> (default <code>66</code>): The exit status to use when
|
||||
exiting after a detected race.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<code>strip_path_prefix</code> (default <code>""</code>): Strip this prefix
|
||||
from all reported file paths, to make reports more concise.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<code>history_size</code> (default <code>1</code>): The per-goroutine memory
|
||||
access history is <code>32K * 2**history_size elements</code>.
|
||||
Increasing this value can avoid a "failed to restore the stack" error in reports, at the
|
||||
cost of increased memory usage.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<code>halt_on_error</code> (default <code>0</code>): Controls whether the program
|
||||
exits after reporting first data race.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Example:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ GORACE="log_path=/tmp/race/report strip_path_prefix=/my/go/sources/" go test -race
|
||||
</pre>
|
||||
|
||||
<h2 id="Excluding_Tests">Excluding Tests</h2>
|
||||
|
||||
<p>
|
||||
When you build with <code>-race</code> flag, the <code>go</code> command defines additional
|
||||
<a href="/pkg/go/build/#hdr-Build_Constraints">build tag</a> <code>race</code>.
|
||||
You can use the tag to exclude some code and tests when running the race detector.
|
||||
Some examples:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
// +build !race
|
||||
|
||||
package foo
|
||||
|
||||
// The test contains a data race. See issue 123.
|
||||
func TestFoo(t *testing.T) {
|
||||
// ...
|
||||
}
|
||||
|
||||
// The test fails under the race detector due to timeouts.
|
||||
func TestBar(t *testing.T) {
|
||||
// ...
|
||||
}
|
||||
|
||||
// The test takes too long under the race detector.
|
||||
func TestBaz(t *testing.T) {
|
||||
// ...
|
||||
}
|
||||
</pre>
|
||||
|
||||
<h2 id="How_To_Use">How To Use</h2>
|
||||
|
||||
<p>
|
||||
To start, run your tests using the race detector (<code>go test -race</code>).
|
||||
The race detector only finds races that happen at runtime, so it can't find
|
||||
races in code paths that are not executed.
|
||||
If your tests have incomplete coverage,
|
||||
you may find more races by running a binary built with <code>-race</code> under a realistic
|
||||
workload.
|
||||
</p>
|
||||
|
||||
<h2 id="Typical_Data_Races">Typical Data Races</h2>
|
||||
|
||||
<p>
|
||||
Here are some typical data races. All of them can be detected with the race detector.
|
||||
</p>
|
||||
|
||||
<h3 id="Race_on_loop_counter">Race on loop counter</h3>
|
||||
|
||||
<pre>
|
||||
func main() {
|
||||
var wg sync.WaitGroup
|
||||
wg.Add(5)
|
||||
for i := 0; i < 5; i++ {
|
||||
go func() {
|
||||
fmt.Println(i) // Not the 'i' you are looking for.
|
||||
wg.Done()
|
||||
}()
|
||||
}
|
||||
wg.Wait()
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The variable <code>i</code> in the function literal is the same variable used by the loop, so
|
||||
the read in the goroutine races with the loop increment.
|
||||
(This program typically prints 55555, not 01234.)
|
||||
The program can be fixed by making a copy of the variable:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
func main() {
|
||||
var wg sync.WaitGroup
|
||||
wg.Add(5)
|
||||
for i := 0; i < 5; i++ {
|
||||
go func(j int) {
|
||||
fmt.Println(j) // Good. Read local copy of the loop counter.
|
||||
wg.Done()
|
||||
}(i)
|
||||
}
|
||||
wg.Wait()
|
||||
}
|
||||
</pre>
|
||||
|
||||
<h3 id="Accidentally_shared_variable">Accidentally shared variable</h3>
|
||||
|
||||
<pre>
|
||||
// ParallelWrite writes data to file1 and file2, returns the errors.
|
||||
func ParallelWrite(data []byte) chan error {
|
||||
res := make(chan error, 2)
|
||||
f1, err := os.Create("file1")
|
||||
if err != nil {
|
||||
res <- err
|
||||
} else {
|
||||
go func() {
|
||||
// This err is shared with the main goroutine,
|
||||
// so the write races with the write below.
|
||||
_, err = f1.Write(data)
|
||||
res <- err
|
||||
f1.Close()
|
||||
}()
|
||||
}
|
||||
f2, err := os.Create("file2") // The second conflicting write to err.
|
||||
if err != nil {
|
||||
res <- err
|
||||
} else {
|
||||
go func() {
|
||||
_, err = f2.Write(data)
|
||||
res <- err
|
||||
f2.Close()
|
||||
}()
|
||||
}
|
||||
return res
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The fix is to introduce new variables in the goroutines (note the use of <code>:=</code>):
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
...
|
||||
_, err := f1.Write(data)
|
||||
...
|
||||
_, err := f2.Write(data)
|
||||
...
|
||||
</pre>
|
||||
|
||||
<h3 id="Unprotected_global_variable">Unprotected global variable</h3>
|
||||
|
||||
<p>
|
||||
If the following code is called from several goroutines, it leads to races on the <code>service</code> map.
|
||||
Concurrent reads and writes of the same map are not safe:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
var service map[string]net.Addr
|
||||
|
||||
func RegisterService(name string, addr net.Addr) {
|
||||
service[name] = addr
|
||||
}
|
||||
|
||||
func LookupService(name string) net.Addr {
|
||||
return service[name]
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
To make the code safe, protect the accesses with a mutex:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
var (
|
||||
service map[string]net.Addr
|
||||
serviceMu sync.Mutex
|
||||
)
|
||||
|
||||
func RegisterService(name string, addr net.Addr) {
|
||||
serviceMu.Lock()
|
||||
defer serviceMu.Unlock()
|
||||
service[name] = addr
|
||||
}
|
||||
|
||||
func LookupService(name string) net.Addr {
|
||||
serviceMu.Lock()
|
||||
defer serviceMu.Unlock()
|
||||
return service[name]
|
||||
}
|
||||
</pre>
|
||||
|
||||
<h3 id="Primitive_unprotected_variable">Primitive unprotected variable</h3>
|
||||
|
||||
<p>
|
||||
Data races can happen on variables of primitive types as well (<code>bool</code>, <code>int</code>, <code>int64</code>, etc.),
|
||||
as in this example:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
type Watchdog struct{ last int64 }
|
||||
|
||||
func (w *Watchdog) KeepAlive() {
|
||||
w.last = time.Now().UnixNano() // First conflicting access.
|
||||
}
|
||||
|
||||
func (w *Watchdog) Start() {
|
||||
go func() {
|
||||
for {
|
||||
time.Sleep(time.Second)
|
||||
// Second conflicting access.
|
||||
if w.last < time.Now().Add(-10*time.Second).UnixNano() {
|
||||
fmt.Println("No keepalives for 10 seconds. Dying.")
|
||||
os.Exit(1)
|
||||
}
|
||||
}
|
||||
}()
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Even such "innocent" data races can lead to hard-to-debug problems caused by
|
||||
non-atomicity of the memory accesses,
|
||||
interference with compiler optimizations,
|
||||
or reordering issues accessing processor memory .
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A typical fix for this race is to use a channel or a mutex.
|
||||
To preserve the lock-free behavior, one can also use the
|
||||
<a href="/pkg/sync/atomic/"><code>sync/atomic</code></a> package.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
type Watchdog struct{ last int64 }
|
||||
|
||||
func (w *Watchdog) KeepAlive() {
|
||||
atomic.StoreInt64(&w.last, time.Now().UnixNano())
|
||||
}
|
||||
|
||||
func (w *Watchdog) Start() {
|
||||
go func() {
|
||||
for {
|
||||
time.Sleep(time.Second)
|
||||
if atomic.LoadInt64(&w.last) < time.Now().Add(-10*time.Second).UnixNano() {
|
||||
fmt.Println("No keepalives for 10 seconds. Dying.")
|
||||
os.Exit(1)
|
||||
}
|
||||
}
|
||||
}()
|
||||
}
|
||||
</pre>
|
||||
|
||||
<h2 id="Supported_Systems">Supported Systems</h2>
|
||||
|
||||
<p>
|
||||
The race detector runs on <code>darwin/amd64</code>, <code>freebsd/amd64</code>,
|
||||
<code>linux/amd64</code>, and <code>windows/amd64</code>.
|
||||
</p>
|
||||
|
||||
<h2 id="Runtime_Overheads">Runtime Overhead</h2>
|
||||
|
||||
<p>
|
||||
The cost of race detection varies by program, but for a typical program, memory
|
||||
usage may increase by 5-10x and execution time by 2-20x.
|
||||
</p>
|
||||
BIN
doc/articles/slice-1.png
Normal file
BIN
doc/articles/slice-1.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 6.2 KiB |
BIN
doc/articles/slice-2.png
Normal file
BIN
doc/articles/slice-2.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 7.1 KiB |
BIN
doc/articles/slice-3.png
Normal file
BIN
doc/articles/slice-3.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 7.1 KiB |
BIN
doc/articles/slice-array.png
Normal file
BIN
doc/articles/slice-array.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.2 KiB |
BIN
doc/articles/slice-struct.png
Normal file
BIN
doc/articles/slice-struct.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 3.6 KiB |
438
doc/articles/slices_usage_and_internals.html
Normal file
438
doc/articles/slices_usage_and_internals.html
Normal file
@@ -0,0 +1,438 @@
|
||||
<!--{
|
||||
"Title": "Slices: usage and internals",
|
||||
"Template": true
|
||||
}-->
|
||||
|
||||
<p>
|
||||
Go's slice type provides a convenient and efficient means of working with
|
||||
sequences of typed data. Slices are analogous to arrays in other languages, but
|
||||
have some unusual properties. This article will look at what slices are and how
|
||||
they are used.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Arrays</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The slice type is an abstraction built on top of Go's array type, and so to
|
||||
understand slices we must first understand arrays.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
An array type definition specifies a length and an element type. For example,
|
||||
the type <code>[4]int</code> represents an array of four integers. An array's
|
||||
size is fixed; its length is part of its type (<code>[4]int</code> and
|
||||
<code>[5]int</code> are distinct, incompatible types). Arrays can be indexed in
|
||||
the usual way, so the expression <code>s[n]</code> accesses the <i>n</i>th
|
||||
element:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
var a [4]int
|
||||
a[0] = 1
|
||||
i := a[0]
|
||||
// i == 1
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Arrays do not need to be initialized explicitly; the zero value of an array is
|
||||
a ready-to-use array whose elements are themselves zeroed:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
// a[2] == 0, the zero value of the int type
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The in-memory representation of <code>[4]int</code> is just four integer values laid out sequentially:
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<img src="slice-array.png">
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Go's arrays are values. An array variable denotes the entire array; it is not a
|
||||
pointer to the first array element (as would be the case in C). This means
|
||||
that when you assign or pass around an array value you will make a copy of its
|
||||
contents. (To avoid the copy you could pass a <i>pointer</i> to the array, but
|
||||
then that's a pointer to an array, not an array.) One way to think about arrays
|
||||
is as a sort of struct but with indexed rather than named fields: a fixed-size
|
||||
composite value.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
An array literal can be specified like so:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
b := [2]string{"Penn", "Teller"}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Or, you can have the compiler count the array elements for you:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
b := [...]string{"Penn", "Teller"}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
In both cases, the type of <code>b</code> is <code>[2]string</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Slices</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Arrays have their place, but they're a bit inflexible, so you don't see them
|
||||
too often in Go code. Slices, though, are everywhere. They build on arrays to
|
||||
provide great power and convenience.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The type specification for a slice is <code>[]T</code>, where <code>T</code> is
|
||||
the type of the elements of the slice. Unlike an array type, a slice type has
|
||||
no specified length.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A slice literal is declared just like an array literal, except you leave out
|
||||
the element count:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
letters := []string{"a", "b", "c", "d"}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
A slice can be created with the built-in function called <code>make</code>,
|
||||
which has the signature,
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
func make([]T, len, cap) []T
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
where T stands for the element type of the slice to be created. The
|
||||
<code>make</code> function takes a type, a length, and an optional capacity.
|
||||
When called, <code>make</code> allocates an array and returns a slice that
|
||||
refers to that array.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
var s []byte
|
||||
s = make([]byte, 5, 5)
|
||||
// s == []byte{0, 0, 0, 0, 0}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
When the capacity argument is omitted, it defaults to the specified length.
|
||||
Here's a more succinct version of the same code:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
s := make([]byte, 5)
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The length and capacity of a slice can be inspected using the built-in
|
||||
<code>len</code> and <code>cap</code> functions.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
len(s) == 5
|
||||
cap(s) == 5
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The next two sections discuss the relationship between length and capacity.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The zero value of a slice is <code>nil</code>. The <code>len</code> and
|
||||
<code>cap</code> functions will both return 0 for a nil slice.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A slice can also be formed by "slicing" an existing slice or array. Slicing is
|
||||
done by specifying a half-open range with two indices separated by a colon. For
|
||||
example, the expression <code>b[1:4]</code> creates a slice including elements
|
||||
1 through 3 of <code>b</code> (the indices of the resulting slice will be 0
|
||||
through 2).
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
b := []byte{'g', 'o', 'l', 'a', 'n', 'g'}
|
||||
// b[1:4] == []byte{'o', 'l', 'a'}, sharing the same storage as b
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The start and end indices of a slice expression are optional; they default to zero and the slice's length respectively:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
// b[:2] == []byte{'g', 'o'}
|
||||
// b[2:] == []byte{'l', 'a', 'n', 'g'}
|
||||
// b[:] == b
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
This is also the syntax to create a slice given an array:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
x := [3]string{"Лайка", "Белка", "Стрелка"}
|
||||
s := x[:] // a slice referencing the storage of x
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
<b>Slice internals</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A slice is a descriptor of an array segment. It consists of a pointer to the
|
||||
array, the length of the segment, and its capacity (the maximum length of the
|
||||
segment).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<img src="slice-struct.png">
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Our variable <code>s</code>, created earlier by <code>make([]byte, 5)</code>,
|
||||
is structured like this:
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<img src="slice-1.png">
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The length is the number of elements referred to by the slice. The capacity is
|
||||
the number of elements in the underlying array (beginning at the element
|
||||
referred to by the slice pointer). The distinction between length and capacity
|
||||
will be made clear as we walk through the next few examples.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
As we slice <code>s</code>, observe the changes in the slice data structure and
|
||||
their relation to the underlying array:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
s = s[2:4]
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
<img src="slice-2.png">
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Slicing does not copy the slice's data. It creates a new slice value that
|
||||
points to the original array. This makes slice operations as efficient as
|
||||
manipulating array indices. Therefore, modifying the <i>elements</i> (not the
|
||||
slice itself) of a re-slice modifies the elements of the original slice:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
d := []byte{'r', 'o', 'a', 'd'}
|
||||
e := d[2:]
|
||||
// e == []byte{'a', 'd'}
|
||||
e[1] == 'm'
|
||||
// e == []byte{'a', 'm'}
|
||||
// d == []byte{'r', 'o', 'a', 'm'}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Earlier we sliced <code>s</code> to a length shorter than its capacity. We can
|
||||
grow s to its capacity by slicing it again:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
s = s[:cap(s)]
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
<img src="slice-3.png">
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A slice cannot be grown beyond its capacity. Attempting to do so will cause a
|
||||
runtime panic, just as when indexing outside the bounds of a slice or array.
|
||||
Similarly, slices cannot be re-sliced below zero to access earlier elements in
|
||||
the array.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Growing slices (the copy and append functions)</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To increase the capacity of a slice one must create a new, larger slice and
|
||||
copy the contents of the original slice into it. This technique is how dynamic
|
||||
array implementations from other languages work behind the scenes. The next
|
||||
example doubles the capacity of <code>s</code> by making a new slice,
|
||||
<code>t</code>, copying the contents of <code>s</code> into <code>t</code>, and
|
||||
then assigning the slice value <code>t</code> to <code>s</code>:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
t := make([]byte, len(s), (cap(s)+1)*2) // +1 in case cap(s) == 0
|
||||
for i := range s {
|
||||
t[i] = s[i]
|
||||
}
|
||||
s = t
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The looping piece of this common operation is made easier by the built-in copy
|
||||
function. As the name suggests, copy copies data from a source slice to a
|
||||
destination slice. It returns the number of elements copied.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
func copy(dst, src []T) int
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The <code>copy</code> function supports copying between slices of different
|
||||
lengths (it will copy only up to the smaller number of elements). In addition,
|
||||
<code>copy</code> can handle source and destination slices that share the same
|
||||
underlying array, handling overlapping slices correctly.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Using <code>copy</code>, we can simplify the code snippet above:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
t := make([]byte, len(s), (cap(s)+1)*2)
|
||||
copy(t, s)
|
||||
s = t
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
A common operation is to append data to the end of a slice. This function
|
||||
appends byte elements to a slice of bytes, growing the slice if necessary, and
|
||||
returns the updated slice value:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/slices.go" `/AppendByte/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
One could use <code>AppendByte</code> like this:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
p := []byte{2, 3, 5}
|
||||
p = AppendByte(p, 7, 11, 13)
|
||||
// p == []byte{2, 3, 5, 7, 11, 13}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Functions like <code>AppendByte</code> are useful because they offer complete
|
||||
control over the way the slice is grown. Depending on the characteristics of
|
||||
the program, it may be desirable to allocate in smaller or larger chunks, or to
|
||||
put a ceiling on the size of a reallocation.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
But most programs don't need complete control, so Go provides a built-in
|
||||
<code>append</code> function that's good for most purposes; it has the
|
||||
signature
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
func append(s []T, x ...T) []T
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The <code>append</code> function appends the elements <code>x</code> to the end
|
||||
of the slice <code>s</code>, and grows the slice if a greater capacity is
|
||||
needed.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
a := make([]int, 1)
|
||||
// a == []int{0}
|
||||
a = append(a, 1, 2, 3)
|
||||
// a == []int{0, 1, 2, 3}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
To append one slice to another, use <code>...</code> to expand the second
|
||||
argument to a list of arguments.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
a := []string{"John", "Paul"}
|
||||
b := []string{"George", "Ringo", "Pete"}
|
||||
a = append(a, b...) // equivalent to "append(a, b[0], b[1], b[2])"
|
||||
// a == []string{"John", "Paul", "George", "Ringo", "Pete"}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Since the zero value of a slice (<code>nil</code>) acts like a zero-length
|
||||
slice, you can declare a slice variable and then append to it in a loop:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/slices.go" `/Filter/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
<b>A possible "gotcha"</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
As mentioned earlier, re-slicing a slice doesn't make a copy of the underlying
|
||||
array. The full array will be kept in memory until it is no longer referenced.
|
||||
Occasionally this can cause the program to hold all the data in memory when
|
||||
only a small piece of it is needed.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For example, this <code>FindDigits</code> function loads a file into memory and
|
||||
searches it for the first group of consecutive numeric digits, returning them
|
||||
as a new slice.
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/slices.go" `/digit/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
This code behaves as advertised, but the returned <code>[]byte</code> points
|
||||
into an array containing the entire file. Since the slice references the
|
||||
original array, as long as the slice is kept around the garbage collector can't
|
||||
release the array; the few useful bytes of the file keep the entire contents in
|
||||
memory.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To fix this problem one can copy the interesting data to a new slice before
|
||||
returning it:
|
||||
</p>
|
||||
|
||||
{{code "/doc/progs/slices.go" `/CopyDigits/` `/STOP/`}}
|
||||
|
||||
<p>
|
||||
A more concise version of this function could be constructed by using
|
||||
<code>append</code>. This is left as an exercise for the reader.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Further Reading</b>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/doc/effective_go.html">Effective Go</a> contains an
|
||||
in-depth treatment of <a href="/doc/effective_go.html#slices">slices</a>
|
||||
and <a href="/doc/effective_go.html#arrays">arrays</a>,
|
||||
and the Go <a href="/doc/go_spec.html">language specification</a>
|
||||
defines <a href="/doc/go_spec.html#Slice_types">slices</a> and their
|
||||
<a href="/doc/go_spec.html#Length_and_capacity">associated</a>
|
||||
<a href="/doc/go_spec.html#Making_slices_maps_and_channels">helper</a>
|
||||
<a href="/doc/go_spec.html#Appending_and_copying_slices">functions</a>.
|
||||
</p>
|
||||
20
doc/articles/wiki/Makefile
Normal file
20
doc/articles/wiki/Makefile
Normal file
@@ -0,0 +1,20 @@
|
||||
# Copyright 2010 The Go Authors. All rights reserved.
|
||||
# Use of this source code is governed by a BSD-style
|
||||
# license that can be found in the LICENSE file.
|
||||
|
||||
all: index.html
|
||||
|
||||
CLEANFILES:=srcextract.bin htmlify.bin get.bin
|
||||
|
||||
index.html: wiki.html srcextract.bin htmlify.bin
|
||||
PATH=.:$$PATH awk '/^!/{system(substr($$0,2)); next} {print}' < wiki.html | tr -d '\r' > index.html
|
||||
|
||||
test: get.bin
|
||||
bash ./test.sh
|
||||
rm -f get.6 get.bin
|
||||
|
||||
%.bin: %.go
|
||||
go build -o $@ $^
|
||||
|
||||
clean:
|
||||
rm -f $(CLEANFILES)
|
||||
@@ -1,6 +1,6 @@
|
||||
<h1>Editing {{.Title}}</h1>
|
||||
<h1>Editing {{.Title |html}}</h1>
|
||||
|
||||
<form action="/save/{{.Title}}" method="POST">
|
||||
<div><textarea name="body" rows="20" cols="80">{{printf "%s" .Body}}</textarea></div>
|
||||
<form action="/save/{{.Title |html}}" method="POST">
|
||||
<div><textarea name="body" rows="20" cols="80">{{printf "%s" .Body |html}}</textarea></div>
|
||||
<div><input type="submit" value="Save"></div>
|
||||
</form>
|
||||
|
||||
@@ -83,15 +83,17 @@ func renderTemplate(w http.ResponseWriter, tmpl string, p *Page) {
|
||||
}
|
||||
}
|
||||
|
||||
var validPath = regexp.MustCompile("^/(edit|save|view)/([a-zA-Z0-9]+)$")
|
||||
const lenPath = len("/view/")
|
||||
|
||||
func getTitle(w http.ResponseWriter, r *http.Request) (string, error) {
|
||||
m := validPath.FindStringSubmatch(r.URL.Path)
|
||||
if m == nil {
|
||||
var titleValidator = regexp.MustCompile("^[a-zA-Z0-9]+$")
|
||||
|
||||
func getTitle(w http.ResponseWriter, r *http.Request) (title string, err error) {
|
||||
title = r.URL.Path[lenPath:]
|
||||
if !titleValidator.MatchString(title) {
|
||||
http.NotFound(w, r)
|
||||
return "", errors.New("Invalid Page Title")
|
||||
err = errors.New("Invalid Page Title")
|
||||
}
|
||||
return m[2], nil // The title is the second subexpression.
|
||||
return
|
||||
}
|
||||
|
||||
func main() {
|
||||
|
||||
@@ -29,8 +29,10 @@ func loadPage(title string) (*Page, error) {
|
||||
return &Page{Title: title, Body: body}, nil
|
||||
}
|
||||
|
||||
const lenPath = len("/view/")
|
||||
|
||||
func editHandler(w http.ResponseWriter, r *http.Request) {
|
||||
title := r.URL.Path[len("/edit/"):]
|
||||
title := r.URL.Path[lenPath:]
|
||||
p, err := loadPage(title)
|
||||
if err != nil {
|
||||
p = &Page{Title: title}
|
||||
@@ -40,7 +42,7 @@ func editHandler(w http.ResponseWriter, r *http.Request) {
|
||||
}
|
||||
|
||||
func viewHandler(w http.ResponseWriter, r *http.Request) {
|
||||
title := r.URL.Path[len("/view/"):]
|
||||
title := r.URL.Path[lenPath:]
|
||||
p, _ := loadPage(title)
|
||||
t, _ := template.ParseFiles("view.html")
|
||||
t.Execute(w, p)
|
||||
|
||||
@@ -70,16 +70,18 @@ func renderTemplate(w http.ResponseWriter, tmpl string, p *Page) {
|
||||
}
|
||||
}
|
||||
|
||||
var validPath = regexp.MustCompile("^/(edit|save|view)/([a-zA-Z0-9]+)$")
|
||||
const lenPath = len("/view/")
|
||||
|
||||
var titleValidator = regexp.MustCompile("^[a-zA-Z0-9]+$")
|
||||
|
||||
func makeHandler(fn func(http.ResponseWriter, *http.Request, string)) http.HandlerFunc {
|
||||
return func(w http.ResponseWriter, r *http.Request) {
|
||||
m := validPath.FindStringSubmatch(r.URL.Path)
|
||||
if m == nil {
|
||||
title := r.URL.Path[lenPath:]
|
||||
if !titleValidator.MatchString(title) {
|
||||
http.NotFound(w, r)
|
||||
return
|
||||
}
|
||||
fn(w, r, m[2])
|
||||
fn(w, r, title)
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
@@ -29,8 +29,10 @@ func loadPage(title string) (*Page, error) {
|
||||
return &Page{Title: title, Body: body}, nil
|
||||
}
|
||||
|
||||
const lenPath = len("/view/")
|
||||
|
||||
func editHandler(w http.ResponseWriter, r *http.Request) {
|
||||
title := r.URL.Path[len("/edit/"):]
|
||||
title := r.URL.Path[lenPath:]
|
||||
p, err := loadPage(title)
|
||||
if err != nil {
|
||||
p = &Page{Title: title}
|
||||
@@ -39,13 +41,13 @@ func editHandler(w http.ResponseWriter, r *http.Request) {
|
||||
}
|
||||
|
||||
func viewHandler(w http.ResponseWriter, r *http.Request) {
|
||||
title := r.URL.Path[len("/view/"):]
|
||||
title := r.URL.Path[lenPath:]
|
||||
p, _ := loadPage(title)
|
||||
renderTemplate(w, "view", p)
|
||||
}
|
||||
|
||||
func saveHandler(w http.ResponseWriter, r *http.Request) {
|
||||
title := r.URL.Path[len("/save/"):]
|
||||
title := r.URL.Path[lenPath:]
|
||||
body := r.FormValue("body")
|
||||
p := &Page{Title: title, Body: []byte(body)}
|
||||
p.save()
|
||||
|
||||
@@ -1,36 +0,0 @@
|
||||
*** final.go 2015-06-14 23:59:22.000000000 +0200
|
||||
--- final-test.go 2015-06-15 00:15:41.000000000 +0200
|
||||
***************
|
||||
*** 7,12 ****
|
||||
--- 7,14 ----
|
||||
import (
|
||||
"html/template"
|
||||
"io/ioutil"
|
||||
+ "log"
|
||||
+ "net"
|
||||
"net/http"
|
||||
"regexp"
|
||||
)
|
||||
***************
|
||||
*** 85,89 ****
|
||||
http.HandleFunc("/edit/", makeHandler(editHandler))
|
||||
http.HandleFunc("/save/", makeHandler(saveHandler))
|
||||
|
||||
! http.ListenAndServe(":8080", nil)
|
||||
}
|
||||
--- 87,101 ----
|
||||
http.HandleFunc("/edit/", makeHandler(editHandler))
|
||||
http.HandleFunc("/save/", makeHandler(saveHandler))
|
||||
|
||||
! l, err := net.Listen("tcp", "127.0.0.1:0")
|
||||
! if err != nil {
|
||||
! log.Fatal(err)
|
||||
! }
|
||||
! err = ioutil.WriteFile("final-test-port.txt", []byte(l.Addr().String()), 0644)
|
||||
! if err != nil {
|
||||
! log.Fatal(err)
|
||||
! }
|
||||
! s := &http.Server{}
|
||||
! s.Serve(l)
|
||||
! return
|
||||
}
|
||||
@@ -67,16 +67,18 @@ func renderTemplate(w http.ResponseWriter, tmpl string, p *Page) {
|
||||
}
|
||||
}
|
||||
|
||||
var validPath = regexp.MustCompile("^/(edit|save|view)/([a-zA-Z0-9]+)$")
|
||||
const lenPath = len("/view/")
|
||||
|
||||
var titleValidator = regexp.MustCompile("^[a-zA-Z0-9]+$")
|
||||
|
||||
func makeHandler(fn func(http.ResponseWriter, *http.Request, string)) http.HandlerFunc {
|
||||
return func(w http.ResponseWriter, r *http.Request) {
|
||||
m := validPath.FindStringSubmatch(r.URL.Path)
|
||||
if m == nil {
|
||||
title := r.URL.Path[lenPath:]
|
||||
if !titleValidator.MatchString(title) {
|
||||
http.NotFound(w, r)
|
||||
return
|
||||
}
|
||||
fn(w, r, m[2])
|
||||
fn(w, r, title)
|
||||
}
|
||||
}
|
||||
|
||||
@@ -84,6 +86,5 @@ func main() {
|
||||
http.HandleFunc("/view/", makeHandler(viewHandler))
|
||||
http.HandleFunc("/edit/", makeHandler(editHandler))
|
||||
http.HandleFunc("/save/", makeHandler(saveHandler))
|
||||
|
||||
http.ListenAndServe(":8080", nil)
|
||||
}
|
||||
|
||||
@@ -13,13 +13,11 @@ import (
|
||||
"net/http"
|
||||
"os"
|
||||
"strings"
|
||||
"time"
|
||||
)
|
||||
|
||||
var (
|
||||
post = flag.String("post", "", "urlencoded form data to POST")
|
||||
addr = flag.Bool("addr", false, "find open address and print to stdout")
|
||||
wait = flag.Duration("wait_for_port", 0, "if non-zero, the amount of time to wait for the address to become available")
|
||||
)
|
||||
|
||||
func main() {
|
||||
@@ -39,18 +37,11 @@ func main() {
|
||||
}
|
||||
var r *http.Response
|
||||
var err error
|
||||
loopUntil := time.Now().Add(*wait)
|
||||
for {
|
||||
if *post != "" {
|
||||
b := strings.NewReader(*post)
|
||||
r, err = http.Post(url, "application/x-www-form-urlencoded", b)
|
||||
} else {
|
||||
r, err = http.Get(url)
|
||||
}
|
||||
if err == nil || *wait == 0 || time.Now().After(loopUntil) {
|
||||
break
|
||||
}
|
||||
time.Sleep(100 * time.Millisecond)
|
||||
if *post != "" {
|
||||
b := strings.NewReader(*post)
|
||||
r, err = http.Post(url, "application/x-www-form-urlencoded", b)
|
||||
} else {
|
||||
r, err = http.Get(url)
|
||||
}
|
||||
if err != nil {
|
||||
log.Fatal(err)
|
||||
|
||||
16
doc/articles/wiki/htmlify.go
Normal file
16
doc/articles/wiki/htmlify.go
Normal file
@@ -0,0 +1,16 @@
|
||||
// Copyright 2010 The Go Authors. All rights reserved.
|
||||
// Use of this source code is governed by a BSD-style
|
||||
// license that can be found in the LICENSE file.
|
||||
|
||||
package main
|
||||
|
||||
import (
|
||||
"io/ioutil"
|
||||
"os"
|
||||
"text/template"
|
||||
)
|
||||
|
||||
func main() {
|
||||
b, _ := ioutil.ReadAll(os.Stdin)
|
||||
template.HTMLEscape(os.Stdout, b)
|
||||
}
|
||||
@@ -46,7 +46,7 @@ $ cd gowiki
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Create a file named <code>wiki.go</code>, open it in your favorite editor, and
|
||||
Create a file named <code>wiki.go</code>, open it in your favorite editor, and
|
||||
add the following lines:
|
||||
</p>
|
||||
|
||||
@@ -60,8 +60,8 @@ import (
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
We import the <code>fmt</code> and <code>ioutil</code> packages from the Go
|
||||
standard library. Later, as we implement additional functionality, we will
|
||||
We import the <code>fmt</code> and <code>ioutil</code> packages from the Go
|
||||
standard library. Later, as we implement additional functionality, we will
|
||||
add more packages to this <code>import</code> declaration.
|
||||
</p>
|
||||
|
||||
@@ -77,7 +77,7 @@ the title and body.
|
||||
{{code "doc/articles/wiki/part1.go" `/^type Page/` `/}/`}}
|
||||
|
||||
<p>
|
||||
The type <code>[]byte</code> means "a <code>byte</code> slice".
|
||||
The type <code>[]byte</code> means "a <code>byte</code> slice".
|
||||
(See <a href="/doc/articles/slices_usage_and_internals.html">Slices: usage and
|
||||
internals</a> for more on slices.)
|
||||
The <code>Body</code> element is a <code>[]byte</code> rather than
|
||||
@@ -86,8 +86,8 @@ libraries we will use, as you'll see below.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <code>Page</code> struct describes how page data will be stored in memory.
|
||||
But what about persistent storage? We can address that by creating a
|
||||
The <code>Page</code> struct describes how page data will be stored in memory.
|
||||
But what about persistent storage? We can address that by creating a
|
||||
<code>save</code> method on <code>Page</code>:
|
||||
</p>
|
||||
|
||||
@@ -96,11 +96,11 @@ But what about persistent storage? We can address that by creating a
|
||||
<p>
|
||||
This method's signature reads: "This is a method named <code>save</code> that
|
||||
takes as its receiver <code>p</code>, a pointer to <code>Page</code> . It takes
|
||||
no parameters, and returns a value of type <code>error</code>."
|
||||
no parameters, and returns a value of type <code>error</code>."
|
||||
</p>
|
||||
|
||||
<p>
|
||||
This method will save the <code>Page</code>'s <code>Body</code> to a text
|
||||
This method will save the <code>Page</code>'s <code>Body</code> to a text
|
||||
file. For simplicity, we will use the <code>Title</code> as the file name.
|
||||
</p>
|
||||
|
||||
@@ -110,36 +110,35 @@ that is the return type of <code>WriteFile</code> (a standard library function
|
||||
that writes a byte slice to a file). The <code>save</code> method returns the
|
||||
error value, to let the application handle it should anything go wrong while
|
||||
writing the file. If all goes well, <code>Page.save()</code> will return
|
||||
<code>nil</code> (the zero-value for pointers, interfaces, and some other
|
||||
<code>nil</code> (the zero-value for pointers, interfaces, and some other
|
||||
types).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The octal integer literal <code>0600</code>, passed as the third parameter to
|
||||
The octal integer constant <code>0600</code>, passed as the third parameter to
|
||||
<code>WriteFile</code>, indicates that the file should be created with
|
||||
read-write permissions for the current user only. (See the Unix man page
|
||||
<code>open(2)</code> for details.)
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In addition to saving pages, we will want to load pages, too:
|
||||
We will want to load pages, too:
|
||||
</p>
|
||||
|
||||
{{code "doc/articles/wiki/part1-noerror.go" `/^func loadPage/` `/^}/`}}
|
||||
|
||||
<p>
|
||||
The function <code>loadPage</code> constructs the file name from the title
|
||||
parameter, reads the file's contents into a new variable <code>body</code>, and
|
||||
returns a pointer to a <code>Page</code> literal constructed with the proper
|
||||
title and body values.
|
||||
The function <code>loadPage</code> constructs the file name from
|
||||
<code>Title</code>, reads the file's contents into a new
|
||||
<code>Page</code>, and returns a pointer to that new <code>page</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Functions can return multiple values. The standard library function
|
||||
<code>io.ReadFile</code> returns <code>[]byte</code> and <code>error</code>.
|
||||
Functions can return multiple values. The standard library function
|
||||
<code>io.ReadFile</code> returns <code>[]byte</code> and <code>error</code>.
|
||||
In <code>loadPage</code>, error isn't being handled yet; the "blank identifier"
|
||||
represented by the underscore (<code>_</code>) symbol is used to throw away the
|
||||
error return value (in essence, assigning the value to nothing).
|
||||
error return value (in essence, assigning the value to nothing).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@@ -153,7 +152,7 @@ function to return <code>*Page</code> and <code>error</code>.
|
||||
<p>
|
||||
Callers of this function can now check the second parameter; if it is
|
||||
<code>nil</code> then it has successfully loaded a Page. If not, it will be an
|
||||
<code>error</code> that can be handled by the caller (see the
|
||||
<code>error</code> that can be handled by the caller (see the
|
||||
<a href="/ref/spec#Errors">language specification</a> for details).
|
||||
</p>
|
||||
|
||||
@@ -173,7 +172,7 @@ printed to the screen.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
You can compile and run the program like this:
|
||||
You can compile and run the program like this:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
@@ -183,7 +182,7 @@ This is a sample page.
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
(If you're using Windows you must type "<code>wiki</code>" without the
|
||||
(If you're using Windows you must type "<code>wiki</code>" without the
|
||||
"<code>./</code>" to run the program.)
|
||||
</p>
|
||||
|
||||
@@ -200,10 +199,10 @@ Here's a full working example of a simple web server:
|
||||
{{code "doc/articles/wiki/http-sample.go"}}
|
||||
|
||||
<p>
|
||||
The <code>main</code> function begins with a call to
|
||||
<code>http.HandleFunc</code>, which tells the <code>http</code> package to
|
||||
handle all requests to the web root (<code>"/"</code>) with
|
||||
<code>handler</code>.
|
||||
The <code>main</code> function begins with a call to
|
||||
<code>http.HandleFunc</code>, which tells the <code>http</code> package to
|
||||
handle all requests to the web root (<code>"/"</code>) with
|
||||
<code>handler</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@@ -220,20 +219,20 @@ its arguments.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
An <code>http.ResponseWriter</code> value assembles the HTTP server's response; by writing
|
||||
An <code>http.ResponseWriter</code> value assembles the HTTP server's response; by writing
|
||||
to it, we send data to the HTTP client.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
An <code>http.Request</code> is a data structure that represents the client
|
||||
HTTP request. <code>r.URL.Path</code> is the path component
|
||||
of the request URL. The trailing <code>[1:]</code> means
|
||||
"create a sub-slice of <code>Path</code> from the 1st character to the end."
|
||||
HTTP request. The string <code>r.URL.Path</code> is the path component
|
||||
of the request URL. The trailing <code>[1:]</code> means
|
||||
"create a sub-slice of <code>Path</code> from the 1st character to the end."
|
||||
This drops the leading "/" from the path name.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If you run this program and access the URL:
|
||||
If you run this program and access the URL:
|
||||
</p>
|
||||
<pre>http://localhost:8080/monkeys</pre>
|
||||
<p>
|
||||
@@ -250,41 +249,43 @@ To use the <code>net/http</code> package, it must be imported:
|
||||
<pre>
|
||||
import (
|
||||
"fmt"
|
||||
"io/ioutil"
|
||||
<b>"net/http"</b>
|
||||
"io/ioutil"
|
||||
)
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Let's create a handler, <code>viewHandler</code> that will allow users to
|
||||
view a wiki page. It will handle URLs prefixed with "/view/".
|
||||
Let's create a handler to view a wiki page:
|
||||
</p>
|
||||
|
||||
{{code "doc/articles/wiki/part2.go" `/^const lenPath/`}}
|
||||
|
||||
{{code "doc/articles/wiki/part2.go" `/^func viewHandler/` `/^}/`}}
|
||||
|
||||
<p>
|
||||
First, this function extracts the page title from <code>r.URL.Path</code>,
|
||||
the path component of the request URL.
|
||||
The <code>Path</code> is re-sliced with <code>[len("/view/"):]</code> to drop
|
||||
the leading <code>"/view/"</code> component of the request path.
|
||||
This is because the path will invariably begin with <code>"/view/"</code>,
|
||||
which is not part of the page's title.
|
||||
the path component of the request URL. The global constant
|
||||
<code>lenPath</code> is the length of the leading <code>"/view/"</code>
|
||||
component of the request path.
|
||||
The <code>Path</code> is re-sliced with <code>[lenPath:]</code> to drop the
|
||||
first 6 characters of the string. This is because the path will invariably
|
||||
begin with <code>"/view/"</code>, which is not part of the page title.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The function then loads the page data, formats the page with a string of simple
|
||||
HTML, and writes it to <code>w</code>, the <code>http.ResponseWriter</code>.
|
||||
The function then loads the page data, formats the page with a string of simple
|
||||
HTML, and writes it to <code>w</code>, the <code>http.ResponseWriter</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Again, note the use of <code>_</code> to ignore the <code>error</code>
|
||||
Again, note the use of <code>_</code> to ignore the <code>error</code>
|
||||
return value from <code>loadPage</code>. This is done here for simplicity
|
||||
and generally considered bad practice. We will attend to this later.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To use this handler, we rewrite our <code>main</code> function to
|
||||
initialize <code>http</code> using the <code>viewHandler</code> to handle
|
||||
To use this handler, we create a <code>main</code> function that
|
||||
initializes <code>http</code> using the <code>viewHandler</code> to handle
|
||||
any requests under the path <code>/view/</code>.
|
||||
</p>
|
||||
|
||||
@@ -309,11 +310,6 @@ $ go build wiki.go
|
||||
$ ./wiki
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
(If you're using Windows you must type "<code>wiki</code>" without the
|
||||
"<code>./</code>" to run the program.)
|
||||
</p>
|
||||
|
||||
<p>
|
||||
With this web server running, a visit to <code><a
|
||||
href="http://localhost:8080/view/test">http://localhost:8080/view/test</a></code>
|
||||
@@ -330,14 +326,14 @@ form.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
First, we add them to <code>main()</code>:
|
||||
First, we add them to <code>main()</code>:
|
||||
</p>
|
||||
|
||||
{{code "doc/articles/wiki/final-noclosure.go" `/^func main/` `/^}/`}}
|
||||
|
||||
<p>
|
||||
The function <code>editHandler</code> loads the page
|
||||
(or, if it doesn't exist, create an empty <code>Page</code> struct),
|
||||
The function <code>editHandler</code> loads the page
|
||||
(or, if it doesn't exist, create an empty <code>Page</code> struct),
|
||||
and displays an HTML form.
|
||||
</p>
|
||||
|
||||
@@ -347,7 +343,7 @@ and displays an HTML form.
|
||||
This function will work fine, but all that hard-coded HTML is ugly.
|
||||
Of course, there is a better way.
|
||||
</p>
|
||||
|
||||
|
||||
<h2>The <code>html/template</code> package</h2>
|
||||
|
||||
<p>
|
||||
@@ -358,20 +354,20 @@ underlying Go code.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
First, we must add <code>html/template</code> to the list of imports. We
|
||||
also won't be using <code>fmt</code> anymore, so we have to remove that.
|
||||
First, we must add <code>html/template</code> to the list of imports:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
import (
|
||||
<b>"html/template"</b>
|
||||
"http"
|
||||
"io/ioutil"
|
||||
"net/http"
|
||||
"os"
|
||||
<b>"html/template"</b>
|
||||
)
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Let's create a template file containing the HTML form.
|
||||
Let's create a template file containing the HTML form.
|
||||
Open a new file named <code>edit.html</code>, and add the following lines:
|
||||
</p>
|
||||
|
||||
@@ -385,8 +381,8 @@ HTML:
|
||||
{{code "doc/articles/wiki/final-noerror.go" `/^func editHandler/` `/^}/`}}
|
||||
|
||||
<p>
|
||||
The function <code>template.ParseFiles</code> will read the contents of
|
||||
<code>edit.html</code> and return a <code>*template.Template</code>.
|
||||
The function <code>template.ParseFiles</code> will read the contents of
|
||||
<code>edit.html</code> and return a <code>*template.Template</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@@ -401,15 +397,19 @@ Template directives are enclosed in double curly braces.
|
||||
The <code>printf "%s" .Body</code> instruction is a function call
|
||||
that outputs <code>.Body</code> as a string instead of a stream of bytes,
|
||||
the same as a call to <code>fmt.Printf</code>.
|
||||
The <code>html/template</code> package helps guarantee that only safe and
|
||||
correct-looking HTML is generated by template actions. For instance, it
|
||||
automatically escapes any greater than sign (<code>></code>), replacing it
|
||||
with <code>&gt;</code>, to make sure user data does not corrupt the form
|
||||
HTML.
|
||||
The <code>|html</code> part of each directive pipes the value through the
|
||||
<code>html</code> formatter before outputting it, which escapes HTML
|
||||
characters (such as replacing <code>></code> with <code>&gt;</code>),
|
||||
preventing user data from corrupting the form HTML.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Since we're working with templates now, let's create a template for our
|
||||
Now that we've removed the <code>fmt.Fprintf</code> statement, we can remove
|
||||
<code>"fmt"</code> from the <code>import</code> list.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
While we're working with templates, let's create a template for our
|
||||
<code>viewHandler</code> called <code>view.html</code>:
|
||||
</p>
|
||||
|
||||
@@ -427,36 +427,28 @@ handlers. Let's remove this duplication by moving the templating code
|
||||
to its own function:
|
||||
</p>
|
||||
|
||||
{{code "doc/articles/wiki/final-template.go" `/^func viewHandler/` `/^}/`}}
|
||||
{{code "doc/articles/wiki/final-template.go" `/^func editHandler/` `/^}/`}}
|
||||
{{code "doc/articles/wiki/final-template.go" `/^func renderTemplate/` `/^}/`}}
|
||||
|
||||
<p>
|
||||
And modify the handlers to use that function:
|
||||
</p>
|
||||
|
||||
{{code "doc/articles/wiki/final-template.go" `/^func viewHandler/` `/^}/`}}
|
||||
{{code "doc/articles/wiki/final-template.go" `/^func editHandler/` `/^}/`}}
|
||||
|
||||
<p>
|
||||
If we comment out the registration of our unimplemented save handler in
|
||||
<code>main</code>, we can once again build and test our program.
|
||||
<a href="part3.go">Click here to view the code we've written so far.</a>
|
||||
The handlers are now shorter and simpler.
|
||||
</p>
|
||||
|
||||
<h2>Handling non-existent pages</h2>
|
||||
|
||||
<p>
|
||||
What if you visit <a href="http://localhost:8080/view/APageThatDoesntExist">
|
||||
<code>/view/APageThatDoesntExist</code></a>? You'll see a page containing
|
||||
HTML. This is because it ignores the error return value from
|
||||
<code>loadPage</code> and continues to try and fill out the template
|
||||
with no data. Instead, if the requested Page doesn't exist, it should
|
||||
redirect the client to the edit Page so the content may be created:
|
||||
<code>/view/APageThatDoesntExist</code></a>? The program will crash. This is
|
||||
because it ignores the error return value from <code>loadPage</code>. Instead,
|
||||
if the requested Page doesn't exist, it should redirect the client to the edit
|
||||
Page so the content may be created:
|
||||
</p>
|
||||
|
||||
{{code "doc/articles/wiki/part3-errorhandling.go" `/^func viewHandler/` `/^}/`}}
|
||||
{{code "doc/articles/wiki/final-noclosure.go" `/^func viewHandler/` `/^}/`}}
|
||||
|
||||
<p>
|
||||
The <code>http.Redirect</code> function adds an HTTP status code of
|
||||
The <code>http.Redirect</code> function adds an HTTP status code of
|
||||
<code>http.StatusFound</code> (302) and a <code>Location</code>
|
||||
header to the HTTP response.
|
||||
</p>
|
||||
@@ -464,24 +456,22 @@ header to the HTTP response.
|
||||
<h2>Saving Pages</h2>
|
||||
|
||||
<p>
|
||||
The function <code>saveHandler</code> will handle the submission of forms
|
||||
located on the edit pages. After uncommenting the related line in
|
||||
<code>main</code>, let's implement the handler:
|
||||
The function <code>saveHandler</code> will handle the form submission.
|
||||
</p>
|
||||
|
||||
{{code "doc/articles/wiki/final-template.go" `/^func saveHandler/` `/^}/`}}
|
||||
|
||||
<p>
|
||||
The page title (provided in the URL) and the form's only field,
|
||||
<code>Body</code>, are stored in a new <code>Page</code>.
|
||||
The page title (provided in the URL) and the form's only field,
|
||||
<code>Body</code>, are stored in a new <code>Page</code>.
|
||||
The <code>save()</code> method is then called to write the data to a file,
|
||||
and the client is redirected to the <code>/view/</code> page.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The value returned by <code>FormValue</code> is of type <code>string</code>.
|
||||
We must convert that value to <code>[]byte</code> before it will fit into
|
||||
the <code>Page</code> struct. We use <code>[]byte(body)</code> to perform
|
||||
We must convert that value to <code>[]byte</code> before it will fit into
|
||||
the <code>Page</code> struct. We use <code>[]byte(body)</code> to perform
|
||||
the conversion.
|
||||
</p>
|
||||
|
||||
@@ -490,9 +480,9 @@ the conversion.
|
||||
<p>
|
||||
There are several places in our program where errors are being ignored. This
|
||||
is bad practice, not least because when an error does occur the program will
|
||||
have unintended behavior. A better solution is to handle the errors and return
|
||||
an error message to the user. That way if something does go wrong, the server
|
||||
will function exactly how we want and the user can be notified.
|
||||
crash. A better solution is to handle the errors and return an error message
|
||||
to the user. That way if something does go wrong, the server will continue to
|
||||
function and the user will be notified.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@@ -502,7 +492,7 @@ First, let's handle the errors in <code>renderTemplate</code>:
|
||||
{{code "doc/articles/wiki/final-parsetemplate.go" `/^func renderTemplate/` `/^}/`}}
|
||||
|
||||
<p>
|
||||
The <code>http.Error</code> function sends a specified HTTP response code
|
||||
The <code>http.Error</code> function sends a specified HTTP response code
|
||||
(in this case "Internal Server Error") and error message.
|
||||
Already the decision to put this in a separate function is paying off.
|
||||
</p>
|
||||
@@ -511,18 +501,18 @@ Already the decision to put this in a separate function is paying off.
|
||||
Now let's fix up <code>saveHandler</code>:
|
||||
</p>
|
||||
|
||||
{{code "doc/articles/wiki/part3-errorhandling.go" `/^func saveHandler/` `/^}/`}}
|
||||
{{code "doc/articles/wiki/final-noclosure.go" `/^func saveHandler/` `/^}/`}}
|
||||
|
||||
<p>
|
||||
Any errors that occur during <code>p.save()</code> will be reported
|
||||
Any errors that occur during <code>p.save()</code> will be reported
|
||||
to the user.
|
||||
</p>
|
||||
|
||||
<h2>Template caching</h2>
|
||||
|
||||
<p>
|
||||
There is an inefficiency in this code: <code>renderTemplate</code> calls
|
||||
<code>ParseFiles</code> every time a page is rendered.
|
||||
There is an inefficiency in this code: <code>renderTemplate</code> calls
|
||||
<code>ParseFiles</code> every time a page is rendered.
|
||||
A better approach would be to call <code>ParseFiles</code> once at program
|
||||
initialization, parsing all templates into a single <code>*Template</code>.
|
||||
Then we can use the
|
||||
@@ -545,11 +535,10 @@ can't be loaded the only sensible thing to do is exit the program.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <code>ParseFiles</code> function takes any number of string arguments that
|
||||
identify our template files, and parses those files into templates that are
|
||||
named after the base file name. If we were to add more templates to our
|
||||
program, we would add their names to the <code>ParseFiles</code> call's
|
||||
arguments.
|
||||
A <code>for</code> loop is used with a <code>range</code> statement to iterate
|
||||
over an array constant containing the names of the templates we want parsed.
|
||||
If we were to add more templates to our program, we would add their names to
|
||||
that array.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@@ -575,33 +564,31 @@ this, we can write a function to validate the title with a regular expression.
|
||||
|
||||
<p>
|
||||
First, add <code>"regexp"</code> to the <code>import</code> list.
|
||||
Then we can create a global variable to store our validation
|
||||
expression:
|
||||
Then we can create a global variable to store our validation regexp:
|
||||
</p>
|
||||
|
||||
{{code "doc/articles/wiki/final-noclosure.go" `/^var validPath/`}}
|
||||
{{code "doc/articles/wiki/final-noclosure.go" `/^var titleValidator/`}}
|
||||
|
||||
<p>
|
||||
The function <code>regexp.MustCompile</code> will parse and compile the
|
||||
regular expression, and return a <code>regexp.Regexp</code>.
|
||||
The function <code>regexp.MustCompile</code> will parse and compile the
|
||||
regular expression, and return a <code>regexp.Regexp</code>.
|
||||
<code>MustCompile</code> is distinct from <code>Compile</code> in that it will
|
||||
panic if the expression compilation fails, while <code>Compile</code> returns
|
||||
an <code>error</code> as a second parameter.
|
||||
an <code>error</code> as a second parameter.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Now, let's write a function that uses the <code>validPath</code>
|
||||
expression to validate path and extract the page title:
|
||||
Now, let's write a function that extracts the title string from the request
|
||||
URL, and tests it against our <code>TitleValidator</code> expression:
|
||||
</p>
|
||||
|
||||
{{code "doc/articles/wiki/final-noclosure.go" `/func getTitle/` `/^}/`}}
|
||||
|
||||
<p>
|
||||
If the title is valid, it will be returned along with a <code>nil</code>
|
||||
error value. If the title is invalid, the function will write a
|
||||
"404 Not Found" error to the HTTP connection, and return an error to the
|
||||
handler. To create a new error, we have to import the <code>errors</code>
|
||||
package.
|
||||
error value. If the title is invalid, the function will write a
|
||||
"404 Not Found" error to the HTTP connection, and return an error to the
|
||||
handler.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@@ -616,10 +603,10 @@ Let's put a call to <code>getTitle</code> in each of the handlers:
|
||||
|
||||
<p>
|
||||
Catching the error condition in each handler introduces a lot of repeated code.
|
||||
What if we could wrap each of the handlers in a function that does this
|
||||
validation and error checking? Go's
|
||||
<a href="/ref/spec#Function_literals">function
|
||||
literals</a> provide a powerful means of abstracting functionality
|
||||
What if we could wrap each of the handlers in a function that does this
|
||||
validation and error checking? Go's
|
||||
<a href="/ref/spec#Function_declarations">function
|
||||
literals</a> provide a powerful means of abstracting functionality
|
||||
that can help us here.
|
||||
</p>
|
||||
|
||||
@@ -666,19 +653,19 @@ Now we can take the code from <code>getTitle</code> and use it here
|
||||
<p>
|
||||
The closure returned by <code>makeHandler</code> is a function that takes
|
||||
an <code>http.ResponseWriter</code> and <code>http.Request</code> (in other
|
||||
words, an <code>http.HandlerFunc</code>).
|
||||
words, an <code>http.HandlerFunc</code>).
|
||||
The closure extracts the <code>title</code> from the request path, and
|
||||
validates it with the <code>TitleValidator</code> regexp. If the
|
||||
<code>title</code> is invalid, an error will be written to the
|
||||
<code>ResponseWriter</code> using the <code>http.NotFound</code> function.
|
||||
<code>ResponseWriter</code> using the <code>http.NotFound</code> function.
|
||||
If the <code>title</code> is valid, the enclosed handler function
|
||||
<code>fn</code> will be called with the <code>ResponseWriter</code>,
|
||||
<code>Request</code>, and <code>title</code> as arguments.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Now we can wrap the handler functions with <code>makeHandler</code> in
|
||||
<code>main</code>, before they are registered with the <code>http</code>
|
||||
Now we can wrap the handler functions with <code>makeHandler</code> in
|
||||
<code>main</code>, before they are registered with the <code>http</code>
|
||||
package:
|
||||
</p>
|
||||
|
||||
@@ -710,7 +697,7 @@ $ ./wiki
|
||||
|
||||
<p>
|
||||
Visiting <a href="http://localhost:8080/view/ANewPage">http://localhost:8080/view/ANewPage</a>
|
||||
should present you with the page edit form. You should then be able to
|
||||
should present you with the page edit form. You should then be able to
|
||||
enter some text, click 'Save', and be redirected to the newly created page.
|
||||
</p>
|
||||
|
||||
@@ -722,11 +709,11 @@ Here are some simple tasks you might want to tackle on your own:
|
||||
|
||||
<ul>
|
||||
<li>Store templates in <code>tmpl/</code> and page data in <code>data/</code>.
|
||||
<li>Add a handler to make the web root redirect to
|
||||
<li>Add a handler to make the web root redirect to
|
||||
<code>/view/FrontPage</code>.</li>
|
||||
<li>Spruce up the page templates by making them valid HTML and adding some
|
||||
CSS rules.</li>
|
||||
<li>Implement inter-page linking by converting instances of
|
||||
<li>Implement inter-page linking by converting instances of
|
||||
<code>[PageName]</code> to <br>
|
||||
<code><a href="/view/PageName">PageName</a></code>.
|
||||
(hint: you could use <code>regexp.ReplaceAllFunc</code> to do this)
|
||||
|
||||
@@ -29,14 +29,16 @@ func loadPage(title string) (*Page, error) {
|
||||
return &Page{Title: title, Body: body}, nil
|
||||
}
|
||||
|
||||
const lenPath = len("/view/")
|
||||
|
||||
func viewHandler(w http.ResponseWriter, r *http.Request) {
|
||||
title := r.URL.Path[len("/view/"):]
|
||||
title := r.URL.Path[lenPath:]
|
||||
p, _ := loadPage(title)
|
||||
fmt.Fprintf(w, "<h1>%s</h1><div>%s</div>", p.Title, p.Body)
|
||||
}
|
||||
|
||||
func editHandler(w http.ResponseWriter, r *http.Request) {
|
||||
title := r.URL.Path[len("/edit/"):]
|
||||
title := r.URL.Path[lenPath:]
|
||||
p, err := loadPage(title)
|
||||
if err != nil {
|
||||
p = &Page{Title: title}
|
||||
|
||||
@@ -29,8 +29,10 @@ func loadPage(title string) (*Page, error) {
|
||||
return &Page{Title: title, Body: body}, nil
|
||||
}
|
||||
|
||||
const lenPath = len("/view/")
|
||||
|
||||
func viewHandler(w http.ResponseWriter, r *http.Request) {
|
||||
title := r.URL.Path[len("/view/"):]
|
||||
title := r.URL.Path[lenPath:]
|
||||
p, _ := loadPage(title)
|
||||
fmt.Fprintf(w, "<h1>%s</h1><div>%s</div>", p.Title, p.Body)
|
||||
}
|
||||
|
||||
@@ -1,73 +0,0 @@
|
||||
// Copyright 2010 The Go Authors. All rights reserved.
|
||||
// Use of this source code is governed by a BSD-style
|
||||
// license that can be found in the LICENSE file.
|
||||
|
||||
package main
|
||||
|
||||
import (
|
||||
"html/template"
|
||||
"io/ioutil"
|
||||
"net/http"
|
||||
)
|
||||
|
||||
type Page struct {
|
||||
Title string
|
||||
Body []byte
|
||||
}
|
||||
|
||||
func (p *Page) save() error {
|
||||
filename := p.Title + ".txt"
|
||||
return ioutil.WriteFile(filename, p.Body, 0600)
|
||||
}
|
||||
|
||||
func loadPage(title string) (*Page, error) {
|
||||
filename := title + ".txt"
|
||||
body, err := ioutil.ReadFile(filename)
|
||||
if err != nil {
|
||||
return nil, err
|
||||
}
|
||||
return &Page{Title: title, Body: body}, nil
|
||||
}
|
||||
|
||||
func renderTemplate(w http.ResponseWriter, tmpl string, p *Page) {
|
||||
t, _ := template.ParseFiles(tmpl + ".html")
|
||||
t.Execute(w, p)
|
||||
}
|
||||
|
||||
func viewHandler(w http.ResponseWriter, r *http.Request) {
|
||||
title := r.URL.Path[len("/view/"):]
|
||||
p, err := loadPage(title)
|
||||
if err != nil {
|
||||
http.Redirect(w, r, "/edit/"+title, http.StatusFound)
|
||||
return
|
||||
}
|
||||
renderTemplate(w, "view", p)
|
||||
}
|
||||
|
||||
func editHandler(w http.ResponseWriter, r *http.Request) {
|
||||
title := r.URL.Path[len("/edit/"):]
|
||||
p, err := loadPage(title)
|
||||
if err != nil {
|
||||
p = &Page{Title: title}
|
||||
}
|
||||
renderTemplate(w, "edit", p)
|
||||
}
|
||||
|
||||
func saveHandler(w http.ResponseWriter, r *http.Request) {
|
||||
title := r.URL.Path[len("/save/"):]
|
||||
body := r.FormValue("body")
|
||||
p := &Page{Title: title, Body: []byte(body)}
|
||||
err := p.save()
|
||||
if err != nil {
|
||||
http.Error(w, err.Error(), http.StatusInternalServerError)
|
||||
return
|
||||
}
|
||||
http.Redirect(w, r, "/view/"+title, http.StatusFound)
|
||||
}
|
||||
|
||||
func main() {
|
||||
http.HandleFunc("/view/", viewHandler)
|
||||
http.HandleFunc("/edit/", editHandler)
|
||||
http.HandleFunc("/save/", saveHandler)
|
||||
http.ListenAndServe(":8080", nil)
|
||||
}
|
||||
@@ -1,57 +0,0 @@
|
||||
// Copyright 2010 The Go Authors. All rights reserved.
|
||||
// Use of this source code is governed by a BSD-style
|
||||
// license that can be found in the LICENSE file.
|
||||
|
||||
package main
|
||||
|
||||
import (
|
||||
"html/template"
|
||||
"io/ioutil"
|
||||
"net/http"
|
||||
)
|
||||
|
||||
type Page struct {
|
||||
Title string
|
||||
Body []byte
|
||||
}
|
||||
|
||||
func (p *Page) save() error {
|
||||
filename := p.Title + ".txt"
|
||||
return ioutil.WriteFile(filename, p.Body, 0600)
|
||||
}
|
||||
|
||||
func loadPage(title string) (*Page, error) {
|
||||
filename := title + ".txt"
|
||||
body, err := ioutil.ReadFile(filename)
|
||||
if err != nil {
|
||||
return nil, err
|
||||
}
|
||||
return &Page{Title: title, Body: body}, nil
|
||||
}
|
||||
|
||||
func renderTemplate(w http.ResponseWriter, tmpl string, p *Page) {
|
||||
t, _ := template.ParseFiles(tmpl + ".html")
|
||||
t.Execute(w, p)
|
||||
}
|
||||
|
||||
func viewHandler(w http.ResponseWriter, r *http.Request) {
|
||||
title := r.URL.Path[len("/view/"):]
|
||||
p, _ := loadPage(title)
|
||||
renderTemplate(w, "view", p)
|
||||
}
|
||||
|
||||
func editHandler(w http.ResponseWriter, r *http.Request) {
|
||||
title := r.URL.Path[len("/edit/"):]
|
||||
p, err := loadPage(title)
|
||||
if err != nil {
|
||||
p = &Page{Title: title}
|
||||
}
|
||||
renderTemplate(w, "edit", p)
|
||||
}
|
||||
|
||||
func main() {
|
||||
http.HandleFunc("/view/", viewHandler)
|
||||
http.HandleFunc("/edit/", editHandler)
|
||||
//http.HandleFunc("/save/", saveHandler)
|
||||
http.ListenAndServe(":8080", nil)
|
||||
}
|
||||
76
doc/articles/wiki/srcextract.go
Normal file
76
doc/articles/wiki/srcextract.go
Normal file
@@ -0,0 +1,76 @@
|
||||
// Copyright 2010 The Go Authors. All rights reserved.
|
||||
// Use of this source code is governed by a BSD-style
|
||||
// license that can be found in the LICENSE file.
|
||||
|
||||
package main
|
||||
|
||||
import (
|
||||
"bytes"
|
||||
"flag"
|
||||
"go/ast"
|
||||
"go/parser"
|
||||
"go/printer"
|
||||
"go/token"
|
||||
"log"
|
||||
"os"
|
||||
"text/template"
|
||||
)
|
||||
|
||||
var (
|
||||
srcFn = flag.String("src", "", "source filename")
|
||||
getName = flag.String("name", "", "func/type name to output")
|
||||
html = flag.Bool("html", true, "output HTML")
|
||||
showPkg = flag.Bool("pkg", false, "show package in output")
|
||||
)
|
||||
|
||||
func main() {
|
||||
// handle input
|
||||
flag.Parse()
|
||||
if *srcFn == "" || *getName == "" {
|
||||
flag.Usage()
|
||||
os.Exit(2)
|
||||
}
|
||||
// load file
|
||||
fs := token.NewFileSet()
|
||||
file, err := parser.ParseFile(fs, *srcFn, nil, 0)
|
||||
if err != nil {
|
||||
log.Fatal(err)
|
||||
}
|
||||
// create filter
|
||||
filter := func(name string) bool {
|
||||
return name == *getName
|
||||
}
|
||||
// filter
|
||||
if !ast.FilterFile(file, filter) {
|
||||
os.Exit(1)
|
||||
}
|
||||
// print the AST
|
||||
var b bytes.Buffer
|
||||
printer.Fprint(&b, fs, file)
|
||||
// drop package declaration
|
||||
if !*showPkg {
|
||||
for {
|
||||
c, err := b.ReadByte()
|
||||
if c == '\n' || err != nil {
|
||||
break
|
||||
}
|
||||
}
|
||||
}
|
||||
// drop leading newlines
|
||||
for {
|
||||
b, err := b.ReadByte()
|
||||
if err != nil {
|
||||
break
|
||||
}
|
||||
if b != '\n' {
|
||||
os.Stdout.Write([]byte{b})
|
||||
break
|
||||
}
|
||||
}
|
||||
// output
|
||||
if *html {
|
||||
template.HTMLEscape(os.Stdout, b.Bytes())
|
||||
} else {
|
||||
b.WriteTo(os.Stdout)
|
||||
}
|
||||
}
|
||||
@@ -4,53 +4,25 @@
|
||||
# license that can be found in the LICENSE file.
|
||||
|
||||
set -e
|
||||
|
||||
if ! which patch > /dev/null; then
|
||||
echo "Skipping test; patch command not found."
|
||||
exit 0
|
||||
fi
|
||||
|
||||
wiki_pid=
|
||||
cleanup() {
|
||||
kill $wiki_pid
|
||||
rm -f test_*.out Test.txt final-test.go final-test.bin final-test-port.txt a.out get.bin
|
||||
rm -f test_*.out Test.txt final-test.bin final-test.go
|
||||
}
|
||||
trap cleanup 0 INT
|
||||
|
||||
rm -f get.bin final-test.bin a.out
|
||||
|
||||
# If called with -all, check that all code snippets compile.
|
||||
if [ "$1" == "-all" ]; then
|
||||
for fn in *.go; do
|
||||
go build -o a.out $fn
|
||||
done
|
||||
fi
|
||||
|
||||
go build -o get.bin get.go
|
||||
cp final.go final-test.go
|
||||
patch final-test.go final-test.patch > /dev/null
|
||||
addr=$(./get.bin -addr)
|
||||
sed s/:8080/$addr/ < final.go > final-test.go
|
||||
go build -o final-test.bin final-test.go
|
||||
./final-test.bin &
|
||||
(./final-test.bin) &
|
||||
wiki_pid=$!
|
||||
|
||||
l=0
|
||||
while [ ! -f ./final-test-port.txt ]
|
||||
do
|
||||
l=$(($l+1))
|
||||
if [ "$l" -gt 5 ]
|
||||
then
|
||||
echo "port not available within 5 seconds"
|
||||
exit 1
|
||||
break
|
||||
fi
|
||||
sleep 1
|
||||
done
|
||||
sleep 1
|
||||
|
||||
addr=$(cat final-test-port.txt)
|
||||
./get.bin http://$addr/edit/Test > test_edit.out
|
||||
diff -u test_edit.out test_edit.good
|
||||
./get.bin -post=body=some%20content http://$addr/save/Test > test_save.out
|
||||
diff -u test_save.out test_view.good # should be the same as viewing
|
||||
./get.bin -post=body=some%20content http://$addr/save/Test
|
||||
diff -u Test.txt test_Test.txt.good
|
||||
./get.bin http://$addr/view/Test > test_view.out
|
||||
diff -u test_view.out test_view.good
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<h1>{{.Title}}</h1>
|
||||
<h1>{{.Title |html}}</h1>
|
||||
|
||||
<p>[<a href="/edit/{{.Title}}">edit</a>]</p>
|
||||
<p>[<a href="/edit/{{.Title |html}}">edit</a>]</p>
|
||||
|
||||
<div>{{printf "%s" .Body}}</div>
|
||||
<div>{{printf "%s" .Body |html}}</div>
|
||||
|
||||
872
doc/asm.html
872
doc/asm.html
@@ -1,872 +0,0 @@
|
||||
<!--{
|
||||
"Title": "A Quick Guide to Go's Assembler",
|
||||
"Path": "/doc/asm"
|
||||
}-->
|
||||
|
||||
<h2 id="introduction">A Quick Guide to Go's Assembler</h2>
|
||||
|
||||
<p>
|
||||
This document is a quick outline of the unusual form of assembly language used by the <code>gc</code> Go compiler.
|
||||
The document is not comprehensive.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The assembler is based on the input style of the Plan 9 assemblers, which is documented in detail
|
||||
<a href="https://9p.io/sys/doc/asm.html">elsewhere</a>.
|
||||
If you plan to write assembly language, you should read that document although much of it is Plan 9-specific.
|
||||
The current document provides a summary of the syntax and the differences with
|
||||
what is explained in that document, and
|
||||
describes the peculiarities that apply when writing assembly code to interact with Go.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The most important thing to know about Go's assembler is that it is not a direct representation of the underlying machine.
|
||||
Some of the details map precisely to the machine, but some do not.
|
||||
This is because the compiler suite (see
|
||||
<a href="https://9p.io/sys/doc/compiler.html">this description</a>)
|
||||
needs no assembler pass in the usual pipeline.
|
||||
Instead, the compiler operates on a kind of semi-abstract instruction set,
|
||||
and instruction selection occurs partly after code generation.
|
||||
The assembler works on the semi-abstract form, so
|
||||
when you see an instruction like <code>MOV</code>
|
||||
what the tool chain actually generates for that operation might
|
||||
not be a move instruction at all, perhaps a clear or load.
|
||||
Or it might correspond exactly to the machine instruction with that name.
|
||||
In general, machine-specific operations tend to appear as themselves, while more general concepts like
|
||||
memory move and subroutine call and return are more abstract.
|
||||
The details vary with architecture, and we apologize for the imprecision; the situation is not well-defined.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The assembler program is a way to parse a description of that
|
||||
semi-abstract instruction set and turn it into instructions to be
|
||||
input to the linker.
|
||||
If you want to see what the instructions look like in assembly for a given architecture, say amd64, there
|
||||
are many examples in the sources of the standard library, in packages such as
|
||||
<a href="/pkg/runtime/"><code>runtime</code></a> and
|
||||
<a href="/pkg/math/big/"><code>math/big</code></a>.
|
||||
You can also examine what the compiler emits as assembly code
|
||||
(the actual output may differ from what you see here):
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ cat x.go
|
||||
package main
|
||||
|
||||
func main() {
|
||||
println(3)
|
||||
}
|
||||
$ GOOS=linux GOARCH=amd64 go tool compile -S x.go # or: go build -gcflags -S x.go
|
||||
|
||||
--- prog list "main" ---
|
||||
0000 (x.go:3) TEXT main+0(SB),$8-0
|
||||
0001 (x.go:3) FUNCDATA $0,gcargs·0+0(SB)
|
||||
0002 (x.go:3) FUNCDATA $1,gclocals·0+0(SB)
|
||||
0003 (x.go:4) MOVQ $3,(SP)
|
||||
0004 (x.go:4) PCDATA $0,$8
|
||||
0005 (x.go:4) CALL ,runtime.printint+0(SB)
|
||||
0006 (x.go:4) PCDATA $0,$-1
|
||||
0007 (x.go:4) PCDATA $0,$0
|
||||
0008 (x.go:4) CALL ,runtime.printnl+0(SB)
|
||||
0009 (x.go:4) PCDATA $0,$-1
|
||||
0010 (x.go:5) RET ,
|
||||
...
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The <code>FUNCDATA</code> and <code>PCDATA</code> directives contain information
|
||||
for use by the garbage collector; they are introduced by the compiler.
|
||||
</p>
|
||||
|
||||
<!-- Commenting out because the feature is gone but it's popular and may come back.
|
||||
|
||||
<p>
|
||||
To see what gets put in the binary after linking, add the <code>-a</code> flag to the linker:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ go tool 6l -a x.6 # or: go build -ldflags -a x.go
|
||||
codeblk [0x2000,0x1d059) at offset 0x1000
|
||||
002000 main.main | (3) TEXT main.main+0(SB),$8
|
||||
002000 65488b0c25a0080000 | (3) MOVQ 2208(GS),CX
|
||||
002009 483b21 | (3) CMPQ SP,(CX)
|
||||
00200c 7707 | (3) JHI ,2015
|
||||
00200e e83da20100 | (3) CALL ,1c250+runtime.morestack00
|
||||
002013 ebeb | (3) JMP ,2000
|
||||
002015 4883ec08 | (3) SUBQ $8,SP
|
||||
002019 | (3) FUNCDATA $0,main.gcargs·0+0(SB)
|
||||
002019 | (3) FUNCDATA $1,main.gclocals·0+0(SB)
|
||||
002019 48c7042403000000 | (4) MOVQ $3,(SP)
|
||||
002021 | (4) PCDATA $0,$8
|
||||
002021 e8aad20000 | (4) CALL ,f2d0+runtime.printint
|
||||
002026 | (4) PCDATA $0,$-1
|
||||
002026 | (4) PCDATA $0,$0
|
||||
002026 e865d40000 | (4) CALL ,f490+runtime.printnl
|
||||
00202b | (4) PCDATA $0,$-1
|
||||
00202b 4883c408 | (5) ADDQ $8,SP
|
||||
00202f c3 | (5) RET ,
|
||||
...
|
||||
</pre>
|
||||
|
||||
-->
|
||||
|
||||
<h3 id="constants">Constants</h3>
|
||||
|
||||
<p>
|
||||
Although the assembler takes its guidance from the Plan 9 assemblers,
|
||||
it is a distinct program, so there are some differences.
|
||||
One is in constant evaluation.
|
||||
Constant expressions in the assembler are parsed using Go's operator
|
||||
precedence, not the C-like precedence of the original.
|
||||
Thus <code>3&1<<2</code> is 4, not 0—it parses as <code>(3&1)<<2</code>
|
||||
not <code>3&(1<<2)</code>.
|
||||
Also, constants are always evaluated as 64-bit unsigned integers.
|
||||
Thus <code>-2</code> is not the integer value minus two,
|
||||
but the unsigned 64-bit integer with the same bit pattern.
|
||||
The distinction rarely matters but
|
||||
to avoid ambiguity, division or right shift where the right operand's
|
||||
high bit is set is rejected.
|
||||
</p>
|
||||
|
||||
<h3 id="symbols">Symbols</h3>
|
||||
|
||||
<p>
|
||||
Some symbols, such as <code>R1</code> or <code>LR</code>,
|
||||
are predefined and refer to registers.
|
||||
The exact set depends on the architecture.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
There are four predeclared symbols that refer to pseudo-registers.
|
||||
These are not real registers, but rather virtual registers maintained by
|
||||
the tool chain, such as a frame pointer.
|
||||
The set of pseudo-registers is the same for all architectures:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
|
||||
<li>
|
||||
<code>FP</code>: Frame pointer: arguments and locals.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<code>PC</code>: Program counter:
|
||||
jumps and branches.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<code>SB</code>: Static base pointer: global symbols.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<code>SP</code>: Stack pointer: top of stack.
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
All user-defined symbols are written as offsets to the pseudo-registers
|
||||
<code>FP</code> (arguments and locals) and <code>SB</code> (globals).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <code>SB</code> pseudo-register can be thought of as the origin of memory, so the symbol <code>foo(SB)</code>
|
||||
is the name <code>foo</code> as an address in memory.
|
||||
This form is used to name global functions and data.
|
||||
Adding <code><></code> to the name, as in <span style="white-space: nowrap"><code>foo<>(SB)</code></span>, makes the name
|
||||
visible only in the current source file, like a top-level <code>static</code> declaration in a C file.
|
||||
Adding an offset to the name refers to that offset from the symbol's address, so
|
||||
<code>foo+4(SB)</code> is four bytes past the start of <code>foo</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <code>FP</code> pseudo-register is a virtual frame pointer
|
||||
used to refer to function arguments.
|
||||
The compilers maintain a virtual frame pointer and refer to the arguments on the stack as offsets from that pseudo-register.
|
||||
Thus <code>0(FP)</code> is the first argument to the function,
|
||||
<code>8(FP)</code> is the second (on a 64-bit machine), and so on.
|
||||
However, when referring to a function argument this way, it is necessary to place a name
|
||||
at the beginning, as in <code>first_arg+0(FP)</code> and <code>second_arg+8(FP)</code>.
|
||||
(The meaning of the offset—offset from the frame pointer—distinct
|
||||
from its use with <code>SB</code>, where it is an offset from the symbol.)
|
||||
The assembler enforces this convention, rejecting plain <code>0(FP)</code> and <code>8(FP)</code>.
|
||||
The actual name is semantically irrelevant but should be used to document
|
||||
the argument's name.
|
||||
It is worth stressing that <code>FP</code> is always a
|
||||
pseudo-register, not a hardware
|
||||
register, even on architectures with a hardware frame pointer.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For assembly functions with Go prototypes, <code>go</code> <code>vet</code> will check that the argument names
|
||||
and offsets match.
|
||||
On 32-bit systems, the low and high 32 bits of a 64-bit value are distinguished by adding
|
||||
a <code>_lo</code> or <code>_hi</code> suffix to the name, as in <code>arg_lo+0(FP)</code> or <code>arg_hi+4(FP)</code>.
|
||||
If a Go prototype does not name its result, the expected assembly name is <code>ret</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <code>SP</code> pseudo-register is a virtual stack pointer
|
||||
used to refer to frame-local variables and the arguments being
|
||||
prepared for function calls.
|
||||
It points to the top of the local stack frame, so references should use negative offsets
|
||||
in the range [−framesize, 0):
|
||||
<code>x-8(SP)</code>, <code>y-4(SP)</code>, and so on.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
On architectures with a hardware register named <code>SP</code>,
|
||||
the name prefix distinguishes
|
||||
references to the virtual stack pointer from references to the architectural
|
||||
<code>SP</code> register.
|
||||
That is, <code>x-8(SP)</code> and <code>-8(SP)</code>
|
||||
are different memory locations:
|
||||
the first refers to the virtual stack pointer pseudo-register,
|
||||
while the second refers to the
|
||||
hardware's <code>SP</code> register.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
On machines where <code>SP</code> and <code>PC</code> are
|
||||
traditionally aliases for a physical, numbered register,
|
||||
in the Go assembler the names <code>SP</code> and <code>PC</code>
|
||||
are still treated specially;
|
||||
for instance, references to <code>SP</code> require a symbol,
|
||||
much like <code>FP</code>.
|
||||
To access the actual hardware register use the true <code>R</code> name.
|
||||
For example, on the ARM architecture the hardware
|
||||
<code>SP</code> and <code>PC</code> are accessible as
|
||||
<code>R13</code> and <code>R15</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Branches and direct jumps are always written as offsets to the PC, or as
|
||||
jumps to labels:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
label:
|
||||
MOVW $0, R1
|
||||
JMP label
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Each label is visible only within the function in which it is defined.
|
||||
It is therefore permitted for multiple functions in a file to define
|
||||
and use the same label names.
|
||||
Direct jumps and call instructions can target text symbols,
|
||||
such as <code>name(SB)</code>, but not offsets from symbols,
|
||||
such as <code>name+4(SB)</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Instructions, registers, and assembler directives are always in UPPER CASE to remind you
|
||||
that assembly programming is a fraught endeavor.
|
||||
(Exception: the <code>g</code> register renaming on ARM.)
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In Go object files and binaries, the full name of a symbol is the
|
||||
package path followed by a period and the symbol name:
|
||||
<code>fmt.Printf</code> or <code>math/rand.Int</code>.
|
||||
Because the assembler's parser treats period and slash as punctuation,
|
||||
those strings cannot be used directly as identifier names.
|
||||
Instead, the assembler allows the middle dot character U+00B7
|
||||
and the division slash U+2215 in identifiers and rewrites them to
|
||||
plain period and slash.
|
||||
Within an assembler source file, the symbols above are written as
|
||||
<code>fmt·Printf</code> and <code>math∕rand·Int</code>.
|
||||
The assembly listings generated by the compilers when using the <code>-S</code> flag
|
||||
show the period and slash directly instead of the Unicode replacements
|
||||
required by the assemblers.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Most hand-written assembly files do not include the full package path
|
||||
in symbol names, because the linker inserts the package path of the current
|
||||
object file at the beginning of any name starting with a period:
|
||||
in an assembly source file within the math/rand package implementation,
|
||||
the package's Int function can be referred to as <code>·Int</code>.
|
||||
This convention avoids the need to hard-code a package's import path in its
|
||||
own source code, making it easier to move the code from one location to another.
|
||||
</p>
|
||||
|
||||
<h3 id="directives">Directives</h3>
|
||||
|
||||
<p>
|
||||
The assembler uses various directives to bind text and data to symbol names.
|
||||
For example, here is a simple complete function definition. The <code>TEXT</code>
|
||||
directive declares the symbol <code>runtime·profileloop</code> and the instructions
|
||||
that follow form the body of the function.
|
||||
The last instruction in a <code>TEXT</code> block must be some sort of jump, usually a <code>RET</code> (pseudo-)instruction.
|
||||
(If it's not, the linker will append a jump-to-itself instruction; there is no fallthrough in <code>TEXTs</code>.)
|
||||
After the symbol, the arguments are flags (see below)
|
||||
and the frame size, a constant (but see below):
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
TEXT runtime·profileloop(SB),NOSPLIT,$8
|
||||
MOVQ $runtime·profileloop1(SB), CX
|
||||
MOVQ CX, 0(SP)
|
||||
CALL runtime·externalthreadhandler(SB)
|
||||
RET
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
In the general case, the frame size is followed by an argument size, separated by a minus sign.
|
||||
(It's not a subtraction, just idiosyncratic syntax.)
|
||||
The frame size <code>$24-8</code> states that the function has a 24-byte frame
|
||||
and is called with 8 bytes of argument, which live on the caller's frame.
|
||||
If <code>NOSPLIT</code> is not specified for the <code>TEXT</code>,
|
||||
the argument size must be provided.
|
||||
For assembly functions with Go prototypes, <code>go</code> <code>vet</code> will check that the
|
||||
argument size is correct.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Note that the symbol name uses a middle dot to separate the components and is specified as an offset from the
|
||||
static base pseudo-register <code>SB</code>.
|
||||
This function would be called from Go source for package <code>runtime</code> using the
|
||||
simple name <code>profileloop</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Global data symbols are defined by a sequence of initializing
|
||||
<code>DATA</code> directives followed by a <code>GLOBL</code> directive.
|
||||
Each <code>DATA</code> directive initializes a section of the
|
||||
corresponding memory.
|
||||
The memory not explicitly initialized is zeroed.
|
||||
The general form of the <code>DATA</code> directive is
|
||||
|
||||
<pre>
|
||||
DATA symbol+offset(SB)/width, value
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
which initializes the symbol memory at the given offset and width with the given value.
|
||||
The <code>DATA</code> directives for a given symbol must be written with increasing offsets.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <code>GLOBL</code> directive declares a symbol to be global.
|
||||
The arguments are optional flags and the size of the data being declared as a global,
|
||||
which will have initial value all zeros unless a <code>DATA</code> directive
|
||||
has initialized it.
|
||||
The <code>GLOBL</code> directive must follow any corresponding <code>DATA</code> directives.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For example,
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
DATA divtab<>+0x00(SB)/4, $0xf4f8fcff
|
||||
DATA divtab<>+0x04(SB)/4, $0xe6eaedf0
|
||||
...
|
||||
DATA divtab<>+0x3c(SB)/4, $0x81828384
|
||||
GLOBL divtab<>(SB), RODATA, $64
|
||||
|
||||
GLOBL runtime·tlsoffset(SB), NOPTR, $4
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
declares and initializes <code>divtab<></code>, a read-only 64-byte table of 4-byte integer values,
|
||||
and declares <code>runtime·tlsoffset</code>, a 4-byte, implicitly zeroed variable that
|
||||
contains no pointers.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
There may be one or two arguments to the directives.
|
||||
If there are two, the first is a bit mask of flags,
|
||||
which can be written as numeric expressions, added or or-ed together,
|
||||
or can be set symbolically for easier absorption by a human.
|
||||
Their values, defined in the standard <code>#include</code> file <code>textflag.h</code>, are:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<code>NOPROF</code> = 1
|
||||
<br>
|
||||
(For <code>TEXT</code> items.)
|
||||
Don't profile the marked function. This flag is deprecated.
|
||||
</li>
|
||||
<li>
|
||||
<code>DUPOK</code> = 2
|
||||
<br>
|
||||
It is legal to have multiple instances of this symbol in a single binary.
|
||||
The linker will choose one of the duplicates to use.
|
||||
</li>
|
||||
<li>
|
||||
<code>NOSPLIT</code> = 4
|
||||
<br>
|
||||
(For <code>TEXT</code> items.)
|
||||
Don't insert the preamble to check if the stack must be split.
|
||||
The frame for the routine, plus anything it calls, must fit in the
|
||||
spare space at the top of the stack segment.
|
||||
Used to protect routines such as the stack splitting code itself.
|
||||
</li>
|
||||
<li>
|
||||
<code>RODATA</code> = 8
|
||||
<br>
|
||||
(For <code>DATA</code> and <code>GLOBL</code> items.)
|
||||
Put this data in a read-only section.
|
||||
</li>
|
||||
<li>
|
||||
<code>NOPTR</code> = 16
|
||||
<br>
|
||||
(For <code>DATA</code> and <code>GLOBL</code> items.)
|
||||
This data contains no pointers and therefore does not need to be
|
||||
scanned by the garbage collector.
|
||||
</li>
|
||||
<li>
|
||||
<code>WRAPPER</code> = 32
|
||||
<br>
|
||||
(For <code>TEXT</code> items.)
|
||||
This is a wrapper function and should not count as disabling <code>recover</code>.
|
||||
</li>
|
||||
<li>
|
||||
<code>NEEDCTXT</code> = 64
|
||||
<br>
|
||||
(For <code>TEXT</code> items.)
|
||||
This function is a closure so it uses its incoming context register.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="runtime">Runtime Coordination</h3>
|
||||
|
||||
<p>
|
||||
For garbage collection to run correctly, the runtime must know the
|
||||
location of pointers in all global data and in most stack frames.
|
||||
The Go compiler emits this information when compiling Go source files,
|
||||
but assembly programs must define it explicitly.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A data symbol marked with the <code>NOPTR</code> flag (see above)
|
||||
is treated as containing no pointers to runtime-allocated data.
|
||||
A data symbol with the <code>RODATA</code> flag
|
||||
is allocated in read-only memory and is therefore treated
|
||||
as implicitly marked <code>NOPTR</code>.
|
||||
A data symbol with a total size smaller than a pointer
|
||||
is also treated as implicitly marked <code>NOPTR</code>.
|
||||
It is not possible to define a symbol containing pointers in an assembly source file;
|
||||
such a symbol must be defined in a Go source file instead.
|
||||
Assembly source can still refer to the symbol by name
|
||||
even without <code>DATA</code> and <code>GLOBL</code> directives.
|
||||
A good general rule of thumb is to define all non-<code>RODATA</code>
|
||||
symbols in Go instead of in assembly.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Each function also needs annotations giving the location of
|
||||
live pointers in its arguments, results, and local stack frame.
|
||||
For an assembly function with no pointer results and
|
||||
either no local stack frame or no function calls,
|
||||
the only requirement is to define a Go prototype for the function
|
||||
in a Go source file in the same package. The name of the assembly
|
||||
function must not contain the package name component (for example,
|
||||
function <code>Syscall</code> in package <code>syscall</code> should
|
||||
use the name <code>·Syscall</code> instead of the equivalent name
|
||||
<code>syscall·Syscall</code> in its <code>TEXT</code> directive).
|
||||
For more complex situations, explicit annotation is needed.
|
||||
These annotations use pseudo-instructions defined in the standard
|
||||
<code>#include</code> file <code>funcdata.h</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If a function has no arguments and no results,
|
||||
the pointer information can be omitted.
|
||||
This is indicated by an argument size annotation of <code>$<i>n</i>-0</code>
|
||||
on the <code>TEXT</code> instruction.
|
||||
Otherwise, pointer information must be provided by
|
||||
a Go prototype for the function in a Go source file,
|
||||
even for assembly functions not called directly from Go.
|
||||
(The prototype will also let <code>go</code> <code>vet</code> check the argument references.)
|
||||
At the start of the function, the arguments are assumed
|
||||
to be initialized but the results are assumed uninitialized.
|
||||
If the results will hold live pointers during a call instruction,
|
||||
the function should start by zeroing the results and then
|
||||
executing the pseudo-instruction <code>GO_RESULTS_INITIALIZED</code>.
|
||||
This instruction records that the results are now initialized
|
||||
and should be scanned during stack movement and garbage collection.
|
||||
It is typically easier to arrange that assembly functions do not
|
||||
return pointers or do not contain call instructions;
|
||||
no assembly functions in the standard library use
|
||||
<code>GO_RESULTS_INITIALIZED</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If a function has no local stack frame,
|
||||
the pointer information can be omitted.
|
||||
This is indicated by a local frame size annotation of <code>$0-<i>n</i></code>
|
||||
on the <code>TEXT</code> instruction.
|
||||
The pointer information can also be omitted if the
|
||||
function contains no call instructions.
|
||||
Otherwise, the local stack frame must not contain pointers,
|
||||
and the assembly must confirm this fact by executing the
|
||||
pseudo-instruction <code>NO_LOCAL_POINTERS</code>.
|
||||
Because stack resizing is implemented by moving the stack,
|
||||
the stack pointer may change during any function call:
|
||||
even pointers to stack data must not be kept in local variables.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Assembly functions should always be given Go prototypes,
|
||||
both to provide pointer information for the arguments and results
|
||||
and to let <code>go</code> <code>vet</code> check that
|
||||
the offsets being used to access them are correct.
|
||||
</p>
|
||||
|
||||
<h2 id="architectures">Architecture-specific details</h2>
|
||||
|
||||
<p>
|
||||
It is impractical to list all the instructions and other details for each machine.
|
||||
To see what instructions are defined for a given machine, say ARM,
|
||||
look in the source for the <code>obj</code> support library for
|
||||
that architecture, located in the directory <code>src/cmd/internal/obj/arm</code>.
|
||||
In that directory is a file <code>a.out.go</code>; it contains
|
||||
a long list of constants starting with <code>A</code>, like this:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
const (
|
||||
AAND = obj.ABaseARM + obj.A_ARCHSPECIFIC + iota
|
||||
AEOR
|
||||
ASUB
|
||||
ARSB
|
||||
AADD
|
||||
...
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
This is the list of instructions and their spellings as known to the assembler and linker for that architecture.
|
||||
Each instruction begins with an initial capital <code>A</code> in this list, so <code>AAND</code>
|
||||
represents the bitwise and instruction,
|
||||
<code>AND</code> (without the leading <code>A</code>),
|
||||
and is written in assembly source as <code>AND</code>.
|
||||
The enumeration is mostly in alphabetical order.
|
||||
(The architecture-independent <code>AXXX</code>, defined in the
|
||||
<code>cmd/internal/obj</code> package,
|
||||
represents an invalid instruction).
|
||||
The sequence of the <code>A</code> names has nothing to do with the actual
|
||||
encoding of the machine instructions.
|
||||
The <code>cmd/internal/obj</code> package takes care of that detail.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The instructions for both the 386 and AMD64 architectures are listed in
|
||||
<code>cmd/internal/obj/x86/a.out.go</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The architectures share syntax for common addressing modes such as
|
||||
<code>(R1)</code> (register indirect),
|
||||
<code>4(R1)</code> (register indirect with offset), and
|
||||
<code>$foo(SB)</code> (absolute address).
|
||||
The assembler also supports some (not necessarily all) addressing modes
|
||||
specific to each architecture.
|
||||
The sections below list these.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
One detail evident in the examples from the previous sections is that data in the instructions flows from left to right:
|
||||
<code>MOVQ</code> <code>$0,</code> <code>CX</code> clears <code>CX</code>.
|
||||
This rule applies even on architectures where the conventional notation uses the opposite direction.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Here follow some descriptions of key Go-specific details for the supported architectures.
|
||||
</p>
|
||||
|
||||
<h3 id="x86">32-bit Intel 386</h3>
|
||||
|
||||
<p>
|
||||
The runtime pointer to the <code>g</code> structure is maintained
|
||||
through the value of an otherwise unused (as far as Go is concerned) register in the MMU.
|
||||
A OS-dependent macro <code>get_tls</code> is defined for the assembler if the source includes
|
||||
a special header, <code>go_asm.h</code>:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
#include "go_asm.h"
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Within the runtime, the <code>get_tls</code> macro loads its argument register
|
||||
with a pointer to the <code>g</code> pointer, and the <code>g</code> struct
|
||||
contains the <code>m</code> pointer.
|
||||
The sequence to load <code>g</code> and <code>m</code> using <code>CX</code> looks like this:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
get_tls(CX)
|
||||
MOVL g(CX), AX // Move g into AX.
|
||||
MOVL g_m(AX), BX // Move g.m into BX.
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Addressing modes:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
|
||||
<li>
|
||||
<code>(DI)(BX*2)</code>: The location at address <code>DI</code> plus <code>BX*2</code>.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<code>64(DI)(BX*2)</code>: The location at address <code>DI</code> plus <code>BX*2</code> plus 64.
|
||||
These modes accept only 1, 2, 4, and 8 as scale factors.
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
When using the compiler and assembler's
|
||||
<code>-dynlink</code> or <code>-shared</code> modes,
|
||||
any load or store of a fixed memory location such as a global variable
|
||||
must be assumed to overwrite <code>CX</code>.
|
||||
Therefore, to be safe for use with these modes,
|
||||
assembly sources should typically avoid CX except between memory references.
|
||||
</p>
|
||||
|
||||
<h3 id="amd64">64-bit Intel 386 (a.k.a. amd64)</h3>
|
||||
|
||||
<p>
|
||||
The two architectures behave largely the same at the assembler level.
|
||||
Assembly code to access the <code>m</code> and <code>g</code>
|
||||
pointers on the 64-bit version is the same as on the 32-bit 386,
|
||||
except it uses <code>MOVQ</code> rather than <code>MOVL</code>:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
get_tls(CX)
|
||||
MOVQ g(CX), AX // Move g into AX.
|
||||
MOVQ g_m(AX), BX // Move g.m into BX.
|
||||
</pre>
|
||||
|
||||
<h3 id="arm">ARM</h3>
|
||||
|
||||
<p>
|
||||
The registers <code>R10</code> and <code>R11</code>
|
||||
are reserved by the compiler and linker.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<code>R10</code> points to the <code>g</code> (goroutine) structure.
|
||||
Within assembler source code, this pointer must be referred to as <code>g</code>;
|
||||
the name <code>R10</code> is not recognized.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To make it easier for people and compilers to write assembly, the ARM linker
|
||||
allows general addressing forms and pseudo-operations like <code>DIV</code> or <code>MOD</code>
|
||||
that may not be expressible using a single hardware instruction.
|
||||
It implements these forms as multiple instructions, often using the <code>R11</code> register
|
||||
to hold temporary values.
|
||||
Hand-written assembly can use <code>R11</code>, but doing so requires
|
||||
being sure that the linker is not also using it to implement any of the other
|
||||
instructions in the function.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
When defining a <code>TEXT</code>, specifying frame size <code>$-4</code>
|
||||
tells the linker that this is a leaf function that does not need to save <code>LR</code> on entry.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The name <code>SP</code> always refers to the virtual stack pointer described earlier.
|
||||
For the hardware register, use <code>R13</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Condition code syntax is to append a period and the one- or two-letter code to the instruction,
|
||||
as in <code>MOVW.EQ</code>.
|
||||
Multiple codes may be appended: <code>MOVM.IA.W</code>.
|
||||
The order of the code modifiers is irrelevant.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Addressing modes:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
|
||||
<li>
|
||||
<code>R0->16</code>
|
||||
<br>
|
||||
<code>R0>>16</code>
|
||||
<br>
|
||||
<code>R0<<16</code>
|
||||
<br>
|
||||
<code>R0@>16</code>:
|
||||
For <code><<</code>, left shift <code>R0</code> by 16 bits.
|
||||
The other codes are <code>-></code> (arithmetic right shift),
|
||||
<code>>></code> (logical right shift), and
|
||||
<code>@></code> (rotate right).
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<code>R0->R1</code>
|
||||
<br>
|
||||
<code>R0>>R1</code>
|
||||
<br>
|
||||
<code>R0<<R1</code>
|
||||
<br>
|
||||
<code>R0@>R1</code>:
|
||||
For <code><<</code>, left shift <code>R0</code> by the count in <code>R1</code>.
|
||||
The other codes are <code>-></code> (arithmetic right shift),
|
||||
<code>>></code> (logical right shift), and
|
||||
<code>@></code> (rotate right).
|
||||
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<code>[R0,g,R12-R15]</code>: For multi-register instructions, the set comprising
|
||||
<code>R0</code>, <code>g</code>, and <code>R12</code> through <code>R15</code> inclusive.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<code>(R5, R6)</code>: Destination register pair.
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
|
||||
<h3 id="arm64">ARM64</h3>
|
||||
|
||||
<p>
|
||||
The ARM64 port is in an experimental state.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Instruction modifiers are appended to the instruction following a period.
|
||||
The only modifiers are <code>P</code> (postincrement) and <code>W</code>
|
||||
(preincrement):
|
||||
<code>MOVW.P</code>, <code>MOVW.W</code>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Addressing modes:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
|
||||
<li>
|
||||
<code>(R5, R6)</code>: Register pair for <code>LDP</code>/<code>STP</code>.
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
|
||||
<h3 id="ppc64">64-bit PowerPC, a.k.a. ppc64</h3>
|
||||
|
||||
<p>
|
||||
The 64-bit PowerPC port is in an experimental state.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Addressing modes:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
|
||||
<li>
|
||||
<code>(R5)(R6*1)</code>: The location at <code>R5</code> plus <code>R6</code>. It is a scaled
|
||||
mode as on the x86, but the only scale allowed is <code>1</code>.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<code>(R5+R6)</code>: Alias for (R5)(R6*1)
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
|
||||
<h3 id="s390x">IBM z/Architecture, a.k.a. s390x</h3>
|
||||
|
||||
<p>
|
||||
The registers <code>R10</code> and <code>R11</code> are reserved.
|
||||
The assembler uses them to hold temporary values when assembling some instructions.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<code>R13</code> points to the <code>g</code> (goroutine) structure.
|
||||
This register must be referred to as <code>g</code>; the name <code>R13</code> is not recognized.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<code>R15</code> points to the stack frame and should typically only be accessed using the
|
||||
virtual registers <code>SP</code> and <code>FP</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Load- and store-multiple instructions operate on a range of registers.
|
||||
The range of registers is specified by a start register and an end register.
|
||||
For example, <code>LMG</code> <code>(R9),</code> <code>R5,</code> <code>R7</code> would load
|
||||
<code>R5</code>, <code>R6</code> and <code>R7</code> with the 64-bit values at
|
||||
<code>0(R9)</code>, <code>8(R9)</code> and <code>16(R9)</code> respectively.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Storage-and-storage instructions such as <code>MVC</code> and <code>XC</code> are written
|
||||
with the length as the first argument.
|
||||
For example, <code>XC</code> <code>$8,</code> <code>(R9),</code> <code>(R9)</code> would clear
|
||||
eight bytes at the address specified in <code>R9</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If a vector instruction takes a length or an index as an argument then it will be the
|
||||
first argument.
|
||||
For example, <code>VLEIF</code> <code>$1,</code> <code>$16,</code> <code>V2</code> will load
|
||||
the value sixteen into index one of <code>V2</code>.
|
||||
Care should be taken when using vector instructions to ensure that they are available at
|
||||
runtime.
|
||||
To use vector instructions a machine must have both the vector facility (bit 129 in the
|
||||
facility list) and kernel support.
|
||||
Without kernel support a vector instruction will have no effect (it will be equivalent
|
||||
to a <code>NOP</code> instruction).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Addressing modes:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
|
||||
<li>
|
||||
<code>(R5)(R6*1)</code>: The location at <code>R5</code> plus <code>R6</code>.
|
||||
It is a scaled mode as on the x86, but the only scale allowed is <code>1</code>.
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
|
||||
<h3 id="unsupported_opcodes">Unsupported opcodes</h3>
|
||||
|
||||
<p>
|
||||
The assemblers are designed to support the compiler so not all hardware instructions
|
||||
are defined for all architectures: if the compiler doesn't generate it, it might not be there.
|
||||
If you need to use a missing instruction, there are two ways to proceed.
|
||||
One is to update the assembler to support that instruction, which is straightforward
|
||||
but only worthwhile if it's likely the instruction will be used again.
|
||||
Instead, for simple one-off cases, it's possible to use the <code>BYTE</code>
|
||||
and <code>WORD</code> directives
|
||||
to lay down explicit data into the instruction stream within a <code>TEXT</code>.
|
||||
Here's how the 386 runtime defines the 64-bit atomic load function.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
// uint64 atomicload64(uint64 volatile* addr);
|
||||
// so actually
|
||||
// void atomicload64(uint64 *res, uint64 volatile *addr);
|
||||
TEXT runtime·atomicload64(SB), NOSPLIT, $0-12
|
||||
MOVL ptr+0(FP), AX
|
||||
TESTL $7, AX
|
||||
JZ 2(PC)
|
||||
MOVL 0, AX // crash with nil ptr deref
|
||||
LEAL ret_lo+4(FP), BX
|
||||
// MOVQ (%EAX), %MM0
|
||||
BYTE $0x0f; BYTE $0x6f; BYTE $0x00
|
||||
// MOVQ %MM0, 0(%EBX)
|
||||
BYTE $0x0f; BYTE $0x7f; BYTE $0x03
|
||||
// EMMS
|
||||
BYTE $0x0F; BYTE $0x77
|
||||
RET
|
||||
</pre>
|
||||
26
doc/cmd.html
26
doc/cmd.html
@@ -27,9 +27,9 @@ the go <code>tool</code> subcommand.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Finally the <code>fmt</code> and <code>godoc</code> commands are installed
|
||||
as regular binaries called <code>gofmt</code> and <code>godoc</code> because
|
||||
they are so often referenced.
|
||||
Finally, two of the commands, <code>fmt</code> and <code>doc</code>, are also
|
||||
installed as regular binaries called <code>gofmt</code> and <code>godoc</code>
|
||||
because they are so often referenced.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@@ -61,13 +61,6 @@ details.
|
||||
<td>Cgo enables the creation of Go packages that call C code.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><a href="//godoc.org/golang.org/x/tools/cmd/cover/">cover</a></td>
|
||||
<td> </td>
|
||||
<td>Cover is a program for creating and analyzing the coverage profiles
|
||||
generated by <code>"go test -coverprofile"</code>.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><a href="/cmd/fix/">fix</a></td>
|
||||
<td> </td>
|
||||
@@ -75,6 +68,13 @@ generated by <code>"go test -coverprofile"</code>.</td>
|
||||
and rewrites them to use newer ones.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><a href="/cmd/go/">doc</a></td>
|
||||
<td> </td>
|
||||
<td>Doc extracts and generates documentation for Go packages, it is also available as
|
||||
an independent <a href="/cmd/godoc/">godoc</a> command with more general options.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><a href="/cmd/go/">fmt</a></td>
|
||||
<td> </td>
|
||||
@@ -82,12 +82,6 @@ and rewrites them to use newer ones.</td>
|
||||
gofmt</a> command with more general options.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><a href="//godoc.org/golang.org/x/tools/cmd/godoc/">godoc</a></td>
|
||||
<td> </td>
|
||||
<td>Godoc extracts and generates documentation for Go packages.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><a href="/cmd/vet/">vet</a></td>
|
||||
<td> </td>
|
||||
|
||||
805
doc/code.html
805
doc/code.html
@@ -6,436 +6,139 @@
|
||||
|
||||
<p>
|
||||
This document demonstrates the development of a simple Go package and
|
||||
introduces the <a href="/cmd/go/">go tool</a>, the standard way to fetch,
|
||||
introduces the <a href="/cmd/go/">go command</a>, the standard way to fetch,
|
||||
build, and install Go packages and commands.
|
||||
</p>
|
||||
|
||||
|
||||
<h2 id="GOPATH">Code organization</h2>
|
||||
|
||||
<h3><code>GOPATH</code> and workspaces</h3>
|
||||
|
||||
<p>
|
||||
The <code>go</code> tool requires you to organize your code in a specific
|
||||
way. Please read this document carefully.
|
||||
It explains the simplest way to get up and running with your Go installation.
|
||||
One of Go's design goals is to make writing software easier. To that end, the
|
||||
<code>go</code> command doesn't use Makefiles or other configuration files to
|
||||
guide program construction. Instead, it uses the source code to find
|
||||
dependencies and determine build conditions. This means your source code and
|
||||
build scripts are always in sync; they are one and the same.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A similar explanation is available as a
|
||||
<a href="//www.youtube.com/watch?v=XCsL89YtqCs">screencast</a>.
|
||||
The one thing you must do is set a <code>GOPATH</code> environment variable.
|
||||
<code>GOPATH</code> tells the <code>go</code> command (and other related tools)
|
||||
where to find and install the Go packages on your system.
|
||||
</p>
|
||||
|
||||
|
||||
<h2 id="Organization">Code organization</h2>
|
||||
|
||||
<h3 id="Overview">Overview</h3>
|
||||
|
||||
<ul>
|
||||
<li>Go programmers typically keep all their Go code in a single <i>workspace</i>.</li>
|
||||
<li>A workspace contains many version control <i>repositories</i>
|
||||
(managed by Git, for example).</li>
|
||||
<li>Each repository contains one or more <i>packages</i>.</li>
|
||||
<li>Each package consists of one or more Go source files in a single directory.</li>
|
||||
<li>The path to a package's directory determines its <i>import path</i>.</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Note that this differs from other programming environments in which every
|
||||
project has a separate workspace and workspaces are closely tied to version
|
||||
control repositories.
|
||||
<code>GOPATH</code> is a list of paths. It shares the syntax of your system's
|
||||
<code>PATH</code> environment variable. A typical <code>GOPATH</code> on
|
||||
a Unix system might look like this:
|
||||
</p>
|
||||
|
||||
<h3 id="Workspaces">Workspaces</h3>
|
||||
<pre>
|
||||
GOPATH=/home/user/ext:/home/user/mygo
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
A workspace is a directory hierarchy with three directories at its root:
|
||||
(On a Windows system use semicolons as the path separator instead of colons.)
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Each path in the list (in this case <code>/home/user/ext</code> or
|
||||
<code>/home/user/mygo</code>) specifies the location of a <i>workspace</i>.
|
||||
A workspace contains Go source files and their associated package objects, and
|
||||
command executables. It has a prescribed structure of three subdirectories:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li><code>src</code> contains Go source files,
|
||||
<li><code>pkg</code> contains package objects, and
|
||||
<li><code>pkg</code> contains compiled package objects, and
|
||||
<li><code>bin</code> contains executable commands.
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
The <code>go</code> tool builds source packages and installs the resulting
|
||||
binaries to the <code>pkg</code> and <code>bin</code> directories.
|
||||
Subdirectories of the <code>src</code> directory hold independent packages, and
|
||||
all source files (<code>.go</code>, <code>.c</code>, <code>.h</code>, and
|
||||
<code>.s</code>) in each subdirectory are elements of that subdirectory's
|
||||
package.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <code>src</code> subdirectory typically contains multiple version control
|
||||
repositories (such as for Git or Mercurial) that track the development of one
|
||||
or more source packages.
|
||||
When building a program that imports the package "<code>widget</code>" the
|
||||
<code>go</code> command looks for <code>src/pkg/widget</code> inside the Go root,
|
||||
and then—if the package source isn't found there—it searches
|
||||
for <code>src/widget</code> inside each workspace in order.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To give you an idea of how a workspace looks in practice, here's an example:
|
||||
Multiple workspaces can offer some flexibility and convenience, but for now
|
||||
we'll concern ourselves with only a single workspace.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Let's work through a simple example. First, create a <code>$HOME/mygo</code>
|
||||
directory and its <code>src</code> subdirectory:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
bin/
|
||||
hello # command executable
|
||||
outyet # command executable
|
||||
pkg/
|
||||
linux_amd64/
|
||||
github.com/golang/example/
|
||||
stringutil.a # package object
|
||||
src/
|
||||
<a href="https://github.com/golang/example/">github.com/golang/example/</a>
|
||||
.git/ # Git repository metadata
|
||||
hello/
|
||||
hello.go # command source
|
||||
outyet/
|
||||
main.go # command source
|
||||
main_test.go # test source
|
||||
stringutil/
|
||||
reverse.go # package source
|
||||
reverse_test.go # test source
|
||||
<a href="https://golang.org/x/image/">golang.org/x/image/</a>
|
||||
.git/ # Git repository metadata
|
||||
bmp/
|
||||
reader.go # package source
|
||||
writer.go # package source
|
||||
... (many more repositories and packages omitted) ...
|
||||
$ mkdir -p $HOME/mygo/src # create a place to put source code
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The tree above shows a workspace containing two repositories
|
||||
(<code>example</code> and <code>image</code>).
|
||||
The <code>example</code> repository contains two commands (<code>hello</code>
|
||||
and <code>outyet</code>) and one library (<code>stringutil</code>).
|
||||
The <code>image</code> repository contains the <code>bmp</code> package
|
||||
and <a href="https://godoc.org/golang.org/x/image">several others</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A typical workspace contains many source repositories containing many
|
||||
packages and commands. Most Go programmers keep <i>all</i> their Go source code
|
||||
and dependencies in a single workspace.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Commands and libraries are built from different kinds of source packages.
|
||||
We will discuss the distinction <a href="#PackageNames">later</a>.
|
||||
</p>
|
||||
|
||||
|
||||
<h3 id="GOPATH">The <code>GOPATH</code> environment variable</h3>
|
||||
|
||||
<p>
|
||||
The <code>GOPATH</code> environment variable specifies the location of your
|
||||
workspace. It is likely the only environment variable you'll need to set
|
||||
when developing Go code.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To get started, create a workspace directory and set <code>GOPATH</code>
|
||||
accordingly. Your workspace can be located wherever you like, but we'll use
|
||||
<code>$HOME/work</code> in this document. Note that this must <b>not</b> be the
|
||||
same path as your Go installation.
|
||||
(Another common setup is to set <code>GOPATH=$HOME</code>.)
|
||||
Next, set it as the <code>GOPATH</code>. You should also add the
|
||||
<code>bin</code> subdirectory to your <code>PATH</code> environment variable so
|
||||
that you can run the commands therein without specifying their full path.
|
||||
To do this, add the following lines to <code>$HOME/.profile</code> (or
|
||||
equivalent):
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ <b>mkdir $HOME/work</b>
|
||||
$ <b>export GOPATH=$HOME/work</b>
|
||||
export GOPATH=$HOME/mygo
|
||||
export PATH=$PATH:$HOME/mygo/bin
|
||||
</pre>
|
||||
|
||||
|
||||
<h3>Import paths</h3>
|
||||
|
||||
<p>
|
||||
For convenience, add the workspace's <code>bin</code> subdirectory
|
||||
to your <code>PATH</code>:
|
||||
The standard packages are given short import paths such as <code>"fmt"</code>
|
||||
and <code>"net/http"</code> for convenience.
|
||||
For your own projects, it is important to choose a base import path that is
|
||||
unlikely to collide with future additions to the standard library or other
|
||||
external libraries.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The best way to choose an import path is to use the location of your version
|
||||
control repository.
|
||||
For instance, if your source repository is at <code>example.com</code>
|
||||
or <code>code.google.com/p/example</code>, you should begin your package
|
||||
paths with that URL, as in "<code>example.com/foo/bar</code>" or
|
||||
"<code>code.google.com/p/example/foo/bar</code>".
|
||||
Using this convention, the <code>go</code> command can automatically check out and
|
||||
build the source code by its import path alone.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If you don't intend to install your code in this way, you should at
|
||||
least use a unique prefix like "<code>widgets/</code>", as in
|
||||
"<code>widgets/foo/bar</code>". A good rule is to use a prefix such as your
|
||||
company or project name, since it is unlikely to be used by another group.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
We'll use <code>example/</code> as our base import path:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ <b>export PATH=$PATH:$GOPATH/bin</b>
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
To learn more about setting up the <code>GOPATH</code> environment variable,
|
||||
please see
|
||||
<a href="/cmd/go/#hdr-GOPATH_environment_variable"><code>'go help gopath'</code></a>
|
||||
</p>
|
||||
|
||||
<h3 id="ImportPaths">Import paths</h3>
|
||||
|
||||
<p>
|
||||
An <i>import path</i> is a string that uniquely identifies a package.
|
||||
A package's import path corresponds to its location inside a workspace
|
||||
or in a remote repository (explained below).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The packages from the standard library are given short import paths such as
|
||||
<code>"fmt"</code> and <code>"net/http"</code>.
|
||||
For your own packages, you must choose a base path that is unlikely to
|
||||
collide with future additions to the standard library or other external
|
||||
libraries.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If you keep your code in a source repository somewhere, then you should use the
|
||||
root of that source repository as your base path.
|
||||
For instance, if you have a <a href="https://github.com/">GitHub</a> account at
|
||||
<code>github.com/user</code>, that should be your base path.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Note that you don't need to publish your code to a remote repository before you
|
||||
can build it. It's just a good habit to organize your code as if you will
|
||||
publish it someday. In practice you can choose any arbitrary path name,
|
||||
as long as it is unique to the standard library and greater Go ecosystem.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
We'll use <code>github.com/user</code> as our base path. Create a directory
|
||||
inside your workspace in which to keep source code:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ <b>mkdir -p $GOPATH/src/github.com/user</b>
|
||||
$ mkdir -p $GOPATH/src/example
|
||||
</pre>
|
||||
|
||||
|
||||
<h3 id="Command">Your first program</h3>
|
||||
<h3>Package names</h3>
|
||||
|
||||
<p>
|
||||
To compile and run a simple program, first choose a package path (we'll use
|
||||
<code>github.com/user/hello</code>) and create a corresponding package directory
|
||||
inside your workspace:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ <b>mkdir $GOPATH/src/github.com/user/hello</b>
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Next, create a file named <code>hello.go</code> inside that directory,
|
||||
containing the following Go code.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
package main
|
||||
|
||||
import "fmt"
|
||||
|
||||
func main() {
|
||||
fmt.Printf("Hello, world.\n")
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Now you can build and install that program with the <code>go</code> tool:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ <b>go install github.com/user/hello</b>
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Note that you can run this command from anywhere on your system. The
|
||||
<code>go</code> tool finds the source code by looking for the
|
||||
<code>github.com/user/hello</code> package inside the workspace specified by
|
||||
<code>GOPATH</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
You can also omit the package path if you run <code>go install</code> from the
|
||||
package directory:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ <b>cd $GOPATH/src/github.com/user/hello</b>
|
||||
$ <b>go install</b>
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
This command builds the <code>hello</code> command, producing an executable
|
||||
binary. It then installs that binary to the workspace's <code>bin</code>
|
||||
directory as <code>hello</code> (or, under Windows, <code>hello.exe</code>).
|
||||
In our example, that will be <code>$GOPATH/bin/hello</code>, which is
|
||||
<code>$HOME/work/bin/hello</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <code>go</code> tool will only print output when an error occurs, so if
|
||||
these commands produce no output they have executed successfully.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
You can now run the program by typing its full path at the command line:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ <b>$GOPATH/bin/hello</b>
|
||||
Hello, world.
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Or, as you have added <code>$GOPATH/bin</code> to your <code>PATH</code>,
|
||||
just type the binary name:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ <b>hello</b>
|
||||
Hello, world.
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
If you're using a source control system, now would be a good time to initialize
|
||||
a repository, add the files, and commit your first change. Again, this step is
|
||||
optional: you do not need to use source control to write Go code.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ <b>cd $GOPATH/src/github.com/user/hello</b>
|
||||
$ <b>git init</b>
|
||||
Initialized empty Git repository in /home/user/work/src/github.com/user/hello/.git/
|
||||
$ <b>git add hello.go</b>
|
||||
$ <b>git commit -m "initial commit"</b>
|
||||
[master (root-commit) 0b4507d] initial commit
|
||||
1 file changed, 1 insertion(+)
|
||||
create mode 100644 hello.go
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Pushing the code to a remote repository is left as an exercise for the reader.
|
||||
</p>
|
||||
|
||||
|
||||
<h3 id="Library">Your first library</h3>
|
||||
|
||||
<p>
|
||||
Let's write a library and use it from the <code>hello</code> program.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Again, the first step is to choose a package path (we'll use
|
||||
<code>github.com/user/stringutil</code>) and create the package directory:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ <b>mkdir $GOPATH/src/github.com/user/stringutil</b>
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Next, create a file named <code>reverse.go</code> in that directory with the
|
||||
following contents.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
// Package stringutil contains utility functions for working with strings.
|
||||
package stringutil
|
||||
|
||||
// Reverse returns its argument string reversed rune-wise left to right.
|
||||
func Reverse(s string) string {
|
||||
r := []rune(s)
|
||||
for i, j := 0, len(r)-1; i < len(r)/2; i, j = i+1, j-1 {
|
||||
r[i], r[j] = r[j], r[i]
|
||||
}
|
||||
return string(r)
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Now, test that the package compiles with <code>go build</code>:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ <b>go build github.com/user/stringutil</b>
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Or, if you are working in the package's source directory, just:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ <b>go build</b>
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
This won't produce an output file. To do that, you must use <code>go
|
||||
install</code>, which places the package object inside the <code>pkg</code>
|
||||
directory of the workspace.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
After confirming that the <code>stringutil</code> package builds,
|
||||
modify your original <code>hello.go</code> (which is in
|
||||
<code>$GOPATH/src/github.com/user/hello</code>) to use it:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
package main
|
||||
|
||||
import (
|
||||
"fmt"
|
||||
|
||||
<b>"github.com/user/stringutil"</b>
|
||||
)
|
||||
|
||||
func main() {
|
||||
fmt.Printf(stringutil.Reverse("!oG ,olleH"))
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Whenever the <code>go</code> tool installs a package or binary, it also
|
||||
installs whatever dependencies it has.
|
||||
So when you install the <code>hello</code> program
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ <b>go install github.com/user/hello</b>
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
the <code>stringutil</code> package will be installed as well, automatically.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Running the new version of the program, you should see a new, reversed message:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ <b>hello</b>
|
||||
Hello, Go!
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
After the steps above, your workspace should look like this:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
bin/
|
||||
hello # command executable
|
||||
pkg/
|
||||
linux_amd64/ # this will reflect your OS and architecture
|
||||
github.com/user/
|
||||
stringutil.a # package object
|
||||
src/
|
||||
github.com/user/
|
||||
hello/
|
||||
hello.go # command source
|
||||
stringutil/
|
||||
reverse.go # package source
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Note that <code>go install</code> placed the <code>stringutil.a</code> object
|
||||
in a directory inside <code>pkg/linux_amd64</code> that mirrors its source
|
||||
directory.
|
||||
This is so that future invocations of the <code>go</code> tool can find the
|
||||
package object and avoid recompiling the package unnecessarily.
|
||||
The <code>linux_amd64</code> part is there to aid in cross-compilation,
|
||||
and will reflect the operating system and architecture of your system.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Go command executables are statically linked; the package objects need not
|
||||
be present to run Go programs.
|
||||
</p>
|
||||
|
||||
|
||||
<h3 id="PackageNames">Package names</h3>
|
||||
|
||||
<p>
|
||||
The first statement in a Go source file must be
|
||||
The first statement in a Go source file should be
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
@@ -451,24 +154,208 @@ where <code><i>name</i></code> is the package's default name for imports.
|
||||
Go's convention is that the package name is the last element of the
|
||||
import path: the package imported as "<code>crypto/rot13</code>"
|
||||
should be named <code>rot13</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Executable commands must always use <code>package main</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
There is no requirement that package names be unique
|
||||
across all packages linked into a single binary,
|
||||
only that the import paths (their full file names) be unique.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Create a new package under <code>example</code> called <code>newmath</code>:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ cd $GOPATH/src/example
|
||||
$ mkdir newmath
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Then create a file named <code>$GOPATH/src/example/newmath/sqrt.go</code>
|
||||
containing the following Go code:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
// Package newmath is a trivial example package.
|
||||
package newmath
|
||||
|
||||
// Sqrt returns an approximation to the square root of x.
|
||||
func Sqrt(x float64) float64 {
|
||||
// This is a terrible implementation.
|
||||
// Real code should import "math" and use math.Sqrt.
|
||||
z := 0.0
|
||||
for i := 0; i < 1000; i++ {
|
||||
z -= (z*z - x) / (2 * x)
|
||||
}
|
||||
return z
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
This package is imported by the path name of the directory it's in, starting
|
||||
after the <code>src</code> component:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
import "example/newmath"
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
See <a href="/doc/effective_go.html#names">Effective Go</a> to learn more about
|
||||
Go's naming conventions.
|
||||
</p>
|
||||
|
||||
|
||||
<h2>Building and installing</h2>
|
||||
|
||||
<p>
|
||||
The <code>go</code> command comprises several subcommands, the most central being
|
||||
<code>install</code>. Running <code>go install <i>importpath</i></code> builds
|
||||
and installs a package and its dependencies.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To "install a package" means to write the package object or executable command
|
||||
to the <code>pkg</code> or <code>bin</code> subdirectory of the workspace in
|
||||
which the source resides.
|
||||
</p>
|
||||
|
||||
<h3>Building a package</h3>
|
||||
|
||||
<p>
|
||||
To build and install the <code>newmath</code> package, type
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ go install example/newmath
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
This command will produce no output if the package and its dependencies
|
||||
are built and installed correctly.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
As a convenience, the <code>go</code> command will assume the current directory
|
||||
if no import path is specified on the command line. This sequence of commands
|
||||
has the same affect as the one above:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ cd $GOPATH/src/example/newmath
|
||||
$ go install
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The resulting workspace directory tree (assuming we're running Linux on a 64-bit
|
||||
system) looks like this:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
pkg/
|
||||
linux_amd64/
|
||||
example/
|
||||
newmath.a # package object
|
||||
src/
|
||||
example/
|
||||
newmath/
|
||||
sqrt.go # package source
|
||||
</pre>
|
||||
|
||||
|
||||
<h3>Building a command</h3>
|
||||
|
||||
<p>
|
||||
The <code>go</code> command treats code belonging to <code>package main</code> as
|
||||
an executable command and installs the package binary to the
|
||||
<code>GOPATH</code>'s <code>bin</code> subdirectory.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Add a command named <code>hello</code> to the source tree.
|
||||
First create the <code>example/hello</code> directory:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ cd $GOPATH/src/example
|
||||
$ mkdir hello
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Then create the file <code>$GOPATH/src/example/hello/hello.go</code>
|
||||
containing the following Go code.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
// Hello is a trivial example of a main package.
|
||||
package main
|
||||
|
||||
import (
|
||||
"example/newmath"
|
||||
"fmt"
|
||||
)
|
||||
|
||||
func main() {
|
||||
fmt.Printf("Hello, world. Sqrt(2) = %v\n", newmath.Sqrt(2))
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Next, run <code>go install</code>, which builds and installs the binary to
|
||||
<code>$GOPATH/bin</code>:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ go install example/hello
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
To run the program, invoke it by name as you would any other command:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ $GOPATH/bin/hello
|
||||
Hello, world. Sqrt(2) = 1.414213562373095
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
If you added <code>$HOME/mygo/bin</code> to your <code>PATH</code>, you may omit
|
||||
the path to the executable:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ hello
|
||||
Hello, world. Sqrt(2) = 1.414213562373095
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The workspace directory tree now looks like this:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
bin/
|
||||
hello # command executable
|
||||
pkg/
|
||||
linux_amd64/
|
||||
example/
|
||||
newmath.a # package object
|
||||
src/
|
||||
example/
|
||||
hello/
|
||||
hello.go # command source
|
||||
newmath/
|
||||
sqrt.go # package source
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The <code>go</code> command also provides a <code>build</code> command, which is
|
||||
like <code>install</code> except it builds all objects in a temporary directory
|
||||
and does not install them under <code>pkg</code> or <code>bin</code>.
|
||||
When building a command an executable named after the last element of the
|
||||
import path is written to the current directory. When building a package,
|
||||
<code>go build</code> serves merely to test that the package and its
|
||||
dependencies can be built. (The resulting package object is thrown away.)
|
||||
</p>
|
||||
|
||||
|
||||
<h2 id="Testing">Testing</h2>
|
||||
|
||||
<p>
|
||||
@@ -486,54 +373,35 @@ if the function calls a failure function such as <code>t.Error</code> or
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Add a test to the <code>stringutil</code> package by creating the file
|
||||
<code>$GOPATH/src/github.com/user/stringutil/reverse_test.go</code> containing
|
||||
the following Go code.
|
||||
Add a test to the <code>newmath</code> package by creating the file
|
||||
<code>$GOPATH/src/example/newmath/sqrt_test.go</code> containing the following
|
||||
Go code.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
package stringutil
|
||||
package newmath
|
||||
|
||||
import "testing"
|
||||
|
||||
func TestReverse(t *testing.T) {
|
||||
cases := []struct {
|
||||
in, want string
|
||||
}{
|
||||
{"Hello, world", "dlrow ,olleH"},
|
||||
{"Hello, 世界", "界世 ,olleH"},
|
||||
{"", ""},
|
||||
}
|
||||
for _, c := range cases {
|
||||
got := Reverse(c.in)
|
||||
if got != c.want {
|
||||
t.Errorf("Reverse(%q) == %q, want %q", c.in, got, c.want)
|
||||
}
|
||||
}
|
||||
func TestSqrt(t *testing.T) {
|
||||
const in, out = 9, 3
|
||||
if x := Sqrt(in); x != out {
|
||||
t.Errorf("Sqrt(%v) = %v, want %v", in, x, out)
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Then run the test with <code>go test</code>:
|
||||
Now run the test with <code>go test</code>:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ <b>go test github.com/user/stringutil</b>
|
||||
ok github.com/user/stringutil 0.165s
|
||||
$ go test example/newmath
|
||||
ok example/newmath
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
As always, if you are running the <code>go</code> tool from the package
|
||||
directory, you can omit the package path:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ <b>go test</b>
|
||||
ok github.com/user/stringutil 0.165s
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Run <code><a href="/cmd/go/#hdr-Test_packages">go help test</a></code> and see the
|
||||
Run <code><a href="/cmd/go/#Test_packages">go help test</a></code> and see the
|
||||
<a href="/pkg/testing/">testing package documentation</a> for more detail.
|
||||
</p>
|
||||
|
||||
@@ -542,19 +410,19 @@ Run <code><a href="/cmd/go/#hdr-Test_packages">go help test</a></code> and see t
|
||||
|
||||
<p>
|
||||
An import path can describe how to obtain the package source code using a
|
||||
revision control system such as Git or Mercurial. The <code>go</code> tool uses
|
||||
revision control system such as Git or Mercurial. The <code>go</code> command uses
|
||||
this property to automatically fetch packages from remote repositories.
|
||||
For instance, the examples described in this document are also kept in a
|
||||
Git repository hosted at GitHub
|
||||
<code><a href="https://github.com/golang/example">github.com/golang/example</a></code>.
|
||||
Mercurial repository hosted at Google Code,
|
||||
<code><a href="http://code.google.com/p/go.example">code.google.com/p/go.example</a></code>.
|
||||
If you include the repository URL in the package's import path,
|
||||
<code>go get</code> will fetch, build, and install it automatically:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ <b>go get github.com/golang/example/hello</b>
|
||||
$ <b>$GOPATH/bin/hello</b>
|
||||
Hello, Go examples!
|
||||
$ go get code.google.com/p/go.example/hello
|
||||
$ $GOPATH/bin/hello
|
||||
Hello, world. Sqrt(2) = 1.414213562373095
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
@@ -566,67 +434,58 @@ fetch and behaves the same as <code>go install</code>.)
|
||||
|
||||
<p>
|
||||
After issuing the above <code>go get</code> command, the workspace directory
|
||||
tree should now look like this:
|
||||
tree should now now look like this:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
bin/
|
||||
hello # command executable
|
||||
hello # command executable
|
||||
pkg/
|
||||
linux_amd64/
|
||||
github.com/golang/example/
|
||||
stringutil.a # package object
|
||||
github.com/user/
|
||||
stringutil.a # package object
|
||||
linux_amd64/
|
||||
code.google.com/p/go.example/
|
||||
newmath.a # package object
|
||||
example/
|
||||
newmath.a # package object
|
||||
src/
|
||||
github.com/golang/example/
|
||||
.git/ # Git repository metadata
|
||||
code.google.com/p/go.example/
|
||||
hello/
|
||||
hello.go # command source
|
||||
stringutil/
|
||||
reverse.go # package source
|
||||
reverse_test.go # test source
|
||||
github.com/user/
|
||||
hello.go # command source
|
||||
newmath/
|
||||
sqrt.go # package source
|
||||
sqrt_test.go # test source
|
||||
example/
|
||||
hello/
|
||||
hello.go # command source
|
||||
stringutil/
|
||||
reverse.go # package source
|
||||
reverse_test.go # test source
|
||||
hello.go # command source
|
||||
newmath/
|
||||
sqrt.go # package source
|
||||
sqrt_test.go # test source
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The <code>hello</code> command hosted at GitHub depends on the
|
||||
<code>stringutil</code> package within the same repository. The imports in
|
||||
<code>hello.go</code> file use the same import path convention, so the
|
||||
<code>go get</code> command is able to locate and install the dependent
|
||||
package, too.
|
||||
The <code>hello</code> command hosted at Google Code depends on the
|
||||
<code>newmath</code> package within the same repository. The imports in
|
||||
<code>hello.go</code> file use the same import path convention, so the <code>go
|
||||
get</code> command is able to locate and install the dependent package, too.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
import "github.com/golang/example/stringutil"
|
||||
import "code.google.com/p/go.example/newmath"
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
This convention is the easiest way to make your Go packages available for
|
||||
others to use.
|
||||
The <a href="//golang.org/wiki/Projects">Go Wiki</a>
|
||||
and <a href="//godoc.org/">godoc.org</a>
|
||||
provide lists of external Go projects.
|
||||
The <a href="http://godashboard.appspot.com/package">Go Package Dashboard</a>
|
||||
displays a list of packages recently installed with the <code>go</code> command.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For more information on using remote repositories with the <code>go</code> tool, see
|
||||
<code><a href="/cmd/go/#hdr-Remote_import_paths">go help importpath</a></code>.
|
||||
For more information on using remote repositories with the <code>go</code> command, see
|
||||
<code><a href="/cmd/go/#Remote_import_path_syntax">go help remote</a></code>.
|
||||
</p>
|
||||
|
||||
|
||||
<h2 id="next">What's next</h2>
|
||||
|
||||
<p>
|
||||
Subscribe to the
|
||||
<a href="//groups.google.com/group/golang-announce">golang-announce</a>
|
||||
mailing list to be notified when a new stable version of Go is released.
|
||||
</p>
|
||||
<h2 id="more">Further reading</h2>
|
||||
|
||||
<p>
|
||||
See <a href="/doc/effective_go.html">Effective Go</a> for tips on writing
|
||||
@@ -634,7 +493,7 @@ clear, idiomatic Go code.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Take <a href="//tour.golang.org/">A Tour of Go</a> to learn the language
|
||||
Take <a href="http://tour.golang.org/">A Tour of Go</a> to learn the language
|
||||
proper.
|
||||
</p>
|
||||
|
||||
@@ -642,21 +501,3 @@ proper.
|
||||
Visit the <a href="/doc/#articles">documentation page</a> for a set of in-depth
|
||||
articles about the Go language and its libraries and tools.
|
||||
</p>
|
||||
|
||||
|
||||
<h2 id="help">Getting help</h2>
|
||||
|
||||
<p>
|
||||
For real-time help, ask the helpful gophers in <code>#go-nuts</code> on the
|
||||
<a href="http://freenode.net/">Freenode</a> IRC server.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The official mailing list for discussion of the Go language is
|
||||
<a href="//groups.google.com/group/golang-nuts">Go Nuts</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Report bugs using the
|
||||
<a href="//golang.org/issue">Go issue tracker</a>.
|
||||
</p>
|
||||
|
||||
115
doc/codereview_with_mq.html
Normal file
115
doc/codereview_with_mq.html
Normal file
@@ -0,0 +1,115 @@
|
||||
<!--{
|
||||
"Title": "Using Mercurial Queues with Codereview"
|
||||
}-->
|
||||
|
||||
<h2 id="Introduction">Introduction</h2>
|
||||
|
||||
<p>
|
||||
The Mercurial Queues extension (<code>mq</code>) provides a mechanism for
|
||||
managing patches on top of a Mercurial repository and is described in detail
|
||||
in Chapters
|
||||
<a href="http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html">12</a>
|
||||
and <a href="http://hgbook.red-bean.com/read/advanced-uses-of-mercurial-queues.html">13</a>
|
||||
of <a href="http://hgbook.red-bean.com/read/">Mercurial: The Definitive Guide</a>.
|
||||
This document explains how to use <code>mq</code> in conjunction
|
||||
with the <code>codereview</code> Mercurial extension described in the
|
||||
instructions for <a href="contribute.html">contributing to the Go project</a>.
|
||||
It assumes you have read those instructions.
|
||||
</p>
|
||||
|
||||
<h2>Configuration</h2>
|
||||
|
||||
<p>
|
||||
To enable <code>mq</code> edit either <code>$HOME/.hgrc</code> (to enable it
|
||||
for all of your repositories) or <code>$GOROOT/.hg/hgrc</code> (to enable it for the
|
||||
repository at <code>$GOROOT</code>) to add:</p>
|
||||
|
||||
<pre>
|
||||
[extensions]
|
||||
mq=
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Since pulling, pushing, updating and committing while <code>mq</code> patches
|
||||
are applied can damage your repository or a remote one, add these lines to
|
||||
prevent that case:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
[hooks]
|
||||
# Prevent "hg pull" if MQ patches are applied.
|
||||
prechangegroup.mq-no-pull = ! hg qtop > /dev/null 2>&1
|
||||
# Prevent "hg push" if MQ patches are applied.
|
||||
preoutgoing.mq-no-push = ! hg qtop > /dev/null 2>&1
|
||||
# Prevent "hg update" if MQ patches are applied.
|
||||
preupdate.mq-no-update = ! hg qtop > /dev/null 2>&1
|
||||
</pre>
|
||||
|
||||
<h2>Making a change</h2>
|
||||
|
||||
<p>
|
||||
The entire checked-out tree is writable and you can use <code>mq</code>,
|
||||
as documented in Chapter
|
||||
<a href="http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html">12</a>
|
||||
of "The Guide",
|
||||
to implement your change as a single patch or a series of patches.
|
||||
|
||||
</p>
|
||||
|
||||
<p>When you are ready to send a change out for review, run</p>
|
||||
|
||||
<pre>
|
||||
$ hg change
|
||||
</pre>
|
||||
|
||||
<p>from any directory in your Go repository with all of the <code>mq</code> patches relevant to your
|
||||
change applied and then proceed as instructed in <a href="contribute.html">contributing
|
||||
to the Go project</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The change number reported by <code>hg change</code>, preceded by a <code>+</code>,
|
||||
can be used as an <code>mq</code> patch guard to assist in controlling which patches
|
||||
are applied as described in Chapter
|
||||
<a href="http://hgbook.red-bean.com/read/advanced-uses-of-mercurial-queues.html">13</a>
|
||||
of "The Guide".
|
||||
For example, the command:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
for p in $(hg qapplied); do hg qguard $p +99999; done
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
will apply the guard <code>+99999</code> guard to all currently applied <code>mq</code>
|
||||
patches.
|
||||
</p>
|
||||
|
||||
<h2>Synchronizing your client</h2>
|
||||
|
||||
<p>While you were working, others might have submitted changes
|
||||
to the repository and, as explained in <a href="contribute.html">contributing
|
||||
to the Go project</a>, it is necessary to synchronize your repository using
|
||||
<code>hg sync</code>before sending your change list for review.
|
||||
Because <code>hg sync</code> runs <code>hg pull -u</code>,
|
||||
you should not run <code>hg sync</code> while <code>mq</code> patches are
|
||||
applied. Instead
|
||||
pop all your patches before running <code>hg sync</code> and reapply them after
|
||||
it has completed.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
When reapplying the patches, you may need to resolve conflicts
|
||||
as described in <a href="contribute.html">contributing to the Go project</a>.
|
||||
</p>
|
||||
|
||||
<h2>Mailing the change for review</h2>
|
||||
|
||||
<p>
|
||||
You should have all of the <code>mq</code> patches relevant to your
|
||||
change applied when you run <code>hg mail</code>.
|
||||
|
||||
<h2>Submitting the change after the review</h2>
|
||||
|
||||
If you are a committer, you should have all of the <code>mq</code> patches relevant to your
|
||||
change applied when you run <code>hg commit</code>.
|
||||
@@ -1,4 +1,4 @@
|
||||
// Copyright 2010 The Go Authors. All rights reserved.
|
||||
// Copyright 2010 The Go Authors. All rights reserved.
|
||||
// Use of this source code is governed by a BSD-style
|
||||
// license that can be found in the LICENSE file.
|
||||
|
||||
@@ -296,8 +296,8 @@ CodewalkViewer.prototype.updateHeight = function() {
|
||||
this.sizer.height(codeHeight);
|
||||
};
|
||||
|
||||
window.initFuncs.push(function() {
|
||||
var viewer = new CodewalkViewer(jQuery('#codewalk-main'));
|
||||
jQuery(document).ready(function() {
|
||||
var viewer = new CodewalkViewer(jQuery());
|
||||
viewer.selectFirstComment();
|
||||
viewer.targetCommentLinksAtBlank();
|
||||
viewer.installEventHandlers();
|
||||
|
||||
@@ -42,7 +42,7 @@
|
||||
its <code>src</code> is just a file name.
|
||||
</step>
|
||||
|
||||
<step title="Specifying a source line" src='doc/codewalk/codewalk.xml:/title="Title"/'>
|
||||
<step title="Specifiying a source line" src='doc/codewalk/codewalk.xml:/title="Title"/'>
|
||||
The most complex part of the codewalk specification is
|
||||
saying what lines to highlight.
|
||||
Instead of ordinary line numbers,
|
||||
@@ -91,7 +91,7 @@
|
||||
|
||||
The full address syntax is summarized in this table
|
||||
(an excerpt of Table II from
|
||||
<a href="https://9p.io/sys/doc/sam/sam.html">The text editor <code>sam</code></a>):
|
||||
<a href="http://plan9.bell-labs.com/sys/doc/sam/sam.html">The text editor <code>sam</code></a>):
|
||||
<br/><br/>
|
||||
|
||||
<table>
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
// Copyright 2011 The Go Authors. All rights reserved.
|
||||
// Copyright 2011 The Go Authors. All rights reserved.
|
||||
// Use of this source code is governed by a BSD-style
|
||||
// license that can be found in the LICENSE file.
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!--
|
||||
Copyright 2011 The Go Authors. All rights reserved.
|
||||
Copyright 2011 The Go Authors. All rights reserved.
|
||||
Use of this source code is governed by a BSD-style
|
||||
license that can be found in the LICENSE file.
|
||||
-->
|
||||
@@ -58,7 +58,7 @@ Prefix Map key
|
||||
this data.
|
||||
</step>
|
||||
|
||||
<step title="The NewChain constructor function" src="doc/codewalk/markov.go:/func New/,/\n}/">
|
||||
<step title="The NewChain constructor function" src="doc/codewalk/markov.go:/func New/,/}/">
|
||||
The <code>Chain</code> struct has two unexported fields (those that
|
||||
do not begin with an upper case character), and so we write a
|
||||
<code>NewChain</code> constructor function that initializes the
|
||||
@@ -181,7 +181,7 @@ p == Prefix{"am", "not"}</pre>
|
||||
one index to the left (if you consider zero as the leftmost index).
|
||||
<pre>
|
||||
p := Prefix{"I", "am"}
|
||||
copy(p, p[1:])
|
||||
copy(p, p[:1])
|
||||
// p == Prefix{"am", "am"}</pre>
|
||||
We then assign the provided <code>word</code> to the last index
|
||||
of the slice:
|
||||
@@ -215,7 +215,7 @@ p[len(p)-1] = suffix
|
||||
|
||||
<step title="Choosing a suffix at random" src="doc/codewalk/markov.go:/next := choices/,/Shift/">
|
||||
To choose a suffix we use the
|
||||
<code><a href="/pkg/math/rand/#Intn">rand.Intn</a></code> function.
|
||||
<code><a href="/pkg/rand/#Intn">rand.Intn</a></code> function.
|
||||
It returns a random integer up to (but not including) the provided
|
||||
value. Passing in <code>len(choices)</code> gives us a random index
|
||||
into the full length of the list.
|
||||
@@ -287,11 +287,11 @@ a plan a man a plan a canal panama</pre>
|
||||
Here's a transcript of generating some text using the Go distribution's
|
||||
README file as source material:
|
||||
<pre>
|
||||
$ ./markov -words=10 < $GOROOT/README
|
||||
$ ./markov -words=10 < $GOROOT/go/README
|
||||
This is the source code repository for the Go source
|
||||
$ ./markov -prefix=1 -words=10 < $GOROOT/README
|
||||
$ ./markov -prefix=1 -words=10 < $GOROOT/go/README
|
||||
This is the go directory (the one containing this README).
|
||||
$ ./markov -prefix=1 -words=10 < $GOROOT/README
|
||||
$ ./markov -prefix=1 -words=10 < $GOROOT/go/README
|
||||
This is the variable if you have just untarred a</pre>
|
||||
</step>
|
||||
|
||||
|
||||
@@ -23,7 +23,7 @@ type score struct {
|
||||
// An action transitions stochastically to a resulting score.
|
||||
type action func(current score) (result score, turnIsOver bool)
|
||||
|
||||
// roll returns the (result, turnIsOver) outcome of simulating a die roll.
|
||||
// roll returns the (result, turnIsOver) outcome of simulating a die roll.
|
||||
// If the roll value is 1, then thisTurn score is abandoned, and the players'
|
||||
// roles swap. Otherwise, the roll value is added to thisTurn.
|
||||
func roll(s score) (score, bool) {
|
||||
|
||||
@@ -1,21 +0,0 @@
|
||||
#!/usr/bin/env bash
|
||||
# Copyright 2013 The Go Authors. All rights reserved.
|
||||
# Use of this source code is governed by a BSD-style
|
||||
# license that can be found in the LICENSE file.
|
||||
|
||||
set -e
|
||||
|
||||
function fail {
|
||||
echo FAIL: doc/codewalk/$1
|
||||
exit 1
|
||||
}
|
||||
|
||||
# markov.xml
|
||||
echo foo | go run markov.go | grep foo > /dev/null || fail markov
|
||||
|
||||
# functions.xml
|
||||
go run pig.go | grep 'Wins, losses staying at k = 100: 210/990 (21.2%), 780/990 (78.8%)' > /dev/null || fail pig
|
||||
|
||||
# sharemem.xml: only build the example, as it uses the network
|
||||
go build urlpoll.go || fail urlpoll
|
||||
rm -f urlpoll
|
||||
@@ -171,7 +171,7 @@ and/or writes to a shared map.
|
||||
|
||||
<step title="Conclusion" src="doc/codewalk/urlpoll.go">
|
||||
In this codewalk we have explored a simple example of using Go's concurrency
|
||||
primitives to share memory through communication.
|
||||
primitives to share memory through commmunication.
|
||||
<br/><br/>
|
||||
This should provide a starting point from which to explore the ways in which
|
||||
goroutines and channels can be used to write expressive and concise concurrent
|
||||
|
||||
@@ -76,7 +76,7 @@ func (r *Resource) Poll() string {
|
||||
return resp.Status
|
||||
}
|
||||
|
||||
// Sleep sleeps for an appropriate interval (dependent on error state)
|
||||
// Sleep sleeps for an appropriate interval (dependant on error state)
|
||||
// before sending the Resource to done.
|
||||
func (r *Resource) Sleep(done chan<- *Resource) {
|
||||
time.Sleep(pollInterval + errTimeout*time.Duration(r.errCount))
|
||||
|
||||
273
doc/conduct.html
273
doc/conduct.html
@@ -1,273 +0,0 @@
|
||||
<!--{
|
||||
"Title": "Go Community Code of Conduct",
|
||||
"Path": "/conduct",
|
||||
"Template": true
|
||||
}-->
|
||||
|
||||
<style>
|
||||
ul {
|
||||
max-width: 800px;
|
||||
}
|
||||
ul ul {
|
||||
margin: 0 0 5px;
|
||||
}
|
||||
</style>
|
||||
|
||||
<h2 id="about">About the Code of Conduct</h2>
|
||||
|
||||
<h3 id="why">Why have a Code of Conduct?</h3>
|
||||
|
||||
<p>
|
||||
Online communities include people from many different backgrounds.
|
||||
The Go contributors are committed to providing a friendly, safe and welcoming
|
||||
environment for all, regardless of age, disability, gender, nationality,
|
||||
ethnicity, religion, sexuality, or similar personal characteristic.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The first goal of the Code of Conduct is to specify a baseline standard
|
||||
of behavior so that people with different social values and communication
|
||||
styles can talk about Go effectively, productively, and respectfully.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The second goal is to provide a mechanism for resolving conflicts in the
|
||||
community when they arise.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The third goal of the Code of Conduct is to make our community welcoming to
|
||||
people from different backgrounds.
|
||||
Diversity is critical to the project; for Go to be successful, it needs
|
||||
contributors and users from all backgrounds.
|
||||
(See <a href="https://blog.golang.org/open-source">Go, Open Source, Community</a>.)
|
||||
</p>
|
||||
|
||||
<p>
|
||||
With that said, a healthy community must allow for disagreement and debate.
|
||||
The Code of Conduct is not a mechanism for people to silence others with whom
|
||||
they disagree.
|
||||
</p>
|
||||
|
||||
<h3 id="spaces">Where does the Code of Conduct apply?</h3>
|
||||
|
||||
<p>
|
||||
If you participate in or contribute to the Go ecosystem in any way,
|
||||
you are encouraged to follow the Code of Conduct while doing so.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Explicit enforcement of the Code of Conduct applies to the
|
||||
official forums operated by the Go project (“Go spaces”):
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>The official <a href="https://github.com/golang/">GitHub projects</a>
|
||||
and <a href="https://go-review.googlesource.com/">code reviews</a>.
|
||||
<li>The <a href="https://groups.google.com/group/golang-nuts">golang-nuts</a> and
|
||||
<a href="https://groups.google.com/group/golang-dev">golang-dev</a> mailing lists.
|
||||
<li>The #go-nuts IRC channel on Freenode.
|
||||
<li>The <a href="https://reddit.com/r/golang">/r/golang subreddit</a>.
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Other Go groups (such as conferences, meetups, and other unofficial forums) are
|
||||
encouraged to adopt this Code of Conduct. Those groups must provide their own
|
||||
moderators and/or working group (see below).
|
||||
</p>
|
||||
|
||||
<h2 id="values">Gopher values</h2>
|
||||
|
||||
<p>
|
||||
These are the values to which people in the Go community (“Gophers”) should aspire.
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>Be friendly and welcoming
|
||||
<li>Be patient
|
||||
<ul>
|
||||
<li>Remember that people have varying communication styles and that not
|
||||
everyone is using their native language.
|
||||
(Meaning and tone can be lost in translation.)
|
||||
</ul>
|
||||
<li>Be thoughtful
|
||||
<ul>
|
||||
<li>Productive communication requires effort.
|
||||
Think about how your words will be interpreted.
|
||||
<li>Remember that sometimes it is best to refrain entirely from commenting.
|
||||
</ul>
|
||||
<li>Be respectful
|
||||
<ul>
|
||||
<li>In particular, respect differences of opinion.
|
||||
</ul>
|
||||
<li>Be charitable
|
||||
<ul>
|
||||
<li>Interpret the arguments of others in good faith, do not seek to disagree.
|
||||
<li>When we do disagree, try to understand why.
|
||||
</ul>
|
||||
<li>Avoid destructive behavior:
|
||||
<ul>
|
||||
<li>Derailing: stay on topic; if you want to talk about something else,
|
||||
start a new conversation.
|
||||
<li>Unconstructive criticism: don't merely decry the current state of affairs;
|
||||
offer—or at least solicit—suggestions as to how things may be improved.
|
||||
<li>Snarking (pithy, unproductive, sniping comments)
|
||||
<li>Discussing potentially offensive or sensitive issues;
|
||||
this all too often leads to unnecessary conflict.
|
||||
<li>Microaggressions: brief and commonplace verbal, behavioral and
|
||||
environmental indignities that communicate hostile, derogatory or negative
|
||||
slights and insults to a person or group.
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
People are complicated.
|
||||
You should expect to be misunderstood and to misunderstand others;
|
||||
when this inevitably occurs, resist the urge to be defensive or assign blame.
|
||||
Try not to take offense where no offense was intended.
|
||||
Give people the benefit of the doubt.
|
||||
Even if the intent was to provoke, do not rise to it.
|
||||
It is the responsibility of <i>all parties</i> to de-escalate conflict when it arises.
|
||||
</p>
|
||||
|
||||
<h2 id="unwelcome_behavior">Unwelcome behavior</h2>
|
||||
|
||||
<p>
|
||||
These actions are explicitly forbidden in Go spaces:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>Insulting, demeaning, hateful, or threatening remarks.
|
||||
<li>Discrimination based on age, disability, gender, nationality, race,
|
||||
religion, sexuality, or similar personal characteristic.
|
||||
<li>Bullying or systematic harassment.
|
||||
<li>Unwelcome sexual advances.
|
||||
<li>Incitement to any of these.
|
||||
</ul>
|
||||
|
||||
<h2 id="moderation">Moderation</h2>
|
||||
|
||||
<p>
|
||||
The Go spaces are not free speech venues; they are for discussion about Go.
|
||||
These spaces have moderators.
|
||||
The goal of the moderators is to facilitate civil discussion about Go.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
When using the official Go spaces you should act in the spirit of the “Gopher
|
||||
values”.
|
||||
If you conduct yourself in a way that is explicitly forbidden by the CoC,
|
||||
you will be warned and asked to stop.
|
||||
If you do not stop, you will be removed from our community spaces temporarily.
|
||||
Repeated, willful breaches of the CoC will result in a permanent ban.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Moderators are held to a higher standard than other community members.
|
||||
If a moderator creates an inappropriate situation, they should expect less
|
||||
leeway than others, and should expect to be removed from their position if they
|
||||
cannot adhere to the CoC.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Complaints about moderator actions must be handled using the reporting process
|
||||
below.
|
||||
</p>
|
||||
|
||||
<h2 id="reporting">Reporting issues</h2>
|
||||
|
||||
<p>
|
||||
The Code of Conduct Working Group is a group of people that represent the Go
|
||||
community. They are responsible for handling conduct-related issues.
|
||||
Their purpose is to de-escalate conflicts and try to resolve issues to the
|
||||
satisfaction of all parties. They are:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>Aditya Mukerjee <dev@chimeracoder.net>
|
||||
<li>Andrew Gerrand <adg@golang.org>
|
||||
<li>Dave Cheney <dave@cheney.net>
|
||||
<li>Jason Buberel <jbuberel@google.com>
|
||||
<li>Peggy Li <peggyli.224@gmail.com>
|
||||
<li>Sarah Adams <sadams.codes@gmail.com>
|
||||
<li>Steve Francia <steve.francia@gmail.com>
|
||||
<li>Verónica López <gveronicalg@gmail.com>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
If you encounter a conduct-related issue, you should report it to the
|
||||
Working Group using the process described below.
|
||||
<b>Do not</b> post about the issue publicly or try to rally sentiment against a
|
||||
particular individual or group.
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>Mail <a href="mailto:conduct@golang.org">conduct@golang.org</a> or
|
||||
<a href="https://golang.org/s/conduct-report">submit an anonymous report</a>.
|
||||
<ul>
|
||||
<li>Your message will reach the Working Group.
|
||||
<li>Reports are confidential within the Working Group.
|
||||
<li>Should you choose to remain anonymous then the Working Group cannot
|
||||
notify you of the outcome of your report.
|
||||
<li>You may contact a member of the group directly if you do not feel
|
||||
comfortable contacting the group as a whole. That member will then raise
|
||||
the issue with the Working Group as a whole, preserving the privacy of the
|
||||
reporter (if desired).
|
||||
<li>If your report concerns a member of the Working Group they will be recused
|
||||
from Working Group discussions of the report.
|
||||
<li>The Working Group will strive to handle reports with discretion and
|
||||
sensitivity, to protect the privacy of the involved parties,
|
||||
and to avoid conflicts of interest.
|
||||
</ul>
|
||||
<li>You should receive a response within 48 hours (likely sooner).
|
||||
(Should you choose to contact a single Working Group member,
|
||||
it may take longer to receive a response.)
|
||||
<li>The Working Group will meet to review the incident and determine what happened.
|
||||
<ul>
|
||||
<li>With the permission of person reporting the incident, the Working Group
|
||||
may reach out to other community members for more context.
|
||||
</ul>
|
||||
<li>The Working Group will reach a decision as to how to act. These may include:
|
||||
<ul>
|
||||
<li>Nothing.
|
||||
<li>A request for a private or public apology.
|
||||
<li>A private or public warning.
|
||||
<li>An imposed vacation (for instance, asking someone to abstain for a week
|
||||
from a mailing list or IRC).
|
||||
<li>A permanent or temporary ban from some or all Go spaces.
|
||||
</ul>
|
||||
<li>The Working Group will reach out to the original reporter to let them know
|
||||
the decision.
|
||||
<li>Appeals to the decision may be made to the Working Group,
|
||||
or to any of its members directly.
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
<b>Note that the goal of the Code of Conduct and the Working Group is to resolve
|
||||
conflicts in the most harmonious way possible.</b>
|
||||
We hope that in most cases issues may be resolved through polite discussion and
|
||||
mutual agreement.
|
||||
Bannings and other forceful measures are to be employed only as a last resort.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Changes to the Code of Conduct (including to the members of the Working Group)
|
||||
should be proposed using the
|
||||
<a href="https://golang.org/s/proposal-process">change proposal process</a>.
|
||||
</p>
|
||||
|
||||
<h2 id="summary">Summary</h2>
|
||||
|
||||
<ul>
|
||||
<li>Treat everyone with respect and kindness.
|
||||
<li>Be thoughtful in how you communicate.
|
||||
<li>Don’t be destructive or inflammatory.
|
||||
<li>If you encounter an issue, please mail <a href="mailto:conduct@golang.org">conduct@golang.org</a>.
|
||||
</ul>
|
||||
|
||||
<h3 id="acknowledgements">Acknowledgements</h3>
|
||||
|
||||
<p>
|
||||
Parts of this document were derived from the Code of Conduct documents of the
|
||||
Django, FreeBSD, and Rust projects.
|
||||
</p>
|
||||
@@ -9,7 +9,7 @@
|
||||
|
||||
<p>
|
||||
Go is an open source project developed by a team at
|
||||
<a href="//google.com/">Google</a> and many
|
||||
<a href="http://google.com/">Google</a> and many
|
||||
<a href="/CONTRIBUTORS">contributors</a> from the open source community.
|
||||
</p>
|
||||
|
||||
@@ -17,72 +17,49 @@ Go is an open source project developed by a team at
|
||||
Go is distributed under a <a href="/LICENSE">BSD-style license</a>.
|
||||
</p>
|
||||
|
||||
<h3 id="announce"><a href="//groups.google.com/group/golang-announce">Announcements Mailing List</a></h3>
|
||||
<h3 id="announce"><a href="http://groups.google.com/group/golang-announce">Announcements Mailing List</a></h3>
|
||||
<p>
|
||||
A low traffic mailing list for important announcements, such as new releases.
|
||||
</p>
|
||||
<p>
|
||||
We encourage all Go users to subscribe to
|
||||
<a href="//groups.google.com/group/golang-announce">golang-announce</a>.
|
||||
<a href="http://groups.google.com/group/golang-announce">golang-announce</a>.
|
||||
</p>
|
||||
|
||||
|
||||
<h2 id="go1">Version history</h2>
|
||||
|
||||
<h3 id="release"><a href="/doc/devel/release.html">Release History</a></h3>
|
||||
|
||||
<p>A <a href="/doc/devel/release.html">summary</a> of the changes between Go releases. Notes for the major releases:</p>
|
||||
|
||||
<ul>
|
||||
<li><a href="/doc/go1.7">Go 1.7</a> <small>(August 2016)</small></li>
|
||||
<li><a href="/doc/go1.6">Go 1.6</a> <small>(February 2016)</small></li>
|
||||
<li><a href="/doc/go1.5">Go 1.5</a> <small>(August 2015)</small></li>
|
||||
<li><a href="/doc/go1.4">Go 1.4</a> <small>(December 2014)</small></li>
|
||||
<li><a href="/doc/go1.3">Go 1.3</a> <small>(June 2014)</small></li>
|
||||
<li><a href="/doc/go1.2">Go 1.2</a> <small>(December 2013)</small></li>
|
||||
<li><a href="/doc/go1.1">Go 1.1</a> <small>(May 2013)</small></li>
|
||||
<li><a href="/doc/go1">Go 1</a> <small>(March 2012)</small></li>
|
||||
</ul>
|
||||
|
||||
<h3 id="go1compat"><a href="/doc/go1compat">Go 1 and the Future of Go Programs</a></h3>
|
||||
<p>
|
||||
What Go 1 defines and the backwards-compatibility guarantees one can expect as
|
||||
Go 1 matures.
|
||||
</p>
|
||||
|
||||
|
||||
<h2 id="resources">Developer Resources</h2>
|
||||
|
||||
<h3 id="source"><a href="https://golang.org/change">Source Code</a></h3>
|
||||
<h3 id="source"><a href="https://code.google.com/p/go/source">Source Code</a></h3>
|
||||
<p>Check out the Go source code.</p>
|
||||
|
||||
<h3 id="golang-dev"><a href="https://groups.google.com/group/golang-dev">Developer</a> and
|
||||
<a href="https://groups.google.com/group/golang-codereviews">Code Review Mailing List</a></h3>
|
||||
<p>The <a href="https://groups.google.com/group/golang-dev">golang-dev</a>
|
||||
mailing list is for discussing code changes to the Go project.
|
||||
The <a href="https://groups.google.com/group/golang-codereviews">golang-codereviews</a>
|
||||
mailing list is for actual reviewing of the code changes (CLs).</p>
|
||||
<h3 id="release"><a href="/doc/devel/release.html">Release History</a></h3>
|
||||
<p>A summary of the changes between Go releases.</p>
|
||||
|
||||
<h3 id="weekly"><a href="/doc/devel/weekly.html">Weekly Snapshot History</a></h3>
|
||||
<p>A summary of the changes between weekly snapshots of Go.</p>
|
||||
|
||||
<h3 id="golang-dev"><a href="http://groups.google.com/group/golang-dev">Developer Mailing List</a></h3>
|
||||
<p>The <a href="http://groups.google.com/group/golang-dev">golang-dev</a>
|
||||
mailing list is for discussing and reviewing code for the Go project.</p>
|
||||
<p>For general discussion of Go programming, see <a
|
||||
href="https://groups.google.com/group/golang-nuts">golang-nuts</a>.</p>
|
||||
href="http://groups.google.com/group/golang-nuts">golang-nuts</a>.</p>
|
||||
|
||||
<h3 id="golang-checkins"><a href="https://groups.google.com/group/golang-checkins">Checkins Mailing List</a></h3>
|
||||
<h3 id="golang-checkins"><a href="http://groups.google.com/group/golang-checkins">Checkins Mailing List</a></h3>
|
||||
<p>A mailing list that receives a message summarizing each checkin to the Go repository.</p>
|
||||
|
||||
<h3 id="build_status"><a href="//build.golang.org/">Build Status</a></h3>
|
||||
<h3 id="build_status"><a href="http://build.golang.org/">Build Status</a></h3>
|
||||
<p>View the status of Go builds across the supported operating
|
||||
systems and architectures.</p>
|
||||
|
||||
|
||||
<h2 id="howto">How you can help</h2>
|
||||
|
||||
<h3><a href="//golang.org/issue">Reporting issues</a></h3>
|
||||
<h3><a href="http://code.google.com/p/go/issues">Reporting issues</a></h3>
|
||||
|
||||
<p>
|
||||
If you spot bugs, mistakes, or inconsistencies in the Go project's code or
|
||||
documentation, please let us know by
|
||||
<a href="//golang.org/issue/new">filing a ticket</a>
|
||||
on our <a href="//golang.org/issue">issue tracker</a>.
|
||||
<a href="http://code.google.com/p/go/issues/entry">filing a ticket</a>
|
||||
on our <a href="http://code.google.com/p/go/issues">issue tracker</a>.
|
||||
(Of course, you should check it's not an existing issue before creating
|
||||
a new one.)
|
||||
</p>
|
||||
@@ -91,18 +68,6 @@ a new one.)
|
||||
We pride ourselves on being meticulous; no issue is too small.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Security-related issues should be reported to
|
||||
<a href="mailto:security@golang.org">security@golang.org</a>.<br>
|
||||
See the <a href="/security">security policy</a> for more details.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Community-related issues should be reported to
|
||||
<a href="mailto:conduct@golang.org">conduct@golang.org</a>.<br>
|
||||
See the <a href="/conduct">Code of Conduct</a> for more details.
|
||||
</p>
|
||||
|
||||
<h3><a href="/doc/contribute.html">Contributing code</a></h3>
|
||||
|
||||
<p>
|
||||
@@ -113,8 +78,31 @@ To get started, read these <a href="/doc/contribute.html">contribution
|
||||
guidelines</a> for information on design, testing, and our code review process.
|
||||
</p>
|
||||
<p>
|
||||
Check <a href="//golang.org/issue">the tracker</a> for
|
||||
Check <a href="http://code.google.com/p/go/issues">the tracker</a> for
|
||||
open issues that interest you. Those labeled
|
||||
<a href="https://github.com/golang/go/issues?q=is%3Aopen+is%3Aissue+label%3Ahelpwanted">helpwanted</a>
|
||||
<a href="http://code.google.com/p/go/issues/list?q=status=HelpWanted">HelpWanted</a>
|
||||
are particularly in need of outside help.
|
||||
</p>
|
||||
|
||||
|
||||
<h2 id="community">The Go Community</h2>
|
||||
|
||||
<h3 id="mailinglist"><a href="http://groups.google.com/group/golang-nuts">Go Nuts Mailing List</a></h3>
|
||||
<p>The <a href="http://groups.google.com/group/golang-nuts">golang-nuts</a>
|
||||
mailing list is for general Go discussion.</p>
|
||||
|
||||
<h3 id="projects"><a href="http://godashboard.appspot.com/project">Go Project Dashboard</a></h3>
|
||||
<p>A list of external Go projects including programs and libraries.</p>
|
||||
|
||||
<h3 id="irc"><a href="irc:irc.freenode.net/go-nuts">Go IRC Channel</a></h3>
|
||||
<p><b>#go-nuts</b> on <b>irc.freenode.net</b> is the official Go IRC channel.</p>
|
||||
|
||||
<h3 id="plus"><a href="https://plus.google.com/101406623878176903605/posts">The Go Programming Language at Google+</a></h3>
|
||||
<p>The Go project's Google+ page.</p>
|
||||
|
||||
<h3 id="twitter"><a href="http://twitter.com/go_nuts">@go_nuts at Twitter</a></h3>
|
||||
<p>The Go project's official Twitter account.</p>
|
||||
|
||||
<h3 id="blog"><a href="http://blog.golang.org/">The Go Blog</a></h3>
|
||||
<p>The official blog of the Go project, featuring news and in-depth articles by
|
||||
the Go team and guests.</p>
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -9,51 +9,27 @@ Besides this overview you might want to consult the
|
||||
<a href="http://sourceware.org/gdb/current/onlinedocs/gdb/">GDB manual</a>.
|
||||
</i></p>
|
||||
|
||||
<p>
|
||||
GDB does not understand Go programs well.
|
||||
The stack management, threading, and runtime contain aspects that differ
|
||||
enough from the execution model GDB expects that they can confuse
|
||||
the debugger, even when the program is compiled with gccgo.
|
||||
As a consequence, although GDB can be useful in some situations, it is
|
||||
not a reliable debugger for Go programs, particularly heavily concurrent ones.
|
||||
Moreover, it is not a priority for the Go project to address these issues, which
|
||||
are difficult.
|
||||
In short, the instructions below should be taken only as a guide to how
|
||||
to use GDB when it works, not as a guarantee of success.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In time, a more Go-centric debugging architecture may be required.
|
||||
</p>
|
||||
|
||||
<h2 id="Introduction">Introduction</h2>
|
||||
|
||||
<p>
|
||||
When you compile and link your Go programs with the <code>gc</code> toolchain
|
||||
on Linux, Mac OS X, FreeBSD or NetBSD, the resulting binaries contain DWARFv3
|
||||
on Linux, Mac OS X or FreeBSD, the resulting binaries contain DWARFv3
|
||||
debugging information that recent versions (>7.1) of the GDB debugger can
|
||||
use to inspect a live process or a core dump.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Pass the <code>'-w'</code> flag to the linker to omit the debug information
|
||||
(for example, <code>go build -ldflags "-w" prog.go</code>).
|
||||
Pass the <code>'-s'</code> flag to the linker to omit the debug information
|
||||
(for example, <code>go build -ldflags "-s" prog.go</code>).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The code generated by the <code>gc</code> compiler includes inlining of
|
||||
function invocations and registerization of variables. These optimizations
|
||||
can sometimes make debugging with <code>gdb</code> harder. To disable them
|
||||
when debugging, pass the flags <code>-gcflags "-N -l"</code> to the
|
||||
<a href="/cmd/go"><code>go</code></a> command used to build the code being
|
||||
debugged.
|
||||
</p>
|
||||
|
||||
<h3 id="Common_Operations">Common Operations</h3>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
Show file and line number for code, set breakpoints and disassemble:
|
||||
Show file and line number for code
|
||||
, set breakpoints and disassemble:
|
||||
<pre>(gdb) <b>list</b>
|
||||
(gdb) <b>list <i>line</i></b>
|
||||
(gdb) <b>list <i>file.go</i>:<i>line</i></b>
|
||||
@@ -120,11 +96,11 @@ For example:
|
||||
|
||||
<p>
|
||||
If you'd like to see how this works, or want to extend it, take a look at <a
|
||||
href="/src/runtime/runtime-gdb.py">src/runtime/runtime-gdb.py</a> in
|
||||
href="/src/pkg/runtime/runtime-gdb.py">src/pkg/runtime/runtime-gdb.py</a> in
|
||||
the Go source distribution. It depends on some special magic types
|
||||
(<code>hash<T,U></code>) and variables (<code>runtime.m</code> and
|
||||
<code>runtime.g</code>) that the linker
|
||||
(<a href="/src/cmd/link/internal/ld/dwarf.go">src/cmd/link/internal/ld/dwarf.go</a>) ensures are described in
|
||||
(<a href="/src/cmd/ld/dwarf.c">src/cmd/ld/dwarf.c</a>) ensures are described in
|
||||
the DWARF code.
|
||||
</p>
|
||||
|
||||
@@ -153,7 +129,7 @@ the form <code>pkg.(*MyType).Meth</code>.
|
||||
<p>
|
||||
In this tutorial we will inspect the binary of the
|
||||
<a href="/pkg/regexp/">regexp</a> package's unit tests. To build the binary,
|
||||
change to <code>$GOROOT/src/regexp</code> and run <code>go test -c</code>.
|
||||
change to <code>$GOROOT/src/pkg/regexp</code> and run <code>go test -c</code>.
|
||||
This should produce an executable file named <code>regexp.test</code>.
|
||||
</p>
|
||||
|
||||
@@ -172,7 +148,7 @@ License GPLv 3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.htm
|
||||
Type "show copying" and "show warranty" for licensing/warranty details.
|
||||
This GDB was configured as "x86_64-linux".
|
||||
|
||||
Reading symbols from /home/user/go/src/regexp/regexp.test...
|
||||
Reading symbols from /home/user/go/src/pkg/regexp/regexp.test...
|
||||
done.
|
||||
Loading Go Runtime support.
|
||||
(gdb)
|
||||
@@ -180,7 +156,7 @@ Loading Go Runtime support.
|
||||
|
||||
<p>
|
||||
The message <code>"Loading Go Runtime support"</code> means that GDB loaded the
|
||||
extension from <code>$GOROOT/src/runtime/runtime-gdb.py</code>.
|
||||
extension from <code>$GOROOT/src/pkg/runtime/runtime-gdb.py</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@@ -196,10 +172,10 @@ $ <b>gdb regexp.test -d $GOROOT</b>
|
||||
If for some reason GDB still can't find that directory or that script, you can load
|
||||
it by hand by telling gdb (assuming you have the go sources in
|
||||
<code>~/go/</code>):
|
||||
</p>
|
||||
<p>
|
||||
|
||||
<pre>
|
||||
(gdb) <b>source ~/go/src/runtime/runtime-gdb.py</b>
|
||||
(gdb) <b>source ~/go/src/pkg/runtime/runtime-gdb.py</b>
|
||||
Loading Go Runtime support.
|
||||
</pre>
|
||||
|
||||
@@ -259,7 +235,7 @@ Set a breakpoint at the <code>TestFind</code> function:
|
||||
|
||||
<pre>
|
||||
(gdb) <b>b 'regexp.TestFind'</b>
|
||||
Breakpoint 1 at 0x424908: file /home/user/go/src/regexp/find_test.go, line 148.
|
||||
Breakpoint 1 at 0x424908: file /home/user/go/src/pkg/regexp/find_test.go, line 148.
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
@@ -268,9 +244,9 @@ Run the program:
|
||||
|
||||
<pre>
|
||||
(gdb) <b>run</b>
|
||||
Starting program: /home/user/go/src/regexp/regexp.test
|
||||
Starting program: /home/user/go/src/pkg/regexp/regexp.test
|
||||
|
||||
Breakpoint 1, regexp.TestFind (t=0xf8404a89c0) at /home/user/go/src/regexp/find_test.go:148
|
||||
Breakpoint 1, regexp.TestFind (t=0xf8404a89c0) at /home/user/go/src/pkg/regexp/find_test.go:148
|
||||
148 func TestFind(t *testing.T) {
|
||||
</pre>
|
||||
|
||||
@@ -297,9 +273,9 @@ Look at the stack trace for where we’ve paused the program:
|
||||
|
||||
<pre>
|
||||
(gdb) <b>bt</b> <i># backtrace</i>
|
||||
#0 regexp.TestFind (t=0xf8404a89c0) at /home/user/go/src/regexp/find_test.go:148
|
||||
#1 0x000000000042f60b in testing.tRunner (t=0xf8404a89c0, test=0x573720) at /home/user/go/src/testing/testing.go:156
|
||||
#2 0x000000000040df64 in runtime.initdone () at /home/user/go/src/runtime/proc.c:242
|
||||
#0 regexp.TestFind (t=0xf8404a89c0) at /home/user/go/src/pkg/regexp/find_test.go:148
|
||||
#1 0x000000000042f60b in testing.tRunner (t=0xf8404a89c0, test=0x573720) at /home/user/go/src/pkg/testing/testing.go:156
|
||||
#2 0x000000000040df64 in runtime.initdone () at /home/user/go/src/pkg/runtime/proc.c:242
|
||||
#3 0x000000f8404a89c0 in ?? ()
|
||||
#4 0x0000000000573720 in ?? ()
|
||||
#5 0x0000000000000000 in ?? ()
|
||||
@@ -311,18 +287,18 @@ The other goroutine, number 1, is stuck in <code>runtime.gosched</code>, blocked
|
||||
|
||||
<pre>
|
||||
(gdb) <b>goroutine 1 bt</b>
|
||||
#0 0x000000000040facb in runtime.gosched () at /home/user/go/src/runtime/proc.c:873
|
||||
#0 0x000000000040facb in runtime.gosched () at /home/user/go/src/pkg/runtime/proc.c:873
|
||||
#1 0x00000000004031c9 in runtime.chanrecv (c=void, ep=void, selected=void, received=void)
|
||||
at /home/user/go/src/runtime/chan.c:342
|
||||
#2 0x0000000000403299 in runtime.chanrecv1 (t=void, c=void) at/home/user/go/src/runtime/chan.c:423
|
||||
at /home/user/go/src/pkg/runtime/chan.c:342
|
||||
#2 0x0000000000403299 in runtime.chanrecv1 (t=void, c=void) at/home/user/go/src/pkg/runtime/chan.c:423
|
||||
#3 0x000000000043075b in testing.RunTests (matchString={void (struct string, struct string, bool *, error *)}
|
||||
0x7ffff7f9ef60, tests= []testing.InternalTest = {...}) at /home/user/go/src/testing/testing.go:201
|
||||
0x7ffff7f9ef60, tests= []testing.InternalTest = {...}) at /home/user/go/src/pkg/testing/testing.go:201
|
||||
#4 0x00000000004302b1 in testing.Main (matchString={void (struct string, struct string, bool *, error *)}
|
||||
0x7ffff7f9ef80, tests= []testing.InternalTest = {...}, benchmarks= []testing.InternalBenchmark = {...})
|
||||
at /home/user/go/src/testing/testing.go:168
|
||||
#5 0x0000000000400dc1 in main.main () at /home/user/go/src/regexp/_testmain.go:98
|
||||
#6 0x00000000004022e7 in runtime.mainstart () at /home/user/go/src/runtime/amd64/asm.s:78
|
||||
#7 0x000000000040ea6f in runtime.initdone () at /home/user/go/src/runtime/proc.c:243
|
||||
at /home/user/go/src/pkg/testing/testing.go:168
|
||||
#5 0x0000000000400dc1 in main.main () at /home/user/go/src/pkg/regexp/_testmain.go:98
|
||||
#6 0x00000000004022e7 in runtime.mainstart () at /home/user/go/src/pkg/runtime/amd64/asm.s:78
|
||||
#7 0x000000000040ea6f in runtime.initdone () at /home/user/go/src/pkg/runtime/proc.c:243
|
||||
#8 0x0000000000000000 in ?? ()
|
||||
</pre>
|
||||
|
||||
@@ -333,7 +309,7 @@ The stack frame shows we’re currently executing the <code>regexp.TestFind</cod
|
||||
<pre>
|
||||
(gdb) <b>info frame</b>
|
||||
Stack level 0, frame at 0x7ffff7f9ff88:
|
||||
rip = 0x425530 in regexp.TestFind (/home/user/go/src/regexp/find_test.go:148);
|
||||
rip = 0x425530 in regexp.TestFind (/home/user/go/src/pkg/regexp/find_test.go:148);
|
||||
saved rip 0x430233
|
||||
called by frame at 0x7ffff7f9ffa8
|
||||
source language minimal.
|
||||
@@ -410,7 +386,7 @@ We can step into the <code>String</code>function call with <code>"s"</code>:
|
||||
|
||||
<pre>
|
||||
(gdb) <b>s</b>
|
||||
regexp.(*Regexp).String (re=0xf84068d070, noname=void) at /home/user/go/src/regexp/regexp.go:97
|
||||
regexp.(*Regexp).String (re=0xf84068d070, noname=void) at /home/user/go/src/pkg/regexp/regexp.go:97
|
||||
97 func (re *Regexp) String() string {
|
||||
</pre>
|
||||
|
||||
@@ -421,12 +397,12 @@ Get a stack trace to see where we are:
|
||||
<pre>
|
||||
(gdb) <b>bt</b>
|
||||
#0 regexp.(*Regexp).String (re=0xf84068d070, noname=void)
|
||||
at /home/user/go/src/regexp/regexp.go:97
|
||||
at /home/user/go/src/pkg/regexp/regexp.go:97
|
||||
#1 0x0000000000425615 in regexp.TestFind (t=0xf840688b60)
|
||||
at /home/user/go/src/regexp/find_test.go:151
|
||||
at /home/user/go/src/pkg/regexp/find_test.go:151
|
||||
#2 0x0000000000430233 in testing.tRunner (t=0xf840688b60, test=0x5747b8)
|
||||
at /home/user/go/src/testing/testing.go:156
|
||||
#3 0x000000000040ea6f in runtime.initdone () at /home/user/go/src/runtime/proc.c:243
|
||||
at /home/user/go/src/pkg/testing/testing.go:156
|
||||
#3 0x000000000040ea6f in runtime.initdone () at /home/user/go/src/pkg/runtime/proc.c:243
|
||||
....
|
||||
</pre>
|
||||
|
||||
|
||||
@@ -1,455 +0,0 @@
|
||||
<!--{
|
||||
"Title": "Pre-Go 1 Release History"
|
||||
}-->
|
||||
|
||||
<p>
|
||||
This page summarizes the changes between stable releases of Go prior to Go 1.
|
||||
See the <a href="release.html">Release History</a> page for notes on recent releases.
|
||||
</p>
|
||||
|
||||
<h2 id="r60">r60 (released 2011/09/07)</h2>
|
||||
|
||||
<p>
|
||||
The r60 release corresponds to
|
||||
<code><a href="weekly.html#2011-08-17">weekly.2011-08-17</a></code>.
|
||||
This section highlights the most significant changes in this release.
|
||||
For a more detailed summary, see the
|
||||
<a href="weekly.html#2011-08-17">weekly release notes</a>.
|
||||
For complete information, see the
|
||||
<a href="//code.google.com/p/go/source/list?r=release-branch.r60">Mercurial change list</a>.
|
||||
</p>
|
||||
|
||||
<h3 id="r60.lang">Language</h3>
|
||||
|
||||
<p>
|
||||
An "else" block is now required to have braces except if the body of the "else"
|
||||
is another "if". Since gofmt always puts those braces in anyway,
|
||||
gofmt-formatted programs will not be affected.
|
||||
To fix other programs, run gofmt.
|
||||
</p>
|
||||
|
||||
<h3 id="r60.pkg">Packages</h3>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/http/">Package http</a>'s URL parsing and query escaping code
|
||||
(such as <code>ParseURL</code> and <code>URLEscape</code>) has been moved to
|
||||
the new <a href="/pkg/url/">url package</a>, with several simplifications to
|
||||
the names. Client code can be updated automatically with gofix.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/image/">Package image</a> has had significant changes made to the
|
||||
<code>Pix</code> field of struct types such as
|
||||
<a href="/pkg/image/#RGBA">image.RGBA</a> and
|
||||
<a href="/pkg/image/#NRGBA">image.NRGBA</a>.
|
||||
The <a href="/pkg/image/#Image">image.Image</a> interface type has not changed,
|
||||
though, and you should not need to change your code if you don't explicitly
|
||||
refer to <code>Pix</code> fields. For example, if you decode a number of images
|
||||
using the <a href="/pkg/image/jpeg/">image/jpeg</a> package, compose them using
|
||||
<a href="/pkg/image/draw/">image/draw</a>, and then encode the result using
|
||||
<a href="/pkg/img/png">image/png</a>, then your code should still work as
|
||||
before.
|
||||
If your code <i>does</i> refer to <code>Pix</code> fields see the
|
||||
<a href="/doc/devel/weekly.html#2011-07-19">weekly.2011-07-19</a>
|
||||
snapshot notes for how to update your code.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/template/">Package template</a> has been replaced with a new
|
||||
templating package (formerly <code>exp/template</code>). The original template
|
||||
package is still available as <a href="/pkg/old/template/">old/template</a>.
|
||||
The <code>old/template</code> package is deprecated and will be removed.
|
||||
The Go tree has been updated to use the new template package. We encourage
|
||||
users of the old template package to switch to the new one. Code that uses
|
||||
<code>template</code> or <code>exp/template</code> will need to change its
|
||||
import lines to <code>"old/template"</code> or <code>"template"</code>,
|
||||
respectively.
|
||||
</p>
|
||||
|
||||
<h3 id="r60.cmd">Tools</h3>
|
||||
|
||||
<p>
|
||||
<a href="/cmd/goinstall/">Goinstall</a> now uses a new tag selection scheme.
|
||||
When downloading or updating, goinstall looks for a tag or branch with the
|
||||
<code>"go."</code> prefix that corresponds to the local Go version. For Go
|
||||
<code>release.r58</code> it looks for <code>go.r58</code>. For
|
||||
<code>weekly.2011-06-03</code> it looks for <code>go.weekly.2011-06-03</code>.
|
||||
If the specific <code>go.X</code> tag or branch is not found, it chooses the
|
||||
closest earlier version. If an appropriate tag or branch is found, goinstall
|
||||
uses that version of the code. Otherwise it uses the default version selected
|
||||
by the version control system. Library authors are encouraged to use the
|
||||
appropriate tag or branch names in their repositories to make their libraries
|
||||
more accessible.
|
||||
</p>
|
||||
|
||||
<h3 id="r60.minor">Minor revisions</h3>
|
||||
|
||||
<p>
|
||||
r60.1 includes a
|
||||
<a href="//golang.org/change/1824581bf62d">linker
|
||||
fix</a>, a pair of
|
||||
<a href="//golang.org/change/9ef4429c2c64">goplay</a>
|
||||
<a href="//golang.org/change/d42ed8c3098e">fixes</a>,
|
||||
and a <code>json</code> package
|
||||
<a href="//golang.org/change/d5e97874fe84">fix</a> and
|
||||
a new
|
||||
<a href="//golang.org/change/4f0e6269213f">struct tag
|
||||
option</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
r60.2
|
||||
<a href="//golang.org/change/ff19536042ac">fixes</a>
|
||||
a memory leak involving maps.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
r60.3 fixes a
|
||||
<a href="//golang.org/change/01fa62f5e4e5">reflect bug</a>.
|
||||
</p>
|
||||
|
||||
<h2 id="r59">r59 (released 2011/08/01)</h2>
|
||||
|
||||
<p>
|
||||
The r59 release corresponds to
|
||||
<code><a href="weekly.html#2011-07-07">weekly.2011-07-07</a></code>.
|
||||
This section highlights the most significant changes in this release.
|
||||
For a more detailed summary, see the
|
||||
<a href="weekly.html#2011-07-07">weekly release notes</a>.
|
||||
For complete information, see the
|
||||
<a href="//code.google.com/p/go/source/list?r=release-branch.r59">Mercurial change list</a>.
|
||||
</p>
|
||||
|
||||
<h3 id="r59.lang">Language</h3>
|
||||
|
||||
<p>
|
||||
This release includes a language change that restricts the use of
|
||||
<code>goto</code>. In essence, a <code>goto</code> statement outside a block
|
||||
cannot jump to a label inside that block. Your code may require changes if it
|
||||
uses <code>goto</code>.
|
||||
See <a href="//golang.org/change/dc6d3cf9279d">this
|
||||
changeset</a> for how the new rule affected the Go tree.
|
||||
</p>
|
||||
|
||||
<h3 id="r59.pkg">Packages</h3>
|
||||
|
||||
<p>
|
||||
As usual, <a href="/cmd/gofix/">gofix</a> will handle the bulk of the rewrites
|
||||
necessary for these changes to package APIs.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/http">Package http</a> has a new
|
||||
<a href="/pkg/http/#FileSystem">FileSystem</a> interface that provides access
|
||||
to files. The <a href="/pkg/http/#FileServer">FileServer</a> helper now takes a
|
||||
<code>FileSystem</code> argument instead of an explicit file system root. By
|
||||
implementing your own <code>FileSystem</code> you can use the
|
||||
<code>FileServer</code> to serve arbitrary data.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/os/">Package os</a>'s <code>ErrorString</code> type has been
|
||||
hidden. Most uses of <code>os.ErrorString</code> can be replaced with
|
||||
<a href="/pkg/os/#NewError">os.NewError</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/reflect/">Package reflect</a> supports a new struct tag scheme
|
||||
that enables sharing of struct tags between multiple packages.
|
||||
In this scheme, the tags must be of the form:
|
||||
</p>
|
||||
<pre>
|
||||
`key:"value" key2:"value2"`
|
||||
</pre>
|
||||
<p>
|
||||
The <a href="/pkg/reflect/#StructField">StructField</a> type's Tag field now
|
||||
has type <a href="/pkg/reflect/#StructTag">StructTag</a>, which has a
|
||||
<code>Get</code> method. Clients of <a href="/pkg/json">json</a> and
|
||||
<a href="/pkg/xml">xml</a> will need to be updated. Code that says
|
||||
</p>
|
||||
<pre>
|
||||
type T struct {
|
||||
X int "name"
|
||||
}
|
||||
</pre>
|
||||
<p>
|
||||
should become
|
||||
</p>
|
||||
<pre>
|
||||
type T struct {
|
||||
X int `json:"name"` // or `xml:"name"`
|
||||
}
|
||||
</pre>
|
||||
<p>
|
||||
Use <a href="/cmd/govet/">govet</a> to identify struct tags that need to be
|
||||
changed to use the new syntax.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/sort/">Package sort</a>'s <code>IntArray</code> type has been
|
||||
renamed to <a href="/pkg/sort/#IntSlice">IntSlice</a>, and similarly for
|
||||
<a href="/pkg/sort/#Float64Slice">Float64Slice</a> and
|
||||
<a href="/pkg/sort/#StringSlice">StringSlice</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/strings/">Package strings</a>'s <code>Split</code> function has
|
||||
itself been split into <a href="/pkg/strings/#Split">Split</a> and
|
||||
<a href="/pkg/strings/#SplitN">SplitN</a>.
|
||||
<code>SplitN</code> is the same as the old <code>Split</code>.
|
||||
The new <code>Split</code> is equivalent to <code>SplitN</code> with a final
|
||||
argument of -1.
|
||||
</p>
|
||||
|
||||
<a href="/pkg/image/draw/">Package image/draw</a>'s
|
||||
<a href="/pkg/image/draw/#Draw">Draw</a> function now takes an additional
|
||||
argument, a compositing operator.
|
||||
If in doubt, use <a href="/pkg/image/draw/#Op">draw.Over</a>.
|
||||
</p>
|
||||
|
||||
<h3 id="r59.cmd">Tools</h3>
|
||||
|
||||
<p>
|
||||
<a href="/cmd/goinstall/">Goinstall</a> now installs packages and commands from
|
||||
arbitrary remote repositories (not just Google Code, Github, and so on).
|
||||
See the <a href="/cmd/goinstall/">goinstall documentation</a> for details.
|
||||
</p>
|
||||
|
||||
<h2 id="r58">r58 (released 2011/06/29)</h2>
|
||||
|
||||
<p>
|
||||
The r58 release corresponds to
|
||||
<code><a href="weekly.html#2011-06-09">weekly.2011-06-09</a></code>
|
||||
with additional bug fixes.
|
||||
This section highlights the most significant changes in this release.
|
||||
For a more detailed summary, see the
|
||||
<a href="weekly.html#2011-06-09">weekly release notes</a>.
|
||||
For complete information, see the
|
||||
<a href="//code.google.com/p/go/source/list?r=release-branch.r58">Mercurial change list</a>.
|
||||
</p>
|
||||
|
||||
<h3 id="r58.lang">Language</h3>
|
||||
|
||||
<p>
|
||||
This release fixes a <a href="//golang.org/change/b720749486e1">use of uninitialized memory in programs that misuse <code>goto</code></a>.
|
||||
</p>
|
||||
|
||||
<h3 id="r58.pkg">Packages</h3>
|
||||
|
||||
<p>
|
||||
As usual, <a href="/cmd/gofix/">gofix</a> will handle the bulk of the rewrites
|
||||
necessary for these changes to package APIs.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/http/">Package http</a> drops the <code>finalURL</code> return
|
||||
value from the <a href="/pkg/http/#Client.Get">Client.Get</a> method. The value
|
||||
is now available via the new <code>Request</code> field on <a
|
||||
href="/pkg/http/#Response">http.Response</a>.
|
||||
Most instances of the type map[string][]string in have been
|
||||
replaced with the new <a href="/pkg/http/#Values">Values</a> type.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/exec/">Package exec</a> has been redesigned with a more
|
||||
convenient and succinct API.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/strconv/">Package strconv</a>'s <a href="/pkg/strconv/#Quote">Quote</a>
|
||||
function now escapes only those Unicode code points not classified as printable
|
||||
by <a href="/pkg/unicode/#IsPrint">unicode.IsPrint</a>.
|
||||
Previously Quote would escape all non-ASCII characters.
|
||||
This also affects the <a href="/pkg/fmt/">fmt</a> package's <code>"%q"</code>
|
||||
formatting directive. The previous quoting behavior is still available via
|
||||
strconv's new <a href="/pkg/strconv/#QuoteToASCII">QuoteToASCII</a> function.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/os/signal/">Package os/signal</a>'s
|
||||
<a href="/pkg/os/#Signal">Signal</a> and
|
||||
<a href="/pkg/os/#UnixSignal">UnixSignal</a> types have been moved to the
|
||||
<a href="/pkg/os/">os</a> package.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/image/draw/">Package image/draw</a> is the new name for
|
||||
<code>exp/draw</code>. The GUI-related code from <code>exp/draw</code> is now
|
||||
located in the <a href="/pkg/exp/gui/">exp/gui</a> package.
|
||||
</p>
|
||||
|
||||
<h3 id="r58.cmd">Tools</h3>
|
||||
|
||||
<p>
|
||||
<a href="/cmd/goinstall/">Goinstall</a> now observes the GOPATH environment
|
||||
variable to build and install your own code and external libraries outside of
|
||||
the Go tree (and avoid writing Makefiles).
|
||||
</p>
|
||||
|
||||
|
||||
<h3 id="r58.minor">Minor revisions</h3>
|
||||
|
||||
<p>r58.1 adds
|
||||
<a href="//golang.org/change/293c25943586">build</a> and
|
||||
<a href="//golang.org/change/bf17e96b6582">runtime</a>
|
||||
changes to make Go run on OS X 10.7 Lion.
|
||||
</p>
|
||||
|
||||
<h2 id="r57">r57 (released 2011/05/03)</h2>
|
||||
|
||||
<p>
|
||||
The r57 release corresponds to
|
||||
<code><a href="weekly.html#2011-04-27">weekly.2011-04-27</a></code>
|
||||
with additional bug fixes.
|
||||
This section highlights the most significant changes in this release.
|
||||
For a more detailed summary, see the
|
||||
<a href="weekly.html#2011-04-27">weekly release notes</a>.
|
||||
For complete information, see the
|
||||
<a href="//code.google.com/p/go/source/list?r=release-branch.r57">Mercurial change list</a>.
|
||||
</p>
|
||||
|
||||
<p>The new <a href="/cmd/gofix">gofix</a> tool finds Go programs that use old APIs and rewrites them to use
|
||||
newer ones. After you update to a new Go release, gofix helps make the
|
||||
necessary changes to your programs. Gofix will handle the http, os, and syscall
|
||||
package changes described below, and we will update the program to keep up with
|
||||
future changes to the libraries.
|
||||
Gofix can’t
|
||||
handle all situations perfectly, so read and test the changes it makes before
|
||||
committing them.
|
||||
See <a href="//blog.golang.org/2011/04/introducing-gofix.html">the gofix blog post</a> for more
|
||||
information.</p>
|
||||
|
||||
<h3 id="r57.lang">Language</h3>
|
||||
|
||||
<p>
|
||||
<a href="/doc/go_spec.html#Receive_operator">Multiple assignment syntax</a> replaces the <code>closed</code> function.
|
||||
The syntax for channel
|
||||
receives allows an optional second assigned value, a boolean value
|
||||
indicating whether the channel is closed. This code:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
v := <-ch
|
||||
if closed(ch) {
|
||||
// channel is closed
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>should now be written as:</p>
|
||||
|
||||
<pre>
|
||||
v, ok := <-ch
|
||||
if !ok {
|
||||
// channel is closed
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p><a href="/doc/go_spec.html#Label_scopes">Unused labels are now illegal</a>, just as unused local variables are.</p>
|
||||
|
||||
<h3 id="r57.pkg">Packages</h3>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/gob/">Package gob</a> will now encode and decode values of types that implement the
|
||||
<a href="/pkg/gob/#GobEncoder">GobEncoder</a> and
|
||||
<a href="/pkg/gob/#GobDecoder">GobDecoder</a> interfaces. This allows types with unexported
|
||||
fields to transmit self-consistent descriptions; examples include
|
||||
<a href="/pkg/big/#Int.GobDecode">big.Int</a> and <a href="/pkg/big/#Rat.GobDecode">big.Rat</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/http/">Package http</a> has been redesigned.
|
||||
For clients, there are new
|
||||
<a href="/pkg/http/#Client">Client</a> and <a href="/pkg/http/#Transport">Transport</a>
|
||||
abstractions that give more control over HTTP details such as headers sent
|
||||
and redirections followed. These abstractions make it easy to implement
|
||||
custom clients that add functionality such as <a href="//code.google.com/p/goauth2/source/browse/oauth/oauth.go">OAuth2</a>.
|
||||
For servers, <a href="/pkg/http/#ResponseWriter">ResponseWriter</a>
|
||||
has dropped its non-essential methods.
|
||||
The Hijack and Flush methods are no longer required;
|
||||
code can test for them by checking whether a specific value implements
|
||||
<a href="/pkg/http/#Hijacker">Hijacker</a> or <a href="/pkg/http/#Flusher">Flusher</a>.
|
||||
The RemoteAddr and UsingTLS methods are replaced by <a href="/pkg/http/#Request">Request</a>'s
|
||||
RemoteAddr and TLS fields.
|
||||
The SetHeader method is replaced by a Header method;
|
||||
its result, of type <a href="/pkg/http/#Header">Header</a>,
|
||||
implements Set and other methods.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/net/">Package net</a>
|
||||
drops the <code>laddr</code> argument from <a href="/pkg/net/#Conn.Dial">Dial</a>
|
||||
and drops the <code>cname</code> return value
|
||||
from <a href="/pkg/net/#LookupHost">LookupHost</a>.
|
||||
The implementation now uses <a href="/cmd/cgo/">cgo</a> to implement
|
||||
network name lookups using the C library getaddrinfo(3)
|
||||
function when possible. This ensures that Go and C programs
|
||||
resolve names the same way and also avoids the OS X
|
||||
application-level firewall.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/os/">Package os</a>
|
||||
introduces simplified <a href="/pkg/os/#File.Open">Open</a>
|
||||
and <a href="/pkg/os/#File.Create">Create</a> functions.
|
||||
The original Open is now available as <a href="/pkg/os/#File.OpenFile">OpenFile</a>.
|
||||
The final three arguments to <a href="/pkg/os/#Process.StartProcess">StartProcess</a>
|
||||
have been replaced by a pointer to a <a href="/pkg/os/#ProcAttr">ProcAttr</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/reflect/">Package reflect</a> has been redesigned.
|
||||
<a href="/pkg/reflect/#Type">Type</a> is now an interface that implements
|
||||
all the possible type methods.
|
||||
Instead of a type switch on a Type <code>t</code>, switch on <code>t.Kind()</code>.
|
||||
<a href="/pkg/reflect/#Value">Value</a> is now a struct value that
|
||||
implements all the possible value methods.
|
||||
Instead of a type switch on a Value <code>v</code>, switch on <code>v.Kind()</code>.
|
||||
Typeof and NewValue are now called <a href="/pkg/reflect/#Type.TypeOf">TypeOf</a> and <a href="/pkg/reflect/#Value.ValueOf">ValueOf</a>
|
||||
To create a writable Value, use <code>New(t).Elem()</code> instead of <code>Zero(t)</code>.
|
||||
See <a href="//golang.org/change/843855f3c026">the change description</a>
|
||||
for the full details.
|
||||
The new API allows a more efficient implementation of Value
|
||||
that avoids many of the allocations required by the previous API.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Remember that gofix will handle the bulk of the rewrites
|
||||
necessary for these changes to package APIs.
|
||||
</p>
|
||||
|
||||
<h3 id="r57.cmd">Tools</h3>
|
||||
|
||||
<p><a href="/cmd/gofix/">Gofix</a>, a new command, is described above.</p>
|
||||
|
||||
<p>
|
||||
<a href="/cmd/gotest/">Gotest</a> is now a Go program instead of a shell script.
|
||||
The new <code>-test.short</code> flag in combination with package testing's Short function
|
||||
allows you to write tests that can be run in normal or “short” mode;
|
||||
all.bash runs tests in short mode to reduce installation time.
|
||||
The Makefiles know about the flag: use <code>make testshort</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The run-time support now implements CPU and memory profiling.
|
||||
Gotest's new
|
||||
<a href="/cmd/gotest/"><code>-test.cpuprofile</code> and
|
||||
<code>-test.memprofile</code> flags</a> make it easy to
|
||||
profile tests.
|
||||
To add profiling to your web server, see the <a href="/pkg/http/pprof/">http/pprof</a>
|
||||
documentation.
|
||||
For other uses, see the <a href="/pkg/runtime/pprof/">runtime/pprof</a> documentation.
|
||||
</p>
|
||||
|
||||
<h3 id="r57.minor">Minor revisions</h3>
|
||||
|
||||
<p>r57.1 fixes a <a href="//golang.org/change/ff2bc62726e7145eb2ecc1e0f076998e4a8f86f0">nil pointer dereference in http.FormFile</a>.</p>
|
||||
<p>r57.2 fixes a <a href="//golang.org/change/063b0ff67d8277df03c956208abc068076818dae">use of uninitialized memory in programs that misuse <code>goto</code></a>.</p>
|
||||
|
||||
<h2 id="r56">r56 (released 2011/03/16)</h2>
|
||||
|
||||
<p>
|
||||
The r56 release was the first stable release and corresponds to
|
||||
<code><a href="weekly.html#2011-03-07">weekly.2011-03-07.1</a></code>.
|
||||
The numbering starts at 56 because before this release,
|
||||
what we now consider weekly snapshots were called releases.
|
||||
</p>
|
||||
@@ -3,222 +3,19 @@
|
||||
}-->
|
||||
|
||||
<p>This page summarizes the changes between official stable releases of Go.
|
||||
The <a href="//golang.org/change">change log</a> has the full details.</p>
|
||||
Between releases we issue less stable
|
||||
<a href="http://blog.golang.org/2011/03/go-becomes-more-stable.html">weekly snapshots</a>.
|
||||
The <a href="weekly.html">weekly snapshot history</a> contains more detail,
|
||||
and the <a href="http://code.google.com/p/go/source/list">Mercurial change log</a>
|
||||
has full details.</p>
|
||||
|
||||
<p>To update to a specific release, use:</p>
|
||||
|
||||
<pre>
|
||||
git pull
|
||||
git checkout <i>release-branch</i>
|
||||
hg pull
|
||||
hg update <i>tag</i>
|
||||
</pre>
|
||||
|
||||
<h2 id="policy">Release Policy</h2>
|
||||
|
||||
<p>
|
||||
Each major Go release obsoletes and ends support for the previous one.
|
||||
For example, if Go 1.5 has been released, then it is the current release
|
||||
and Go 1.4 and earlier are no longer supported.
|
||||
We fix critical problems in the current release as needed by issuing minor revisions
|
||||
(for example, Go 1.5.1, Go 1.5.2, and so on).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
As a special case, we issue minor revisions for critical security problems
|
||||
in both the current release and the previous release.
|
||||
For example, if Go 1.5 is the current release then we will issue minor revisions
|
||||
to fix critical security problems in both Go 1.4 and Go 1.5 as they arise.
|
||||
See the <a href="/security">security policy</a> for more details.
|
||||
</p>
|
||||
|
||||
<h2 id="go1.7">go1.7 (released 2016/08/15)</h2>
|
||||
|
||||
<p>
|
||||
Go 1.7 is a major release of Go.
|
||||
Read the <a href="/doc/go1.7">Go 1.7 Release Notes</a> for more information.
|
||||
</p>
|
||||
|
||||
<h3 id="go1.7.minor">Minor revisions</h3>
|
||||
|
||||
<p>
|
||||
go1.7.1 (released 2016/09/07) includes fixes to the compiler, runtime,
|
||||
documentation, and the <code>compress/flate</code>, <code>hash/crc32</code>,
|
||||
<code>io</code>, <code>net</code>, <code>net/http</code>,
|
||||
<code>path/filepath</code>, <code>reflect</code>, and <code>syscall</code>
|
||||
packages.
|
||||
See the <a href="https://github.com/golang/go/issues?q=milestone%3AGo1.7.1">Go
|
||||
1.7.1 milestone</a> on our issue tracker for details.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
go1.7.2 (released 2016/10/17) includes fixes to the compiler, runtime,
|
||||
and the <code>crypto/cipher</code>, <code>crypto/tls</code>,
|
||||
<code>net/http</code>, and <code>strings</code> packages.
|
||||
See the <a href="https://github.com/golang/go/issues?q=milestone%3AGo1.7.2">Go
|
||||
1.7.2 milestone</a> on our issue tracker for details.
|
||||
</p>
|
||||
|
||||
<h2 id="go1.6">go1.6 (released 2016/02/17)</h2>
|
||||
|
||||
<p>
|
||||
Go 1.6 is a major release of Go.
|
||||
Read the <a href="/doc/go1.6">Go 1.6 Release Notes</a> for more information.
|
||||
</p>
|
||||
|
||||
<h3 id="go1.6.minor">Minor revisions</h3>
|
||||
|
||||
<p>
|
||||
go1.6.1 (released 2016/04/12) includes two security fixes.
|
||||
See the <a href="https://github.com/golang/go/issues?q=milestone%3AGo1.6.1">Go
|
||||
1.6.1 milestone</a> on our issue tracker for details.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
go1.6.2 (released 2016/04/20) includes fixes to the compiler, runtime, tools,
|
||||
documentation, and the <code>mime/multipart</code>, <code>net/http</code>, and
|
||||
<code>sort</code> packages.
|
||||
See the <a href="https://github.com/golang/go/issues?q=milestone%3AGo1.6.2">Go
|
||||
1.6.2 milestone</a> on our issue tracker for details.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
go1.6.3 (released 2016/07/17) includes security fixes to the
|
||||
<code>net/http/cgi</code> package and <code>net/http</code> package when used in
|
||||
a CGI environment.
|
||||
See the <a href="https://github.com/golang/go/issues?q=milestone%3AGo1.6.3">Go
|
||||
1.6.3 milestone</a> on our issue tracker for details.
|
||||
</p>
|
||||
|
||||
<h2 id="go1.5">go1.5 (released 2015/08/19)</h2>
|
||||
|
||||
<p>
|
||||
Go 1.5 is a major release of Go.
|
||||
Read the <a href="/doc/go1.5">Go 1.5 Release Notes</a> for more information.
|
||||
</p>
|
||||
|
||||
<h3 id="go1.5.minor">Minor revisions</h3>
|
||||
|
||||
<p>
|
||||
go1.5.1 (released 2015/09/08) includes bug fixes to the compiler, assembler, and
|
||||
the <code>fmt</code>, <code>net/textproto</code>, <code>net/http</code>, and
|
||||
<code>runtime</code> packages.
|
||||
See the <a href="https://github.com/golang/go/issues?q=milestone%3AGo1.5.1">Go
|
||||
1.5.1 milestone</a> on our issue tracker for details.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
go1.5.2 (released 2015/12/02) includes bug fixes to the compiler, linker, and
|
||||
the <code>mime/multipart</code>, <code>net</code>, and <code>runtime</code>
|
||||
packages.
|
||||
See the <a href="https://github.com/golang/go/issues?q=milestone%3AGo1.5.2">Go
|
||||
1.5.2 milestone</a> on our issue tracker for details.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
go1.5.3 (released 2016/01/13) includes a security fix to the <code>math/big</code> package
|
||||
affecting the <code>crypto/tls</code> package.
|
||||
See the <a href="https://golang.org/s/go153announce">release announcement</a> for details.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
go1.5.4 (released 2016/04/12) includes two security fixes.
|
||||
It contains the same fixes as Go 1.6.1 and was released at the same time.
|
||||
See the <a href="https://github.com/golang/go/issues?q=milestone%3AGo1.6.1">Go
|
||||
1.6.1 milestone</a> on our issue tracker for details.
|
||||
</p>
|
||||
|
||||
<h2 id="go1.4">go1.4 (released 2014/12/10)</h2>
|
||||
|
||||
<p>
|
||||
Go 1.4 is a major release of Go.
|
||||
Read the <a href="/doc/go1.4">Go 1.4 Release Notes</a> for more information.
|
||||
</p>
|
||||
|
||||
<h3 id="go1.4.minor">Minor revisions</h3>
|
||||
|
||||
<p>
|
||||
go1.4.1 (released 2015/01/15) includes bug fixes to the linker and the <code>log</code>, <code>syscall</code>, and <code>runtime</code> packages.
|
||||
See the <a href="https://github.com/golang/go/issues?q=milestone%3AGo1.4.1">Go 1.4.1 milestone on our issue tracker</a> for details.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
go1.4.2 (released 2015/02/17) includes bug fixes to the <code>go</code> command, the compiler and linker, and the <code>runtime</code>, <code>syscall</code>, <code>reflect</code>, and <code>math/big</code> packages.
|
||||
See the <a href="https://github.com/golang/go/issues?q=milestone%3AGo1.4.2">Go 1.4.2 milestone on our issue tracker</a> for details.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
go1.4.3 (released 2015/09/22) includes security fixes to the <code>net/http</code> package and bug fixes to the <code>runtime</code> package.
|
||||
See the <a href="https://github.com/golang/go/issues?q=milestone%3AGo1.4.3">Go 1.4.3 milestone on our issue tracker</a> for details.
|
||||
</p>
|
||||
|
||||
<h2 id="go1.3">go1.3 (released 2014/06/18)</h2>
|
||||
|
||||
<p>
|
||||
Go 1.3 is a major release of Go.
|
||||
Read the <a href="/doc/go1.3">Go 1.3 Release Notes</a> for more information.
|
||||
</p>
|
||||
|
||||
<h3 id="go1.3.minor">Minor revisions</h3>
|
||||
|
||||
<p>
|
||||
go1.3.1 (released 2014/08/13) includes bug fixes to the compiler and the <code>runtime</code>, <code>net</code>, and <code>crypto/rsa</code> packages.
|
||||
See the <a href="https://github.com/golang/go/commits/go1.3.1">change history</a> for details.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
go1.3.2 (released 2014/09/25) includes bug fixes to cgo and the crypto/tls packages.
|
||||
See the <a href="https://github.com/golang/go/commits/go1.3.2">change history</a> for details.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
go1.3.3 (released 2014/09/30) includes further bug fixes to cgo, the runtime package, and the nacl port.
|
||||
See the <a href="https://github.com/golang/go/commits/go1.3.3">change history</a> for details.
|
||||
</p>
|
||||
|
||||
<h2 id="go1.2">go1.2 (released 2013/12/01)</h2>
|
||||
|
||||
<p>
|
||||
Go 1.2 is a major release of Go.
|
||||
Read the <a href="/doc/go1.2">Go 1.2 Release Notes</a> for more information.
|
||||
</p>
|
||||
|
||||
<h3 id="go1.2.minor">Minor revisions</h3>
|
||||
|
||||
<p>
|
||||
go1.2.1 (released 2014/03/02) includes bug fixes to the <code>runtime</code>, <code>net</code>, and <code>database/sql</code> packages.
|
||||
See the <a href="https://github.com/golang/go/commits/go1.2.1">change history</a> for details.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
go1.2.2 (released 2014/05/05) includes a
|
||||
<a href="https://github.com/golang/go/commits/go1.2.2">security fix</a>
|
||||
that affects the tour binary included in the binary distributions (thanks to Guillaume T).
|
||||
</p>
|
||||
|
||||
<h2 id="go1.1">go1.1 (released 2013/05/13)</h2>
|
||||
|
||||
<p>
|
||||
Go 1.1 is a major release of Go.
|
||||
Read the <a href="/doc/go1.1">Go 1.1 Release Notes</a> for more information.
|
||||
</p>
|
||||
|
||||
<h3 id="go1.1.minor">Minor revisions</h3>
|
||||
|
||||
<p>
|
||||
go1.1.1 (released 2013/06/13) includes several compiler and runtime bug fixes.
|
||||
See the <a href="https://github.com/golang/go/commits/go1.1.1">change history</a> for details.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
go1.1.2 (released 2013/08/13) includes fixes to the <code>gc</code> compiler
|
||||
and <code>cgo</code>, and the <code>bufio</code>, <code>runtime</code>,
|
||||
<code>syscall</code>, and <code>time</code> packages.
|
||||
See the <a href="https://github.com/golang/go/commits/go1.1.2">change history</a> for details.
|
||||
If you use package syscall's <code>Getrlimit</code> and <code>Setrlimit</code>
|
||||
functions under Linux on the ARM or 386 architectures, please note change
|
||||
<a href="//golang.org/cl/11803043">11803043</a>
|
||||
that fixes <a href="//golang.org/issue/5949">issue 5949</a>.
|
||||
</p>
|
||||
|
||||
<h2 id="go1">go1 (released 2012/03/28)</h2>
|
||||
|
||||
<p>
|
||||
@@ -238,36 +35,449 @@ The go1 release corresponds to
|
||||
<code><a href="weekly.html#2012-03-27">weekly.2012-03-27</a></code>.
|
||||
</p>
|
||||
|
||||
<h3 id="go1.minor">Minor revisions</h3>
|
||||
<h2 id="r60">r60 (released 2011/09/07)</h2>
|
||||
|
||||
<p>
|
||||
go1.0.1 (released 2012/04/25) was issued to
|
||||
<a href="//golang.org/cl/6061043">fix</a> an
|
||||
<a href="//golang.org/issue/3545">escape analysis bug</a>
|
||||
that can lead to memory corruption.
|
||||
It also includes several minor code and documentation fixes.
|
||||
The r60 release corresponds to
|
||||
<code><a href="weekly.html#2011-08-17">weekly.2011-08-17</a></code>.
|
||||
This section highlights the most significant changes in this release.
|
||||
For a more detailed summary, see the
|
||||
<a href="weekly.html#2011-08-17">weekly release notes</a>.
|
||||
For complete information, see the
|
||||
<a href="http://code.google.com/p/go/source/list?r=release-branch.r60">Mercurial change list</a>.
|
||||
</p>
|
||||
|
||||
<h3 id="r60.lang">Language</h3>
|
||||
|
||||
<p>
|
||||
An "else" block is now required to have braces except if the body of the "else"
|
||||
is another "if". Since gofmt always puts those braces in anyway,
|
||||
gofmt-formatted programs will not be affected.
|
||||
To fix other programs, run gofmt.
|
||||
</p>
|
||||
|
||||
<h3 id="r60.pkg">Packages</h3>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/http/">Package http</a>'s URL parsing and query escaping code
|
||||
(such as <code>ParseURL</code> and <code>URLEscape</code>) has been moved to
|
||||
the new <a href="/pkg/url/">url package</a>, with several simplifications to
|
||||
the names. Client code can be updated automatically with gofix.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
go1.0.2 (released 2012/06/13) was issued to fix two bugs in the implementation
|
||||
of maps using struct or array keys:
|
||||
<a href="//golang.org/issue/3695">issue 3695</a> and
|
||||
<a href="//golang.org/issue/3573">issue 3573</a>.
|
||||
It also includes many minor code and documentation fixes.
|
||||
<a href="/pkg/image/">Package image</a> has had significant changes made to the
|
||||
<code>Pix</code> field of struct types such as
|
||||
<a href="/pkg/image/#RGBA">image.RGBA</a> and
|
||||
<a href="/pkg/image/#NRGBA">image.NRGBA</a>.
|
||||
The <a href="/pkg/image/#Image">image.Image</a> interface type has not changed,
|
||||
though, and you should not need to change your code if you don't explicitly
|
||||
refer to <code>Pix</code> fields. For example, if you decode a number of images
|
||||
using the <a href="/pkg/image/jpeg/">image/jpeg</a> package, compose them using
|
||||
<a href="/pkg/image/draw/">image/draw</a>, and then encode the result using
|
||||
<a href="/pkg/img/png">image/png</a>, then your code should still work as
|
||||
before.
|
||||
If your code <i>does</i> refer to <code>Pix</code> fields see the
|
||||
<a href="/doc/devel/weekly.html#2011-07-19">weekly.2011-07-19</a>
|
||||
snapshot notes for how to update your code.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
go1.0.3 (released 2012/09/21) includes minor code and documentation fixes.
|
||||
<a href="/pkg/template/">Package template</a> has been replaced with a new
|
||||
templating package (formerly <code>exp/template</code>). The original template
|
||||
package is still available as <a href="/pkg/old/template/">old/template</a>.
|
||||
The <code>old/template</code> package is deprecated and will be removed.
|
||||
The Go tree has been updated to use the new template package. We encourage
|
||||
users of the old template package to switch to the new one. Code that uses
|
||||
<code>template</code> or <code>exp/template</code> will need to change its
|
||||
import lines to <code>"old/template"</code> or <code>"template"</code>,
|
||||
respectively.
|
||||
</p>
|
||||
|
||||
<h3 id="r60.cmd">Tools</h3>
|
||||
|
||||
<p>
|
||||
<a href="/cmd/goinstall/">Goinstall</a> now uses a new tag selection scheme.
|
||||
When downloading or updating, goinstall looks for a tag or branch with the
|
||||
<code>"go."</code> prefix that corresponds to the local Go version. For Go
|
||||
<code>release.r58</code> it looks for <code>go.r58</code>. For
|
||||
<code>weekly.2011-06-03</code> it looks for <code>go.weekly.2011-06-03</code>.
|
||||
If the specific <code>go.X</code> tag or branch is not found, it chooses the
|
||||
closest earlier version. If an appropriate tag or branch is found, goinstall
|
||||
uses that version of the code. Otherwise it uses the default version selected
|
||||
by the version control system. Library authors are encouraged to use the
|
||||
appropriate tag or branch names in their repositories to make their libraries
|
||||
more accessible.
|
||||
</p>
|
||||
|
||||
<h3 id="r60.minor">Minor revisions</h3>
|
||||
|
||||
<p>
|
||||
r60.1 includes a
|
||||
<a href="http://code.google.com/p/go/source/detail?r=1824581bf62d">linker
|
||||
fix</a>, a pair of
|
||||
<a href="http://code.google.com/p/go/source/detail?r=9ef4429c2c64">goplay</a>
|
||||
<a href="http://code.google.com/p/go/source/detail?r=d42ed8c3098e">fixes</a>,
|
||||
and a <code>json</code> package
|
||||
<a href="http://code.google.com/p/go/source/detail?r=d5e97874fe84">fix</a> and
|
||||
a new
|
||||
<a href="http://code.google.com/p/go/source/detail?r=4f0e6269213f">struct tag
|
||||
option</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
See the <a href="https://github.com/golang/go/commits/release-branch.go1">go1 release branch history</a> for the complete list of changes.
|
||||
r60.2
|
||||
<a href="http://code.google.com/p/go/source/detail?r=ff19536042ac">fixes</a>
|
||||
a memory leak involving maps.
|
||||
</p>
|
||||
|
||||
<h2 id="pre.go1">Older releases</h2>
|
||||
|
||||
<p>
|
||||
See the <a href="pre_go1.html">Pre-Go 1 Release History</a> page for notes
|
||||
on earlier releases.
|
||||
r60.3 fixes a
|
||||
<a href="http://code.google.com/p/go/source/detail?r=01fa62f5e4e5">reflect bug</a>.
|
||||
</p>
|
||||
|
||||
<h2 id="r59">r59 (released 2011/08/01)</h2>
|
||||
|
||||
<p>
|
||||
The r59 release corresponds to
|
||||
<code><a href="weekly.html#2011-07-07">weekly.2011-07-07</a></code>.
|
||||
This section highlights the most significant changes in this release.
|
||||
For a more detailed summary, see the
|
||||
<a href="weekly.html#2011-07-07">weekly release notes</a>.
|
||||
For complete information, see the
|
||||
<a href="http://code.google.com/p/go/source/list?r=release-branch.r59">Mercurial change list</a>.
|
||||
</p>
|
||||
|
||||
<h3 id="r59.lang">Language</h3>
|
||||
|
||||
<p>
|
||||
This release includes a language change that restricts the use of
|
||||
<code>goto</code>. In essence, a <code>goto</code> statement outside a block
|
||||
cannot jump to a label inside that block. Your code may require changes if it
|
||||
uses <code>goto</code>.
|
||||
See <a href="http://code.google.com/p/go/source/detail?r=dc6d3cf9279d">this
|
||||
changeset</a> for how the new rule affected the Go tree.
|
||||
</p>
|
||||
|
||||
<h3 id="r59.pkg">Packages</h3>
|
||||
|
||||
<p>
|
||||
As usual, <a href="/cmd/gofix/">gofix</a> will handle the bulk of the rewrites
|
||||
necessary for these changes to package APIs.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/http">Package http</a> has a new
|
||||
<a href="/pkg/http/#FileSystem">FileSystem</a> interface that provides access
|
||||
to files. The <a href="/pkg/http/#FileServer">FileServer</a> helper now takes a
|
||||
<code>FileSystem</code> argument instead of an explicit file system root. By
|
||||
implementing your own <code>FileSystem</code> you can use the
|
||||
<code>FileServer</code> to serve arbitrary data.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/os/">Package os</a>'s <code>ErrorString</code> type has been
|
||||
hidden. Most uses of <code>os.ErrorString</code> can be replaced with
|
||||
<a href="/pkg/os/#NewError">os.NewError</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/reflect/">Package reflect</a> supports a new struct tag scheme
|
||||
that enables sharing of struct tags between multiple packages.
|
||||
In this scheme, the tags must be of the form:
|
||||
</p>
|
||||
<pre>
|
||||
`key:"value" key2:"value2"`
|
||||
</pre>
|
||||
<p>
|
||||
The <a href="/pkg/reflect/#StructField">StructField</a> type's Tag field now
|
||||
has type <a href="/pkg/reflect/#StructTag">StructTag</a>, which has a
|
||||
<code>Get</code> method. Clients of <a href="/pkg/json">json</a> and
|
||||
<a href="/pkg/xml">xml</a> will need to be updated. Code that says
|
||||
</p>
|
||||
<pre>
|
||||
type T struct {
|
||||
X int "name"
|
||||
}
|
||||
</pre>
|
||||
<p>
|
||||
should become
|
||||
</p>
|
||||
<pre>
|
||||
type T struct {
|
||||
X int `json:"name"` // or `xml:"name"`
|
||||
}
|
||||
</pre>
|
||||
<p>
|
||||
Use <a href="/cmd/govet/">govet</a> to identify struct tags that need to be
|
||||
changed to use the new syntax.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/sort/">Package sort</a>'s <code>IntArray</code> type has been
|
||||
renamed to <a href="/pkg/sort/#IntSlice">IntSlice</a>, and similarly for
|
||||
<a href="/pkg/sort/#Float64Slice">Float64Slice</a> and
|
||||
<a href="/pkg/sort/#StringSlice">StringSlice</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/strings/">Package strings</a>'s <code>Split</code> function has
|
||||
itself been split into <a href="/pkg/strings/#Split">Split</a> and
|
||||
<a href="/pkg/strings/#SplitN">SplitN</a>.
|
||||
<code>SplitN</code> is the same as the old <code>Split</code>.
|
||||
The new <code>Split</code> is equivalent to <code>SplitN</code> with a final
|
||||
argument of -1.
|
||||
</p>
|
||||
|
||||
<a href="/pkg/image/draw/">Package image/draw</a>'s
|
||||
<a href="/pkg/image/draw/#Draw">Draw</a> function now takes an additional
|
||||
argument, a compositing operator.
|
||||
If in doubt, use <a href="/pkg/image/draw/#Op">draw.Over</a>.
|
||||
</p>
|
||||
|
||||
<h3 id="r59.cmd">Tools</h3>
|
||||
|
||||
<p>
|
||||
<a href="/cmd/goinstall/">Goinstall</a> now installs packages and commands from
|
||||
arbitrary remote repositories (not just Google Code, Github, and so on).
|
||||
See the <a href="/cmd/goinstall/">goinstall documentation</a> for details.
|
||||
</p>
|
||||
|
||||
<h2 id="r58">r58 (released 2011/06/29)</h2>
|
||||
|
||||
<p>
|
||||
The r58 release corresponds to
|
||||
<code><a href="weekly.html#2011-06-09">weekly.2011-06-09</a></code>
|
||||
with additional bug fixes.
|
||||
This section highlights the most significant changes in this release.
|
||||
For a more detailed summary, see the
|
||||
<a href="weekly.html#2011-06-09">weekly release notes</a>.
|
||||
For complete information, see the
|
||||
<a href="http://code.google.com/p/go/source/list?r=release-branch.r58">Mercurial change list</a>.
|
||||
</p>
|
||||
|
||||
<h3 id="r58.lang">Language</h3>
|
||||
|
||||
<p>
|
||||
This release fixes a <a href="http://code.google.com/p/go/source/detail?r=b720749486e1">use of uninitialized memory in programs that misuse <code>goto</code></a>.
|
||||
</p>
|
||||
|
||||
<h3 id="r58.pkg">Packages</h3>
|
||||
|
||||
<p>
|
||||
As usual, <a href="/cmd/gofix/">gofix</a> will handle the bulk of the rewrites
|
||||
necessary for these changes to package APIs.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/http/">Package http</a> drops the <code>finalURL</code> return
|
||||
value from the <a href="/pkg/http/#Client.Get">Client.Get</a> method. The value
|
||||
is now available via the new <code>Request</code> field on <a
|
||||
href="/pkg/http/#Response">http.Response</a>.
|
||||
Most instances of the type map[string][]string in have been
|
||||
replaced with the new <a href="/pkg/http/#Values">Values</a> type.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/exec/">Package exec</a> has been redesigned with a more
|
||||
convenient and succinct API.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/strconv/">Package strconv</a>'s <a href="/pkg/strconv/#Quote">Quote</a>
|
||||
function now escapes only those Unicode code points not classified as printable
|
||||
by <a href="/pkg/unicode/#IsPrint">unicode.IsPrint</a>.
|
||||
Previously Quote would escape all non-ASCII characters.
|
||||
This also affects the <a href="/pkg/fmt/">fmt</a> package's <code>"%q"</code>
|
||||
formatting directive. The previous quoting behavior is still available via
|
||||
strconv's new <a href="/pkg/strconv/#QuoteToASCII">QuoteToASCII</a> function.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/os/signal/">Package os/signal</a>'s
|
||||
<a href="/pkg/os/#Signal">Signal</a> and
|
||||
<a href="/pkg/os/#UnixSignal">UnixSignal</a> types have been moved to the
|
||||
<a href="/pkg/os/">os</a> package.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/image/draw/">Package image/draw</a> is the new name for
|
||||
<code>exp/draw</code>. The GUI-related code from <code>exp/draw</code> is now
|
||||
located in the <a href="/pkg/exp/gui/">exp/gui</a> package.
|
||||
</p>
|
||||
|
||||
<h3 id="r58.cmd">Tools</h3>
|
||||
|
||||
<p>
|
||||
<a href="/cmd/goinstall/">Goinstall</a> now observes the GOPATH environment
|
||||
variable to build and install your own code and external libraries outside of
|
||||
the Go tree (and avoid writing Makefiles).
|
||||
</p>
|
||||
|
||||
|
||||
<h3 id="r58.minor">Minor revisions</h3>
|
||||
|
||||
<p>r58.1 adds
|
||||
<a href="http://code.google.com/p/go/source/detail?r=293c25943586">build</a> and
|
||||
<a href="http://code.google.com/p/go/source/detail?r=bf17e96b6582">runtime</a>
|
||||
changes to make Go run on OS X 10.7 Lion.
|
||||
</p>
|
||||
|
||||
<h2 id="r57">r57 (released 2011/05/03)</h2>
|
||||
|
||||
<p>
|
||||
The r57 release corresponds to
|
||||
<code><a href="weekly.html#2011-04-27">weekly.2011-04-27</a></code>
|
||||
with additional bug fixes.
|
||||
This section highlights the most significant changes in this release.
|
||||
For a more detailed summary, see the
|
||||
<a href="weekly.html#2011-04-27">weekly release notes</a>.
|
||||
For complete information, see the
|
||||
<a href="http://code.google.com/p/go/source/list?r=release-branch.r57">Mercurial change list</a>.
|
||||
</p>
|
||||
|
||||
<p>The new <a href="/cmd/gofix">gofix</a> tool finds Go programs that use old APIs and rewrites them to use
|
||||
newer ones. After you update to a new Go release, gofix helps make the
|
||||
necessary changes to your programs. Gofix will handle the http, os, and syscall
|
||||
package changes described below, and we will update the program to keep up with
|
||||
future changes to the libraries.
|
||||
Gofix can’t
|
||||
handle all situations perfectly, so read and test the changes it makes before
|
||||
committing them.
|
||||
See <a href="http://blog.golang.org/2011/04/introducing-gofix.html">the gofix blog post</a> for more
|
||||
information.</p>
|
||||
|
||||
<h3 id="r57.lang">Language</h3>
|
||||
|
||||
<p>
|
||||
<a href="/doc/go_spec.html#Receive_operator">Multiple assignment syntax</a> replaces the <code>closed</code> function.
|
||||
The syntax for channel
|
||||
receives allows an optional second assigned value, a boolean value
|
||||
indicating whether the channel is closed. This code:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
v := <-ch
|
||||
if closed(ch) {
|
||||
// channel is closed
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>should now be written as:</p>
|
||||
|
||||
<pre>
|
||||
v, ok := <-ch
|
||||
if !ok {
|
||||
// channel is closed
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p><a href="/doc/go_spec.html#Label_scopes">Unused labels are now illegal</a>, just as unused local variables are.</p>
|
||||
|
||||
<h3 id="r57.pkg">Packages</h3>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/gob/">Package gob</a> will now encode and decode values of types that implement the
|
||||
<a href="/pkg/gob/#GobEncoder">GobEncoder</a> and
|
||||
<a href="/pkg/gob/#GobDecoder">GobDecoder</a> interfaces. This allows types with unexported
|
||||
fields to transmit self-consistent descriptions; examples include
|
||||
<a href="/pkg/big/#Int.GobDecode">big.Int</a> and <a href="/pkg/big/#Rat.GobDecode">big.Rat</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/http/">Package http</a> has been redesigned.
|
||||
For clients, there are new
|
||||
<a href="/pkg/http/#Client">Client</a> and <a href="/pkg/http/#Transport">Transport</a>
|
||||
abstractions that give more control over HTTP details such as headers sent
|
||||
and redirections followed. These abstractions make it easy to implement
|
||||
custom clients that add functionality such as <a href="http://code.google.com/p/goauth2/source/browse/oauth/oauth.go">OAuth2</a>.
|
||||
For servers, <a href="/pkg/http/#ResponseWriter">ResponseWriter</a>
|
||||
has dropped its non-essential methods.
|
||||
The Hijack and Flush methods are no longer required;
|
||||
code can test for them by checking whether a specific value implements
|
||||
<a href="/pkg/http/#Hijacker">Hijacker</a> or <a href="/pkg/http/#Flusher">Flusher</a>.
|
||||
The RemoteAddr and UsingTLS methods are replaced by <a href="/pkg/http/#Request">Request</a>'s
|
||||
RemoteAddr and TLS fields.
|
||||
The SetHeader method is replaced by a Header method;
|
||||
its result, of type <a href="/pkg/http/#Header">Header</a>,
|
||||
implements Set and other methods.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/net/">Package net</a>
|
||||
drops the <code>laddr</code> argument from <a href="/pkg/net/#Conn.Dial">Dial</a>
|
||||
and drops the <code>cname</code> return value
|
||||
from <a href="/pkg/net/#LookupHost">LookupHost</a>.
|
||||
The implementation now uses <a href="/cmd/cgo/">cgo</a> to implement
|
||||
network name lookups using the C library getaddrinfo(3)
|
||||
function when possible. This ensures that Go and C programs
|
||||
resolve names the same way and also avoids the OS X
|
||||
application-level firewall.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/os/">Package os</a>
|
||||
introduces simplified <a href="/pkg/os/#File.Open">Open</a>
|
||||
and <a href="/pkg/os/#File.Create">Create</a> functions.
|
||||
The original Open is now available as <a href="/pkg/os/#File.OpenFile">OpenFile</a>.
|
||||
The final three arguments to <a href="/pkg/os/#Process.StartProcess">StartProcess</a>
|
||||
have been replaced by a pointer to a <a href="/pkg/os/#ProcAttr">ProcAttr</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/pkg/reflect/">Package reflect</a> has been redesigned.
|
||||
<a href="/pkg/reflect/#Type">Type</a> is now an interface that implements
|
||||
all the possible type methods.
|
||||
Instead of a type switch on a Type <code>t</code>, switch on <code>t.Kind()</code>.
|
||||
<a href="/pkg/reflect/#Value">Value</a> is now a struct value that
|
||||
implements all the possible value methods.
|
||||
Instead of a type switch on a Value <code>v</code>, switch on <code>v.Kind()</code>.
|
||||
Typeof and NewValue are now called <a href="/pkg/reflect/#Type.TypeOf">TypeOf</a> and <a href="/pkg/reflect/#Value.ValueOf">ValueOf</a>
|
||||
To create a writable Value, use <code>New(t).Elem()</code> instead of <code>Zero(t)</code>.
|
||||
See <a href="http://code.google.com/p/go/source/detail?r=843855f3c026">the change description</a>
|
||||
for the full details.
|
||||
The new API allows a more efficient implementation of Value
|
||||
that avoids many of the allocations required by the previous API.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Remember that gofix will handle the bulk of the rewrites
|
||||
necessary for these changes to package APIs.
|
||||
</p>
|
||||
|
||||
<h3 id="r57.cmd">Tools</h3>
|
||||
|
||||
<p><a href="/cmd/gofix/">Gofix</a>, a new command, is described above.</p>
|
||||
|
||||
<p>
|
||||
<a href="/cmd/gotest/">Gotest</a> is now a Go program instead of a shell script.
|
||||
The new <code>-test.short</code> flag in combination with package testing's Short function
|
||||
allows you to write tests that can be run in normal or “short” mode;
|
||||
all.bash runs tests in short mode to reduce installation time.
|
||||
The Makefiles know about the flag: use <code>make testshort</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The run-time support now implements CPU and memory profiling.
|
||||
Gotest's new
|
||||
<a href="/cmd/gotest/"><code>-test.cpuprofile</code> and
|
||||
<code>-test.memprofile</code> flags</a> make it easy to
|
||||
profile tests.
|
||||
To add profiling to your web server, see the <a href="/pkg/http/pprof/">http/pprof</a>
|
||||
documentation.
|
||||
For other uses, see the <a href="/pkg/runtime/pprof/">runtime/pprof</a> documentation.
|
||||
</p>
|
||||
|
||||
<h3 id="r57.minor">Minor revisions</h3>
|
||||
|
||||
<p>r57.1 fixes a <a href="http://code.google.com/p/go/source/detail?r=ff2bc62726e7145eb2ecc1e0f076998e4a8f86f0">nil pointer dereference in http.FormFile</a>.</p>
|
||||
<p>r57.2 fixes a <a href="http://code.google.com/p/go/source/detail?r=063b0ff67d8277df03c956208abc068076818dae">use of uninitialized memory in programs that misuse <code>goto</code></a>.</p>
|
||||
|
||||
<h2 id="r56">r56 (released 2011/03/16)</h2>
|
||||
|
||||
<p>
|
||||
The r56 release was the first stable release and corresponds to
|
||||
<code><a href="weekly.html#2011-03-07">weekly.2011-03-07.1</a></code>.
|
||||
The numbering starts at 56 because before this release,
|
||||
what we now consider weekly snapshots were called releases.
|
||||
</p>
|
||||
|
||||
@@ -3,9 +3,18 @@
|
||||
}-->
|
||||
|
||||
<p>This page summarizes the changes between tagged weekly snapshots of Go.
|
||||
Such snapshots are no longer created. This page remains as a historical reference only.</p>
|
||||
For full details, see the <a href="http://code.google.com/p/go/source/list">Mercurial change log</a>.</p>
|
||||
|
||||
<p>For recent information, see the <a href="//golang.org/change">change log</a> and <a href="//groups.google.com/group/golang-dev/">development mailing list</a>.</p>
|
||||
<p>Weekly snapshots occur often and may not be stable.
|
||||
If stability of API and code is more important than having the
|
||||
latest features, use the <a href="release.html">official releases</a> instead.</p>
|
||||
|
||||
<p>To update to a specific snapshot, use:</p>
|
||||
|
||||
<pre>
|
||||
hg pull
|
||||
hg update weekly.<i>YYYY-MM-DD</i>
|
||||
</pre>
|
||||
|
||||
<h2 id="2012-03-27">2012-03-27 (<a href="release.html#go1">Go 1</a>)</h2>
|
||||
|
||||
@@ -2035,7 +2044,7 @@ Other changes:
|
||||
* spec: define order of multiple assignment.
|
||||
* syscall/windows: dll function load and calling changes (thanks Alex Brainman).
|
||||
* syscall: add #ifdefs to fix the manual corrections in ztypes_linux_arm.go (thanks Dave Cheney),
|
||||
adjust Mount to accommodate stricter FS implementations.
|
||||
adjust Mount to accomodate stricter FS implementations.
|
||||
* testing: fix time reported for failing tests.
|
||||
* utf8: add Valid and ValidString.
|
||||
* websocket: tweak hybi ReadHandshake to support Firefox (thanks Luca Greco).
|
||||
@@ -4362,7 +4371,7 @@ The print/println bootstrapping functions now write to standard error.
|
||||
To write to standard output, use fmt.Print[ln].
|
||||
|
||||
A new tool, govet, has been added to the Go distribution. Govet is a static
|
||||
checker for Go programs. At the moment, and for the foreseeable future,
|
||||
checker for Go programs. At the moment, and for the forseeable future,
|
||||
it only checks arguments to print calls.
|
||||
|
||||
The cgo tool for writing Go bindings for C code has changed so that it no
|
||||
@@ -5971,7 +5980,7 @@ You can now check build status on various platforms at the Go Dashboard:
|
||||
* runtime: add SetFinalizer
|
||||
* time: Sleep through interruptions (thanks Chris Wedgwood)
|
||||
add RFC822 formats
|
||||
experimental implementation of Ticker using two goroutines for all tickers
|
||||
experimental implemenation of Ticker using two goroutines for all tickers
|
||||
* xml: allow underscores in XML element names (thanks Michael Hoisie)
|
||||
allow any scalar type in xml.Unmarshal
|
||||
</pre>
|
||||
|
||||
181
doc/docs.html
181
doc/docs.html
@@ -33,28 +33,20 @@ libraries.
|
||||
|
||||
<img class="gopher" src="/doc/gopher/doc.png"/>
|
||||
|
||||
<h3 id="go_tour"><a href="//tour.golang.org/">A Tour of Go</a></h3>
|
||||
<h3 id="go_tour"><a href="http://tour.golang.org/">A Tour of Go</a></h3>
|
||||
<p>
|
||||
An interactive introduction to Go in three sections.
|
||||
The first section covers basic syntax and data structures; the second discusses
|
||||
methods and interfaces; and the third introduces Go's concurrency primitives.
|
||||
Each section concludes with a few exercises so you can practice what you've
|
||||
learned. You can <a href="//tour.golang.org/">take the tour online</a> or
|
||||
install it locally with:
|
||||
</p>
|
||||
<p>
|
||||
<pre>
|
||||
$ go get golang.org/x/tour/gotour
|
||||
</pre>
|
||||
This will place the <code>gotour</code> binary in your workspace's <code>bin</code> directory.
|
||||
learned. You can <a href="http://tour.golang.org/">take the tour online</a> or
|
||||
<a href="http://code.google.com/p/go-tour/">install it locally</a>.
|
||||
</p>
|
||||
|
||||
<h3 id="code"><a href="code.html">How to write Go code</a></h3>
|
||||
<p>
|
||||
Also available as a
|
||||
<a href="//www.youtube.com/watch?v=XCsL89YtqCs">screencast</a>, this doc
|
||||
explains how to use the <a href="/cmd/go/">go command</a> to fetch, build, and
|
||||
install packages, commands, and run tests.
|
||||
How to use the <a href="/cmd/go/">go command</a> to fetch, build, and install
|
||||
packages, commands, and run tests.
|
||||
</p>
|
||||
|
||||
<h3 id="effective_go"><a href="effective_go.html">Effective Go</a></h3>
|
||||
@@ -64,52 +56,36 @@ A must read for any new Go programmer. It augments the tour and
|
||||
the language specification, both of which should be read first.
|
||||
</p>
|
||||
|
||||
<h3 id="faq"><a href="/doc/faq">Frequently Asked Questions (FAQ)</a></h3>
|
||||
<h3 id="appengine"><a href="http://code.google.com/appengine/docs/go/gettingstarted/">Getting Started with Go on App Engine</a></h3>
|
||||
<p>
|
||||
How to develop and deploy a simple Go project with
|
||||
<a href="http://code.google.com/appengine/">Google App Engine</a>.
|
||||
</p>
|
||||
|
||||
<h3 id="go_faq"><a href="go_faq.html">Frequently Asked Questions (FAQ)</a></h3>
|
||||
<p>
|
||||
Answers to common questions about Go.
|
||||
</p>
|
||||
|
||||
<h3 id="wiki"><a href="/wiki">The Go Wiki</a></h3>
|
||||
<h3 id="wiki"><a href="http://code.google.com/p/go-wiki/wiki">Go Language Community Wiki</a></h3>
|
||||
<p>A wiki maintained by the Go community.</p>
|
||||
|
||||
<h4 id="learn_more">More</h4>
|
||||
<h2 id="go1">Go version 1</h2>
|
||||
|
||||
<h3 id="go1notes"><a href="/doc/go1.html">Go 1 Release Notes</a></h3>
|
||||
<p>
|
||||
See the <a href="/wiki/Learn">Learn</a> page at the <a href="/wiki">Wiki</a>
|
||||
for more Go learning resources.
|
||||
A guide for updating your code to work with Go 1.
|
||||
</p>
|
||||
|
||||
|
||||
<h2 id="references">References</h2>
|
||||
|
||||
<h3 id="pkg"><a href="/pkg/">Package Documentation</a></h3>
|
||||
<h3 id="go1compat"><a href="/doc/go1compat.html">Go 1 and the Future of Go Programs</a></h3>
|
||||
<p>
|
||||
The documentation for the Go standard library.
|
||||
What Go 1 defines and the backwards-compatibility guarantees one can expect as
|
||||
Go 1 matures.
|
||||
</p>
|
||||
|
||||
<h3 id="cmd"><a href="/doc/cmd">Command Documentation</a></h3>
|
||||
<p>
|
||||
The documentation for the Go tools.
|
||||
</p>
|
||||
<h2 id="articles">Go Articles</h2>
|
||||
|
||||
<h3 id="spec"><a href="/ref/spec">Language Specification</a></h3>
|
||||
<p>
|
||||
The official Go Language specification.
|
||||
</p>
|
||||
|
||||
<h3 id="go_mem"><a href="/ref/mem">The Go Memory Model</a></h3>
|
||||
<p>
|
||||
A document that specifies the conditions under which reads of a variable in
|
||||
one goroutine can be guaranteed to observe values produced by writes to the
|
||||
same variable in a different goroutine.
|
||||
</p>
|
||||
|
||||
<h3 id="release"><a href="/doc/devel/release.html">Release History</a></h3>
|
||||
<p>A summary of the changes between Go releases.</p>
|
||||
|
||||
|
||||
<h2 id="articles">Articles</h2>
|
||||
|
||||
<h3 id="blog"><a href="//blog.golang.org/">The Go Blog</a></h3>
|
||||
<h3 id="blog"><a href="http://blog.golang.org/">The Go Blog</a></h3>
|
||||
<p>The official blog of the Go project, featuring news and in-depth articles by
|
||||
the Go team and guests.</p>
|
||||
|
||||
@@ -126,80 +102,113 @@ Guided tours of Go programs.
|
||||
|
||||
<h4>Language</h4>
|
||||
<ul>
|
||||
<li><a href="/blog/json-rpc-tale-of-interfaces">JSON-RPC: a tale of interfaces</a></li>
|
||||
<li><a href="/blog/gos-declaration-syntax">Go's Declaration Syntax</a></li>
|
||||
<li><a href="/blog/defer-panic-and-recover">Defer, Panic, and Recover</a></li>
|
||||
<li><a href="/blog/go-concurrency-patterns-timing-out-and">Go Concurrency Patterns: Timing out, moving on</a></li>
|
||||
<li><a href="/blog/go-slices-usage-and-internals">Go Slices: usage and internals</a></li>
|
||||
<li><a href="/blog/gif-decoder-exercise-in-go-interfaces">A GIF decoder: an exercise in Go interfaces</a></li>
|
||||
<li><a href="/blog/error-handling-and-go">Error Handling and Go</a></li>
|
||||
<li><a href="/blog/organizing-go-code">Organizing Go code</a></li>
|
||||
<li><a href="/doc/articles/json_rpc_tale_of_interfaces.html">JSON-RPC: a tale of interfaces</a></li>
|
||||
<li><a href="/doc/articles/gos_declaration_syntax.html">Go's Declaration Syntax</a></li>
|
||||
<li><a href="/doc/articles/defer_panic_recover.html">Defer, Panic, and Recover</a></li>
|
||||
<li><a href="/doc/articles/concurrency_patterns.html">Go Concurrency Patterns: Timing out, moving on</a></li>
|
||||
<li><a href="/doc/articles/slices_usage_and_internals.html">Go Slices: usage and internals</a></li>
|
||||
<li><a href="http://blog.golang.org/2011/05/gif-decoder-exercise-in-go-interfaces.html">A GIF decoder: an exercise in Go interfaces</a></li>
|
||||
<li><a href="/doc/articles/error_handling.html">Error Handling and Go</a></li>
|
||||
</ul>
|
||||
|
||||
<h4>Packages</h4>
|
||||
<ul>
|
||||
<li><a href="/blog/json-and-go">JSON and Go</a> - using the <a href="/pkg/encoding/json/">json</a> package.</li>
|
||||
<li><a href="/blog/gobs-of-data">Gobs of data</a> - the design and use of the <a href="/pkg/encoding/gob/">gob</a> package.</li>
|
||||
<li><a href="/blog/laws-of-reflection">The Laws of Reflection</a> - the fundamentals of the <a href="/pkg/reflect/">reflect</a> package.</li>
|
||||
<li><a href="/blog/go-image-package">The Go image package</a> - the fundamentals of the <a href="/pkg/image/">image</a> package.</li>
|
||||
<li><a href="/blog/go-imagedraw-package">The Go image/draw package</a> - the fundamentals of the <a href="/pkg/image/draw/">image/draw</a> package.</li>
|
||||
<li><a href="/doc/articles/json_and_go.html">JSON and Go</a> - using the <a href="/pkg/encoding/json/">json</a> package.</li>
|
||||
<li><a href="/doc/articles/gobs_of_data.html">Gobs of data</a> - the design and use of the <a href="/pkg/encoding/gob/">gob</a> package.</li>
|
||||
<li><a href="/doc/articles/laws_of_reflection.html">The Laws of Reflection</a> - the fundamentals of the <a href="/pkg/reflect/">reflect</a> package.</li>
|
||||
<li><a href="/doc/articles/image_package.html">The Go image package</a> - the fundamentals of the <a href="/pkg/image/">image</a> package.</li>
|
||||
<li><a href="/doc/articles/image_draw.html">The Go image/draw package</a> - the fundamentals of the <a href="/pkg/image/draw/">image/draw</a> package.</li>
|
||||
</ul>
|
||||
|
||||
<h4>Tools</h4>
|
||||
<ul>
|
||||
<li><a href="/doc/articles/go_command.html">About the Go command</a> - why we wrote it, what it is, what it's not, and how to use it.</li>
|
||||
<li><a href="/blog/c-go-cgo">C? Go? Cgo!</a> - linking against C code with <a href="/cmd/cgo/">cgo</a>.</li>
|
||||
<li><a href="/doc/articles/c_go_cgo.html">C? Go? Cgo!</a> - linking against C code with <a href="/cmd/cgo/">cgo</a>.</li>
|
||||
<li><a href="/doc/gdb">Debugging Go Code with GDB</a></li>
|
||||
<li><a href="/blog/godoc-documenting-go-code">Godoc: documenting Go code</a> - writing good documentation for <a href="/cmd/godoc/">godoc</a>.</li>
|
||||
<li><a href="/blog/profiling-go-programs">Profiling Go Programs</a></li>
|
||||
<li><a href="/doc/articles/race_detector.html">Data Race Detector</a> - a manual for the data race detector.</li>
|
||||
<li><a href="/blog/race-detector">Introducing the Go Race Detector</a> - an introduction to the race detector.</li>
|
||||
<li><a href="/doc/asm">A Quick Guide to Go's Assembler</a> - an introduction to the assembler used by Go.</li>
|
||||
<li><a href="/doc/articles/godoc_documenting_go_code.html">Godoc: documenting Go code</a> - writing good documentation for <a href="/cmd/godoc/">godoc</a>.</li>
|
||||
<li><a href="http://blog.golang.org/2011/06/profiling-go-programs.html">Profiling Go Programs</a></li>
|
||||
</ul>
|
||||
|
||||
<h4 id="articles_more">More</h4>
|
||||
<p>
|
||||
See the <a href="/wiki/Articles">Articles page</a> at the
|
||||
<a href="/wiki">Wiki</a> for more Go articles.
|
||||
</p>
|
||||
|
||||
|
||||
<h2 id="talks">Talks</h2>
|
||||
|
||||
<img class="gopher" src="/doc/gopher/talks.png"/>
|
||||
|
||||
<h3 id="video_tour_of_go"><a href="http://research.swtch.com/gotour">A Video Tour of Go</a></h3>
|
||||
<p>
|
||||
Three things that make Go fast, fun, and productive:
|
||||
interfaces, reflection, and concurrency. Builds a toy web crawler to
|
||||
demonstrate these.
|
||||
The talks marked with a red asterisk (<font color="red">*</font>) were written
|
||||
before Go 1 and contain some examples that are no longer correct, but they are
|
||||
still of value.
|
||||
</p>
|
||||
|
||||
<h3 id="go_code_that_grows"><a href="//vimeo.com/53221560">Code that grows with grace</a></h3>
|
||||
<h3 id="writing_web_apps"><a href="http://www.youtube.com/watch?v=-i0hat7pdpk">Writing Web Apps in Go</a><font color="red">*</font></h3>
|
||||
<p>
|
||||
One of Go's key design goals is code adaptability; that it should be easy to take a simple design and build upon it in a clean and natural way. In this talk Andrew Gerrand describes a simple "chat roulette" server that matches pairs of incoming TCP connections, and then use Go's concurrency mechanisms, interfaces, and standard library to extend it with a web interface and other features. While the function of the program changes dramatically, Go's flexibility preserves the original design as it grows.
|
||||
A talk by Rob Pike and Andrew Gerrand presented at Google I/O 2011.
|
||||
It walks through the construction and deployment of a simple web application
|
||||
and unveils the <a href="http://blog.golang.org/2011/05/go-and-google-app-engine.html">Go runtime for App Engine</a>.
|
||||
See the <a href="/doc/talks/io2011/Writing_Web_Apps_in_Go.pdf">presentation slides</a>.
|
||||
</p>
|
||||
|
||||
<h3 id="go_concurrency_patterns"><a href="//www.youtube.com/watch?v=f6kdp27TYZs">Go Concurrency Patterns</a></h3>
|
||||
<h3 id="real_world_go"><a href="http://www.youtube.com/watch?v=7QDVRowyUQA">Real World Go</a><font color="red">*</font></h3>
|
||||
<p>
|
||||
Concurrency is the key to designing high performance network services. Go's concurrency primitives (goroutines and channels) provide a simple and efficient means of expressing concurrent execution. In this talk we see how tricky concurrency problems can be solved gracefully with simple Go code.
|
||||
A talk by Andrew Gerrand presented at Google I/O Bootcamp 2011.
|
||||
It gives a broad overview of Go's type system and concurrency model
|
||||
and provides four examples of Go programs that solve real problems.
|
||||
See the <a href="/doc/talks/io2011/Real_World_Go.pdf">presentation slides</a>.
|
||||
</p>
|
||||
|
||||
<h3 id="advanced_go_concurrency_patterns"><a href="//www.youtube.com/watch?v=QDDwwePbDtw">Advanced Go Concurrency Patterns</a></h3>
|
||||
<h3 id="integrated_apps"><a href="http://www.youtube.com/watch?v=Mo1YKpIF1PQ">Building Integrated Apps on Google's Cloud Platform</a></h3>
|
||||
<p>
|
||||
This talk expands on the <i>Go Concurrency Patterns</i> talk to dive deeper into Go's concurrency primitives.
|
||||
A talk by Andrew Gerrand presented at Google Developer Day Japan 2011.
|
||||
It discusses the development of a web application that runs on Google
|
||||
App Engine and renders images that it stores on Google Cloud Storage.
|
||||
</p>
|
||||
|
||||
<h3 id="go_programming"><a href="http://www.youtube.com/watch?v=jgVhBThJdXc">Go Programming</a><font color="red">*</font></h3>
|
||||
<p>
|
||||
A presentation delivered by Rob Pike and Russ Cox at Google I/O 2010. It
|
||||
illustrates how programming in Go differs from other languages through a set of
|
||||
examples demonstrating features particular to Go. These include concurrency,
|
||||
embedded types, methods on any type, and program construction using interfaces.
|
||||
</p>
|
||||
|
||||
<h3 id="practical_go_programming"><a href="http://www.youtube.com/watch?v=2-pPAvqyluI">Practical Go Programming</a><font color="red">*</font></h3>
|
||||
<p>
|
||||
This talk presents the development of a complete web application in Go.
|
||||
It looks at design, storage, concurrency, and scaling issues in detail, using
|
||||
the simple example of an URL shortening service.
|
||||
See the <a href="http://wh3rd.net/practical-go/">presentation slides</a>.
|
||||
</p>
|
||||
|
||||
<h4 id="talks_more">More</h4>
|
||||
<p>
|
||||
See the <a href="/talks">Go Talks site</a> and <a href="/wiki/GoTalks">wiki page</a> for more Go talks.
|
||||
See the <a href="http://code.google.com/p/go-wiki/wiki/GoTalks">GoTalks
|
||||
page</a> at the <a href="http://code.google.com/p/go-wiki/wiki">Go Wiki</a> for
|
||||
more Go talks.
|
||||
</p>
|
||||
|
||||
|
||||
<h2 id="nonenglish">Non-English Documentation</h2>
|
||||
|
||||
<p>
|
||||
See the <a href="/wiki/NonEnglish">NonEnglish</a> page
|
||||
at the <a href="/wiki">Wiki</a> for localized
|
||||
See the <a href="http://code.google.com/p/go-wiki/wiki/NonEnglish">NonEnglish</a> page
|
||||
at the <a href="http://code.google.com/p/go-wiki/wiki">Go Wiki</a> for localized
|
||||
documentation.
|
||||
</p>
|
||||
|
||||
<h2 id="community">The Go Community</h2>
|
||||
|
||||
<img class="gopher" src="/doc/gopher/project.png"/>
|
||||
|
||||
<h3 id="mailinglist"><a href="http://groups.google.com/group/golang-nuts">Go Nuts Mailing List</a></h3>
|
||||
<p>The <a href="http://groups.google.com/group/golang-nuts">golang-nuts</a>
|
||||
mailing list is for general Go discussion.</p>
|
||||
|
||||
<h3 id="projects"><a href="http://godashboard.appspot.com/project">Go Project Dashboard</a></h3>
|
||||
<p>A list of external Go projects including programs and libraries.</p>
|
||||
|
||||
<h3 id="irc"><a href="irc:irc.freenode.net/go-nuts">Go IRC Channel</a></h3>
|
||||
<p><b>#go-nuts</b> on <b>irc.freenode.net</b> is the official Go IRC channel.</p>
|
||||
|
||||
<h3 id="plus"><a href="https://plus.google.com/101406623878176903605/posts">The Go Programming Language at Google+</a></h3>
|
||||
<p>The Go project's Google+ page.</p>
|
||||
|
||||
<h3 id="twitter"><a href="http://twitter.com/go_nuts">@go_nuts at Twitter</a></h3>
|
||||
<p>The Go project's official Twitter account.</p>
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -10,10 +10,6 @@ For information on contributing to parts of Go other than gccgo,
|
||||
see <a href="/doc/contribute.html">Contributing to the Go project</a>. For
|
||||
information on building gccgo for yourself,
|
||||
see <a href="/doc/gccgo_install.html">Setting up and using gccgo</a>.
|
||||
For more of the gritty details on the process of doing development
|
||||
with the gccgo frontend,
|
||||
see <a href="https://go.googlesource.com/gofrontend/+/master/HACKING">the
|
||||
file HACKING</a> in the gofrontend repository.
|
||||
</p>
|
||||
|
||||
<h2>Legal Prerequisites</h2>
|
||||
@@ -30,9 +26,7 @@ contribution rules</a>.
|
||||
|
||||
<p>
|
||||
The master sources for the gccgo frontend may be found at
|
||||
<a href="http://go.googlesource.com/gofrontend">http://go.googlesource.com/gofrontend</a>.
|
||||
They are mirrored
|
||||
at <a href="http://github.com/golang/gofrontend">http://github.com/golang/gofrontend</a>.
|
||||
<a href="http://code.google.com/p/gofrontend">http://code.google.com/p/gofrontend</a>.
|
||||
The master sources are not buildable by themselves, but only in
|
||||
conjunction with GCC (in the future, other compilers may be
|
||||
supported). Changes made to the gccgo frontend are also applied to
|
||||
@@ -42,7 +36,7 @@ is mirrored to the <code>gcc/go/gofrontend</code> directory in the GCC
|
||||
repository, and the <code>gofrontend</code> <code>libgo</code>
|
||||
directory is mirrored to the GCC <code>libgo</code> directory. In
|
||||
addition, the <code>test</code> directory
|
||||
from <a href="//go.googlesource.com/go">the main Go repository</a>
|
||||
from <a href="http://code.google.com/p/go">the main Go repository</a>
|
||||
is mirrored to the <code>gcc/testsuite/go.test/test</code> directory
|
||||
in the GCC repository.
|
||||
</p>
|
||||
@@ -55,17 +49,19 @@ them.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The gccgo frontend is written in C++.
|
||||
It follows the GNU and GCC coding standards for C++.
|
||||
In writing code for the frontend, follow the formatting of the
|
||||
surrounding code.
|
||||
Almost all GCC-specific code is not in the frontend proper and is
|
||||
instead in the GCC sources in the <code>gcc/go</code> directory.
|
||||
The gccgo frontend is written in C++. It follows the GNU coding
|
||||
standards to the extent that they apply to C++. In writing code for
|
||||
the frontend, follow the formatting of the surrounding code. Although
|
||||
the frontend is currently tied to the rest of the GCC codebase, we
|
||||
plan to make it more independent. Eventually all GCC-specific code
|
||||
will migrate out of the frontend proper and into GCC proper. In the
|
||||
GCC sources this will generally mean moving code
|
||||
from <code>gcc/go/gofrontend</code> to <code>gcc/go</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The run-time library for gccgo is mostly the same as the library
|
||||
in <a href="//go.googlesource.com/go">the main Go repository</a>.
|
||||
in <a href="http://code.google.com/p/go">the main Go repository</a>.
|
||||
The library code in the Go repository is periodically merged into
|
||||
the <code>libgo/go</code> directory of the <code>gofrontend</code> and
|
||||
then the GCC repositories, using the shell
|
||||
@@ -73,7 +69,7 @@ script <code>libgo/merge.sh</code>. Accordingly, most library changes
|
||||
should be made in the main Go repository. The files outside
|
||||
of <code>libgo/go</code> are gccgo-specific; that said, some of the
|
||||
files in <code>libgo/runtime</code> are based on files
|
||||
in <code>src/runtime</code> in the main Go repository.
|
||||
in <code>src/pkg/runtime</code> in the main Go repository.
|
||||
</p>
|
||||
|
||||
<h2>Testing</h2>
|
||||
@@ -88,7 +84,7 @@ To run the gccgo test suite, run <code>make check-go</code> in your
|
||||
build directory. This will run various tests
|
||||
under <code>gcc/testsuite/go.*</code> and will also run
|
||||
the <code>libgo</code> testsuite. This copy of the tests from the
|
||||
main Go repository is run using the DejaGNU script found
|
||||
main Go repository is run using the DejaGNU script found in
|
||||
in <code>gcc/testsuite/go.test/go-test.exp</code>.
|
||||
</p>
|
||||
|
||||
@@ -104,9 +100,7 @@ or <code>gcc/testsuite/go.dg</code> directories in the GCC repository.
|
||||
|
||||
<p>
|
||||
Changes to the Go frontend should follow the same process as for the
|
||||
main Go repository, only for the <code>gofrontend</code> project and
|
||||
the <code>gofrontend-dev@googlegroups.com</code> mailing list
|
||||
rather than the <code>go</code> project and the
|
||||
<code>golang-dev@googlegroups.com</code> mailing list. Those changes
|
||||
will then be merged into the GCC sources.
|
||||
main Go repository, only for the <code>gofrontend</code> project
|
||||
rather than the <code>go</code> project. Those changes will then be
|
||||
merged into the GCC sources.
|
||||
</p>
|
||||
|
||||
@@ -32,24 +32,10 @@ will include Go support.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The GCC 4.7.1 release and all later 4.7 releases include a complete
|
||||
<a href="/doc/go1.html">Go 1</a> compiler and libraries.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Due to timing, the GCC 4.8.0 and 4.8.1 releases are close to but not
|
||||
identical to Go 1.1. The GCC 4.8.2 release includes a complete Go
|
||||
1.1.2 implementation.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The GCC 4.9 releases include a complete Go 1.2 implementation.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The GCC 5 releases include a complete implementation of the Go 1.4
|
||||
user libraries. The Go 1.4 runtime is not fully merged, but that
|
||||
should not be visible to Go programs.
|
||||
The GCC 4.7.0 release includes Go support that is very close to
|
||||
<a href="/doc/go1.html">Go 1</a>. Due to release timing it will not
|
||||
include the last few changes to the Go 1 libraries. The GCC 4.7.1
|
||||
release should include a complete Go 1 compiler and libraries.
|
||||
</p>
|
||||
|
||||
<h2 id="Source_code">Source code</h2>
|
||||
@@ -139,8 +125,6 @@ described on
|
||||
the <a href="http://gcc.gnu.org/install/prerequisites.html">gcc web
|
||||
site</a>. It is important to install all the prerequisites before
|
||||
running the gcc <code>configure</code> script.
|
||||
The prerequisite libraries can be conveniently downloaded using the
|
||||
script <code>contrib/download_prerequisites</code> in the GCC sources.
|
||||
|
||||
<h3 id="Build_commands">Build commands</h3>
|
||||
|
||||
@@ -163,11 +147,11 @@ make install
|
||||
<h3 id="Ubuntu">A note on Ubuntu</h3>
|
||||
|
||||
<p>
|
||||
Current versions of Ubuntu and versions of GCC before 4.8 disagree on
|
||||
Current versions of Ubuntu and current versions of gcc disagree on
|
||||
where system libraries and header files are found. This is not a
|
||||
gccgo issue. When building older versions of GCC, setting these
|
||||
environment variables while configuring and building gccgo may fix the
|
||||
problem.
|
||||
gccgo issue, and we hope this will be resolved soon. Until it is,
|
||||
setting these environment variables while configuring and building
|
||||
gccgo may fix the problem.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
@@ -180,10 +164,13 @@ export LIBRARY_PATH C_INCLUDE_PATH CPLUS_INCLUDE_PATH
|
||||
<h2 id="Using_gccgo">Using gccgo</h2>
|
||||
|
||||
<p>
|
||||
The gccgo compiler works like other gcc frontends. As of GCC 5 the gccgo
|
||||
installation also includes a version of the <code>go</code> command,
|
||||
which may be used to build Go programs as described at
|
||||
<a href="https://golang.org/cmd/go">https://golang.org/cmd/go</a>.
|
||||
The gccgo compiler works like other gcc frontends. The gccgo
|
||||
installation does not currently include a version of
|
||||
the <code>go</code> command. However if you have the <code>go</code>
|
||||
command from an installation of the <code>gc</code> compiler, you can
|
||||
use it with gccgo by passing the option <code>-compiler gccgo</code>
|
||||
to <code>go build</code> or <code>go install</code> or <code>go
|
||||
test</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@@ -235,14 +222,13 @@ name the directory where <code>libgo.so</code> is found.
|
||||
|
||||
<li>
|
||||
<p>
|
||||
Passing a <code>-Wl,-R</code> option when you link (replace lib with
|
||||
lib64 if appropriate for your system):
|
||||
Passing a <code>-Wl,-R</code> option when you link:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
go build -gccgoflags -Wl,-R,${prefix}/lib/gcc/MACHINE/VERSION
|
||||
[or]
|
||||
gccgo -o file file.o -Wl,-R,${prefix}/lib/gcc/MACHINE/VERSION
|
||||
[or]
|
||||
gccgo -o file file.o -Wl,-R,${prefix}/lib64/gcc/MACHINE/VERSION
|
||||
</pre>
|
||||
</li>
|
||||
|
||||
@@ -270,33 +256,27 @@ and <code>-g</code> options.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <code>-fgo-pkgpath=PKGPATH</code> option may be used to set a
|
||||
unique prefix for the package being compiled.
|
||||
This option is automatically used by the go command, but you may want
|
||||
to use it if you invoke gccgo directly.
|
||||
This option is intended for use with large
|
||||
programs that contain many packages, in order to allow multiple
|
||||
packages to use the same identifier as the package name.
|
||||
The <code>PKGPATH</code> may be any string; a good choice for the
|
||||
string is the path used to import the package.
|
||||
The <code>-fgo-prefix=PREFIX</code> option may be used to set a unique
|
||||
prefix for the package being compiled. This option is intended for
|
||||
use with large programs that contain many packages, in order to allow
|
||||
multiple packages to use the same identifier as the package name.
|
||||
The <code>PREFIX</code> may be any string; a good choice for the
|
||||
string is the directory where the package will be installed.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <code>-I</code> and <code>-L</code> options, which are synonyms
|
||||
for the compiler, may be used to set the search path for finding
|
||||
imports.
|
||||
These options are not needed if you build with the go command.
|
||||
</p>
|
||||
|
||||
<h2 id="Imports">Imports</h2>
|
||||
|
||||
<p>
|
||||
When you compile a file that exports something, the export
|
||||
information will be stored directly in the object file.
|
||||
If you build with gccgo directly, rather than with the go command,
|
||||
then when you import a package, you must tell gccgo how to find the
|
||||
file.
|
||||
</p>
|
||||
information will be stored directly in the object file. When
|
||||
you import a package, you must tell gccgo how to
|
||||
find the file.
|
||||
|
||||
<p>
|
||||
When you import the package <var>FILE</var> with gccgo,
|
||||
@@ -305,9 +285,9 @@ first one that it finds.
|
||||
|
||||
<ul>
|
||||
<li><code><var>FILE</var>.gox</code>
|
||||
<li><code><var>FILE</var>.o</code>
|
||||
<li><code>lib<var>FILE</var>.so</code>
|
||||
<li><code>lib<var>FILE</var>.a</code>
|
||||
<li><code><var>FILE</var>.o</code>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
@@ -329,10 +309,9 @@ gccgo. Both options take directories to search. The
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The gccgo compiler does not currently (2015-06-15) record
|
||||
The gccgo compiler does not currently (2012-03-20) record
|
||||
the file name of imported packages in the object file. You must
|
||||
arrange for the imported data to be linked into the program.
|
||||
Again, this is not necessary when building with the go command.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
@@ -406,23 +385,23 @@ struct __go_slice {
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The type of a Go function is a pointer to a struct (this is
|
||||
<b style="color: red;">subject to change</b>). The first field in the
|
||||
struct points to the code of the function, which will be equivalent to
|
||||
a pointer to a C function whose parameter types are equivalent, with
|
||||
an additional trailing parameter. The trailing parameter is the
|
||||
closure, and the argument to pass is a pointer to the Go function
|
||||
struct.
|
||||
|
||||
When a Go function returns more than one value, the C function returns
|
||||
a struct. For example, these functions are roughly equivalent:
|
||||
The type of a Go function with no receiver is equivalent to a C function
|
||||
whose parameter types are equivalent. When a Go function returns more
|
||||
than one value, the C function returns a struct. For example, these
|
||||
functions have equivalent types:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
func GoFunction(int) (int, float64)
|
||||
struct { int i; float64 f; } CFunction(int, void*)
|
||||
struct { int i; float64 f; } CFunction(int)
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
A pointer to a Go function is equivalent to a pointer to a C function
|
||||
when the functions have equivalent types (this is
|
||||
<b style="color: red;">subject to change</b>).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Go <code>interface</code>, <code>channel</code>, and <code>map</code>
|
||||
types have no corresponding C type (<code>interface</code> is a
|
||||
@@ -478,14 +457,6 @@ i := c_open(&name[0], syscall.O_RDONLY, 0);
|
||||
<code>os.Open</code> function instead).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Note that if the C function can block, such as in a call
|
||||
to <code>read</code>, calling the C function may block the Go program.
|
||||
Unless you have a clear understanding of what you are doing, all calls
|
||||
between C and Go should be implemented through cgo or SWIG, as for
|
||||
the <code>gc</code> compiler.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The name of Go functions accessed from C is subject to change. At present
|
||||
the name of a Go function that does not have a receiver is
|
||||
@@ -537,4 +508,4 @@ port is for x86. The goal is to extend the port to most of the
|
||||
<a href="http://www.rtems.org/wiki/index.php/SupportedCPUs">
|
||||
architectures supported by <code>RTEMS</code></a>. For more information on the port,
|
||||
as well as instructions on how to install it, please see this
|
||||
<a href="http://www.rtems.org/wiki/index.php/GCCGoRTEMS"><code>RTEMS</code> Wiki page</a>.
|
||||
<a href="http://www.rtems.com/wiki/index.php/GCCGoRTEMS"><code>RTEMS</code> Wiki page</a>.
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user