mirror of
https://github.com/golang/go.git
synced 2026-02-04 09:55:06 +03:00
Compare commits
11 Commits
dev.power6
...
go1.1
| Author | SHA1 | Date | |
|---|---|---|---|
|
205f850cea | ||
|
|
6c7631126f | ||
|
|
9294a08f1b | ||
|
|
46a6097aa7 | ||
|
|
91504a0e0d | ||
|
|
836b670612 | ||
|
|
0a98e78c1f | ||
|
|
c785d6af66 | ||
|
|
99aa2da7ea | ||
|
|
0f1a18b773 | ||
|
|
1c5438aae8 |
31
.hgignore
31
.hgignore
@@ -2,13 +2,13 @@ syntax:glob
|
||||
.DS_Store
|
||||
.git
|
||||
.gitignore
|
||||
*.[5689ao]
|
||||
*.a[5689o]
|
||||
*.[568ao]
|
||||
*.a[568o]
|
||||
*.so
|
||||
*.pyc
|
||||
._*
|
||||
.nfs.*
|
||||
[5689a].out
|
||||
[568a].out
|
||||
*~
|
||||
*.orig
|
||||
*.rej
|
||||
@@ -23,26 +23,33 @@ _test
|
||||
_testmain.go
|
||||
build.out
|
||||
test.out
|
||||
doc/tmpltohtml
|
||||
doc/articles/wiki/*.bin
|
||||
include/plan9/libc_plan9.h
|
||||
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/liblink/anames?.c
|
||||
src/cmd/?l/enam.c
|
||||
src/cmd/cc/y.output
|
||||
src/cmd/cgo/zdefaultcc.go
|
||||
src/cmd/dist/dist.dSYM
|
||||
src/cmd/gc/mkbuiltin1
|
||||
src/cmd/gc/opnames.h
|
||||
src/cmd/gc/y.output
|
||||
src/cmd/go/zdefaultcc.go
|
||||
src/go/doc/headscan
|
||||
src/runtime/mkversion
|
||||
src/runtime/z*
|
||||
src/unicode/maketables
|
||||
src/*.*/
|
||||
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
|
||||
|
||||
23
.hgtags
23
.hgtags
@@ -114,25 +114,4 @@ dc5e410f0b4c32ab11dc992593a2bcf5f607381b weekly
|
||||
2ccfd4b451d319941bfe3e08037e1462d3c15093 go1.0.1
|
||||
5e806355a9e1491aaab53d3612fed4c550b130c0 go1.0.2
|
||||
2d8bc3c94ecb3ec8f70556d5fd237788903c7281 go1.0.3
|
||||
35da6063e57f8cefc82ba1ea542c4d9393ea9dfd go1.1rc2
|
||||
5a15f0dae37931da46f0356cf4cffe775a061c12 go1.1rc3
|
||||
e570c2daeaca10663d36d6dee7f8d1d76e8f7b92 go1.1
|
||||
a7bd9a33067b3537351276e0178a045748ad046a go1.1.1
|
||||
414057ac1f1fc850957088e4c5e95cdbccd2d594 go1.1.2
|
||||
45475ec7eab1c588fc4210b34d5901b15ca1e479 go1.2rc2
|
||||
7422495a6bf9d5e84828ee466406293be84f565a go1.2rc3
|
||||
94af58f9fd71feda5c316d791ed11aaf015f9e82 go1.2rc4
|
||||
b3d5a20b070a92da2458c5788694d1359b353f4a go1.2rc5
|
||||
87dea3f5ebe7510998c84dbeeec89382b7d42f9c go1.2
|
||||
0ddbdc3c7ce27e66508fe58ab81ff29324786026 go1.2.1
|
||||
9c4fdd8369ca4483fbed1cb8e67f02643ca10f79 go1.2.2
|
||||
f8b50ad4cac4d4c4ecf48324b4f512f65e82cc1c go1.3beta1
|
||||
9e1652c32289c164126b6171f024afad5665fc9e go1.3beta2
|
||||
9d5451df4e53acc58a848005b7ec3a24c4b6050c go1.3rc1
|
||||
3f66a43d5180052e2e1e38d979d1aa5ad05b21f9 go1.3rc2
|
||||
9895f9e36435468d503eaa74ee217f28d5e28dd4 go1.3
|
||||
073fc578434bf3e1e22749b559d273c8da728ebb go1.3.1
|
||||
85518b1d6f8d6e16133b9ed2c9db6807522d37de go1.3.2
|
||||
f44017549ff9c3cc5eef74ebe7276cd0dfc066b6 go1.3.3
|
||||
f44017549ff9c3cc5eef74ebe7276cd0dfc066b6 release
|
||||
1fdfd7dfaedb1b7702141617e621ab7328a236a1 go1.4beta1
|
||||
2d8bc3c94ecb3ec8f70556d5fd237788903c7281 release
|
||||
|
||||
157
AUTHORS
157
AUTHORS
@@ -8,94 +8,60 @@
|
||||
|
||||
# Please keep the list sorted.
|
||||
|
||||
Aaron France <aaron.l.france@gmail.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>
|
||||
Ahmed Waheed Moanes <oneofone@gmail.com>
|
||||
Akshat Kumar <seed@mail.nanosouffle.net>
|
||||
Alan Shreve <alan@inconshreveable.com>
|
||||
Albert Strasheim <fullung@gmail.com>
|
||||
Alberto Donizetti <alb.donizetti@gmail.com>
|
||||
Alberto García Hierro <alberto@garciahierro.com> <alberto.garcia.hierro@gmail.com>
|
||||
Aleksandar Dezelin <dezelin@gmail.com>
|
||||
Alex A Skinner <alex@lx.lc>
|
||||
Alex Brainman <alex.brainman@gmail.com>
|
||||
Alex Jin <toalexjin@gmail.com>
|
||||
Alexander Larsson <alexander.larsson@gmail.com>
|
||||
Alexander Orlov <alexander.orlov@loxal.net>
|
||||
Alexander Reece <awreece@gmail.com>
|
||||
Alexander Surma <surma@surmair.de>
|
||||
Alexander Zhavnerchik <alex.vizor@gmail.com>
|
||||
Alexandre Normand <alexandre.normand@gmail.com>
|
||||
Alexei Sholik <alcosholik@gmail.com>
|
||||
Alexey Borzenkov <snaury@gmail.com>
|
||||
Alexey Palazhchenko <alexey.palazhchenko@gmail.com>
|
||||
Amir Mohammad Saied <amir@gluegadget.com>
|
||||
Amrut Joshi <amrut.joshi@gmail.com>
|
||||
Andrei Vieru <euvieru@gmail.com>
|
||||
Andrew Balholm <andybalholm@gmail.com>
|
||||
Andrew Bonventre <andybons@chromium.org>
|
||||
Andrew Bursavich <abursavich@gmail.com>
|
||||
Andrew Harding <andrew@spacemonkey.com>
|
||||
Andrew Lutomirski <andy@luto.us>
|
||||
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>
|
||||
Andrey Mirtchovski <mirtchovski@gmail.com>
|
||||
Andriy Lytvynov <lytvynov.a.v@gmail.com>
|
||||
Andy Davis <andy@bigandian.com>
|
||||
Anfernee Yongkun Gui <anfernee.gui@gmail.com>
|
||||
Anh Hai Trinh <anh.hai.trinh@gmail.com>
|
||||
Anschel Schaffer-Cohen <anschelsc@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>
|
||||
Arnaud Ysmal <arnaud.ysmal@gmail.com>
|
||||
Arne Hormann <arnehormann@gmail.com>
|
||||
Aron Nopanen <aron.nopanen@gmail.com>
|
||||
Arvindh Rajesh Tamilmani <art@a-30.net>
|
||||
Ato Araki <ato.araki@gmail.com>
|
||||
Aulus Egnatius Varialus <varialus@gmail.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 Mizerany <blake.mizerany@gmail.com>
|
||||
Bobby Powers <bobbypowers@gmail.com>
|
||||
Brendan Daniel Tracey <tracey.brendan@gmail.com>
|
||||
Brian Dellisanti <briandellisanti@gmail.com>
|
||||
Brian G. Merrell <bgmerrell@gmail.com>
|
||||
Brian Gitonga Marete <marete@toshnix.com>
|
||||
Brian Ketelsen <bketelsen@gmail.com>
|
||||
Caine Tighe <arctanofyourface@gmail.com>
|
||||
Caleb Spare <cespare@gmail.com>
|
||||
Carl Chatfield <carlchatfield@gmail.com>
|
||||
Carlos Castillo <cookieo9@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 Howey <howeyc@gmail.com>
|
||||
Chris Jones <chris@cjones.org>
|
||||
Chris Lennert <calennert@gmail.com>
|
||||
Chris McGee <sirnewton_01@yahoo.ca> <newton688@gmail.com>
|
||||
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 Nielsen <m4dh4tt3r@gmail.com>
|
||||
@@ -104,45 +70,29 @@ Christopher Wedgwood <cw@f00f.org>
|
||||
Clement Skau <clementskau@gmail.com>
|
||||
Conrad Meyer <cemeyer@cs.washington.edu>
|
||||
Corey Thomasson <cthom.lists@gmail.com>
|
||||
Cristian Staretu <unclejacksons@gmail.com>
|
||||
Damian Gryski <dgryski@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 Krech <eikeon@eikeon.com>
|
||||
Daniel Lidén <daniel.liden.87@gmail.com>
|
||||
Daniel Morsing <daniel.morsing@gmail.com>
|
||||
Daniel Theophanes <kardianos@gmail.com>
|
||||
Darren Elwood <darren@textnode.com>
|
||||
Dave Cheney <dave@cheney.net>
|
||||
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 Jakob Fritz <david.jakob.fritz@gmail.com>
|
||||
David Leon Gil <coruus@gmail.com>
|
||||
David Thomas <davidthomas426@gmail.com>
|
||||
David Titarenco <david.titarenco@gmail.com>
|
||||
Dean Prichard <dean.prichard@gmail.com>
|
||||
Denis Brandolini <denis.brandolini@gmail.com>
|
||||
Derek Parker <parkerderek86@gmail.com>
|
||||
Devon H. O'Dell <devon.odell@gmail.com>
|
||||
Dhiru Kholia <dhiru.kholia@gmail.com>
|
||||
Dimitri Tcaciuc <dtcaciuc@gmail.com>
|
||||
Dmitri Shuralyov <shurcooL@gmail.com>
|
||||
Dmitriy Shelenin <deemok@googlemail.com> <deemok@gmail.com>
|
||||
Dmitry Chestnykh <dchest@gmail.com>
|
||||
Dominik Honnef <dominik.honnef@gmail.com>
|
||||
Donovan Hide <donovanhide@gmail.com>
|
||||
Dropbox, Inc.
|
||||
Duncan Holm <mail@frou.org>
|
||||
Dustin Sallings <dsallings@gmail.com>
|
||||
Dustin Shields-Cloues <dcloues@gmail.com>
|
||||
Eden Li <eden.li@gmail.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>
|
||||
@@ -151,51 +101,33 @@ Eric Clark <zerohp@gmail.com>
|
||||
Eric Milliken <emilliken@gmail.com>
|
||||
Eric Roshan-Eisner <eric.d.eisner@gmail.com>
|
||||
Erik St. Martin <alakriti@gmail.com>
|
||||
Erik Westrup <erik.westrup@gmail.com>
|
||||
Esko Luontola <esko.luontola@gmail.com>
|
||||
Evan Shaw <chickencha@gmail.com>
|
||||
Ewan Chou <coocood@gmail.com>
|
||||
Fabrizio Milo <mistobaan@gmail.com>
|
||||
Fan Hongjian <fan.howard@gmail.com>
|
||||
Fastly, Inc.
|
||||
Fatih Arslan <fatih@arslan.io>
|
||||
Fazlul Shahriar <fshahriar@gmail.com>
|
||||
Felix Geisendörfer <haimuiba@gmail.com>
|
||||
Firmansyah Adiputra <frm.adiputra@gmail.com>
|
||||
Florian Uekermann <florian@uekermann-online.de>
|
||||
Florian Weimer <fw@deneb.enyo.de>
|
||||
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>
|
||||
Gabriel Aszalos <gabriel.aszalos@gmail.com>
|
||||
Frithjof Schulze <schulze@math.uni-hannover.de>
|
||||
Gary Burd <gary@beagledreams.com>
|
||||
Gautham Thambidorai <gautham.dorai@gmail.com>
|
||||
Georg Reinke <guelfey@gmail.com>
|
||||
Gerasimos Dimitriadis <gedimitr@gmail.com>
|
||||
Gideon Jan-Wessel Redelinghuys <gjredelinghuys@gmail.com>
|
||||
Giles Lean <giles.lean@pobox.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>
|
||||
Gustav Paul <gustav.paul@gmail.com>
|
||||
Gustavo Niemeyer <gustavo@niemeyer.net>
|
||||
Gwenael Treguier <gwenn.kahz@gmail.com>
|
||||
Harley Laue <losinggeneration@gmail.com>
|
||||
Hector Chu <hectorchu@gmail.com>
|
||||
Hector Martin Cantero <hector@marcansoft.com>
|
||||
Henning Schmiedehausen <henning@schmiedehausen.org>
|
||||
Henrik Edwards <henrik.edwards@gmail.com>
|
||||
Herbert Georg Fischer <herbert.fischer@gmail.com>
|
||||
Hong Ruiqi <hongruiqi@gmail.com>
|
||||
Icarus Sparry <golang@icarus.freeuk.com>
|
||||
Ingo Oeser <nightlyone@googlemail.com>
|
||||
Isaac Wagner <ibw@isaacwagner.me>
|
||||
Jakob Borg <jakob@nym.se>
|
||||
Jakub Ryszard Czarnowicz <j.czarnowicz@gmail.com>
|
||||
James David Chalfant <james.chalfant@gmail.com>
|
||||
James Fysh <james.fysh@gmail.com>
|
||||
James Gray <james@james4k.com>
|
||||
@@ -204,133 +136,82 @@ James P. Cooper <jamespcooper@gmail.com>
|
||||
James Toy <nil@opensesame.st>
|
||||
James Whitehead <jnwhiteh@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 Del Ponte <delpontej@gmail.com>
|
||||
Jason Travis <infomaniac7@gmail.com>
|
||||
Jay Weisskopf <jay@jayschwa.net>
|
||||
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>
|
||||
Jim McGrath <jimmc2@gmail.com>
|
||||
Jimmy Zelinskie <jimmyzelinskie@gmail.com>
|
||||
Jingcheng Zhang <diogin@gmail.com>
|
||||
Joakim Sernbrant <serbaut@gmail.com>
|
||||
Joe Poirier <jdpoirier@gmail.com>
|
||||
Joe Shaw <joe@joeshaw.org>
|
||||
Joel Stemmer <stemmertech@gmail.com>
|
||||
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 Shahid <jvshahid@gmail.com>
|
||||
John Tuley <john@tuley.org>
|
||||
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>
|
||||
Jose Luis Vázquez González <josvazg@gmail.com>
|
||||
Joseph Holsten <joseph@josephholsten.com>
|
||||
Josh Bleecher Snyder <josharian@gmail.com>
|
||||
Josh Goebel <dreamer3@gmail.com>
|
||||
Josh Holland <jrh@joshh.co.uk>
|
||||
Joshua Chase <jcjoshuachase@gmail.com>
|
||||
JT Olds <jtolds@xnet5.com>
|
||||
Jukka-Pekka Kekkonen <karatepekka@gmail.com>
|
||||
Julian Phillips <julian@quantumfyre.co.uk>
|
||||
Julien Schmidt <google@julienschmidt.com>
|
||||
Kai Backman <kaib@golang.org>
|
||||
Kamil Kisiel <kamil@kamilkisiel.net> <kamil.kisiel@gmail.com>
|
||||
Katrina Owen <katrina.owen@gmail.com>
|
||||
Kei Son <hey.calmdown@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>
|
||||
Kevin Ballard <kevin@sb.org>
|
||||
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>
|
||||
Linaro Limited
|
||||
Lorenzo Stoakes <lstoakes@gmail.com>
|
||||
Luca Greco <luca.greco@alcacoop.it>
|
||||
Lucio De Re <lucio.dere@gmail.com>
|
||||
Luit van Drongelen <luitvd@gmail.com>
|
||||
Luka Zakrajšek <tr00.g33k@gmail.com>
|
||||
Luke Curley <qpingu@gmail.com>
|
||||
Manuel Mendez <mmendez534@gmail.com>
|
||||
Marc Weistroff <marc@weistroff.net>
|
||||
Marco Hennings <marco.hennings@freiheit.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 Neubauer <m.ne@gmx.net>
|
||||
Martin Olsson <martin@minimum.se>
|
||||
Mateusz Czapliński <czapkofan@gmail.com>
|
||||
Mathieu Lonjaret <mathieu.lonjaret@gmail.com>
|
||||
Mats Lidell <mats.lidell@cag.se>
|
||||
Matt Aimonetti <mattaimonetti@gmail.com>
|
||||
Matt Jibson <matt.jibson@gmail.com>
|
||||
Matt Joiner <anacrolix@gmail.com>
|
||||
Matt Reiferson <mreiferson@gmail.com>
|
||||
Matthew Cottingham <mattcottingham@gmail.com>
|
||||
Matthew Horsnell <matthew.horsnell@gmail.com>
|
||||
Maxim Khitrov <max@mxcrypt.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 Gehring <mg@ebfe.org>
|
||||
Michael Hoisie <hoisie@gmail.com>
|
||||
Michael Lewis <mikelikespie@gmail.com>
|
||||
Michael MacInnis <Michael.P.MacInnis@gmail.com>
|
||||
Michael Pearson <mipearson@gmail.com>
|
||||
Michael Stapelberg <michael@stapelberg.de>
|
||||
Michael Teichgräber <mteichgraeber@gmx.de>
|
||||
Michał Derkacz <ziutek@lnet.pl>
|
||||
Miek Gieben <miek@miek.nl>
|
||||
Mihai Borobocea <MihaiBorobocea@gmail.com>
|
||||
Mikael Tillenius <mikti42@gmail.com>
|
||||
Mike Andrews <mra@xoba.com>
|
||||
Mike Rosset <mike.rosset@gmail.com>
|
||||
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>
|
||||
Moov Corporation
|
||||
Moriyoshi Koizumi <mozo@mozo.jp>
|
||||
Môshe van der Sterre <moshevds@gmail.com>
|
||||
Nan Deng <monnand@gmail.com>
|
||||
Nathan John Youngman <nj@nathany.com>
|
||||
Nathan P Finch <nate.finch@gmail.com>
|
||||
ngmoco, LLC
|
||||
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>
|
||||
Nicolas Kaiser <nikai@nikai.net>
|
||||
Nicolas Owens <mischief@offblast.org>
|
||||
Nigel Kerr <nigel.kerr@gmail.com>
|
||||
Noah Campbell <noahcampbell@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 Saingre <osaingre@gmail.com>
|
||||
@@ -340,40 +221,28 @@ 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 Sbarra <Sbarra.Paul@gmail.com>
|
||||
Paul van Brouwershaven <paul@vanbrouwershaven.com>
|
||||
Pavel Zinovkin <pavel.zinovkin@gmail.com>
|
||||
Percy Wegmann <ox.to.a.cart@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 Mundy <go.peter.90@gmail.com>
|
||||
Péter Surányi <speter.go1@gmail.com>
|
||||
Péter Szilágyi <peterke@gmail.com>
|
||||
Peter Waller <peter.waller@gmail.com>
|
||||
Peter Williams <pwil3058@gmail.com>
|
||||
Philip K. Warren <pkwarren@gmail.com>
|
||||
Pieter Droogendijk <pieter@binky.org.uk>
|
||||
Pietro Gagliardi <pietro10@mac.com>
|
||||
Preetam Jinka <pj@preet.am>
|
||||
Quan Yong Zhai <qyzhai@gmail.com>
|
||||
Raif S. Naffah <go@naffah-raif.name>
|
||||
Red Hat, Inc.
|
||||
Rémy Oudompheng <oudomphe@phare.normalesup.org>
|
||||
Richard Crowley <r@rcrowley.org>
|
||||
Richard Eric Gavaletz <gavaletz@gmail.com>
|
||||
Richard Musiol <mail@richard-musiol.de>
|
||||
Rick Arnold <rickarnoldjr@gmail.com>
|
||||
Risto Jaakko Saarelma <rsaarelm@gmail.com>
|
||||
Robert Daniel Kortschak <dan.kortschak@adelaide.edu.au>
|
||||
Robert Dinu <r@varp.se>
|
||||
Robert Dinu <r@oktett.se>
|
||||
Robert Figueiredo <robfig@gmail.com>
|
||||
Robert Hencke <robert.hencke@gmail.com>
|
||||
Robert Obryk <robryk@gmail.com>
|
||||
@@ -382,15 +251,11 @@ 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>
|
||||
Ron Hashimoto <mail@h2so5.net>
|
||||
Ron Minnich <rminnich@gmail.com>
|
||||
Ross Light <rlight2@gmail.com>
|
||||
Rowan Worth <sqweek@gmail.com>
|
||||
Ryan Hitchman <hitchmanr@gmail.com>
|
||||
Ryan Slade <ryanslade@gmail.com>
|
||||
S.Çağlar Onur <caglar@10ur.org>
|
||||
Sanjay Menakuru <balasanjay@gmail.com>
|
||||
Scott Ferguson <scottwferg@gmail.com>
|
||||
Scott Lawrence <bytbox@gmail.com>
|
||||
Sebastien Binet <seb.binet@gmail.com>
|
||||
Sébastien Paolacci <sebastien.paolacci@gmail.com>
|
||||
@@ -401,38 +266,25 @@ Shane Hansen <shanemhansen@gmail.com>
|
||||
Shawn Smith <shawn.p.smith@gmail.com>
|
||||
Shenghou Ma <minux.ma@gmail.com>
|
||||
Shivakumar GN <shivakumar.gn@gmail.com>
|
||||
Simon Whitehead <chemnova@gmail.com>
|
||||
Sokolov Yura <funny.falcon@gmail.com>
|
||||
Spring Mc <heresy.mc@gmail.com>
|
||||
StalkR <stalkr@stalkr.net>
|
||||
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>
|
||||
Steven Elliot Harris <seharris@gmail.com>
|
||||
Steven Hartland <steven.hartland@multiplay.co.uk>
|
||||
Sven Almgren <sven@tras.se>
|
||||
Szabolcs Nagy <nsz@port70.net>
|
||||
Tad Glines <tad.glines@gmail.com>
|
||||
Taj Khattra <taj.khattra@gmail.com>
|
||||
Tarmigan Casebolt <tarmigan@gmail.com>
|
||||
Taru Karttunen <taruti@taruti.net>
|
||||
Tetsuo Kiso <tetsuokiso9@gmail.com>
|
||||
Thiago Fransosi Farina <thiago.farina@gmail.com>
|
||||
Thomas Alan Copeland <talan.copeland@gmail.com>
|
||||
Thomas Kappler <tkappler@gmail.com>
|
||||
Timo Savola <timo.savola@gmail.com>
|
||||
Timo Truyts <alkaloid.btx@gmail.com>
|
||||
Tobias Columbus <tobias.columbus@gmail.com>
|
||||
Tom Linford <tomlinford@gmail.com>
|
||||
Tor Andersson <tor.andersson@gmail.com>
|
||||
Travis Cline <travis.cline@gmail.com>
|
||||
Tudor Golubenco <tudor.g@gmail.com>
|
||||
Tw <tw19881113@gmail.com>
|
||||
Tyler Bunnell <tylerbunnell@gmail.com>
|
||||
Ugorji Nwoke <ugorji@gmail.com>
|
||||
Ulf Holm Nielsen <doktor@dyregod.dk>
|
||||
Uriel Mangado <uriel@berlinblue.org>
|
||||
Vadim Vygonets <unixdj@gmail.com>
|
||||
Vincent Ambo <tazjin@googlemail.com>
|
||||
@@ -443,8 +295,6 @@ Volker Dobler <dr.volker.dobler@gmail.com>
|
||||
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>
|
||||
Xia Bin <snyh@snyh.org>
|
||||
Xing Xing <mikespook@gmail.com>
|
||||
Yasuhiro Matsumoto <mattn.jp@gmail.com>
|
||||
Yissakhar Z. Beck <yissakhar.beck@gmail.com>
|
||||
@@ -455,4 +305,3 @@ Yuusei Kuwana <kuwana@kumama.org>
|
||||
Yuval Pavel Zholkover <paulzhol@gmail.com>
|
||||
Ziad Hatahet <hatahet@gmail.com>
|
||||
Zorion Arrizabalaga <zorionk@gmail.com>
|
||||
申习之 <bronze1man@gmail.com>
|
||||
|
||||
203
CONTRIBUTORS
203
CONTRIBUTORS
@@ -31,72 +31,47 @@
|
||||
|
||||
# Please keep the list sorted.
|
||||
|
||||
Aaron France <aaron.l.france@gmail.com>
|
||||
Aaron Kemp <kemp.aaron@gmail.com>
|
||||
Abhinav Gupta <abhinav.g90@gmail.com>
|
||||
Adam Langley <agl@golang.org>
|
||||
Adrian Nos <nos.adrian@gmail.com>
|
||||
Adrian O'Grady <elpollouk@gmail.com>
|
||||
Adrien Bustany <adrien-xx-google@bustany.org>
|
||||
Ahmed Waheed Moanes <oneofone@gmail.com>
|
||||
Akshat Kumar <seed@mail.nanosouffle.net>
|
||||
Alan Donovan <adonovan@google.com>
|
||||
Alan Shreve <alan@inconshreveable.com>
|
||||
Albert Strasheim <fullung@gmail.com>
|
||||
Alberto Donizetti <alb.donizetti@gmail.com>
|
||||
Alberto García Hierro <alberto@garciahierro.com> <alberto.garcia.hierro@gmail.com>
|
||||
Aleksandar Dezelin <dezelin@gmail.com>
|
||||
Alex A Skinner <alex@lx.lc>
|
||||
Alex Brainman <alex.brainman@gmail.com>
|
||||
Alex Bramley <abramley@google.com>
|
||||
Alex Jin <toalexjin@gmail.com>
|
||||
Alexander Larsson <alexander.larsson@gmail.com>
|
||||
Alexander Orlov <alexander.orlov@loxal.net>
|
||||
Alexander Reece <awreece@gmail.com>
|
||||
Alexander Surma <surma@surmair.de>
|
||||
Alexander Zhavnerchik <alex.vizor@gmail.com>
|
||||
Alexandre Normand <alexandre.normand@gmail.com>
|
||||
Alexandru Moșoi <brtzsnr@gmail.com>
|
||||
Alexei Sholik <alcosholik@gmail.com>
|
||||
Alexey Borzenkov <snaury@gmail.com>
|
||||
Alexey Palazhchenko <alexey.palazhchenko@gmail.com>
|
||||
Alexis Imperial-Legrand <ail@google.com>
|
||||
Amir Mohammad Saied <amir@gluegadget.com>
|
||||
Amrut Joshi <amrut.joshi@gmail.com>
|
||||
Andrea Spadaccini <spadaccio@google.com>
|
||||
Andreas Jellinghaus <andreas@ionisiert.de> <anj@google.com>
|
||||
Andrei Vieru <euvieru@gmail.com>
|
||||
Andres Erbsen <andreser@google.com>
|
||||
Andrew Balholm <andybalholm@gmail.com>
|
||||
Andrew Bonventre <andybons@chromium.org>
|
||||
Andrew Bursavich <abursavich@gmail.com>
|
||||
Andrew Gerrand <adg@golang.org>
|
||||
Andrew Harding <andrew@spacemonkey.com>
|
||||
Andrew Lutomirski <andy@luto.us>
|
||||
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>
|
||||
Andrey Mirtchovski <mirtchovski@gmail.com>
|
||||
Andriy Lytvynov <lytvynov.a.v@gmail.com>
|
||||
Andy Davis <andy@bigandian.com>
|
||||
Anfernee Yongkun Gui <anfernee.gui@gmail.com>
|
||||
Anh Hai Trinh <anh.hai.trinh@gmail.com>
|
||||
Anschel Schaffer-Cohen <anschelsc@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>
|
||||
Arnaud Ysmal <arnaud.ysmal@gmail.com>
|
||||
Arne Hormann <arnehormann@gmail.com>
|
||||
Aron Nopanen <aron.nopanen@gmail.com>
|
||||
Arvindh Rajesh Tamilmani <art@a-30.net>
|
||||
Asim Shankar <asimshankar@gmail.com>
|
||||
Ato Araki <ato.araki@gmail.com>
|
||||
Aulus Egnatius Varialus <varialus@gmail.com>
|
||||
Austin Clements <austin@google.com> <aclements@csail.mit.edu>
|
||||
Austin Clements <aclements@csail.mit.edu>
|
||||
Balazs Lecz <leczb@google.com>
|
||||
Ben Eitzen <eitzenb@golang.org>
|
||||
Ben Fried <ben.fried@gmail.com>
|
||||
@@ -104,50 +79,34 @@ Ben Lynn <benlynn@gmail.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>
|
||||
Bill Neubauer <wcn@golang.org> <wcn@google.com> <bill.neubauer@gmail.com>
|
||||
Bill Thiede <couchmoney@gmail.com>
|
||||
Billie Harold Cleek <bhcleek@gmail.com>
|
||||
Bjorn Tillenius <bjorn@tillenius.me>
|
||||
Bjorn Tipling <bjorn.tipling@gmail.com>
|
||||
Blake Mizerany <blake.mizerany@gmail.com>
|
||||
Bobby Powers <bobbypowers@gmail.com>
|
||||
Brad Fitzpatrick <bradfitz@golang.org> <bradfitz@gmail.com>
|
||||
Brad Garcia <bgarcia@golang.org>
|
||||
Brendan Daniel Tracey <tracey.brendan@gmail.com>
|
||||
Brendan O'Dea <bod@golang.org>
|
||||
Brian Dellisanti <briandellisanti@gmail.com>
|
||||
Brian G. Merrell <bgmerrell@gmail.com>
|
||||
Brian Gitonga Marete <marete@toshnix.com>
|
||||
Brian Ketelsen <bketelsen@gmail.com>
|
||||
Brian Slesinsky <skybrian@google.com>
|
||||
Burcu Dogan <jbd@google.com>
|
||||
Caine Tighe <arctanofyourface@gmail.com>
|
||||
Caleb Spare <cespare@gmail.com>
|
||||
Carl Chatfield <carlchatfield@gmail.com>
|
||||
Carl Mastrangelo <notcarl@google.com>
|
||||
Carl Shapiro <cshapiro@google.com> <cshapiro@golang.org>
|
||||
Carlos Castillo <cookieo9@gmail.com>
|
||||
Cary Hull <chull@google.com>
|
||||
Case Nelson <case.nelson@gmail.com>
|
||||
Casey Marshall <casey.marshall@gmail.com>
|
||||
Catalin Patulea <catalinp@google.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 Howey <howeyc@gmail.com>
|
||||
Chris Hundt <hundt@google.com>
|
||||
Chris Jones <chris@cjones.org> <chris.jones.yar@gmail.com>
|
||||
Chris Lennert <calennert@gmail.com>
|
||||
Chris Manghane <cmang@golang.org>
|
||||
Chris McGee <sirnewton_01@yahoo.ca> <newton688@gmail.com>
|
||||
Christian Himpel <chressie@googlemail.com> <chressie@gmail.com>
|
||||
Christine Hansmann <chhansmann@gmail.com>
|
||||
Christoffer Buchholz <christoffer.buchholz@gmail.com>
|
||||
Christoph Hack <christoph@tux21b.org>
|
||||
Christopher Cahoon <chris.cahoon@gmail.com>
|
||||
Christopher Nielsen <m4dh4tt3r@gmail.com>
|
||||
@@ -159,59 +118,37 @@ Colby Ranger <cranger@google.com>
|
||||
Conrad Meyer <cemeyer@cs.washington.edu>
|
||||
Corey Thomasson <cthom.lists@gmail.com>
|
||||
Cosmos Nicolaou <cnicolaou@google.com>
|
||||
Cristian Staretu <unclejacksons@gmail.com>
|
||||
Damian Gryski <dgryski@gmail.com>
|
||||
Damien Neil <dneil@google.com>
|
||||
Dan Callahan <dan.callahan@gmail.com>
|
||||
Dan Peterson <dpiddy@gmail.com>
|
||||
Dan Sinclair <dan.sinclair@gmail.com>
|
||||
Daniel Fleischman <danielfleischman@gmail.com>
|
||||
Daniel Krech <eikeon@eikeon.com>
|
||||
Daniel Lidén <daniel.liden.87@gmail.com>
|
||||
Daniel Morsing <daniel.morsing@gmail.com>
|
||||
Daniel Nadasi <dnadasi@google.com>
|
||||
Daniel Theophanes <kardianos@gmail.com>
|
||||
Darren Elwood <darren@textnode.com>
|
||||
Dave Borowitz <dborowitz@google.com>
|
||||
Dave Cheney <dave@cheney.net>
|
||||
Dave Day <djd@golang.org>
|
||||
Dave Grijalva <dgrijalva@ngmoco.com>
|
||||
David Anderson <danderson@google.com>
|
||||
David Barnett <dbarnett@google.com>
|
||||
David Bürgin <676c7473@gmail.com>
|
||||
David Calavera <david.calavera@gmail.com>
|
||||
David Covert <davidhcovert@gmail.com>
|
||||
David Crawshaw <david.crawshaw@zentus.com> <crawshaw@google.com> <crawshaw@golang.org>
|
||||
David Crawshaw <david.crawshaw@zentus.com> <crawshaw@google.com>
|
||||
David du Colombier <0intro@gmail.com>
|
||||
David Forsythe <dforsythe@gmail.com>
|
||||
David G. Andersen <dave.andersen@gmail.com>
|
||||
David Jakob Fritz <david.jakob.fritz@gmail.com>
|
||||
David Leon Gil <coruus@gmail.com>
|
||||
David McLeish <davemc@google.com>
|
||||
David Presotto <presotto@gmail.com>
|
||||
David Symonds <dsymonds@golang.org>
|
||||
David Thomas <davidthomas426@gmail.com>
|
||||
David Titarenco <david.titarenco@gmail.com>
|
||||
Dean Prichard <dean.prichard@gmail.com>
|
||||
Denis Brandolini <denis.brandolini@gmail.com>
|
||||
Derek Parker <parkerderek86@gmail.com>
|
||||
Devon H. O'Dell <devon.odell@gmail.com>
|
||||
Dhiru Kholia <dhiru.kholia@gmail.com>
|
||||
Dimitri Tcaciuc <dtcaciuc@gmail.com>
|
||||
Dmitri Shuralyov <shurcooL@gmail.com>
|
||||
Dmitriy Shelenin <deemok@googlemail.com> <deemok@gmail.com>
|
||||
Dmitriy Vyukov <dvyukov@google.com>
|
||||
Dmitry Chestnykh <dchest@gmail.com>
|
||||
Dominik Honnef <dominik.honnef@gmail.com>
|
||||
Donovan Hide <donovanhide@gmail.com>
|
||||
Drew Hintz <adhintz@google.com>
|
||||
Duncan Holm <mail@frou.org>
|
||||
Dustin Long <dustmop@gmail.com>
|
||||
Dustin Sallings <dsallings@gmail.com>
|
||||
Dustin Shields-Cloues <dcloues@gmail.com>
|
||||
Eden Li <eden.li@gmail.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>
|
||||
@@ -220,52 +157,33 @@ Eric Clark <zerohp@gmail.com>
|
||||
Eric Milliken <emilliken@gmail.com>
|
||||
Eric Roshan-Eisner <eric.d.eisner@gmail.com>
|
||||
Erik St. Martin <alakriti@gmail.com>
|
||||
Erik Westrup <erik.westrup@gmail.com>
|
||||
Esko Luontola <esko.luontola@gmail.com>
|
||||
Evan Kroske <evankroske@google.com>
|
||||
Evan Martin <evan.martin@gmail.com>
|
||||
Evan Shaw <chickencha@gmail.com>
|
||||
Ewan Chou <coocood@gmail.com>
|
||||
Fabrizio Milo <mistobaan@gmail.com>
|
||||
Fan Hongjian <fan.howard@gmail.com>
|
||||
Fatih Arslan <fatih@arslan.io>
|
||||
Fazlul Shahriar <fshahriar@gmail.com>
|
||||
Felix Geisendörfer <haimuiba@gmail.com>
|
||||
Firmansyah Adiputra <frm.adiputra@gmail.com>
|
||||
Florian Uekermann <florian@uekermann-online.de> <f1@uekermann-online.de>
|
||||
Florian Weimer <fw@deneb.enyo.de>
|
||||
Folke Behrens <folke@google.com>
|
||||
Francesc Campoy <campoy@golang.org>
|
||||
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>
|
||||
Frithjof Schulze <schulze@math.uni-hannover.de>
|
||||
Fumitoshi Ukai <ukai@google.com>
|
||||
Gaal Yahas <gaal@google.com>
|
||||
Gabriel Aszalos <gabriel.aszalos@gmail.com>
|
||||
Gary Burd <gary@beagledreams.com> <gary.burd@gmail.com>
|
||||
Gautham Thambidorai <gautham.dorai@gmail.com>
|
||||
Georg Reinke <guelfey@gmail.com>
|
||||
Gerasimos Dimitriadis <gedimitr@gmail.com>
|
||||
Gideon Jan-Wessel Redelinghuys <gjredelinghuys@gmail.com>
|
||||
Giles Lean <giles.lean@pobox.com>
|
||||
Glenn Lewis <gmlewis@google.com>
|
||||
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>
|
||||
Gustav Paul <gustav.paul@gmail.com>
|
||||
Gustavo Franco <gustavorfranco@gmail.com>
|
||||
Gustavo Niemeyer <gustavo@niemeyer.net> <n13m3y3r@gmail.com>
|
||||
Gwenael Treguier <gwenn.kahz@gmail.com>
|
||||
Hana Kim <hyangah@gmail.com>
|
||||
Han-Wen Nienhuys <hanwen@google.com>
|
||||
Harley Laue <losinggeneration@gmail.com>
|
||||
Hector Chu <hectorchu@gmail.com>
|
||||
Hector Martin Cantero <hector@marcansoft.com>
|
||||
Henning Schmiedehausen <henning@schmiedehausen.org>
|
||||
Henrik Edwards <henrik.edwards@gmail.com>
|
||||
Herbert Georg Fischer <herbert.fischer@gmail.com>
|
||||
Hong Ruiqi <hongruiqi@gmail.com>
|
||||
Hossein Sheikh Attar <hattar@google.com>
|
||||
@@ -275,38 +193,27 @@ Ingo Oeser <nightlyone@googlemail.com> <nightlyone@gmail.com>
|
||||
Isaac Wagner <ibw@isaacwagner.me>
|
||||
Ivan Krasin <krasin@golang.org>
|
||||
Jacob Baskin <jbaskin@google.com>
|
||||
Jakob Borg <jakob@nym.se>
|
||||
Jakub Ryszard Czarnowicz <j.czarnowicz@gmail.com>
|
||||
James Aguilar <jaguilar@google.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 Robinson <jamesr@google.com> <jamesr.gatech@gmail.com>
|
||||
James Toy <nil@opensesame.st>
|
||||
James Tucker <raggi@google.com>
|
||||
James Whitehead <jnwhiteh@gmail.com>
|
||||
Jamie Gennis <jgennis@google.com> <jgennis@gmail.com>
|
||||
Jamie Turner <jamwt@dropbox.com>
|
||||
Jamie Wilkinson <jaq@spacepants.org>
|
||||
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> <jani.monoses@gmail.com>
|
||||
Jaroslavas Počepko <jp@webmaster.ms>
|
||||
Jason Del Ponte <delpontej@gmail.com>
|
||||
Jason Travis <infomaniac7@gmail.com>
|
||||
Jay Weisskopf <jay@jayschwa.net>
|
||||
Jean-Marc Eurin <jmeurin@google.com>
|
||||
Jed Denlea <jed@fastly.com>
|
||||
Jeff Hodges <jeff@somethingsimilar.com>
|
||||
Jeff R. Allen <jra@nella.org> <jeff.allen@gmail.com>
|
||||
Jeff Sickel <jas@corpus-callosum.com>
|
||||
Jeff Wendling <jeff@spacemonkey.com>
|
||||
Jens Frederich <jfrederich@gmail.com>
|
||||
Jeremiah Harmsen <jeremiah@google.com>
|
||||
Jeremy Jackins <jeremyjackins@gmail.com>
|
||||
Jeremy Schlatter <jeremy.schlatter@gmail.com>
|
||||
@@ -315,19 +222,13 @@ Jimmy Zelinskie <jimmyzelinskie@gmail.com>
|
||||
Jingcheng Zhang <diogin@gmail.com>
|
||||
Joakim Sernbrant <serbaut@gmail.com>
|
||||
Joe Poirier <jdpoirier@gmail.com>
|
||||
Joe Shaw <joe@joeshaw.org>
|
||||
Joel Sing <jsing@google.com>
|
||||
Joel Stemmer <stemmertech@gmail.com>
|
||||
Johan Euphrosine <proppy@google.com>
|
||||
John Asmuth <jasmuth@gmail.com>
|
||||
John Beisley <huin@google.com>
|
||||
John C Barstow <jbowtie@amathaine.com>
|
||||
John DeNero <denero@google.com>
|
||||
John Graham-Cumming <jgc@jgc.org> <jgrahamc@gmail.com>
|
||||
John Howard Palevich <jack.palevich@gmail.com>
|
||||
John Newlin <jnewlin@google.com>
|
||||
John Shahid <jvshahid@gmail.com>
|
||||
John Tuley <john@tuley.org>
|
||||
Jonathan Allie <jonallie@google.com>
|
||||
Jonathan Feinberg <feinberg@google.com>
|
||||
Jonathan Gold <jgold.bg@gmail.com>
|
||||
@@ -341,34 +242,22 @@ Jongmin Kim <atomaths@gmail.com>
|
||||
Jos Visser <josv@google.com>
|
||||
Jose Luis Vázquez González <josvazg@gmail.com>
|
||||
Joseph Bonneau <jcb@google.com>
|
||||
Joseph Holsten <joseph@josephholsten.com>
|
||||
Josh Bleecher Snyder <josharian@gmail.com>
|
||||
Josh Goebel <dreamer3@gmail.com>
|
||||
Josh Hoak <jhoak@google.com>
|
||||
Josh Holland <jrh@joshh.co.uk>
|
||||
Joshua Chase <jcjoshuachase@gmail.com>
|
||||
JP Sugarbroad <jpsugar@google.com>
|
||||
JT Olds <jtolds@xnet5.com>
|
||||
Jukka-Pekka Kekkonen <karatepekka@gmail.com>
|
||||
Julian Phillips <julian@quantumfyre.co.uk>
|
||||
Julien Schmidt <google@julienschmidt.com>
|
||||
Kai Backman <kaib@golang.org>
|
||||
Kamil Kisiel <kamil@kamilkisiel.net> <kamil.kisiel@gmail.com>
|
||||
Katrina Owen <katrina.owen@gmail.com>
|
||||
Kay Zhu <kayzhu@google.com>
|
||||
Kei Son <hey.calmdown@gmail.com>
|
||||
Keith Randall <khr@golang.org>
|
||||
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.rockot@gmail.com>
|
||||
Ken Thompson <ken@golang.org>
|
||||
Kevin Ballard <kevin@sb.org>
|
||||
Kevin Klues <klueska@gmail.com> <klueska@google.com>
|
||||
Kirklin McDonald <kirklin.mcdonald@gmail.com>
|
||||
Kyle Consalus <consalus@gmail.com>
|
||||
Kyle Isom <kyle@gokyle.net>
|
||||
Kyle Lemons <kyle@kylelemons.net> <kevlar@google.com>
|
||||
L Campbell <unpantsu@gmail.com>
|
||||
Lai Jiangshan <eag0628@gmail.com>
|
||||
@@ -378,88 +267,52 @@ Louis Kruger <louisk@google.com>
|
||||
Luca Greco <luca.greco@alcacoop.it>
|
||||
Lucio De Re <lucio.dere@gmail.com>
|
||||
Luit van Drongelen <luitvd@gmail.com>
|
||||
Luka Zakrajšek <tr00.g33k@gmail.com>
|
||||
Luke Curley <qpingu@gmail.com>
|
||||
Luuk van Dijk <lvd@golang.org> <lvd@google.com>
|
||||
Manoj Dayaram <platform-dev@moovweb.com> <manoj.dayaram@moovweb.com>
|
||||
Manu Garg <manugarg@google.com>
|
||||
Manuel Mendez <mmendez534@gmail.com>
|
||||
Marc Weistroff <marc@weistroff.net>
|
||||
Marcel van Lohuizen <mpvl@golang.org>
|
||||
Marco Hennings <marco.hennings@freiheit.com>
|
||||
Mark Theunissen <mark.theunissen@gmail.com>
|
||||
Mark Zavislak <zavislak@google.com>
|
||||
Marko Juhani Silokunnas <marko.silokunnas@gmail.com>
|
||||
Marko Mikulicic <mkm@google.com>
|
||||
Marko Tiikkaja <marko@joh.to>
|
||||
Markus Duft <markus.duft@salomon.at>
|
||||
Markus Sonderegger <marraison@gmail.com>
|
||||
Markus Zimmermann <zimmski@gmail.com>
|
||||
Martin Neubauer <m.ne@gmx.net>
|
||||
Martin Olsson <martin@minimum.se>
|
||||
Mateusz Czapliński <czapkofan@gmail.com>
|
||||
Mathieu Lonjaret <mathieu.lonjaret@gmail.com>
|
||||
Mats Lidell <mats.lidell@cag.se> <mats.lidell@gmail.com>
|
||||
Matt Aimonetti <mattaimonetti@gmail.com>
|
||||
Matt Brown <mdbrown@google.com>
|
||||
Matt Jibson <matt.jibson@gmail.com>
|
||||
Matt Joiner <anacrolix@gmail.com>
|
||||
Matt Jones <mrjones@google.com>
|
||||
Matt Reiferson <mreiferson@gmail.com>
|
||||
Matthew Cottingham <mattcottingham@gmail.com>
|
||||
Matthew Dempsky <mdempsky@google.com>
|
||||
Matthew Horsnell <matthew.horsnell@gmail.com>
|
||||
Maxim Khitrov <max@mxcrypt.com>
|
||||
Maxim Pimenov <mpimenov@google.com>
|
||||
Maxim Ushakov <ushakov@google.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 Gehring <mg@ebfe.org>
|
||||
Michael Hoisie <hoisie@gmail.com>
|
||||
Michael Hudson-Doyle <michael.hudson@linaro.org>
|
||||
Michael Kelly <mjk@google.com>
|
||||
Michael Lewis <mikelikespie@gmail.com>
|
||||
Michael MacInnis <Michael.P.MacInnis@gmail.com>
|
||||
Michael Matloob <matloob@google.com>
|
||||
Michael Pearson <mipearson@gmail.com>
|
||||
Michael Piatek <piatek@google.com>
|
||||
Michael Shields <mshields@google.com>
|
||||
Michael Stapelberg <michael@stapelberg.de> <mstplbrg@googlemail.com>
|
||||
Michael T. Jones <mtj@google.com> <michael.jones@gmail.com>
|
||||
Michael Teichgräber <mteichgraeber@gmx.de> <mt4swm@googlemail.com>
|
||||
Michał Derkacz <ziutek@lnet.pl>
|
||||
Miek Gieben <miek@miek.nl> <remigius.gieben@gmail.com>
|
||||
Mihai Borobocea <MihaiBorobocea@gmail.com>
|
||||
Mikael Tillenius <mikti42@gmail.com>
|
||||
Mike Andrews <mra@xoba.com>
|
||||
Mike Rosset <mike.rosset@gmail.com>
|
||||
Mike Samuel <mikesamuel@gmail.com>
|
||||
Mike Solomon <msolo@gmail.com>
|
||||
Mikhail Panchenko <m@mihasya.com>
|
||||
Miki Tebeka <miki.tebeka@gmail.com>
|
||||
Mikio Hara <mikioh.mikioh@gmail.com>
|
||||
Mikkel Krautz <mikkel@krautz.dk> <krautz@gmail.com>
|
||||
Miquel Sabaté Solà <mikisabate@gmail.com>
|
||||
Moriyoshi Koizumi <mozo@mozo.jp>
|
||||
Môshe van der Sterre <moshevds@gmail.com>
|
||||
Mrunal Patel <mrunalp@gmail.com>
|
||||
Nan Deng <monnand@gmail.com>
|
||||
Nathan John Youngman <nj@nathany.com>
|
||||
Nathan P Finch <nate.finch@gmail.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>
|
||||
Nicolas Kaiser <nikai@nikai.net>
|
||||
Nicolas Owens <mischief@offblast.org>
|
||||
Nigel Kerr <nigel.kerr@gmail.com>
|
||||
Nigel Tao <nigeltao@golang.org>
|
||||
Noah Campbell <noahcampbell@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 Saingre <osaingre@gmail.com>
|
||||
@@ -469,81 +322,57 @@ 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 Riley <pfr@google.com>
|
||||
Patrick Smith <pat42smith@gmail.com>
|
||||
Paul A Querna <paul.querna@gmail.com>
|
||||
Paul Borman <borman@google.com>
|
||||
Paul Chang <paulchang@google.com>
|
||||
Paul Hammond <paul@paulhammond.org>
|
||||
Paul Lalonde <paul.a.lalonde@gmail.com>
|
||||
Paul Nasrat <pnasrat@google.com>
|
||||
Paul Sbarra <Sbarra.Paul@gmail.com>
|
||||
Paul van Brouwershaven <paul@vanbrouwershaven.com>
|
||||
Pavel Zinovkin <pavel.zinovkin@gmail.com>
|
||||
Pawel Szczur <filemon@google.com>
|
||||
Percy Wegmann <ox.to.a.cart@gmail.com>
|
||||
Petar Maymounkov <petarm@gmail.com>
|
||||
Peter Armitage <peter.armitage@gmail.com>
|
||||
Peter Collingbourne <pcc@google.com>
|
||||
Peter Froehlich <peter.hans.froehlich@gmail.com>
|
||||
Peter Kleiweg <pkleiweg@xs4all.nl>
|
||||
Peter McKenzie <petermck@google.com>
|
||||
Peter Mundy <go.peter.90@gmail.com>
|
||||
Péter Surányi <speter.go1@gmail.com>
|
||||
Péter Szabó <pts@google.com>
|
||||
Péter Szilágyi <peterke@gmail.com>
|
||||
Peter Waller <peter.waller@gmail.com>
|
||||
Peter Weinberger <pjw@golang.org>
|
||||
Peter Williams <pwil3058@gmail.com>
|
||||
Phil Pennock <pdp@golang.org>
|
||||
Philip K. Warren <pkwarren@gmail.com>
|
||||
Pieter Droogendijk <pieter@binky.org.uk>
|
||||
Pietro Gagliardi <pietro10@mac.com>
|
||||
Preetam Jinka <pj@preet.am>
|
||||
Quan Yong Zhai <qyzhai@gmail.com>
|
||||
Raif S. Naffah <go@naffah-raif.name>
|
||||
Raph Levien <raph@google.com>
|
||||
Raul Silvera <rsilvera@google.com>
|
||||
Rémy Oudompheng <oudomphe@phare.normalesup.org> <remyoudompheng@gmail.com>
|
||||
Richard Crowley <r@rcrowley.org>
|
||||
Richard Eric Gavaletz <gavaletz@gmail.com>
|
||||
Richard Musiol <mail@richard-musiol.de> <neelance@gmail.com>
|
||||
Rick Arnold <rickarnoldjr@gmail.com>
|
||||
Rick Hudson <rlh@golang.org>
|
||||
Risto Jaakko Saarelma <rsaarelm@gmail.com>
|
||||
Rob Pike <r@golang.org>
|
||||
Robert Daniel Kortschak <dan.kortschak@adelaide.edu.au>
|
||||
Robert Dinu <r@varp.se>
|
||||
Robert Dinu <r@oktett.se>
|
||||
Robert Figueiredo <robfig@gmail.com>
|
||||
Robert Griesemer <gri@golang.org>
|
||||
Robert Hencke <robert.hencke@gmail.com>
|
||||
Robert Obryk <robryk@gmail.com>
|
||||
Robert Sesek <rsesek@google.com>
|
||||
Robert Snedegar <roberts@google.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>
|
||||
Ron Hashimoto <mail@h2so5.net>
|
||||
Ron Minnich <rminnich@gmail.com>
|
||||
Ross Light <rlight2@gmail.com>
|
||||
Rowan Worth <sqweek@gmail.com>
|
||||
Rui Ueyama <ruiu@google.com>
|
||||
Russ Cox <rsc@golang.org>
|
||||
Ryan Barrett <ryanb@google.com>
|
||||
Ryan Hitchman <hitchmanr@gmail.com>
|
||||
Ryan Slade <ryanslade@gmail.com>
|
||||
S.Çağlar Onur <caglar@10ur.org>
|
||||
Sam Thorogood <thorogood@google.com> <sam.thorogood@gmail.com>
|
||||
Sameer Ajmani <sameer@golang.org> <ajmani@gmail.com>
|
||||
Sanjay Menakuru <balasanjay@gmail.com>
|
||||
Scott Ferguson <scottwferg@gmail.com>
|
||||
Scott Lawrence <bytbox@gmail.com>
|
||||
Scott Schwartz <scotts@golang.org>
|
||||
Sean Burford <sburford@google.com>
|
||||
Sebastien Binet <seb.binet@gmail.com>
|
||||
Sébastien Paolacci <sebastien.paolacci@gmail.com>
|
||||
Sergei Skorobogatov <skorobo@rambler.ru>
|
||||
@@ -552,12 +381,9 @@ Sergio Luis O. B. Correia <sergio@correia.cc>
|
||||
Shane Hansen <shanemhansen@gmail.com>
|
||||
Shawn Ledbetter <sledbetter@google.com>
|
||||
Shawn Smith <shawn.p.smith@gmail.com>
|
||||
Shenghou Ma <minux@golang.org> <minux.ma@gmail.com>
|
||||
Shenghou Ma <minux.ma@gmail.com>
|
||||
Shivakumar GN <shivakumar.gn@gmail.com>
|
||||
Simon Whitehead <chemnova@gmail.com>
|
||||
Sokolov Yura <funny.falcon@gmail.com>
|
||||
Spring Mc <heresy.mc@gmail.com>
|
||||
StalkR <stalkr@stalkr.net>
|
||||
Stefan Nilsson <snilsson@nada.kth.se> <trolleriprofessorn@gmail.com>
|
||||
Stéphane Travostino <stephane.travostino@gmail.com>
|
||||
Stephen Ma <stephenm@golang.org>
|
||||
@@ -565,33 +391,21 @@ Stephen McQuay <stephen@mcquay.me>
|
||||
Stephen Weinberg <stephen@q5comm.com>
|
||||
Steve McCoy <mccoyst@gmail.com>
|
||||
Steven Elliot Harris <seharris@gmail.com>
|
||||
Steven Hartland <steven.hartland@multiplay.co.uk>
|
||||
Sugu Sougoumarane <ssougou@gmail.com>
|
||||
Sven Almgren <sven@tras.se>
|
||||
Szabolcs Nagy <nsz@port70.net>
|
||||
Tad Glines <tad.glines@gmail.com>
|
||||
Taj Khattra <taj.khattra@gmail.com>
|
||||
Tarmigan Casebolt <tarmigan@gmail.com>
|
||||
Taru Karttunen <taruti@taruti.net>
|
||||
Tetsuo Kiso <tetsuokiso9@gmail.com>
|
||||
Thiago Fransosi Farina <thiago.farina@gmail.com> <tfarina@chromium.org>
|
||||
Thomas Alan Copeland <talan.copeland@gmail.com>
|
||||
Thomas Habets <habets@google.com>
|
||||
Thomas Kappler <tkappler@gmail.com>
|
||||
Timo Savola <timo.savola@gmail.com>
|
||||
Timo Truyts <alkaloid.btx@gmail.com>
|
||||
Tobias Columbus <tobias.columbus@gmail.com> <tobias.columbus@googlemail.com>
|
||||
Todd Wang <toddwang@gmail.com>
|
||||
Tom Linford <tomlinford@gmail.com>
|
||||
Tom Szymanski <tgs@google.com>
|
||||
Tor Andersson <tor.andersson@gmail.com>
|
||||
Travis Cline <travis.cline@gmail.com>
|
||||
Trevor Strohman <trevor.strohman@gmail.com>
|
||||
Tudor Golubenco <tudor.g@gmail.com>
|
||||
Tw <tw19881113@gmail.com>
|
||||
Tyler Bunnell <tylerbunnell@gmail.com>
|
||||
Ugorji Nwoke <ugorji@gmail.com>
|
||||
Ulf Holm Nielsen <doktor@dyregod.dk>
|
||||
Uriel Mangado <uriel@berlinblue.org>
|
||||
Vadim Vygonets <unixdj@gmail.com>
|
||||
Vega Garcia Luis Alfonso <vegacom@gmail.com>
|
||||
@@ -602,14 +416,10 @@ Vish Subramanian <vish@google.com>
|
||||
Vladimir Nikishenko <vova616@gmail.com>
|
||||
Volker Dobler <dr.volker.dobler@gmail.com>
|
||||
Wei Guangjing <vcc.163@gmail.com>
|
||||
Will Norris <willnorris@google.com>
|
||||
Willem van der Schyff <willemvds@gmail.com>
|
||||
William Chan <willchan@chromium.org>
|
||||
William Josephson <wjosephson@gmail.com>
|
||||
William Orr <will@worrbase.com> <ay1244@gmail.com>
|
||||
Xia Bin <snyh@snyh.org>
|
||||
Xing Xing <mikespook@gmail.com>
|
||||
Yan Zou <yzou@google.com>
|
||||
Yasuhiro Matsumoto <mattn.jp@gmail.com>
|
||||
Yissakhar Z. Beck <yissakhar.beck@gmail.com>
|
||||
Yongjian Xu <i3dmaster@gmail.com>
|
||||
@@ -620,4 +430,3 @@ Yuval Pavel Zholkover <paulzhol@gmail.com>
|
||||
Yves Junqueira <yves.junqueira@gmail.com>
|
||||
Ziad Hatahet <hatahet@gmail.com>
|
||||
Zorion Arrizabalaga <zorionk@gmail.com>
|
||||
申习之 <bronze1man@gmail.com>
|
||||
|
||||
7
README
7
README
@@ -1,12 +1,11 @@
|
||||
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-source.html
|
||||
in your web browser.
|
||||
visit http://golang.org/ or load doc/install.html in your web browser.
|
||||
|
||||
After installing Go, you can view a nicely formatted
|
||||
doc/install-source.html by running godoc --http=:6060
|
||||
and then visiting http://localhost:6060/doc/install/source.
|
||||
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.
|
||||
|
||||
321
api/except.txt
321
api/except.txt
@@ -5,326 +5,5 @@ pkg syscall (darwin-amd64), func Fchflags(string, int) error
|
||||
pkg syscall (darwin-amd64-cgo), func Fchflags(string, int) error
|
||||
pkg syscall (freebsd-386), func Fchflags(string, int) error
|
||||
pkg syscall (freebsd-amd64), func Fchflags(string, int) error
|
||||
pkg syscall (freebsd-arm), func Fchflags(string, int) error
|
||||
pkg syscall (freebsd-arm-cgo), func Fchflags(string, int) error
|
||||
pkg syscall (netbsd-arm), func Fchflags(string, int) error
|
||||
pkg syscall (netbsd-arm-cgo), func Fchflags(string, int) error
|
||||
pkg testing, func RegisterCover(Cover)
|
||||
pkg text/template/parse, type DotNode bool
|
||||
pkg text/template/parse, type Node interface { Copy, String, Type }
|
||||
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-cgo), const ImplementsGetwd = false
|
||||
pkg syscall (darwin-amd64), const ImplementsGetwd = false
|
||||
pkg syscall (darwin-amd64-cgo), const ImplementsGetwd = false
|
||||
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 unicode, const Version = "6.2.0"
|
||||
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-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-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), 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), 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 (netbsd-arm), const SizeofIfData = 132
|
||||
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), type IfMsghdr struct, Pad_cgo_1 [4]uint8
|
||||
pkg unicode, const Version = "6.3.0"
|
||||
|
||||
48654
api/go1.1.txt
48654
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
143
api/go1.txt
143
api/go1.txt
@@ -391,18 +391,6 @@ pkg crypto/dsa, var ErrInvalidPublicKey error
|
||||
pkg crypto/ecdsa, func GenerateKey(elliptic.Curve, io.Reader) (*PrivateKey, error)
|
||||
pkg crypto/ecdsa, func Sign(io.Reader, *PrivateKey, []uint8) (*big.Int, *big.Int, error)
|
||||
pkg crypto/ecdsa, func Verify(*PublicKey, []uint8, *big.Int, *big.Int) bool
|
||||
pkg crypto/ecdsa, method (PrivateKey) Add(*big.Int, *big.Int, *big.Int, *big.Int) (*big.Int, *big.Int)
|
||||
pkg crypto/ecdsa, method (PrivateKey) Double(*big.Int, *big.Int) (*big.Int, *big.Int)
|
||||
pkg crypto/ecdsa, method (PrivateKey) IsOnCurve(*big.Int, *big.Int) bool
|
||||
pkg crypto/ecdsa, method (PrivateKey) Params() *elliptic.CurveParams
|
||||
pkg crypto/ecdsa, method (PrivateKey) ScalarBaseMult([]uint8) (*big.Int, *big.Int)
|
||||
pkg crypto/ecdsa, method (PrivateKey) ScalarMult(*big.Int, *big.Int, []uint8) (*big.Int, *big.Int)
|
||||
pkg crypto/ecdsa, method (PublicKey) Add(*big.Int, *big.Int, *big.Int, *big.Int) (*big.Int, *big.Int)
|
||||
pkg crypto/ecdsa, method (PublicKey) Double(*big.Int, *big.Int) (*big.Int, *big.Int)
|
||||
pkg crypto/ecdsa, method (PublicKey) IsOnCurve(*big.Int, *big.Int) bool
|
||||
pkg crypto/ecdsa, method (PublicKey) Params() *elliptic.CurveParams
|
||||
pkg crypto/ecdsa, method (PublicKey) ScalarBaseMult([]uint8) (*big.Int, *big.Int)
|
||||
pkg crypto/ecdsa, method (PublicKey) ScalarMult(*big.Int, *big.Int, []uint8) (*big.Int, *big.Int)
|
||||
pkg crypto/ecdsa, type PrivateKey struct
|
||||
pkg crypto/ecdsa, type PrivateKey struct, D *big.Int
|
||||
pkg crypto/ecdsa, type PrivateKey struct, embedded PublicKey
|
||||
@@ -1626,7 +1614,6 @@ pkg debug/elf, method (NType) GoString() string
|
||||
pkg debug/elf, method (NType) String() string
|
||||
pkg debug/elf, method (OSABI) GoString() string
|
||||
pkg debug/elf, method (OSABI) String() string
|
||||
pkg debug/elf, method (Prog) ReadAt([]uint8, int64) (int, error)
|
||||
pkg debug/elf, method (ProgFlag) GoString() string
|
||||
pkg debug/elf, method (ProgFlag) String() string
|
||||
pkg debug/elf, method (ProgType) GoString() string
|
||||
@@ -1643,7 +1630,6 @@ pkg debug/elf, method (R_SPARC) GoString() string
|
||||
pkg debug/elf, method (R_SPARC) String() string
|
||||
pkg debug/elf, method (R_X86_64) GoString() string
|
||||
pkg debug/elf, method (R_X86_64) String() string
|
||||
pkg debug/elf, method (Section) ReadAt([]uint8, int64) (int, error)
|
||||
pkg debug/elf, method (SectionFlag) GoString() string
|
||||
pkg debug/elf, method (SectionFlag) String() string
|
||||
pkg debug/elf, method (SectionIndex) GoString() string
|
||||
@@ -1688,7 +1674,7 @@ pkg debug/elf, type Header32 struct
|
||||
pkg debug/elf, type Header32 struct, Ehsize uint16
|
||||
pkg debug/elf, type Header32 struct, Entry uint32
|
||||
pkg debug/elf, type Header32 struct, Flags uint32
|
||||
pkg debug/elf, type Header32 struct, Ident [16]uint8
|
||||
pkg debug/elf, type Header32 struct, Ident [EI_NIDENT]uint8
|
||||
pkg debug/elf, type Header32 struct, Machine uint16
|
||||
pkg debug/elf, type Header32 struct, Phentsize uint16
|
||||
pkg debug/elf, type Header32 struct, Phnum uint16
|
||||
@@ -1703,7 +1689,7 @@ pkg debug/elf, type Header64 struct
|
||||
pkg debug/elf, type Header64 struct, Ehsize uint16
|
||||
pkg debug/elf, type Header64 struct, Entry uint64
|
||||
pkg debug/elf, type Header64 struct, Flags uint32
|
||||
pkg debug/elf, type Header64 struct, Ident [16]uint8
|
||||
pkg debug/elf, type Header64 struct, Ident [EI_NIDENT]uint8
|
||||
pkg debug/elf, type Header64 struct, Machine uint16
|
||||
pkg debug/elf, type Header64 struct, Phentsize uint16
|
||||
pkg debug/elf, type Header64 struct, Phnum uint16
|
||||
@@ -1925,9 +1911,7 @@ pkg debug/macho, method (Dysymtab) Raw() []uint8
|
||||
pkg debug/macho, method (LoadBytes) Raw() []uint8
|
||||
pkg debug/macho, method (LoadCmd) GoString() string
|
||||
pkg debug/macho, method (LoadCmd) String() string
|
||||
pkg debug/macho, method (Section) ReadAt([]uint8, int64) (int, error)
|
||||
pkg debug/macho, method (Segment) Raw() []uint8
|
||||
pkg debug/macho, method (Segment) ReadAt([]uint8, int64) (int, error)
|
||||
pkg debug/macho, method (Symtab) Raw() []uint8
|
||||
pkg debug/macho, type Cpu uint32
|
||||
pkg debug/macho, type Dylib struct
|
||||
@@ -2170,7 +2154,6 @@ pkg debug/pe, method (*File) Section(string) *Section
|
||||
pkg debug/pe, method (*FormatError) Error() string
|
||||
pkg debug/pe, method (*Section) Data() ([]uint8, error)
|
||||
pkg debug/pe, method (*Section) Open() io.ReadSeeker
|
||||
pkg debug/pe, method (Section) ReadAt([]uint8, int64) (int, error)
|
||||
pkg debug/pe, type File struct
|
||||
pkg debug/pe, type File struct, Sections []*Section
|
||||
pkg debug/pe, type File struct, embedded FileHeader
|
||||
@@ -3676,7 +3659,7 @@ pkg image/draw, func Draw(Image, image.Rectangle, image.Image, image.Point, Op)
|
||||
pkg image/draw, func DrawMask(Image, image.Rectangle, image.Image, image.Point, image.Image, image.Point, Op)
|
||||
pkg image/draw, type Image interface { At, Bounds, ColorModel, Set }
|
||||
pkg image/draw, type Image interface, At(int, int) color.Color
|
||||
pkg image/draw, type Image interface, Bounds() image.Rectangle
|
||||
pkg image/draw, type Image interface, Bounds() Rectangle
|
||||
pkg image/draw, type Image interface, ColorModel() color.Model
|
||||
pkg image/draw, type Image interface, Set(int, int, color.Color)
|
||||
pkg image/draw, type Op int
|
||||
@@ -4181,7 +4164,7 @@ pkg math, func Trunc(float64) float64
|
||||
pkg math, func Y0(float64) float64
|
||||
pkg math, func Y1(float64) float64
|
||||
pkg math, func Yn(int, float64) float64
|
||||
pkg math/big, const MaxBase ideal-char
|
||||
pkg math/big, const MaxBase ideal-int
|
||||
pkg math/big, func NewInt(int64) *Int
|
||||
pkg math/big, func NewRat(int64, int64) *Rat
|
||||
pkg math/big, method (*Int) Abs(*Int) *Int
|
||||
@@ -5283,14 +5266,6 @@ pkg os/exec, method (*Cmd) StdoutPipe() (io.ReadCloser, error)
|
||||
pkg os/exec, method (*Cmd) Wait() error
|
||||
pkg os/exec, method (*Error) Error() string
|
||||
pkg os/exec, method (*ExitError) Error() string
|
||||
pkg os/exec, method (ExitError) Exited() bool
|
||||
pkg os/exec, method (ExitError) Pid() int
|
||||
pkg os/exec, method (ExitError) String() string
|
||||
pkg os/exec, method (ExitError) Success() bool
|
||||
pkg os/exec, method (ExitError) Sys() interface{}
|
||||
pkg os/exec, method (ExitError) SysUsage() interface{}
|
||||
pkg os/exec, method (ExitError) SystemTime() time.Duration
|
||||
pkg os/exec, method (ExitError) UserTime() time.Duration
|
||||
pkg os/exec, type Cmd struct
|
||||
pkg os/exec, type Cmd struct, Args []string
|
||||
pkg os/exec, type Cmd struct, Dir string
|
||||
@@ -5712,7 +5687,6 @@ pkg runtime, type MemProfileRecord struct, Stack0 [32]uintptr
|
||||
pkg runtime, type MemStats struct
|
||||
pkg runtime, type MemStats struct, Alloc uint64
|
||||
pkg runtime, type MemStats struct, BuckHashSys uint64
|
||||
pkg runtime, type MemStats struct, BySize [61]struct
|
||||
pkg runtime, type MemStats struct, DebugGC bool
|
||||
pkg runtime, type MemStats struct, EnableGC bool
|
||||
pkg runtime, type MemStats struct, Frees uint64
|
||||
@@ -6061,7 +6035,6 @@ pkg syscall (darwin-386), const EAUTH Errno
|
||||
pkg syscall (darwin-386), const EBADARCH Errno
|
||||
pkg syscall (darwin-386), const EBADEXEC Errno
|
||||
pkg syscall (darwin-386), const EBADMACHO Errno
|
||||
pkg syscall (darwin-386), const EBADMSG Errno
|
||||
pkg syscall (darwin-386), const EBADRPC Errno
|
||||
pkg syscall (darwin-386), const ECHO ideal-int
|
||||
pkg syscall (darwin-386), const ECHOCTL ideal-int
|
||||
@@ -6073,11 +6046,9 @@ pkg syscall (darwin-386), const ECHOPRT ideal-int
|
||||
pkg syscall (darwin-386), const EDEVERR Errno
|
||||
pkg syscall (darwin-386), const EFTYPE Errno
|
||||
pkg syscall (darwin-386), const ELAST Errno
|
||||
pkg syscall (darwin-386), const EMULTIHOP Errno
|
||||
pkg syscall (darwin-386), const ENEEDAUTH Errno
|
||||
pkg syscall (darwin-386), const ENOATTR Errno
|
||||
pkg syscall (darwin-386), const ENODATA Errno
|
||||
pkg syscall (darwin-386), const ENOLINK Errno
|
||||
pkg syscall (darwin-386), const ENOPOLICY Errno
|
||||
pkg syscall (darwin-386), const ENOSR Errno
|
||||
pkg syscall (darwin-386), const ENOSTR Errno
|
||||
@@ -6087,7 +6058,6 @@ pkg syscall (darwin-386), const EPROCLIM Errno
|
||||
pkg syscall (darwin-386), const EPROCUNAVAIL Errno
|
||||
pkg syscall (darwin-386), const EPROGMISMATCH Errno
|
||||
pkg syscall (darwin-386), const EPROGUNAVAIL Errno
|
||||
pkg syscall (darwin-386), const EPROTO Errno
|
||||
pkg syscall (darwin-386), const EPWROFF Errno
|
||||
pkg syscall (darwin-386), const ERPCMISMATCH Errno
|
||||
pkg syscall (darwin-386), const ESHLIBVERS Errno
|
||||
@@ -7883,7 +7853,6 @@ pkg syscall (darwin-386-cgo), const EAUTH Errno
|
||||
pkg syscall (darwin-386-cgo), const EBADARCH Errno
|
||||
pkg syscall (darwin-386-cgo), const EBADEXEC Errno
|
||||
pkg syscall (darwin-386-cgo), const EBADMACHO Errno
|
||||
pkg syscall (darwin-386-cgo), const EBADMSG Errno
|
||||
pkg syscall (darwin-386-cgo), const EBADRPC Errno
|
||||
pkg syscall (darwin-386-cgo), const ECHO ideal-int
|
||||
pkg syscall (darwin-386-cgo), const ECHOCTL ideal-int
|
||||
@@ -7895,11 +7864,9 @@ pkg syscall (darwin-386-cgo), const ECHOPRT ideal-int
|
||||
pkg syscall (darwin-386-cgo), const EDEVERR Errno
|
||||
pkg syscall (darwin-386-cgo), const EFTYPE Errno
|
||||
pkg syscall (darwin-386-cgo), const ELAST Errno
|
||||
pkg syscall (darwin-386-cgo), const EMULTIHOP Errno
|
||||
pkg syscall (darwin-386-cgo), const ENEEDAUTH Errno
|
||||
pkg syscall (darwin-386-cgo), const ENOATTR Errno
|
||||
pkg syscall (darwin-386-cgo), const ENODATA Errno
|
||||
pkg syscall (darwin-386-cgo), const ENOLINK Errno
|
||||
pkg syscall (darwin-386-cgo), const ENOPOLICY Errno
|
||||
pkg syscall (darwin-386-cgo), const ENOSR Errno
|
||||
pkg syscall (darwin-386-cgo), const ENOSTR Errno
|
||||
@@ -7909,7 +7876,6 @@ pkg syscall (darwin-386-cgo), const EPROCLIM Errno
|
||||
pkg syscall (darwin-386-cgo), const EPROCUNAVAIL Errno
|
||||
pkg syscall (darwin-386-cgo), const EPROGMISMATCH Errno
|
||||
pkg syscall (darwin-386-cgo), const EPROGUNAVAIL Errno
|
||||
pkg syscall (darwin-386-cgo), const EPROTO Errno
|
||||
pkg syscall (darwin-386-cgo), const EPWROFF Errno
|
||||
pkg syscall (darwin-386-cgo), const ERPCMISMATCH Errno
|
||||
pkg syscall (darwin-386-cgo), const ESHLIBVERS Errno
|
||||
@@ -9705,7 +9671,6 @@ pkg syscall (darwin-amd64), const EAUTH Errno
|
||||
pkg syscall (darwin-amd64), const EBADARCH Errno
|
||||
pkg syscall (darwin-amd64), const EBADEXEC Errno
|
||||
pkg syscall (darwin-amd64), const EBADMACHO Errno
|
||||
pkg syscall (darwin-amd64), const EBADMSG Errno
|
||||
pkg syscall (darwin-amd64), const EBADRPC Errno
|
||||
pkg syscall (darwin-amd64), const ECHO ideal-int
|
||||
pkg syscall (darwin-amd64), const ECHOCTL ideal-int
|
||||
@@ -9717,11 +9682,9 @@ pkg syscall (darwin-amd64), const ECHOPRT ideal-int
|
||||
pkg syscall (darwin-amd64), const EDEVERR Errno
|
||||
pkg syscall (darwin-amd64), const EFTYPE Errno
|
||||
pkg syscall (darwin-amd64), const ELAST Errno
|
||||
pkg syscall (darwin-amd64), const EMULTIHOP Errno
|
||||
pkg syscall (darwin-amd64), const ENEEDAUTH Errno
|
||||
pkg syscall (darwin-amd64), const ENOATTR Errno
|
||||
pkg syscall (darwin-amd64), const ENODATA Errno
|
||||
pkg syscall (darwin-amd64), const ENOLINK Errno
|
||||
pkg syscall (darwin-amd64), const ENOPOLICY Errno
|
||||
pkg syscall (darwin-amd64), const ENOSR Errno
|
||||
pkg syscall (darwin-amd64), const ENOSTR Errno
|
||||
@@ -9731,7 +9694,6 @@ pkg syscall (darwin-amd64), const EPROCLIM Errno
|
||||
pkg syscall (darwin-amd64), const EPROCUNAVAIL Errno
|
||||
pkg syscall (darwin-amd64), const EPROGMISMATCH Errno
|
||||
pkg syscall (darwin-amd64), const EPROGUNAVAIL Errno
|
||||
pkg syscall (darwin-amd64), const EPROTO Errno
|
||||
pkg syscall (darwin-amd64), const EPWROFF Errno
|
||||
pkg syscall (darwin-amd64), const ERPCMISMATCH Errno
|
||||
pkg syscall (darwin-amd64), const ESHLIBVERS Errno
|
||||
@@ -11534,7 +11496,6 @@ pkg syscall (darwin-amd64-cgo), const EAUTH Errno
|
||||
pkg syscall (darwin-amd64-cgo), const EBADARCH Errno
|
||||
pkg syscall (darwin-amd64-cgo), const EBADEXEC Errno
|
||||
pkg syscall (darwin-amd64-cgo), const EBADMACHO Errno
|
||||
pkg syscall (darwin-amd64-cgo), const EBADMSG Errno
|
||||
pkg syscall (darwin-amd64-cgo), const EBADRPC Errno
|
||||
pkg syscall (darwin-amd64-cgo), const ECHO ideal-int
|
||||
pkg syscall (darwin-amd64-cgo), const ECHOCTL ideal-int
|
||||
@@ -11546,11 +11507,9 @@ pkg syscall (darwin-amd64-cgo), const ECHOPRT ideal-int
|
||||
pkg syscall (darwin-amd64-cgo), const EDEVERR Errno
|
||||
pkg syscall (darwin-amd64-cgo), const EFTYPE Errno
|
||||
pkg syscall (darwin-amd64-cgo), const ELAST Errno
|
||||
pkg syscall (darwin-amd64-cgo), const EMULTIHOP Errno
|
||||
pkg syscall (darwin-amd64-cgo), const ENEEDAUTH Errno
|
||||
pkg syscall (darwin-amd64-cgo), const ENOATTR Errno
|
||||
pkg syscall (darwin-amd64-cgo), const ENODATA Errno
|
||||
pkg syscall (darwin-amd64-cgo), const ENOLINK Errno
|
||||
pkg syscall (darwin-amd64-cgo), const ENOPOLICY Errno
|
||||
pkg syscall (darwin-amd64-cgo), const ENOSR Errno
|
||||
pkg syscall (darwin-amd64-cgo), const ENOSTR Errno
|
||||
@@ -11560,7 +11519,6 @@ pkg syscall (darwin-amd64-cgo), const EPROCLIM Errno
|
||||
pkg syscall (darwin-amd64-cgo), const EPROCUNAVAIL Errno
|
||||
pkg syscall (darwin-amd64-cgo), const EPROGMISMATCH Errno
|
||||
pkg syscall (darwin-amd64-cgo), const EPROGUNAVAIL Errno
|
||||
pkg syscall (darwin-amd64-cgo), const EPROTO Errno
|
||||
pkg syscall (darwin-amd64-cgo), const EPWROFF Errno
|
||||
pkg syscall (darwin-amd64-cgo), const ERPCMISMATCH Errno
|
||||
pkg syscall (darwin-amd64-cgo), const ESHLIBVERS Errno
|
||||
@@ -13525,7 +13483,6 @@ pkg syscall (freebsd-386), const DT_SOCK ideal-int
|
||||
pkg syscall (freebsd-386), const DT_UNKNOWN ideal-int
|
||||
pkg syscall (freebsd-386), const DT_WHT ideal-int
|
||||
pkg syscall (freebsd-386), const EAUTH Errno
|
||||
pkg syscall (freebsd-386), const EBADMSG Errno
|
||||
pkg syscall (freebsd-386), const EBADRPC Errno
|
||||
pkg syscall (freebsd-386), const ECHO ideal-int
|
||||
pkg syscall (freebsd-386), const ECHOCTL ideal-int
|
||||
@@ -13537,16 +13494,13 @@ pkg syscall (freebsd-386), const ECHOPRT ideal-int
|
||||
pkg syscall (freebsd-386), const EDOOFUS Errno
|
||||
pkg syscall (freebsd-386), const EFTYPE Errno
|
||||
pkg syscall (freebsd-386), const ELAST Errno
|
||||
pkg syscall (freebsd-386), const EMULTIHOP Errno
|
||||
pkg syscall (freebsd-386), const ENEEDAUTH Errno
|
||||
pkg syscall (freebsd-386), const ENOATTR Errno
|
||||
pkg syscall (freebsd-386), const ENOLINK Errno
|
||||
pkg syscall (freebsd-386), const ENOTCAPABLE Errno
|
||||
pkg syscall (freebsd-386), const EPROCLIM Errno
|
||||
pkg syscall (freebsd-386), const EPROCUNAVAIL Errno
|
||||
pkg syscall (freebsd-386), const EPROGMISMATCH Errno
|
||||
pkg syscall (freebsd-386), const EPROGUNAVAIL Errno
|
||||
pkg syscall (freebsd-386), const EPROTO Errno
|
||||
pkg syscall (freebsd-386), const ERPCMISMATCH Errno
|
||||
pkg syscall (freebsd-386), const EVFILT_AIO ideal-int
|
||||
pkg syscall (freebsd-386), const EVFILT_FS ideal-int
|
||||
@@ -15501,7 +15455,6 @@ pkg syscall (freebsd-amd64), const DT_SOCK ideal-int
|
||||
pkg syscall (freebsd-amd64), const DT_UNKNOWN ideal-int
|
||||
pkg syscall (freebsd-amd64), const DT_WHT ideal-int
|
||||
pkg syscall (freebsd-amd64), const EAUTH Errno
|
||||
pkg syscall (freebsd-amd64), const EBADMSG Errno
|
||||
pkg syscall (freebsd-amd64), const EBADRPC Errno
|
||||
pkg syscall (freebsd-amd64), const ECHO ideal-int
|
||||
pkg syscall (freebsd-amd64), const ECHOCTL ideal-int
|
||||
@@ -15513,16 +15466,13 @@ pkg syscall (freebsd-amd64), const ECHOPRT ideal-int
|
||||
pkg syscall (freebsd-amd64), const EDOOFUS Errno
|
||||
pkg syscall (freebsd-amd64), const EFTYPE Errno
|
||||
pkg syscall (freebsd-amd64), const ELAST Errno
|
||||
pkg syscall (freebsd-amd64), const EMULTIHOP Errno
|
||||
pkg syscall (freebsd-amd64), const ENEEDAUTH Errno
|
||||
pkg syscall (freebsd-amd64), const ENOATTR Errno
|
||||
pkg syscall (freebsd-amd64), const ENOLINK Errno
|
||||
pkg syscall (freebsd-amd64), const ENOTCAPABLE Errno
|
||||
pkg syscall (freebsd-amd64), const EPROCLIM Errno
|
||||
pkg syscall (freebsd-amd64), const EPROCUNAVAIL Errno
|
||||
pkg syscall (freebsd-amd64), const EPROGMISMATCH Errno
|
||||
pkg syscall (freebsd-amd64), const EPROGUNAVAIL Errno
|
||||
pkg syscall (freebsd-amd64), const EPROTO Errno
|
||||
pkg syscall (freebsd-amd64), const ERPCMISMATCH Errno
|
||||
pkg syscall (freebsd-amd64), const EVFILT_AIO ideal-int
|
||||
pkg syscall (freebsd-amd64), const EVFILT_FS ideal-int
|
||||
@@ -17365,7 +17315,6 @@ pkg syscall (linux-386), const DT_WHT ideal-int
|
||||
pkg syscall (linux-386), const EADV Errno
|
||||
pkg syscall (linux-386), const EBADE Errno
|
||||
pkg syscall (linux-386), const EBADFD Errno
|
||||
pkg syscall (linux-386), const EBADMSG Errno
|
||||
pkg syscall (linux-386), const EBADR Errno
|
||||
pkg syscall (linux-386), const EBADRQC Errno
|
||||
pkg syscall (linux-386), const EBADSLT Errno
|
||||
@@ -17396,13 +17345,11 @@ pkg syscall (linux-386), const ELIBMAX Errno
|
||||
pkg syscall (linux-386), const ELIBSCN Errno
|
||||
pkg syscall (linux-386), const ELNRNG Errno
|
||||
pkg syscall (linux-386), const EMEDIUMTYPE Errno
|
||||
pkg syscall (linux-386), const EMULTIHOP Errno
|
||||
pkg syscall (linux-386), const ENAVAIL Errno
|
||||
pkg syscall (linux-386), const ENOANO Errno
|
||||
pkg syscall (linux-386), const ENOCSI Errno
|
||||
pkg syscall (linux-386), const ENODATA Errno
|
||||
pkg syscall (linux-386), const ENOKEY Errno
|
||||
pkg syscall (linux-386), const ENOLINK Errno
|
||||
pkg syscall (linux-386), const ENOMEDIUM Errno
|
||||
pkg syscall (linux-386), const ENONET Errno
|
||||
pkg syscall (linux-386), const ENOPKG Errno
|
||||
@@ -17430,7 +17377,6 @@ pkg syscall (linux-386), const EPOLL_CTL_ADD ideal-int
|
||||
pkg syscall (linux-386), const EPOLL_CTL_DEL ideal-int
|
||||
pkg syscall (linux-386), const EPOLL_CTL_MOD ideal-int
|
||||
pkg syscall (linux-386), const EPOLL_NONBLOCK ideal-int
|
||||
pkg syscall (linux-386), const EPROTO Errno
|
||||
pkg syscall (linux-386), const EREMCHG Errno
|
||||
pkg syscall (linux-386), const EREMOTEIO Errno
|
||||
pkg syscall (linux-386), const ERESTART Errno
|
||||
@@ -19554,7 +19500,6 @@ pkg syscall (linux-386-cgo), const DT_WHT ideal-int
|
||||
pkg syscall (linux-386-cgo), const EADV Errno
|
||||
pkg syscall (linux-386-cgo), const EBADE Errno
|
||||
pkg syscall (linux-386-cgo), const EBADFD Errno
|
||||
pkg syscall (linux-386-cgo), const EBADMSG Errno
|
||||
pkg syscall (linux-386-cgo), const EBADR Errno
|
||||
pkg syscall (linux-386-cgo), const EBADRQC Errno
|
||||
pkg syscall (linux-386-cgo), const EBADSLT Errno
|
||||
@@ -19585,13 +19530,11 @@ pkg syscall (linux-386-cgo), const ELIBMAX Errno
|
||||
pkg syscall (linux-386-cgo), const ELIBSCN Errno
|
||||
pkg syscall (linux-386-cgo), const ELNRNG Errno
|
||||
pkg syscall (linux-386-cgo), const EMEDIUMTYPE Errno
|
||||
pkg syscall (linux-386-cgo), const EMULTIHOP Errno
|
||||
pkg syscall (linux-386-cgo), const ENAVAIL Errno
|
||||
pkg syscall (linux-386-cgo), const ENOANO Errno
|
||||
pkg syscall (linux-386-cgo), const ENOCSI Errno
|
||||
pkg syscall (linux-386-cgo), const ENODATA Errno
|
||||
pkg syscall (linux-386-cgo), const ENOKEY Errno
|
||||
pkg syscall (linux-386-cgo), const ENOLINK Errno
|
||||
pkg syscall (linux-386-cgo), const ENOMEDIUM Errno
|
||||
pkg syscall (linux-386-cgo), const ENONET Errno
|
||||
pkg syscall (linux-386-cgo), const ENOPKG Errno
|
||||
@@ -19619,7 +19562,6 @@ pkg syscall (linux-386-cgo), const EPOLL_CTL_ADD ideal-int
|
||||
pkg syscall (linux-386-cgo), const EPOLL_CTL_DEL ideal-int
|
||||
pkg syscall (linux-386-cgo), const EPOLL_CTL_MOD ideal-int
|
||||
pkg syscall (linux-386-cgo), const EPOLL_NONBLOCK ideal-int
|
||||
pkg syscall (linux-386-cgo), const EPROTO Errno
|
||||
pkg syscall (linux-386-cgo), const EREMCHG Errno
|
||||
pkg syscall (linux-386-cgo), const EREMOTEIO Errno
|
||||
pkg syscall (linux-386-cgo), const ERESTART Errno
|
||||
@@ -21743,7 +21685,6 @@ pkg syscall (linux-amd64), const DT_WHT ideal-int
|
||||
pkg syscall (linux-amd64), const EADV Errno
|
||||
pkg syscall (linux-amd64), const EBADE Errno
|
||||
pkg syscall (linux-amd64), const EBADFD Errno
|
||||
pkg syscall (linux-amd64), const EBADMSG Errno
|
||||
pkg syscall (linux-amd64), const EBADR Errno
|
||||
pkg syscall (linux-amd64), const EBADRQC Errno
|
||||
pkg syscall (linux-amd64), const EBADSLT Errno
|
||||
@@ -21774,13 +21715,11 @@ pkg syscall (linux-amd64), const ELIBMAX Errno
|
||||
pkg syscall (linux-amd64), const ELIBSCN Errno
|
||||
pkg syscall (linux-amd64), const ELNRNG Errno
|
||||
pkg syscall (linux-amd64), const EMEDIUMTYPE Errno
|
||||
pkg syscall (linux-amd64), const EMULTIHOP Errno
|
||||
pkg syscall (linux-amd64), const ENAVAIL Errno
|
||||
pkg syscall (linux-amd64), const ENOANO Errno
|
||||
pkg syscall (linux-amd64), const ENOCSI Errno
|
||||
pkg syscall (linux-amd64), const ENODATA Errno
|
||||
pkg syscall (linux-amd64), const ENOKEY Errno
|
||||
pkg syscall (linux-amd64), const ENOLINK Errno
|
||||
pkg syscall (linux-amd64), const ENOMEDIUM Errno
|
||||
pkg syscall (linux-amd64), const ENONET Errno
|
||||
pkg syscall (linux-amd64), const ENOPKG Errno
|
||||
@@ -21808,7 +21747,6 @@ pkg syscall (linux-amd64), const EPOLL_CTL_ADD ideal-int
|
||||
pkg syscall (linux-amd64), const EPOLL_CTL_DEL ideal-int
|
||||
pkg syscall (linux-amd64), const EPOLL_CTL_MOD ideal-int
|
||||
pkg syscall (linux-amd64), const EPOLL_NONBLOCK ideal-int
|
||||
pkg syscall (linux-amd64), const EPROTO Errno
|
||||
pkg syscall (linux-amd64), const EREMCHG Errno
|
||||
pkg syscall (linux-amd64), const EREMOTEIO Errno
|
||||
pkg syscall (linux-amd64), const ERESTART Errno
|
||||
@@ -23914,7 +23852,6 @@ pkg syscall (linux-amd64-cgo), const DT_WHT ideal-int
|
||||
pkg syscall (linux-amd64-cgo), const EADV Errno
|
||||
pkg syscall (linux-amd64-cgo), const EBADE Errno
|
||||
pkg syscall (linux-amd64-cgo), const EBADFD Errno
|
||||
pkg syscall (linux-amd64-cgo), const EBADMSG Errno
|
||||
pkg syscall (linux-amd64-cgo), const EBADR Errno
|
||||
pkg syscall (linux-amd64-cgo), const EBADRQC Errno
|
||||
pkg syscall (linux-amd64-cgo), const EBADSLT Errno
|
||||
@@ -23945,13 +23882,11 @@ pkg syscall (linux-amd64-cgo), const ELIBMAX Errno
|
||||
pkg syscall (linux-amd64-cgo), const ELIBSCN Errno
|
||||
pkg syscall (linux-amd64-cgo), const ELNRNG Errno
|
||||
pkg syscall (linux-amd64-cgo), const EMEDIUMTYPE Errno
|
||||
pkg syscall (linux-amd64-cgo), const EMULTIHOP Errno
|
||||
pkg syscall (linux-amd64-cgo), const ENAVAIL Errno
|
||||
pkg syscall (linux-amd64-cgo), const ENOANO Errno
|
||||
pkg syscall (linux-amd64-cgo), const ENOCSI Errno
|
||||
pkg syscall (linux-amd64-cgo), const ENODATA Errno
|
||||
pkg syscall (linux-amd64-cgo), const ENOKEY Errno
|
||||
pkg syscall (linux-amd64-cgo), const ENOLINK Errno
|
||||
pkg syscall (linux-amd64-cgo), const ENOMEDIUM Errno
|
||||
pkg syscall (linux-amd64-cgo), const ENONET Errno
|
||||
pkg syscall (linux-amd64-cgo), const ENOPKG Errno
|
||||
@@ -23979,7 +23914,6 @@ pkg syscall (linux-amd64-cgo), const EPOLL_CTL_ADD ideal-int
|
||||
pkg syscall (linux-amd64-cgo), const EPOLL_CTL_DEL ideal-int
|
||||
pkg syscall (linux-amd64-cgo), const EPOLL_CTL_MOD ideal-int
|
||||
pkg syscall (linux-amd64-cgo), const EPOLL_NONBLOCK ideal-int
|
||||
pkg syscall (linux-amd64-cgo), const EPROTO Errno
|
||||
pkg syscall (linux-amd64-cgo), const EREMCHG Errno
|
||||
pkg syscall (linux-amd64-cgo), const EREMOTEIO Errno
|
||||
pkg syscall (linux-amd64-cgo), const ERESTART Errno
|
||||
@@ -26085,7 +26019,6 @@ pkg syscall (linux-arm), const DT_WHT ideal-int
|
||||
pkg syscall (linux-arm), const EADV Errno
|
||||
pkg syscall (linux-arm), const EBADE Errno
|
||||
pkg syscall (linux-arm), const EBADFD Errno
|
||||
pkg syscall (linux-arm), const EBADMSG Errno
|
||||
pkg syscall (linux-arm), const EBADR Errno
|
||||
pkg syscall (linux-arm), const EBADRQC Errno
|
||||
pkg syscall (linux-arm), const EBADSLT Errno
|
||||
@@ -26119,13 +26052,11 @@ pkg syscall (linux-arm), const ELIBMAX Errno
|
||||
pkg syscall (linux-arm), const ELIBSCN Errno
|
||||
pkg syscall (linux-arm), const ELNRNG Errno
|
||||
pkg syscall (linux-arm), const EMEDIUMTYPE Errno
|
||||
pkg syscall (linux-arm), const EMULTIHOP Errno
|
||||
pkg syscall (linux-arm), const ENAVAIL Errno
|
||||
pkg syscall (linux-arm), const ENOANO Errno
|
||||
pkg syscall (linux-arm), const ENOCSI Errno
|
||||
pkg syscall (linux-arm), const ENODATA Errno
|
||||
pkg syscall (linux-arm), const ENOKEY Errno
|
||||
pkg syscall (linux-arm), const ENOLINK Errno
|
||||
pkg syscall (linux-arm), const ENOMEDIUM Errno
|
||||
pkg syscall (linux-arm), const ENONET Errno
|
||||
pkg syscall (linux-arm), const ENOPKG Errno
|
||||
@@ -26153,7 +26084,6 @@ pkg syscall (linux-arm), const EPOLL_CTL_ADD ideal-int
|
||||
pkg syscall (linux-arm), const EPOLL_CTL_DEL ideal-int
|
||||
pkg syscall (linux-arm), const EPOLL_CTL_MOD ideal-int
|
||||
pkg syscall (linux-arm), const EPOLL_NONBLOCK ideal-int
|
||||
pkg syscall (linux-arm), const EPROTO Errno
|
||||
pkg syscall (linux-arm), const EREMCHG Errno
|
||||
pkg syscall (linux-arm), const EREMOTEIO Errno
|
||||
pkg syscall (linux-arm), const ERESTART Errno
|
||||
@@ -28208,7 +28138,6 @@ pkg syscall (windows-386), const DUPLICATE_SAME_ACCESS ideal-int
|
||||
pkg syscall (windows-386), const EADV Errno
|
||||
pkg syscall (windows-386), const EBADE Errno
|
||||
pkg syscall (windows-386), const EBADFD Errno
|
||||
pkg syscall (windows-386), const EBADMSG Errno
|
||||
pkg syscall (windows-386), const EBADR Errno
|
||||
pkg syscall (windows-386), const EBADRQC Errno
|
||||
pkg syscall (windows-386), const EBADSLT Errno
|
||||
@@ -28232,13 +28161,11 @@ pkg syscall (windows-386), const ELIBMAX Errno
|
||||
pkg syscall (windows-386), const ELIBSCN Errno
|
||||
pkg syscall (windows-386), const ELNRNG Errno
|
||||
pkg syscall (windows-386), const EMEDIUMTYPE Errno
|
||||
pkg syscall (windows-386), const EMULTIHOP Errno
|
||||
pkg syscall (windows-386), const ENAVAIL Errno
|
||||
pkg syscall (windows-386), const ENOANO Errno
|
||||
pkg syscall (windows-386), const ENOCSI Errno
|
||||
pkg syscall (windows-386), const ENODATA Errno
|
||||
pkg syscall (windows-386), const ENOKEY Errno
|
||||
pkg syscall (windows-386), const ENOLINK Errno
|
||||
pkg syscall (windows-386), const ENOMEDIUM Errno
|
||||
pkg syscall (windows-386), const ENONET Errno
|
||||
pkg syscall (windows-386), const ENOPKG Errno
|
||||
@@ -28248,7 +28175,6 @@ pkg syscall (windows-386), const ENOTNAM Errno
|
||||
pkg syscall (windows-386), const ENOTRECOVERABLE Errno
|
||||
pkg syscall (windows-386), const ENOTUNIQ Errno
|
||||
pkg syscall (windows-386), const EOWNERDEAD Errno
|
||||
pkg syscall (windows-386), const EPROTO Errno
|
||||
pkg syscall (windows-386), const EREMCHG Errno
|
||||
pkg syscall (windows-386), const EREMOTEIO Errno
|
||||
pkg syscall (windows-386), const ERESTART Errno
|
||||
@@ -28829,12 +28755,12 @@ pkg syscall (windows-386), type InterfaceInfo struct, BroadcastAddress SockaddrG
|
||||
pkg syscall (windows-386), type InterfaceInfo struct, Flags uint32
|
||||
pkg syscall (windows-386), type InterfaceInfo struct, Netmask SockaddrGen
|
||||
pkg syscall (windows-386), type IpAdapterInfo struct
|
||||
pkg syscall (windows-386), type IpAdapterInfo struct, AdapterName [260]uint8
|
||||
pkg syscall (windows-386), type IpAdapterInfo struct, Address [8]uint8
|
||||
pkg syscall (windows-386), type IpAdapterInfo struct, AdapterName [MAX_ADAPTER_NAME_LENGTH + 4]uint8
|
||||
pkg syscall (windows-386), type IpAdapterInfo struct, Address [MAX_ADAPTER_ADDRESS_LENGTH]uint8
|
||||
pkg syscall (windows-386), type IpAdapterInfo struct, AddressLength uint32
|
||||
pkg syscall (windows-386), type IpAdapterInfo struct, ComboIndex uint32
|
||||
pkg syscall (windows-386), type IpAdapterInfo struct, CurrentIpAddress *IpAddrString
|
||||
pkg syscall (windows-386), type IpAdapterInfo struct, Description [132]uint8
|
||||
pkg syscall (windows-386), type IpAdapterInfo struct, Description [MAX_ADAPTER_DESCRIPTION_LENGTH + 4]uint8
|
||||
pkg syscall (windows-386), type IpAdapterInfo struct, DhcpEnabled uint32
|
||||
pkg syscall (windows-386), type IpAdapterInfo struct, DhcpServer IpAddrString
|
||||
pkg syscall (windows-386), type IpAdapterInfo struct, GatewayList IpAddrString
|
||||
@@ -28854,14 +28780,14 @@ pkg syscall (windows-386), type IpAddrString struct, IpMask IpMaskString
|
||||
pkg syscall (windows-386), type IpAddrString struct, Next *IpAddrString
|
||||
pkg syscall (windows-386), type IpAddressString struct
|
||||
pkg syscall (windows-386), type IpAddressString struct, String [16]uint8
|
||||
pkg syscall (windows-386), type IpMaskString struct
|
||||
pkg syscall (windows-386), type IpMaskString IpAddressString
|
||||
pkg syscall (windows-386), type LazyDLL struct
|
||||
pkg syscall (windows-386), type LazyDLL struct, Name string
|
||||
pkg syscall (windows-386), type LazyProc struct
|
||||
pkg syscall (windows-386), type LazyProc struct, Name string
|
||||
pkg syscall (windows-386), type MibIfRow struct
|
||||
pkg syscall (windows-386), type MibIfRow struct, AdminStatus uint32
|
||||
pkg syscall (windows-386), type MibIfRow struct, Descr [256]uint8
|
||||
pkg syscall (windows-386), type MibIfRow struct, Descr [MAXLEN_IFDESCR]uint8
|
||||
pkg syscall (windows-386), type MibIfRow struct, DescrLen uint32
|
||||
pkg syscall (windows-386), type MibIfRow struct, InDiscards uint32
|
||||
pkg syscall (windows-386), type MibIfRow struct, InErrors uint32
|
||||
@@ -28872,7 +28798,7 @@ pkg syscall (windows-386), type MibIfRow struct, InUnknownProtos uint32
|
||||
pkg syscall (windows-386), type MibIfRow struct, Index uint32
|
||||
pkg syscall (windows-386), type MibIfRow struct, LastChange uint32
|
||||
pkg syscall (windows-386), type MibIfRow struct, Mtu uint32
|
||||
pkg syscall (windows-386), type MibIfRow struct, Name [256]uint16
|
||||
pkg syscall (windows-386), type MibIfRow struct, Name [MAX_INTERFACE_NAME_LEN]uint16
|
||||
pkg syscall (windows-386), type MibIfRow struct, OperStatus uint32
|
||||
pkg syscall (windows-386), type MibIfRow struct, OutDiscards uint32
|
||||
pkg syscall (windows-386), type MibIfRow struct, OutErrors uint32
|
||||
@@ -28880,7 +28806,7 @@ pkg syscall (windows-386), type MibIfRow struct, OutNUcastPkts uint32
|
||||
pkg syscall (windows-386), type MibIfRow struct, OutOctets uint32
|
||||
pkg syscall (windows-386), type MibIfRow struct, OutQLen uint32
|
||||
pkg syscall (windows-386), type MibIfRow struct, OutUcastPkts uint32
|
||||
pkg syscall (windows-386), type MibIfRow struct, PhysAddr [8]uint8
|
||||
pkg syscall (windows-386), type MibIfRow struct, PhysAddr [MAXLEN_PHYSADDR]uint8
|
||||
pkg syscall (windows-386), type MibIfRow struct, PhysAddrLen uint32
|
||||
pkg syscall (windows-386), type MibIfRow struct, Speed uint32
|
||||
pkg syscall (windows-386), type MibIfRow struct, Type uint32
|
||||
@@ -28969,7 +28895,7 @@ pkg syscall (windows-386), type Timezoneinformation struct, DaylightName [32]uin
|
||||
pkg syscall (windows-386), type Timezoneinformation struct, StandardBias int32
|
||||
pkg syscall (windows-386), type Timezoneinformation struct, StandardDate Systemtime
|
||||
pkg syscall (windows-386), type Timezoneinformation struct, StandardName [32]uint16
|
||||
pkg syscall (windows-386), type Token uintptr
|
||||
pkg syscall (windows-386), type Token Handle
|
||||
pkg syscall (windows-386), type Tokenprimarygroup struct
|
||||
pkg syscall (windows-386), type Tokenprimarygroup struct, PrimaryGroup *SID
|
||||
pkg syscall (windows-386), type Tokenuser struct
|
||||
@@ -28988,11 +28914,11 @@ pkg syscall (windows-386), type WSABuf struct
|
||||
pkg syscall (windows-386), type WSABuf struct, Buf *uint8
|
||||
pkg syscall (windows-386), type WSABuf struct, Len uint32
|
||||
pkg syscall (windows-386), type WSAData struct
|
||||
pkg syscall (windows-386), type WSAData struct, Description [257]uint8
|
||||
pkg syscall (windows-386), type WSAData struct, Description [WSADESCRIPTION_LEN + 1]uint8
|
||||
pkg syscall (windows-386), type WSAData struct, HighVersion uint16
|
||||
pkg syscall (windows-386), type WSAData struct, MaxSockets uint16
|
||||
pkg syscall (windows-386), type WSAData struct, MaxUdpDg uint16
|
||||
pkg syscall (windows-386), type WSAData struct, SystemStatus [129]uint8
|
||||
pkg syscall (windows-386), type WSAData struct, SystemStatus [WSASYS_STATUS_LEN + 1]uint8
|
||||
pkg syscall (windows-386), type WSAData struct, VendorInfo *uint8
|
||||
pkg syscall (windows-386), type WSAData struct, Version uint16
|
||||
pkg syscall (windows-386), type WaitStatus struct
|
||||
@@ -29008,7 +28934,7 @@ pkg syscall (windows-386), type Win32finddata struct
|
||||
pkg syscall (windows-386), type Win32finddata struct, AlternateFileName [13]uint16
|
||||
pkg syscall (windows-386), type Win32finddata struct, CreationTime Filetime
|
||||
pkg syscall (windows-386), type Win32finddata struct, FileAttributes uint32
|
||||
pkg syscall (windows-386), type Win32finddata struct, FileName [259]uint16
|
||||
pkg syscall (windows-386), type Win32finddata struct, FileName [MAX_PATH - 1]uint16
|
||||
pkg syscall (windows-386), type Win32finddata struct, FileSizeHigh uint32
|
||||
pkg syscall (windows-386), type Win32finddata struct, FileSizeLow uint32
|
||||
pkg syscall (windows-386), type Win32finddata struct, LastAccessTime Filetime
|
||||
@@ -29137,7 +29063,6 @@ pkg syscall (windows-amd64), const DUPLICATE_SAME_ACCESS ideal-int
|
||||
pkg syscall (windows-amd64), const EADV Errno
|
||||
pkg syscall (windows-amd64), const EBADE Errno
|
||||
pkg syscall (windows-amd64), const EBADFD Errno
|
||||
pkg syscall (windows-amd64), const EBADMSG Errno
|
||||
pkg syscall (windows-amd64), const EBADR Errno
|
||||
pkg syscall (windows-amd64), const EBADRQC Errno
|
||||
pkg syscall (windows-amd64), const EBADSLT Errno
|
||||
@@ -29161,13 +29086,11 @@ pkg syscall (windows-amd64), const ELIBMAX Errno
|
||||
pkg syscall (windows-amd64), const ELIBSCN Errno
|
||||
pkg syscall (windows-amd64), const ELNRNG Errno
|
||||
pkg syscall (windows-amd64), const EMEDIUMTYPE Errno
|
||||
pkg syscall (windows-amd64), const EMULTIHOP Errno
|
||||
pkg syscall (windows-amd64), const ENAVAIL Errno
|
||||
pkg syscall (windows-amd64), const ENOANO Errno
|
||||
pkg syscall (windows-amd64), const ENOCSI Errno
|
||||
pkg syscall (windows-amd64), const ENODATA Errno
|
||||
pkg syscall (windows-amd64), const ENOKEY Errno
|
||||
pkg syscall (windows-amd64), const ENOLINK Errno
|
||||
pkg syscall (windows-amd64), const ENOMEDIUM Errno
|
||||
pkg syscall (windows-amd64), const ENONET Errno
|
||||
pkg syscall (windows-amd64), const ENOPKG Errno
|
||||
@@ -29177,7 +29100,6 @@ pkg syscall (windows-amd64), const ENOTNAM Errno
|
||||
pkg syscall (windows-amd64), const ENOTRECOVERABLE Errno
|
||||
pkg syscall (windows-amd64), const ENOTUNIQ Errno
|
||||
pkg syscall (windows-amd64), const EOWNERDEAD Errno
|
||||
pkg syscall (windows-amd64), const EPROTO Errno
|
||||
pkg syscall (windows-amd64), const EREMCHG Errno
|
||||
pkg syscall (windows-amd64), const EREMOTEIO Errno
|
||||
pkg syscall (windows-amd64), const ERESTART Errno
|
||||
@@ -29758,12 +29680,12 @@ pkg syscall (windows-amd64), type InterfaceInfo struct, BroadcastAddress Sockadd
|
||||
pkg syscall (windows-amd64), type InterfaceInfo struct, Flags uint32
|
||||
pkg syscall (windows-amd64), type InterfaceInfo struct, Netmask SockaddrGen
|
||||
pkg syscall (windows-amd64), type IpAdapterInfo struct
|
||||
pkg syscall (windows-amd64), type IpAdapterInfo struct, AdapterName [260]uint8
|
||||
pkg syscall (windows-amd64), type IpAdapterInfo struct, Address [8]uint8
|
||||
pkg syscall (windows-amd64), type IpAdapterInfo struct, AdapterName [MAX_ADAPTER_NAME_LENGTH + 4]uint8
|
||||
pkg syscall (windows-amd64), type IpAdapterInfo struct, Address [MAX_ADAPTER_ADDRESS_LENGTH]uint8
|
||||
pkg syscall (windows-amd64), type IpAdapterInfo struct, AddressLength uint32
|
||||
pkg syscall (windows-amd64), type IpAdapterInfo struct, ComboIndex uint32
|
||||
pkg syscall (windows-amd64), type IpAdapterInfo struct, CurrentIpAddress *IpAddrString
|
||||
pkg syscall (windows-amd64), type IpAdapterInfo struct, Description [132]uint8
|
||||
pkg syscall (windows-amd64), type IpAdapterInfo struct, Description [MAX_ADAPTER_DESCRIPTION_LENGTH + 4]uint8
|
||||
pkg syscall (windows-amd64), type IpAdapterInfo struct, DhcpEnabled uint32
|
||||
pkg syscall (windows-amd64), type IpAdapterInfo struct, DhcpServer IpAddrString
|
||||
pkg syscall (windows-amd64), type IpAdapterInfo struct, GatewayList IpAddrString
|
||||
@@ -29783,14 +29705,14 @@ pkg syscall (windows-amd64), type IpAddrString struct, IpMask IpMaskString
|
||||
pkg syscall (windows-amd64), type IpAddrString struct, Next *IpAddrString
|
||||
pkg syscall (windows-amd64), type IpAddressString struct
|
||||
pkg syscall (windows-amd64), type IpAddressString struct, String [16]uint8
|
||||
pkg syscall (windows-amd64), type IpMaskString struct
|
||||
pkg syscall (windows-amd64), type IpMaskString IpAddressString
|
||||
pkg syscall (windows-amd64), type LazyDLL struct
|
||||
pkg syscall (windows-amd64), type LazyDLL struct, Name string
|
||||
pkg syscall (windows-amd64), type LazyProc struct
|
||||
pkg syscall (windows-amd64), type LazyProc struct, Name string
|
||||
pkg syscall (windows-amd64), type MibIfRow struct
|
||||
pkg syscall (windows-amd64), type MibIfRow struct, AdminStatus uint32
|
||||
pkg syscall (windows-amd64), type MibIfRow struct, Descr [256]uint8
|
||||
pkg syscall (windows-amd64), type MibIfRow struct, Descr [MAXLEN_IFDESCR]uint8
|
||||
pkg syscall (windows-amd64), type MibIfRow struct, DescrLen uint32
|
||||
pkg syscall (windows-amd64), type MibIfRow struct, InDiscards uint32
|
||||
pkg syscall (windows-amd64), type MibIfRow struct, InErrors uint32
|
||||
@@ -29801,7 +29723,7 @@ pkg syscall (windows-amd64), type MibIfRow struct, InUnknownProtos uint32
|
||||
pkg syscall (windows-amd64), type MibIfRow struct, Index uint32
|
||||
pkg syscall (windows-amd64), type MibIfRow struct, LastChange uint32
|
||||
pkg syscall (windows-amd64), type MibIfRow struct, Mtu uint32
|
||||
pkg syscall (windows-amd64), type MibIfRow struct, Name [256]uint16
|
||||
pkg syscall (windows-amd64), type MibIfRow struct, Name [MAX_INTERFACE_NAME_LEN]uint16
|
||||
pkg syscall (windows-amd64), type MibIfRow struct, OperStatus uint32
|
||||
pkg syscall (windows-amd64), type MibIfRow struct, OutDiscards uint32
|
||||
pkg syscall (windows-amd64), type MibIfRow struct, OutErrors uint32
|
||||
@@ -29809,7 +29731,7 @@ pkg syscall (windows-amd64), type MibIfRow struct, OutNUcastPkts uint32
|
||||
pkg syscall (windows-amd64), type MibIfRow struct, OutOctets uint32
|
||||
pkg syscall (windows-amd64), type MibIfRow struct, OutQLen uint32
|
||||
pkg syscall (windows-amd64), type MibIfRow struct, OutUcastPkts uint32
|
||||
pkg syscall (windows-amd64), type MibIfRow struct, PhysAddr [8]uint8
|
||||
pkg syscall (windows-amd64), type MibIfRow struct, PhysAddr [MAXLEN_PHYSADDR]uint8
|
||||
pkg syscall (windows-amd64), type MibIfRow struct, PhysAddrLen uint32
|
||||
pkg syscall (windows-amd64), type MibIfRow struct, Speed uint32
|
||||
pkg syscall (windows-amd64), type MibIfRow struct, Type uint32
|
||||
@@ -29898,7 +29820,7 @@ pkg syscall (windows-amd64), type Timezoneinformation struct, DaylightName [32]u
|
||||
pkg syscall (windows-amd64), type Timezoneinformation struct, StandardBias int32
|
||||
pkg syscall (windows-amd64), type Timezoneinformation struct, StandardDate Systemtime
|
||||
pkg syscall (windows-amd64), type Timezoneinformation struct, StandardName [32]uint16
|
||||
pkg syscall (windows-amd64), type Token uintptr
|
||||
pkg syscall (windows-amd64), type Token Handle
|
||||
pkg syscall (windows-amd64), type Tokenprimarygroup struct
|
||||
pkg syscall (windows-amd64), type Tokenprimarygroup struct, PrimaryGroup *SID
|
||||
pkg syscall (windows-amd64), type Tokenuser struct
|
||||
@@ -29917,11 +29839,11 @@ pkg syscall (windows-amd64), type WSABuf struct
|
||||
pkg syscall (windows-amd64), type WSABuf struct, Buf *uint8
|
||||
pkg syscall (windows-amd64), type WSABuf struct, Len uint32
|
||||
pkg syscall (windows-amd64), type WSAData struct
|
||||
pkg syscall (windows-amd64), type WSAData struct, Description [257]uint8
|
||||
pkg syscall (windows-amd64), type WSAData struct, Description [WSADESCRIPTION_LEN + 1]uint8
|
||||
pkg syscall (windows-amd64), type WSAData struct, HighVersion uint16
|
||||
pkg syscall (windows-amd64), type WSAData struct, MaxSockets uint16
|
||||
pkg syscall (windows-amd64), type WSAData struct, MaxUdpDg uint16
|
||||
pkg syscall (windows-amd64), type WSAData struct, SystemStatus [129]uint8
|
||||
pkg syscall (windows-amd64), type WSAData struct, SystemStatus [WSASYS_STATUS_LEN + 1]uint8
|
||||
pkg syscall (windows-amd64), type WSAData struct, VendorInfo *uint8
|
||||
pkg syscall (windows-amd64), type WSAData struct, Version uint16
|
||||
pkg syscall (windows-amd64), type WaitStatus struct
|
||||
@@ -29937,7 +29859,7 @@ pkg syscall (windows-amd64), type Win32finddata struct
|
||||
pkg syscall (windows-amd64), type Win32finddata struct, AlternateFileName [13]uint16
|
||||
pkg syscall (windows-amd64), type Win32finddata struct, CreationTime Filetime
|
||||
pkg syscall (windows-amd64), type Win32finddata struct, FileAttributes uint32
|
||||
pkg syscall (windows-amd64), type Win32finddata struct, FileName [259]uint16
|
||||
pkg syscall (windows-amd64), type Win32finddata struct, FileName [MAX_PATH - 1]uint16
|
||||
pkg syscall (windows-amd64), type Win32finddata struct, FileSizeHigh uint32
|
||||
pkg syscall (windows-amd64), type Win32finddata struct, FileSizeLow uint32
|
||||
pkg syscall (windows-amd64), type Win32finddata struct, LastAccessTime Filetime
|
||||
@@ -29962,6 +29884,7 @@ pkg syscall, const EAFNOSUPPORT Errno
|
||||
pkg syscall, const EAGAIN Errno
|
||||
pkg syscall, const EALREADY Errno
|
||||
pkg syscall, const EBADF Errno
|
||||
pkg syscall, const EBADMSG Errno
|
||||
pkg syscall, const EBUSY Errno
|
||||
pkg syscall, const ECANCELED Errno
|
||||
pkg syscall, const ECHILD Errno
|
||||
@@ -29989,6 +29912,7 @@ pkg syscall, const ELOOP Errno
|
||||
pkg syscall, const EMFILE Errno
|
||||
pkg syscall, const EMLINK Errno
|
||||
pkg syscall, const EMSGSIZE Errno
|
||||
pkg syscall, const EMULTIHOP Errno
|
||||
pkg syscall, const ENAMETOOLONG Errno
|
||||
pkg syscall, const ENETDOWN Errno
|
||||
pkg syscall, const ENETRESET Errno
|
||||
@@ -29999,6 +29923,7 @@ pkg syscall, const ENODEV Errno
|
||||
pkg syscall, const ENOENT Errno
|
||||
pkg syscall, const ENOEXEC Errno
|
||||
pkg syscall, const ENOLCK Errno
|
||||
pkg syscall, const ENOLINK Errno
|
||||
pkg syscall, const ENOMEM Errno
|
||||
pkg syscall, const ENOMSG Errno
|
||||
pkg syscall, const ENOPROTOOPT Errno
|
||||
@@ -30017,6 +29942,7 @@ pkg syscall, const EOVERFLOW Errno
|
||||
pkg syscall, const EPERM Errno
|
||||
pkg syscall, const EPFNOSUPPORT Errno
|
||||
pkg syscall, const EPIPE Errno
|
||||
pkg syscall, const EPROTO Errno
|
||||
pkg syscall, const EPROTONOSUPPORT Errno
|
||||
pkg syscall, const EPROTOTYPE Errno
|
||||
pkg syscall, const ERANGE Errno
|
||||
@@ -30055,7 +29981,7 @@ pkg syscall, const IP_MULTICAST_LOOP ideal-int
|
||||
pkg syscall, const IP_MULTICAST_TTL ideal-int
|
||||
pkg syscall, const IP_TOS ideal-int
|
||||
pkg syscall, const IP_TTL ideal-int
|
||||
pkg syscall, const ImplementsGetwd ideal-bool
|
||||
pkg syscall, const ImplementsGetwd bool
|
||||
pkg syscall, const O_APPEND ideal-int
|
||||
pkg syscall, const O_ASYNC ideal-int
|
||||
pkg syscall, const O_CLOEXEC ideal-int
|
||||
@@ -30622,7 +30548,7 @@ pkg unicode, const MaxRune ideal-char
|
||||
pkg unicode, const ReplacementChar ideal-char
|
||||
pkg unicode, const TitleCase ideal-int
|
||||
pkg unicode, const UpperCase ideal-int
|
||||
pkg unicode, const UpperLower ideal-char
|
||||
pkg unicode, const UpperLower ideal-int
|
||||
pkg unicode, const Version ideal-string
|
||||
pkg unicode, func Is(*RangeTable, int32) bool
|
||||
pkg unicode, func IsControl(int32) bool
|
||||
@@ -30869,3 +30795,8 @@ pkg unicode/utf8, func RuneLen(int32) int
|
||||
pkg unicode/utf8, func RuneStart(uint8) bool
|
||||
pkg unicode/utf8, func Valid([]uint8) bool
|
||||
pkg unicode/utf8, func ValidString(string) bool
|
||||
pkg unsafe, func Alignof(ArbitraryType) uintptr
|
||||
pkg unsafe, func Offsetof(ArbitraryType) uintptr
|
||||
pkg unsafe, func Sizeof(ArbitraryType) uintptr
|
||||
pkg unsafe, type ArbitraryType int
|
||||
pkg unsafe, type Pointer *ArbitraryType
|
||||
|
||||
141
api/next.txt
141
api/next.txt
@@ -1,141 +0,0 @@
|
||||
pkg debug/goobj, const SBSS = 21
|
||||
pkg debug/goobj, const SBSS SymKind
|
||||
pkg debug/goobj, const SCONST = 31
|
||||
pkg debug/goobj, const SCONST SymKind
|
||||
pkg debug/goobj, const SDATA = 19
|
||||
pkg debug/goobj, const SDATA SymKind
|
||||
pkg debug/goobj, const SDYNIMPORT = 32
|
||||
pkg debug/goobj, const SDYNIMPORT SymKind
|
||||
pkg debug/goobj, const SELFROSECT = 12
|
||||
pkg debug/goobj, const SELFROSECT SymKind
|
||||
pkg debug/goobj, const SELFRXSECT = 2
|
||||
pkg debug/goobj, const SELFRXSECT SymKind
|
||||
pkg debug/goobj, const SELFSECT = 14
|
||||
pkg debug/goobj, const SELFSECT SymKind
|
||||
pkg debug/goobj, const SFILE = 29
|
||||
pkg debug/goobj, const SFILE SymKind
|
||||
pkg debug/goobj, const SFILEPATH = 30
|
||||
pkg debug/goobj, const SFILEPATH SymKind
|
||||
pkg debug/goobj, const SFUNCTAB = 8
|
||||
pkg debug/goobj, const SFUNCTAB SymKind
|
||||
pkg debug/goobj, const SGOFUNC = 6
|
||||
pkg debug/goobj, const SGOFUNC SymKind
|
||||
pkg debug/goobj, const SGOSTRING = 5
|
||||
pkg debug/goobj, const SGOSTRING SymKind
|
||||
pkg debug/goobj, const SHOSTOBJ = 33
|
||||
pkg debug/goobj, const SHOSTOBJ SymKind
|
||||
pkg debug/goobj, const SINITARR = 18
|
||||
pkg debug/goobj, const SINITARR SymKind
|
||||
pkg debug/goobj, const SMACHO = 15
|
||||
pkg debug/goobj, const SMACHO SymKind
|
||||
pkg debug/goobj, const SMACHOGOT = 16
|
||||
pkg debug/goobj, const SMACHOGOT SymKind
|
||||
pkg debug/goobj, const SMACHOINDIRECTGOT = 28
|
||||
pkg debug/goobj, const SMACHOINDIRECTGOT SymKind
|
||||
pkg debug/goobj, const SMACHOINDIRECTPLT = 27
|
||||
pkg debug/goobj, const SMACHOINDIRECTPLT SymKind
|
||||
pkg debug/goobj, const SMACHOPLT = 13
|
||||
pkg debug/goobj, const SMACHOPLT SymKind
|
||||
pkg debug/goobj, const SMACHOSYMSTR = 25
|
||||
pkg debug/goobj, const SMACHOSYMSTR SymKind
|
||||
pkg debug/goobj, const SMACHOSYMTAB = 26
|
||||
pkg debug/goobj, const SMACHOSYMTAB SymKind
|
||||
pkg debug/goobj, const SNOPTRBSS = 22
|
||||
pkg debug/goobj, const SNOPTRBSS SymKind
|
||||
pkg debug/goobj, const SNOPTRDATA = 17
|
||||
pkg debug/goobj, const SNOPTRDATA SymKind
|
||||
pkg debug/goobj, const SPCLNTAB = 11
|
||||
pkg debug/goobj, const SPCLNTAB SymKind
|
||||
pkg debug/goobj, const SRODATA = 7
|
||||
pkg debug/goobj, const SRODATA SymKind
|
||||
pkg debug/goobj, const SSTRING = 4
|
||||
pkg debug/goobj, const SSTRING SymKind
|
||||
pkg debug/goobj, const SSYMTAB = 10
|
||||
pkg debug/goobj, const SSYMTAB SymKind
|
||||
pkg debug/goobj, const STEXT = 1
|
||||
pkg debug/goobj, const STEXT SymKind
|
||||
pkg debug/goobj, const STLSBSS = 23
|
||||
pkg debug/goobj, const STLSBSS SymKind
|
||||
pkg debug/goobj, const STYPE = 3
|
||||
pkg debug/goobj, const STYPE SymKind
|
||||
pkg debug/goobj, const STYPELINK = 9
|
||||
pkg debug/goobj, const STYPELINK SymKind
|
||||
pkg debug/goobj, const SWINDOWS = 20
|
||||
pkg debug/goobj, const SWINDOWS SymKind
|
||||
pkg debug/goobj, const SXREF = 24
|
||||
pkg debug/goobj, const SXREF SymKind
|
||||
pkg debug/goobj, func Parse(io.ReadSeeker, string) (*Package, error)
|
||||
pkg debug/goobj, method (Sym) String() string
|
||||
pkg debug/goobj, method (SymID) String() string
|
||||
pkg debug/goobj, method (SymKind) String() string
|
||||
pkg debug/goobj, type Data struct
|
||||
pkg debug/goobj, type Data struct, Offset int64
|
||||
pkg debug/goobj, type Data struct, Size int64
|
||||
pkg debug/goobj, type Func struct
|
||||
pkg debug/goobj, type Func struct, Args int
|
||||
pkg debug/goobj, type Func struct, File []string
|
||||
pkg debug/goobj, type Func struct, Frame int
|
||||
pkg debug/goobj, type Func struct, FuncData []FuncData
|
||||
pkg debug/goobj, type Func struct, Leaf bool
|
||||
pkg debug/goobj, type Func struct, NoSplit bool
|
||||
pkg debug/goobj, type Func struct, PCData []Data
|
||||
pkg debug/goobj, type Func struct, PCFile Data
|
||||
pkg debug/goobj, type Func struct, PCLine Data
|
||||
pkg debug/goobj, type Func struct, PCSP Data
|
||||
pkg debug/goobj, type Func struct, Var []Var
|
||||
pkg debug/goobj, type FuncData struct
|
||||
pkg debug/goobj, type FuncData struct, Offset int64
|
||||
pkg debug/goobj, type FuncData struct, Sym SymID
|
||||
pkg debug/goobj, type Package struct
|
||||
pkg debug/goobj, type Package struct, ImportPath string
|
||||
pkg debug/goobj, type Package struct, Imports []string
|
||||
pkg debug/goobj, type Package struct, MaxVersion int
|
||||
pkg debug/goobj, type Package struct, Syms []*Sym
|
||||
pkg debug/goobj, type Reloc struct
|
||||
pkg debug/goobj, type Reloc struct, Add int
|
||||
pkg debug/goobj, type Reloc struct, Offset int
|
||||
pkg debug/goobj, type Reloc struct, Size int
|
||||
pkg debug/goobj, type Reloc struct, Sym SymID
|
||||
pkg debug/goobj, type Reloc struct, Type int
|
||||
pkg debug/goobj, type Sym struct
|
||||
pkg debug/goobj, type Sym struct, Data Data
|
||||
pkg debug/goobj, type Sym struct, DupOK bool
|
||||
pkg debug/goobj, type Sym struct, Func *Func
|
||||
pkg debug/goobj, type Sym struct, Kind SymKind
|
||||
pkg debug/goobj, type Sym struct, Reloc []Reloc
|
||||
pkg debug/goobj, type Sym struct, Size int
|
||||
pkg debug/goobj, type Sym struct, Type SymID
|
||||
pkg debug/goobj, type Sym struct, embedded SymID
|
||||
pkg debug/goobj, type SymID struct
|
||||
pkg debug/goobj, type SymID struct, Name string
|
||||
pkg debug/goobj, type SymID struct, Version int
|
||||
pkg debug/goobj, type SymKind int
|
||||
pkg debug/goobj, type Var struct
|
||||
pkg debug/goobj, type Var struct, Kind int
|
||||
pkg debug/goobj, type Var struct, Name string
|
||||
pkg debug/goobj, type Var struct, Offset int
|
||||
pkg debug/goobj, type Var struct, Type SymID
|
||||
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
|
||||
|
||||
32
doc/Makefile
Normal file
32
doc/Makefile
Normal file
@@ -0,0 +1,32 @@
|
||||
# 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)
|
||||
|
||||
compare:
|
||||
for i in $(RAWHTML); do \
|
||||
godoc -url /doc/$${i/.rawhtml/.html} | diff -u $$i -; \
|
||||
done
|
||||
179
doc/articles/c_go_cgo.html
Normal file
179
doc/articles/c_go_cgo.html
Normal file
@@ -0,0 +1,179 @@
|
||||
<!--{
|
||||
"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/#hdr-Compile_packages_and_dependencies">"
|
||||
<code>go build</code>"</a> or
|
||||
<a href="/cmd/go/#hdr-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 <a href="http://code.google.com/p/go-wiki/wiki/Projects">Go Community Wiki</a>
|
||||
lists many packages, some of which use cgo.
|
||||
</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
|
||||
<code>ch</code> 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 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://golang.org/s/camjsondecode">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>
|
||||
@@ -99,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>
|
||||
|
||||
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>
|
||||
147
doc/articles/godoc_documenting_go_code.html
Normal file
147
doc/articles/godoc_documenting_go_code.html
Normal file
@@ -0,0 +1,147 @@
|
||||
<!--{
|
||||
"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/"><code>gob</code></a>
|
||||
package'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/sync/atomic/#pkg-note-BUG"><code>sync/atomic</code></a> package:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
// BUG(rsc): On x86-32, the 64-bit functions use instructions
|
||||
// unavailable before the Pentium MMX. On both ARM and x86-32, it is the
|
||||
// caller's responsibility to arrange for 64-bit alignment of 64-bit
|
||||
// words accessed atomically.
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Godoc treats executable commands in the same way. It looks for a comment on
|
||||
package main, which is sometimes put in a separate file called <code>doc.go</code>.
|
||||
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>
|
||||
|
||||
<p>
|
||||
Godoc recognizes example functions written according to the
|
||||
<a href="/pkg/testing/#pkg-overview"><code>testing</code></a> package's naming
|
||||
conventions and presents them appropriately.
|
||||
</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>Uniform</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.Uniform</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 analogous 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; x < 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, analogous 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>
|
||||
|
||||
357
doc/articles/json_and_go.html
Normal file
357
doc/articles/json_and_go.html
Normal file
@@ -0,0 +1,357 @@
|
||||
<!--{
|
||||
"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 <code>m</code> 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 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>`json:"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 <code>Name</code> field of m will be
|
||||
populated, and the <code>Food</code> 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 <code>interface{}</code></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/`}}
|
||||
|
||||
<p>
|
||||
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:
|
||||
</p>
|
||||
|
||||
<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/#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>
|
||||
@@ -57,35 +57,35 @@ Here is an example:
|
||||
WARNING: DATA RACE
|
||||
Read by goroutine 185:
|
||||
net.(*pollServer).AddFD()
|
||||
src/net/fd_unix.go:89 +0x398
|
||||
src/pkg/net/fd_unix.go:89 +0x398
|
||||
net.(*pollServer).WaitWrite()
|
||||
src/net/fd_unix.go:247 +0x45
|
||||
src/pkg/net/fd_unix.go:247 +0x45
|
||||
net.(*netFD).Write()
|
||||
src/net/fd_unix.go:540 +0x4d4
|
||||
src/pkg/net/fd_unix.go:540 +0x4d4
|
||||
net.(*conn).Write()
|
||||
src/net/net.go:129 +0x101
|
||||
src/pkg/net/net.go:129 +0x101
|
||||
net.func·060()
|
||||
src/net/timeout_test.go:603 +0xaf
|
||||
src/pkg/net/timeout_test.go:603 +0xaf
|
||||
|
||||
Previous write by goroutine 184:
|
||||
net.setWriteDeadline()
|
||||
src/net/sockopt_posix.go:135 +0xdf
|
||||
src/pkg/net/sockopt_posix.go:135 +0xdf
|
||||
net.setDeadline()
|
||||
src/net/sockopt_posix.go:144 +0x9c
|
||||
src/pkg/net/sockopt_posix.go:144 +0x9c
|
||||
net.(*conn).SetDeadline()
|
||||
src/net/net.go:161 +0xe3
|
||||
src/pkg/net/net.go:161 +0xe3
|
||||
net.func·061()
|
||||
src/net/timeout_test.go:616 +0x3ed
|
||||
src/pkg/net/timeout_test.go:616 +0x3ed
|
||||
|
||||
Goroutine 185 (running) created at:
|
||||
net.func·061()
|
||||
src/net/timeout_test.go:609 +0x288
|
||||
src/pkg/net/timeout_test.go:609 +0x288
|
||||
|
||||
Goroutine 184 (running) created at:
|
||||
net.TestProlongTimeout()
|
||||
src/net/timeout_test.go:618 +0x298
|
||||
src/pkg/net/timeout_test.go:618 +0x298
|
||||
testing.tRunner()
|
||||
src/testing/testing.go:301 +0xe8
|
||||
src/pkg/testing/testing.go:301 +0xe8
|
||||
</pre>
|
||||
|
||||
<h2 id="Options">Options</h2>
|
||||
@@ -128,11 +128,6 @@ 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>
|
||||
@@ -377,8 +372,7 @@ func (w *Watchdog) Start() {
|
||||
<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>.
|
||||
The race detector runs on <code>darwin/amd64</code>, <code>linux/amd64</code>, and <code>windows/amd64</code>.
|
||||
</p>
|
||||
|
||||
<h2 id="Runtime_Overheads">Runtime Overhead</h2>
|
||||
|
||||
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)
|
||||
@@ -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()
|
||||
|
||||
@@ -5,19 +5,12 @@
|
||||
package main
|
||||
|
||||
import (
|
||||
"flag"
|
||||
"html/template"
|
||||
"io/ioutil"
|
||||
"log"
|
||||
"net"
|
||||
"net/http"
|
||||
"regexp"
|
||||
)
|
||||
|
||||
var (
|
||||
addr = flag.Bool("addr", false, "find open address and print to final-port.txt")
|
||||
)
|
||||
|
||||
type Page struct {
|
||||
Title string
|
||||
Body []byte
|
||||
@@ -74,38 +67,24 @@ 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)
|
||||
}
|
||||
}
|
||||
|
||||
func main() {
|
||||
flag.Parse()
|
||||
http.HandleFunc("/view/", makeHandler(viewHandler))
|
||||
http.HandleFunc("/edit/", makeHandler(editHandler))
|
||||
http.HandleFunc("/save/", makeHandler(saveHandler))
|
||||
|
||||
if *addr {
|
||||
l, err := net.Listen("tcp", "127.0.0.1:0")
|
||||
if err != nil {
|
||||
log.Fatal(err)
|
||||
}
|
||||
err = ioutil.WriteFile("final-port.txt", []byte(l.Addr().String()), 0644)
|
||||
if err != nil {
|
||||
log.Fatal(err)
|
||||
}
|
||||
s := &http.Server{}
|
||||
s.Serve(l)
|
||||
return
|
||||
}
|
||||
|
||||
http.ListenAndServe(":8080", nil)
|
||||
}
|
||||
|
||||
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)
|
||||
}
|
||||
@@ -128,10 +128,11 @@ In addition to saving pages, we will want to load pages, too:
|
||||
{{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
|
||||
the title parameter, reads the file's contents into a new
|
||||
variable <code>body</code>, and returns two values: a pointer to a
|
||||
<code>Page</code> literal constructed with the proper title and body
|
||||
values and <code>nil</code> for the error value.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@@ -260,15 +261,18 @@ Let's create a handler, <code>viewHandler</code> that will allow users to
|
||||
view a wiki page. It will handle URLs prefixed with "/view/".
|
||||
</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's title.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@@ -428,11 +432,6 @@ to its own function:
|
||||
</p>
|
||||
|
||||
{{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/` `/^}/`}}
|
||||
|
||||
@@ -466,7 +465,7 @@ header to the HTTP response.
|
||||
<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:
|
||||
<code>main</code>, let's implement the the handler:
|
||||
</p>
|
||||
|
||||
{{code "doc/articles/wiki/final-template.go" `/^func saveHandler/` `/^}/`}}
|
||||
@@ -575,11 +574,10 @@ 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
|
||||
@@ -590,8 +588,9 @@ 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, <code>getTitle</code>, 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/` `/^}/`}}
|
||||
@@ -618,7 +617,7 @@ Let's put a call to <code>getTitle</code> in each of the handlers:
|
||||
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
|
||||
<a href="/ref/spec#Function_declarations">function
|
||||
literals</a> provide a powerful means of abstracting functionality
|
||||
that can help us here.
|
||||
</p>
|
||||
|
||||
@@ -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)
|
||||
}
|
||||
|
||||
@@ -29,13 +29,15 @@ func loadPage(title string) (*Page, error) {
|
||||
return &Page{Title: title, Body: body}, nil
|
||||
}
|
||||
|
||||
const lenPath = len("/view/")
|
||||
|
||||
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/"):]
|
||||
title := r.URL.Path[lenPath:]
|
||||
p, err := loadPage(title)
|
||||
if err != nil {
|
||||
http.Redirect(w, r, "/edit/"+title, http.StatusFound)
|
||||
@@ -45,7 +47,7 @@ func viewHandler(w http.ResponseWriter, r *http.Request) {
|
||||
}
|
||||
|
||||
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}
|
||||
@@ -54,7 +56,7 @@ func editHandler(w http.ResponseWriter, r *http.Request) {
|
||||
}
|
||||
|
||||
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)}
|
||||
err := p.save()
|
||||
|
||||
@@ -29,19 +29,21 @@ func loadPage(title string) (*Page, error) {
|
||||
return &Page{Title: title, Body: body}, nil
|
||||
}
|
||||
|
||||
const lenPath = len("/view/")
|
||||
|
||||
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/"):]
|
||||
title := r.URL.Path[lenPath:]
|
||||
p, _ := loadPage(title)
|
||||
renderTemplate(w, "view", p)
|
||||
}
|
||||
|
||||
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}
|
||||
|
||||
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)
|
||||
}
|
||||
}
|
||||
@@ -7,39 +7,18 @@ set -e
|
||||
wiki_pid=
|
||||
cleanup() {
|
||||
kill $wiki_pid
|
||||
rm -f test_*.out Test.txt final.bin final-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.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
|
||||
go build -o final.bin final.go
|
||||
(./final.bin --addr) &
|
||||
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) &
|
||||
wiki_pid=$!
|
||||
|
||||
l=0
|
||||
while [ ! -f ./final-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
|
||||
|
||||
addr=$(cat final-port.txt)
|
||||
./get.bin http://$addr/edit/Test > test_edit.out
|
||||
./get.bin --wait_for_port=5s 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
|
||||
|
||||
537
doc/asm.html
537
doc/asm.html
@@ -1,537 +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>
|
||||
suite of Go compilers (<code>6g</code>, <code>8g</code>, etc.).
|
||||
The document is not comprehensive.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The assembler is based on the input to the Plan 9 assemblers, which is documented in detail
|
||||
<a href="http://plan9.bell-labs.com/sys/doc/asm.html">on the Plan 9 site</a>.
|
||||
If you plan to write assembly language, you should read that document although much of it is Plan 9-specific.
|
||||
This document provides a summary of the syntax 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="http://plan9.bell-labs.com/sys/doc/compiler.html">this description</a>)
|
||||
needs no assembler pass in the usual pipeline.
|
||||
Instead, the compiler emits a kind of incompletely defined instruction set, in binary form, which the linker
|
||||
then completes.
|
||||
In particular, the linker does instruction selection, so when you see an instruction like <code>MOV</code>
|
||||
what the linker 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 generate that intermediate, incompletely defined instruction sequence
|
||||
as input for 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:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ cat x.go
|
||||
package main
|
||||
|
||||
func main() {
|
||||
println(3)
|
||||
}
|
||||
$ go tool 6g -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="symbols">Symbols</h3>
|
||||
|
||||
<p>
|
||||
Some symbols, such as <code>PC</code>, <code>R0</code> and <code>SP</code>, are predeclared and refer to registers.
|
||||
There are two other predeclared symbols, <code>SB</code> (static base) and <code>FP</code> (frame pointer).
|
||||
All user-defined symbols other than jump labels are written as offsets to these pseudo-registers.
|
||||
</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 <code>foo<>(SB)</code>, makes the name
|
||||
visible only in the current source file, like a top-level <code>static</code> declaration in a C file.
|
||||
</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.
|
||||
When referring to a function argument this way, it is conventional to place the name
|
||||
at the beginning, as in <code>first_arg+0(FP)</code> and <code>second_arg+8(FP)</code>.
|
||||
Some of the assemblers enforce this convention, rejecting plain <code>0(FP)</code> and <code>8(FP)</code>.
|
||||
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.
|
||||
On architectures with a real 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>
|
||||
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>
|
||||
</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.
|
||||
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>
|
||||
|
||||
<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 32-bit Intel x86,
|
||||
look in the top-level header file for the corresponding linker, in this case <code>8l</code>.
|
||||
That is, the file <code>$GOROOT/src/cmd/8l/8.out.h</code> contains a C enumeration, called <code>as</code>,
|
||||
of the instructions and their spellings as known to the assembler and linker for that architecture.
|
||||
In that file you'll find a declaration that begins
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
enum as
|
||||
{
|
||||
AXXX,
|
||||
AAAA,
|
||||
AAAD,
|
||||
AAAM,
|
||||
AAAS,
|
||||
AADCB,
|
||||
...
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Each instruction begins with a initial capital <code>A</code> in this list, so <code>AADCB</code>
|
||||
represents the <code>ADCB</code> (add carry byte) instruction.
|
||||
The enumeration is in alphabetical order, plus some late additions (<code>AXXX</code> occupies
|
||||
the zero slot as an invalid instruction).
|
||||
The sequence has nothing to do with the actual encoding of the machine instructions.
|
||||
Again, the linker takes care of that detail.
|
||||
</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 convention applies even on architectures where the usual mode is the opposite direction.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Here follows 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
|
||||
an architecture-dependent header file, like this:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
#include "zasm_GOOS_GOARCH.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>
|
||||
|
||||
<h3 id="amd64">64-bit Intel 386 (a.k.a. amd64)</h3>
|
||||
|
||||
<p>
|
||||
The assembly code to access the <code>m</code> and <code>g</code>
|
||||
pointers is the same as on the 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>
|
||||
|
||||
<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-8
|
||||
MOVL ptr+0(FP), AX
|
||||
LEAL ret_lo+4(FP), BX
|
||||
BYTE $0x0f; BYTE $0x6f; BYTE $0x00 // MOVQ (%EAX), %MM0
|
||||
BYTE $0x0f; BYTE $0x7f; BYTE $0x03 // MOVQ %MM0, 0(%EBX)
|
||||
BYTE $0x0F; BYTE $0x77 // EMMS
|
||||
RET
|
||||
</pre>
|
||||
28
doc/cmd.html
28
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/code.google.com/p/go.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>
|
||||
@@ -83,13 +83,7 @@ gofmt</a> command with more general options.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><a href="//godoc.org/code.google.com/p/go.tools/cmd/godoc/">godoc</a></td>
|
||||
<td> </td>
|
||||
<td>Godoc extracts and generates documentation for Go packages.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><a href="//godoc.org/code.google.com/p/go.tools/cmd/vet/">vet</a></td>
|
||||
<td><a href="/cmd/vet/">vet</a></td>
|
||||
<td> </td>
|
||||
<td>Vet examines Go source code and reports suspicious constructs, such as Printf
|
||||
calls whose arguments do not align with the format string.</td>
|
||||
|
||||
@@ -18,7 +18,7 @@ It explains the simplest way to get up and running with your Go installation.
|
||||
|
||||
<p>
|
||||
A similar explanation is available as a
|
||||
<a href="//www.youtube.com/watch?v=XCsL89YtqCs">screencast</a>.
|
||||
<a href="http://www.youtube.com/watch?v=XCsL89YtqCs">screencast</a>.
|
||||
</p>
|
||||
|
||||
|
||||
@@ -295,9 +295,9 @@ package newmath
|
||||
|
||||
// Sqrt returns an approximation to the square root of x.
|
||||
func Sqrt(x float64) float64 {
|
||||
z := 1.0
|
||||
for i := 0; i < 1000; i++ {
|
||||
z -= (z*z - x) / (2 * z)
|
||||
z := 0.0
|
||||
for i := 0; i < 1000; i++ {
|
||||
z -= (z*z - x) / (2 * x)
|
||||
}
|
||||
return z
|
||||
}
|
||||
@@ -508,7 +508,7 @@ revision control system such as Git or Mercurial. The <code>go</code> tool uses
|
||||
this property to automatically fetch packages from remote repositories.
|
||||
For instance, the examples described in this document are also kept in a
|
||||
Mercurial repository hosted at Google Code,
|
||||
<code><a href="//code.google.com/p/go.example">code.google.com/p/go.example</a></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>
|
||||
@@ -569,24 +569,18 @@ import "code.google.com/p/go.example/newmath"
|
||||
<p>
|
||||
This convention is the easiest way to make your Go packages available for
|
||||
others to use.
|
||||
The <a href="//code.google.com/p/go-wiki/wiki/Projects">Go Wiki</a>
|
||||
and <a href="//godoc.org/">godoc.org</a>
|
||||
The <a href="http://code.google.com/p/go-wiki/wiki/Projects">Go Wiki</a>
|
||||
and <a href="http://godoc.org/">godoc.org</a>
|
||||
provide lists of external Go projects.
|
||||
</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>.
|
||||
<code><a href="/cmd/go/#hdr-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
|
||||
@@ -594,7 +588,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>
|
||||
|
||||
@@ -602,21 +596,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="//code.google.com/p/go/issues/list">Go issue tracker</a>.
|
||||
</p>
|
||||
|
||||
@@ -296,7 +296,7 @@ CodewalkViewer.prototype.updateHeight = function() {
|
||||
this.sizer.height(codeHeight);
|
||||
};
|
||||
|
||||
window.initFuncs.push(function() {
|
||||
jQuery(document).ready(function() {
|
||||
var viewer = new CodewalkViewer(jQuery('#codewalk-main'));
|
||||
viewer.selectFirstComment();
|
||||
viewer.targetCommentLinksAtBlank();
|
||||
|
||||
@@ -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,
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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,77 +17,46 @@ 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 summary of the changes between Go releases.</p>
|
||||
|
||||
<h4 id="go1notes"><a href="/doc/go1">Go 1 Release Notes</a></h4>
|
||||
<p>
|
||||
A guide for updating your code to work with Go 1.
|
||||
</p>
|
||||
|
||||
<h4 id="release notes"><a href="/doc/go1.1">Go 1.1 Release Notes</a></h4>
|
||||
<p>
|
||||
A list of significant changes in Go 1.1, with instructions for updating
|
||||
your code where necessary.
|
||||
Each point release includes a similar document appropriate for that
|
||||
release: <a href="/doc/go1.2">Go 1.2</a>, <a href="/doc/go1.3">Go 1.3</a>,
|
||||
and so on.
|
||||
</p>
|
||||
|
||||
<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://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="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="golang-bugs"><a href="https://groups.google.com/group/golang-bugs">Bugs Mailing List</a></h3>
|
||||
<p>A mailing list that receives each update to the Go <a href="//golang.org/issue">issue tracker</a>.</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="https://code.google.com/p/go/issues">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="https://code.google.com/p/go/issues/entry">filing a ticket</a>
|
||||
on our <a href="https://code.google.com/p/go/issues">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>
|
||||
@@ -106,8 +75,34 @@ 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="https://code.google.com/p/go/issues">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://code.google.com/p/go/issues/list?q=status=HelpWanted">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://code.google.com/p/go-wiki/wiki/Projects">Go Wiki Projects Page</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="pluscom"><a href="https://plus.google.com/communities/114112804251407510571">The Go+ community</a></h3>
|
||||
<p>The Google+ community for Go enthusiasts.</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>
|
||||
|
||||
@@ -22,7 +22,7 @@ you're working on if you want it to become part of the main repository.
|
||||
|
||||
<p>
|
||||
Before undertaking to write something new for the Go project, send
|
||||
mail to the <a href="https://groups.google.com/group/golang-nuts">mailing
|
||||
mail to the <a href="http://groups.google.com/group/golang-nuts">mailing
|
||||
list</a> to discuss what you plan to do. This gives everyone a
|
||||
chance to validate the design, helps prevent duplication of effort,
|
||||
and ensures that the idea fits inside the goals for the language
|
||||
@@ -45,14 +45,10 @@ tree to make sure the changes don't break other packages or programs:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ cd go/src
|
||||
$ ./all.bash
|
||||
cd $GOROOT/src
|
||||
./all.bash # On Windows, run all.bat
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
(To build under Windows use <code>all.bat</code>.)
|
||||
</p>
|
||||
|
||||
<p>
|
||||
After running for a while, the command should print "<code>ALL TESTS PASSED</code>".
|
||||
</p>
|
||||
@@ -99,11 +95,11 @@ command.
|
||||
|
||||
<h3>Configure the extension</h3>
|
||||
|
||||
<p>Edit <code>.hg/hgrc</code> in the root of your Go checkout to add:</p>
|
||||
<p>Edit <code>$GOROOT/.hg/hgrc</code> to add:</p>
|
||||
|
||||
<pre>
|
||||
[extensions]
|
||||
codereview = /path/to/go/lib/codereview/codereview.py
|
||||
codereview = $GOROOT/lib/codereview/codereview.py
|
||||
|
||||
[ui]
|
||||
username = Your Name <you@server.dom>
|
||||
@@ -115,35 +111,17 @@ you are a committer (see below), but Mercurial complains if it is missing.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
As the codereview extension is only enabled for your Go checkout, the remainder of this document assumes you
|
||||
are inside the go directory when issuing commands.
|
||||
After adding the extension, <code>hg help codereview</code>
|
||||
will show documentation for its commands. As the codereview extension is only
|
||||
enabled for your checkout in <code>$GOROOT</code>, the remainder of this
|
||||
document assumes you are inside <code>$GOROOT</code> when issuing commands.
|
||||
</p>
|
||||
|
||||
<p>To contribute to subrepositories, edit the <code>.hg/hgrc</code> for each
|
||||
subrepository in the same way. For example, add the codereview extension to
|
||||
<code>code.google.com/p/go.tools/.hg/hgrc</code>.
|
||||
</p>
|
||||
|
||||
<h3>Understanding the extension</h3>
|
||||
|
||||
<p>After adding the code review extension, you can run</p>
|
||||
|
||||
<pre>
|
||||
$ hg help codereview
|
||||
</pre>
|
||||
|
||||
<p>to learn more about its commands. To learn about a specific code-review-specific
|
||||
command such as <code>change</code>, run</p>
|
||||
|
||||
<pre>
|
||||
$ hg help change
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Windows users may need to perform extra steps to get the code review
|
||||
Windows users may need to perform extra steps to get the code review
|
||||
extension working. See the
|
||||
<a href="https://code.google.com/p/go-wiki/wiki/CodeReview">CodeReview page</a>
|
||||
on the <a href="https://code.google.com/p/go-wiki/wiki">Go Wiki</a> for details.
|
||||
<a href="https://code.google.com/p/go-wiki/wiki/CodeReview">CodeReview page</a>
|
||||
on the <a href="http://code.google.com/p/go-wiki/wiki">Go Wiki</a> for details.
|
||||
</p>
|
||||
|
||||
<h3>Log in to the code review site.</h3>
|
||||
@@ -154,7 +132,7 @@ The code review server uses a Google Account to authenticate.
|
||||
<a href="https://www.google.com/accounts/Login?hl=en&continue=http://www.google.com/">sign in at google.com</a>,
|
||||
you can use it to sign in to the code review server.)
|
||||
The email address you use on the Code Review site
|
||||
will be recorded in the <a href="https://code.google.com/p/go/source/list">Mercurial change log</a>
|
||||
will be recorded in the <a href="http://code.google.com/p/go/source/list">Mercurial change log</a>
|
||||
and in the <a href="/CONTRIBUTORS"><code>CONTRIBUTORS</code></a> file.
|
||||
You can <a href="https://www.google.com/accounts/NewAccount">create a Google Account</a>
|
||||
associated with any address where you receive email.
|
||||
@@ -163,6 +141,7 @@ application-specific password and use that when prompted for a password.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ cd $GOROOT
|
||||
$ hg code-login
|
||||
Email (login for uploading to codereview.appspot.com): rsc@golang.org
|
||||
Password for rsc@golang.org:
|
||||
@@ -172,7 +151,7 @@ Saving authentication cookies to /Users/rsc/.codereview_upload_cookies_coderevie
|
||||
|
||||
<h3>Configure your account settings.</h3>
|
||||
|
||||
<p>Edit your <a href="https://codereview.appspot.com/settings">code review settings</a>.
|
||||
<p>Edit your <a href="http://codereview.appspot.com/settings">code review settings</a>.
|
||||
Grab a nickname.
|
||||
Many people prefer to set the Context option to
|
||||
“Whole file” to see more context when reviewing changes.
|
||||
@@ -234,9 +213,9 @@ Description:
|
||||
<enter description here>
|
||||
|
||||
Files:
|
||||
src/math/sin.go
|
||||
src/math/tan.go
|
||||
src/regexp/regexp.go
|
||||
src/pkg/math/sin.go
|
||||
src/pkg/math/tan.go
|
||||
src/pkg/regexp/regexp.go
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
@@ -247,7 +226,7 @@ These can be code review nicknames or arbitrary email addresses.
|
||||
Unless explicitly told otherwise, such as in the discussion leading
|
||||
up to sending in the change list, leave the reviewer field blank.
|
||||
This means that the
|
||||
<a href="https://groups.google.com/group/golang-codereviews">golang-codereviews@googlegroups.com</a>
|
||||
<a href="http://groups.google.com/group/golang-dev">golang-dev@googlegroups.com</a>
|
||||
mailing list will be used as the reviewer.
|
||||
</p>
|
||||
|
||||
@@ -277,7 +256,7 @@ After editing, the template might now read:
|
||||
# Lines beginning with # are ignored.
|
||||
# Multi-line values should be indented.
|
||||
|
||||
Reviewer: golang-codereviews@googlegroups.com
|
||||
Reviewer: golang-dev@googlegroups.com
|
||||
CC: math-nuts@swtch.com
|
||||
|
||||
Description:
|
||||
@@ -287,17 +266,17 @@ Description:
|
||||
Fixes issue 159.
|
||||
|
||||
Files:
|
||||
src/math/sin.go
|
||||
src/math/tan.go
|
||||
src/pkg/math/sin.go
|
||||
src/pkg/math/tan.go
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The special sentence “Fixes issue 159.” associates
|
||||
the change with issue 159 in the <a href="https://code.google.com/p/go/issues/list">Go issue tracker</a>.
|
||||
the change with issue 159 in the <a href="http://code.google.com/p/go/issues/list">Go issue tracker</a>.
|
||||
When this change is eventually submitted, the issue
|
||||
tracker will automatically mark the issue as fixed.
|
||||
(These conventions are described in detail by the
|
||||
<a href="https://code.google.com/p/support/wiki/IssueTracker#Integration_with_version_control">Google Project Hosting Issue Tracker documentation</a>.)
|
||||
<a href="http://code.google.com/p/support/wiki/IssueTracker#Integration_with_version_control">Google Project Hosting Issue Tracker documentation</a>.)
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@@ -309,93 +288,9 @@ which <code>hg change</code> will print, something like:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
CL created: https://codereview.appspot.com/99999
|
||||
CL created: http://codereview.appspot.com/99999
|
||||
</pre>
|
||||
|
||||
<h3>Mail the change for review</h3>
|
||||
|
||||
<p>
|
||||
Creating or uploading the change uploads a copy of the diff to the code review server,
|
||||
but it does not notify anyone about it. To do that, you need to run <code>hg mail</code>
|
||||
(see below).
|
||||
</p>
|
||||
|
||||
<p>To send out a change for review, run <code>hg mail</code> using the change list number
|
||||
assigned during <code>hg change</code>:</p>
|
||||
|
||||
<pre>
|
||||
$ hg mail 99999
|
||||
</pre>
|
||||
|
||||
<p>You can add to the <code>Reviewer:</code> and <code>CC:</code> lines
|
||||
using the <code>-r</code> or <code>--cc</code> options.
|
||||
In the above example, we could have left the <code>Reviewer</code> and <code>CC</code>
|
||||
lines blank and then run:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ hg mail -r golang-codereviews@googlegroups.com --cc math-nuts@swtch.com 99999
|
||||
</pre>
|
||||
|
||||
<p>to achieve the same effect.</p>
|
||||
|
||||
<p>Note that <code>-r</code> and <code>--cc</code> cannot be spelled <code>--r</code> or <code>-cc</code>.</p>
|
||||
|
||||
<p>
|
||||
If your change relates to an open issue, please add a comment to the issue
|
||||
announcing your proposed fix, including a link to your CL.
|
||||
</p>
|
||||
|
||||
<h3>Reviewing code</h3>
|
||||
|
||||
<p>
|
||||
Running <code>hg mail</code> will send an email to you and the reviewers
|
||||
asking them to visit the issue's URL and make comments on the change.
|
||||
When done, the reviewer clicks “Publish and Mail comments”
|
||||
to send comments back.
|
||||
</p>
|
||||
|
||||
|
||||
<h3>Revise and upload</h3>
|
||||
|
||||
<p>
|
||||
When you have revised the code and are ready for another round of review,
|
||||
you can upload your change and send mail asking the reviewers to
|
||||
please take another look (<code>PTAL</code>). Use the change list number
|
||||
assigned during <code>hg change</code>
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ hg mail 99999
|
||||
</pre>
|
||||
|
||||
|
||||
<p>
|
||||
Or to upload your change without sending a notification, run
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ hg upload 99999
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
You will probably revise your code in response to the reviewer comments.
|
||||
You might also visit the code review web page and reply to the comments,
|
||||
letting the reviewer know that you've addressed them or explain why you
|
||||
haven't. When you're done replying, click “Publish and Mail comments”
|
||||
to send the line-by-line replies and any other comments.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The reviewer can comment on the new copy, and the process repeats.
|
||||
The reviewer approves the change by replying with a mail that says
|
||||
<code>LGTM</code>: looks good to me.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
You can see a list of your pending changes by running <code>hg pending</code> (<code>hg p</code> for short).
|
||||
</p>
|
||||
|
||||
<h3>Adding or removing files from an existing change</h3>
|
||||
|
||||
<p>
|
||||
@@ -457,11 +352,11 @@ adding changesets
|
||||
adding manifests
|
||||
adding file changes
|
||||
added 1 changeset with 2 changes to 2 files
|
||||
getting src/flag/flag.go
|
||||
getting src/pkg/flag/flag.go
|
||||
couldn't find merge tool hgmerge
|
||||
merging src/flag/flag_test.go
|
||||
merging src/pkg/flag/flag_test.go
|
||||
warning: conflicts during merge.
|
||||
<i>merging src/flag/flag_test.go failed!</i>
|
||||
<i>merging src/pkg/flag/flag_test.go failed!</i>
|
||||
1 file updated, 0 files merged, 0 files removed, 1 file unresolved
|
||||
use 'hg resolve' to retry unresolved file merges
|
||||
$
|
||||
@@ -473,7 +368,7 @@ Mercurial failed to merge your changes with the independent change.
|
||||
When this happens, Mercurial leaves both edits in the file,
|
||||
marked by <code><<<<<<<</code> and
|
||||
<code>>>>>>>></code>.
|
||||
It is now your job to edit the file to combine them.
|
||||
it is now your job to edit the file to combine them.
|
||||
Continuing the example, searching for those strings in <code>flag_test.go</code>
|
||||
might turn up:
|
||||
</p>
|
||||
@@ -517,6 +412,88 @@ changes, but you may still need to run
|
||||
<code>hg resolve -m</code> to mark the conflict resolved.
|
||||
</p>
|
||||
|
||||
<h3>Mail the change for review</h3>
|
||||
|
||||
<p>
|
||||
Creating or uploading the change uploads a copy of the diff to the code review server,
|
||||
but it does not notify anyone about it. To do that, you need to run <code>hg mail</code>
|
||||
(see below).
|
||||
</p>
|
||||
|
||||
<p>To send out a change for review, run <code>hg mail</code> using the change list number
|
||||
assigned during <code>hg change</code>:</p>
|
||||
|
||||
<pre>
|
||||
$ hg mail 99999
|
||||
</pre>
|
||||
|
||||
<p>You can add to the <code>Reviewer:</code> and <code>CC:</code> lines
|
||||
using the <code>-r</code> or <code>--cc</code> options.
|
||||
In the above example, we could have left the <code>Reviewer</code> and <code>CC</code>
|
||||
lines blank and then run:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ hg mail -r golang-dev@googlegroups.com --cc math-nuts@swtch.com 99999
|
||||
</pre>
|
||||
|
||||
<p>to achieve the same effect.</p>
|
||||
|
||||
<p>Note that <code>-r</code> and <code>--cc</code> cannot be spelled <code>--r</code> or <code>-cc</code>.</p>
|
||||
|
||||
<p>
|
||||
If your change relates to an open issue, please add a comment to the issue
|
||||
announcing your proposed fix, including a link to your CL.
|
||||
</p>
|
||||
|
||||
<h3>Reviewing code</h3>
|
||||
|
||||
<p>
|
||||
Running <code>hg mail</code> will send an email to you and the reviewers
|
||||
asking them to visit the issue's URL and make comments on the change.
|
||||
When done, the reviewer clicks “Publish and Mail comments”
|
||||
to send comments back.
|
||||
</p>
|
||||
|
||||
|
||||
<h3>Revise and upload</h3>
|
||||
|
||||
<p>
|
||||
You will probably revise your code in response to the reviewer comments. When
|
||||
you have done this, you can upload your change to the code review server
|
||||
without sending a notification by running <code>hg upload</code> using the change
|
||||
list number assigned during <code>hg change</code>
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ hg upload 99999
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
When you have revised the code and are ready for another round of review, run
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ hg mail 99999
|
||||
</pre>
|
||||
|
||||
<p>again to upload the latest copy and send mail asking the reviewers to please take another look
|
||||
(<code>PTAL</code>).
|
||||
You might also visit the code review web page and reply to the comments,
|
||||
letting the reviewer know that you've addressed them or explain why you
|
||||
haven't. When you're done replying, click “Publish and Mail comments”
|
||||
to send the line-by-line replies and any other comments.
|
||||
</p>
|
||||
<p>
|
||||
The reviewer can comment on the new copy, and the process repeats.
|
||||
The reviewer approves the change by replying with a mail that says
|
||||
<code>LGTM</code>: looks good to me.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
You can see a list of your pending changes by running <code>hg pending</code> (<code>hg p</code> for short).
|
||||
</p>
|
||||
|
||||
<h3>Reviewing code by others</h3>
|
||||
|
||||
<p>
|
||||
@@ -606,18 +583,11 @@ $ hg submit 99999
|
||||
local repository out of date; must sync before submit
|
||||
</pre>
|
||||
|
||||
<h3>More information</h3>
|
||||
|
||||
<p>
|
||||
In addition to the information here, the Go community maintains a <a href="https://code.google.com/p/go-wiki/wiki/CodeReview">CodeReview</a> wiki page.
|
||||
Feel free to contribute to this page as you learn the review process.
|
||||
</p>
|
||||
|
||||
<h2 id="copyright">Copyright</h2>
|
||||
|
||||
<p>Files in the Go repository don't list author names,
|
||||
both to avoid clutter and to avoid having to keep the lists up to date.
|
||||
Instead, your name will appear in the <a href="https://code.google.com/p/go/source/list">Mercurial change log</a>
|
||||
Instead, your name will appear in the <a href="http://code.google.com/p/go/source/list">Mercurial change log</a>
|
||||
and in the <a href="/CONTRIBUTORS"><code>CONTRIBUTORS</code></a> file
|
||||
and perhaps the <a href="/AUTHORS"><code>AUTHORS</code></a> file.
|
||||
</p>
|
||||
@@ -632,15 +602,13 @@ In order for them to do that, you need to have completed one of the
|
||||
contributor license agreements:
|
||||
<ul>
|
||||
<li>
|
||||
If you are the copyright holder, you will need to agree to the
|
||||
<a href="https://developers.google.com/open-source/cla/individual">individual
|
||||
If you are the copyright holder, you will need to agree to
|
||||
the <a href="http://code.google.com/legal/individual-cla-v1.0.html">individual
|
||||
contributor license agreement</a>, which can be completed online.
|
||||
</li>
|
||||
<li>
|
||||
If your organization is the copyright holder, the organization
|
||||
will need to agree to the
|
||||
<a href="https://developers.google.com/open-source/cla/corporate">corporate
|
||||
contributor license agreement</a>.
|
||||
will need to agree to the <a href="http://code.google.com/legal/corporate-cla-v1.0.html">corporate contributor license agreement</a>.
|
||||
(If the copyright holder for your code has already completed the
|
||||
agreement in connection with another Google open source project,
|
||||
it does not need to be completed again.)
|
||||
@@ -654,7 +622,7 @@ This rigmarole needs to be done only for your first submission.
|
||||
<p>Code that you contribute should use the standard copyright header:</p>
|
||||
|
||||
<pre>
|
||||
// Copyright 2014 The Go Authors. All rights reserved.
|
||||
// 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.
|
||||
</pre>
|
||||
|
||||
@@ -9,23 +9,6 @@ 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>
|
||||
@@ -36,8 +19,8 @@ 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>
|
||||
@@ -120,7 +103,7 @@ 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
|
||||
@@ -153,7 +136,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 +155,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 +163,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>
|
||||
@@ -199,7 +182,7 @@ it by hand by telling gdb (assuming you have the go sources in
|
||||
</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 +242,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 +251,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 +280,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 +294,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 +316,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 +393,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 +404,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>
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
}-->
|
||||
|
||||
<p>This page summarizes the changes between official stable releases of Go.
|
||||
The <a href="//code.google.com/p/go/source/list">Mercurial change log</a>
|
||||
The <a href="http://code.google.com/p/go/source/list">Mercurial change log</a>
|
||||
has the full details.</p>
|
||||
|
||||
<p>To update to a specific release, use:</p>
|
||||
@@ -13,75 +13,6 @@ hg pull
|
||||
hg update <i>tag</i>
|
||||
</pre>
|
||||
|
||||
<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="//code.google.com/p/go/source/list?name=release-branch.go1.3&r=073fc578434bf3e1e22749b559d273c8da728ebb">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="//code.google.com/p/go/source/list?name=release-branch.go1.3&r=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="//code.google.com/p/go/source/list?name=release-branch.go1.3&r=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="//code.google.com/p/go/source/list?name=release-branch.go1.2&r=7ada9e760ce34e78aee5b476c9621556d0fa5d31">change history</a> for details.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
go1.2.2 (released 2014/05/05) includes a
|
||||
<a href="//code.google.com/p/go/source/detail?r=bda3619e7a2c&repo=tools">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="//code.google.com/p/go/source/list?name=release-branch.go1.1&r=43c4a41d24382a56a90e924800c681e435d9e399">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="//code.google.com/p/go/source/list?name=release-branch.go1.1&r=a6a9792f94acd4ff686b2bc57383d163608b91cf">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/change/55ac276af5a7">55ac276af5a7</a>
|
||||
that fixes <a href="//golang.org/issue/5949">issue 5949</a>.
|
||||
</p>
|
||||
|
||||
<h2 id="go1">go1 (released 2012/03/28)</h2>
|
||||
|
||||
<p>
|
||||
@@ -105,17 +36,17 @@ The go1 release corresponds to
|
||||
|
||||
<p>
|
||||
go1.0.1 (released 2012/04/25) was issued to
|
||||
<a href="//golang.org/change/a890477d3dfb">fix</a> an
|
||||
<a href="//golang.org/issue/3545">escape analysis bug</a>
|
||||
that can lead to memory corruption.
|
||||
<a href="https://code.google.com/p/go/source/detail?r=a890477d3dfb">fix</a> an
|
||||
<a href="https://code.google.com/p/go/issues/detail?id=3545">escape analysis
|
||||
bug</a> that can lead to memory corruption.
|
||||
It also includes several minor code and documentation fixes.
|
||||
</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>.
|
||||
<a href="http://code.google.com/p/go/issues/detail?id=3695">issue 3695</a> and
|
||||
<a href="http://code.google.com/p/go/issues/detail?id=3573">issue 3573</a>.
|
||||
It also includes many minor code and documentation fixes.
|
||||
</p>
|
||||
|
||||
@@ -124,7 +55,7 @@ go1.0.3 (released 2012/09/21) includes minor code and documentation fixes.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
See the <a href="//code.google.com/p/go/source/list?name=release-branch.go1">go1 release branch history</a> for the complete list of changes.
|
||||
See the <a href="http://code.google.com/p/go/source/list?name=release-branch.go1">go1 release branch history</a> for the complete list of changes.
|
||||
</p>
|
||||
|
||||
<h2 id="r60">r60 (released 2011/09/07)</h2>
|
||||
@@ -136,7 +67,7 @@ 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>.
|
||||
<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>
|
||||
@@ -206,26 +137,26 @@ more accessible.
|
||||
|
||||
<p>
|
||||
r60.1 includes a
|
||||
<a href="//golang.org/change/1824581bf62d">linker
|
||||
<a href="http://code.google.com/p/go/source/detail?r=1824581bf62d">linker
|
||||
fix</a>, a pair of
|
||||
<a href="//golang.org/change/9ef4429c2c64">goplay</a>
|
||||
<a href="//golang.org/change/d42ed8c3098e">fixes</a>,
|
||||
<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="//golang.org/change/d5e97874fe84">fix</a> and
|
||||
<a href="http://code.google.com/p/go/source/detail?r=d5e97874fe84">fix</a> and
|
||||
a new
|
||||
<a href="//golang.org/change/4f0e6269213f">struct tag
|
||||
<a href="http://code.google.com/p/go/source/detail?r=4f0e6269213f">struct tag
|
||||
option</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
r60.2
|
||||
<a href="//golang.org/change/ff19536042ac">fixes</a>
|
||||
<a href="http://code.google.com/p/go/source/detail?r=ff19536042ac">fixes</a>
|
||||
a memory leak involving maps.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
r60.3 fixes a
|
||||
<a href="//golang.org/change/01fa62f5e4e5">reflect bug</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>
|
||||
@@ -237,7 +168,7 @@ 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>.
|
||||
<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>
|
||||
@@ -247,7 +178,7 @@ 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
|
||||
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>
|
||||
|
||||
@@ -345,13 +276,13 @@ 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>.
|
||||
<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="//golang.org/change/b720749486e1">use of uninitialized memory in programs that misuse <code>goto</code></a>.
|
||||
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>
|
||||
@@ -410,8 +341,8 @@ the Go tree (and avoid writing Makefiles).
|
||||
<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>
|
||||
<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>
|
||||
|
||||
@@ -425,7 +356,7 @@ 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>.
|
||||
<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
|
||||
@@ -436,7 +367,7 @@ 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
|
||||
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>
|
||||
@@ -482,7 +413,7 @@ 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>.
|
||||
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;
|
||||
@@ -526,7 +457,7 @@ 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>
|
||||
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.
|
||||
@@ -562,8 +493,8 @@ For other uses, see the <a href="/pkg/runtime/pprof/">runtime/pprof</a> document
|
||||
|
||||
<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>
|
||||
<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>
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
<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>
|
||||
|
||||
<p>For recent information, see the <a href="//code.google.com/p/go/source/list">Mercurial change log</a> and <a href="//groups.google.com/group/golang-dev/">development mailing list</a>.</p>
|
||||
<p>For recent information, see the <a href="http://code.google.com/p/go/source/list">Mercurial change log</a> and <a href="http://groups.google.com/group/golang-dev/">development mailing list</a>.</p>
|
||||
|
||||
<h2 id="2012-03-27">2012-03-27 (<a href="release.html#go1">Go 1</a>)</h2>
|
||||
|
||||
|
||||
165
doc/docs.html
165
doc/docs.html
@@ -33,20 +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
|
||||
<a href="//code.google.com/p/go-tour/">install it locally</a>.
|
||||
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
|
||||
<a href="http://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.
|
||||
</p>
|
||||
@@ -58,52 +58,45 @@ 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="ref"><a href="/ref/">Go References</a></h3>
|
||||
<p>Language specification, memory model, and detailed documentation for the commands and packages.</p>
|
||||
|
||||
<h3 id="appengine"><a href="https://developers.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="https://developers.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="go1.1notes"><a href="/doc/go1.1.html">Go 1.1 Release Notes</a></h3>
|
||||
<p>
|
||||
The documentation for the Go standard library.
|
||||
A list of significant changes in Go 1.1, with instructions for updating your
|
||||
code where necessary.
|
||||
</p>
|
||||
|
||||
<h3 id="cmd"><a href="/doc/cmd">Command 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 tools.
|
||||
What Go 1 defines and the backwards-compatibility guarantees one can expect as
|
||||
Go 1 matures.
|
||||
</p>
|
||||
|
||||
<h3 id="spec"><a href="/ref/spec">Language Specification</a></h3>
|
||||
<p>
|
||||
The official Go Language specification.
|
||||
</p>
|
||||
<h2 id="articles">Go Articles</h2>
|
||||
|
||||
<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>
|
||||
|
||||
@@ -120,48 +113,44 @@ 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>
|
||||
<li><a href="/doc/articles/race_detector.html">Data Race Detector</a> - testing Go programs for race conditions.</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"/>
|
||||
|
||||
<p>
|
||||
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="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:
|
||||
@@ -169,31 +158,63 @@ interfaces, reflection, and concurrency. Builds a toy web crawler to
|
||||
demonstrate these.
|
||||
</p>
|
||||
|
||||
<h3 id="go_code_that_grows"><a href="//vimeo.com/53221560">Code that grows with grace</a></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.
|
||||
</p>
|
||||
|
||||
<h3 id="go_concurrency_patterns"><a href="//www.youtube.com/watch?v=f6kdp27TYZs">Go Concurrency Patterns</a></h3>
|
||||
<h3 id="go_concurrency_patterns"><a href="http://www.youtube.com/watch?v=f6kdp27TYZs">Go Concurrency Patterns</a></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.
|
||||
</p>
|
||||
|
||||
<h3 id="advanced_go_concurrency_patterns"><a href="//www.youtube.com/watch?v=QDDwwePbDtw">Advanced Go Concurrency Patterns</a></h3>
|
||||
<h3 id="meet_the_go_team"><a href="http://www.youtube.com/watch?v=sln-gJaURzk">Meet the Go team</a></h3>
|
||||
<p>
|
||||
This talk expands on the <i>Go Concurrency Patterns</i> talk to dive deeper into Go's concurrency primitives.
|
||||
A panel discussion with David Symonds, Robert Griesemer, Rob Pike, Ken Thompson, Andrew Gerrand, and Brad Fitzpatrick.
|
||||
</p>
|
||||
|
||||
<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>
|
||||
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="http://talks.golang.org/2011/Writing_Web_Apps_in_Go.pdf">presentation slides</a>.
|
||||
</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>
|
||||
|
||||
<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://code.google.com/p/go-wiki/wiki/Projects">Go Wiki Projects Page</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>
|
||||
|
||||
@@ -28,7 +28,7 @@ will be easy for other Go programmers to understand.
|
||||
<p>
|
||||
This document gives tips for writing clear, idiomatic Go code.
|
||||
It augments the <a href="/ref/spec">language specification</a>,
|
||||
the <a href="//tour.golang.org/">Tour of Go</a>,
|
||||
the <a href="http://tour.golang.org/">Tour of Go</a>,
|
||||
and <a href="/doc/code.html">How to Write Go Code</a>,
|
||||
all of which you
|
||||
should read first.
|
||||
@@ -37,15 +37,15 @@ should read first.
|
||||
<h3 id="examples">Examples</h3>
|
||||
|
||||
<p>
|
||||
The <a href="/src/">Go package sources</a>
|
||||
The <a href="/src/pkg/">Go package sources</a>
|
||||
are intended to serve not
|
||||
only as the core library but also as examples of how to
|
||||
use the language.
|
||||
Moreover, many of the packages contain working, self-contained
|
||||
executable examples you can run directly from the
|
||||
<a href="//golang.org">golang.org</a> web site, such as
|
||||
<a href="//golang.org/pkg/strings/#example_Map">this one</a> (if
|
||||
necessary, click on the word "Example" to open it up).
|
||||
<a href="http://golang.org">golang.org</a> web site, such as
|
||||
<a href="http://golang.org/pkg/strings/#example_Map">this one</a> (click
|
||||
on the word "Example" to open it up).
|
||||
If you have a question about how to approach a problem or how something
|
||||
might be implemented, the documentation, code and examples in the
|
||||
library can provide answers, ideas and
|
||||
@@ -214,7 +214,7 @@ not be used.
|
||||
One adjustment <code>godoc</code> does do is to display indented
|
||||
text in a fixed-width font, suitable for program snippets.
|
||||
The package comment for the
|
||||
<a href="/pkg/fmt/"><code>fmt</code> package</a> uses this to good effect.
|
||||
<a href="http://golang.org/pkg/fmt/"><code>fmt</code> package</a> uses this to good effect.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@@ -288,7 +288,7 @@ var (
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Grouping can also indicate relationships between items,
|
||||
Even for private names, grouping can also indicate relationships between items,
|
||||
such as the fact that a set of variables is protected by a mutex.
|
||||
</p>
|
||||
|
||||
@@ -344,13 +344,13 @@ determines just which package is being used.
|
||||
<p>
|
||||
Another convention is that the package name is the base name of
|
||||
its source directory;
|
||||
the package in <code>src/encoding/base64</code>
|
||||
the package in <code>src/pkg/encoding/base64</code>
|
||||
is imported as <code>"encoding/base64"</code> but has name <code>base64</code>,
|
||||
not <code>encoding_base64</code> and not <code>encodingBase64</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The importer of a package will use the name to refer to its contents,
|
||||
The importer of a package will use the name to refer to its contents.
|
||||
so exported names in the package can use that fact
|
||||
to avoid stutter.
|
||||
(Don't use the <code>import .</code> notation, which can simplify
|
||||
@@ -506,8 +506,6 @@ slightly generalized
|
||||
<code>switch</code> is more flexible;
|
||||
<code>if</code> and <code>switch</code> accept an optional
|
||||
initialization statement like that of <code>for</code>;
|
||||
<code>break</code> and <code>continue</code> statements
|
||||
take an optional label to identify what to break or continue;
|
||||
and there are new control structures including a type switch and a
|
||||
multiway communications multiplexer, <code>select</code>.
|
||||
The syntax is also slightly different:
|
||||
@@ -701,7 +699,6 @@ for _, value := range array {
|
||||
|
||||
<p>
|
||||
The blank identifier has many uses, as described in <a href="#blank">a later section</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For strings, the <code>range</code> does more work for you, breaking out individual
|
||||
@@ -710,7 +707,7 @@ Erroneous encodings consume one byte and produce the
|
||||
replacement rune U+FFFD.
|
||||
(The name (with associated builtin type) <code>rune</code> is Go terminology for a
|
||||
single Unicode code point.
|
||||
See <a href="/ref/spec#Rune_literals">the language specification</a>
|
||||
See <a href="http://golang.org/ref/spec#Rune_literals">the language specification</a>
|
||||
for details.)
|
||||
The loop
|
||||
</p>
|
||||
@@ -784,47 +781,7 @@ func shouldEscape(c byte) bool {
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Although they are not nearly as common in Go as some other C-like
|
||||
languages, <code>break</code> statements can be used to terminate
|
||||
a <code>switch</code> early.
|
||||
Sometimes, though, it's necessary to break out of a surrounding loop,
|
||||
not the switch, and in Go that can be accomplished by putting a label
|
||||
on the loop and "breaking" to that label.
|
||||
This example shows both uses.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
Loop:
|
||||
for n := 0; n < len(src); n += size {
|
||||
switch {
|
||||
case src[n] < sizeOne:
|
||||
if validateOnly {
|
||||
break
|
||||
}
|
||||
size = 1
|
||||
update(src[n])
|
||||
|
||||
case src[n] < sizeTwo:
|
||||
if n+1 >= len(src) {
|
||||
err = errShortInput
|
||||
break Loop
|
||||
}
|
||||
if validateOnly {
|
||||
break
|
||||
}
|
||||
size = 2
|
||||
update(src[n] + src[n+1]<<shift)
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Of course, the <code>continue</code> statement also accepts an optional label
|
||||
but it applies only to loops.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To close this section, here's a comparison routine for byte slices that uses two
|
||||
Here's a comparison routine for byte slices that uses two
|
||||
<code>switch</code> statements:
|
||||
</p>
|
||||
<pre>
|
||||
@@ -841,16 +798,16 @@ func Compare(a, b []byte) int {
|
||||
}
|
||||
}
|
||||
switch {
|
||||
case len(a) > len(b):
|
||||
return 1
|
||||
case len(a) < len(b):
|
||||
return -1
|
||||
case len(a) > len(b):
|
||||
return 1
|
||||
}
|
||||
return 0
|
||||
}
|
||||
</pre>
|
||||
|
||||
<h3 id="type_switch">Type switch</h3>
|
||||
<h2 id="type_switch">Type switch</h2>
|
||||
|
||||
<p>
|
||||
A switch can also be used to discover the dynamic type of an interface
|
||||
@@ -925,7 +882,7 @@ func nextInt(b []byte, i int) (int, int) {
|
||||
}
|
||||
x := 0
|
||||
for ; i < len(b) && isDigit(b[i]); i++ {
|
||||
x = x*10 + int(b[i]) - '0'
|
||||
x = x*10 + int(b[i])-'0'
|
||||
}
|
||||
return x, i
|
||||
}
|
||||
@@ -1386,9 +1343,8 @@ func (file *File) Read(buf []byte) (n int, err error)
|
||||
</pre>
|
||||
<p>
|
||||
The method returns the number of bytes read and an error value, if
|
||||
any.
|
||||
To read into the first 32 bytes of a larger buffer
|
||||
<code>buf</code>, <i>slice</i> (here used as a verb) the buffer.
|
||||
any. To read into the first 32 bytes of a larger buffer
|
||||
<code>b</code>, <i>slice</i> (here used as a verb) the buffer.
|
||||
</p>
|
||||
<pre>
|
||||
n, err := f.Read(buf[0:32])
|
||||
@@ -1489,7 +1445,7 @@ If the slices might grow or shrink, they should be allocated independently
|
||||
to avoid overwriting the next line; if not, it can be more efficient to construct
|
||||
the object with a single allocation.
|
||||
For reference, here are sketches of the two methods.
|
||||
First, a line at a time:
|
||||
First, a line a time:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
@@ -1540,7 +1496,7 @@ with colon-separated key-value pairs,
|
||||
so it's easy to build them during initialization.
|
||||
</p>
|
||||
<pre>
|
||||
var timeZone = map[string]int{
|
||||
var timeZone = map[string] int {
|
||||
"UTC": 0*60*60,
|
||||
"EST": -5*60*60,
|
||||
"CST": -6*60*60,
|
||||
@@ -1567,7 +1523,7 @@ Set the map entry to <code>true</code> to put the value in the set, and then
|
||||
test it by simple indexing.
|
||||
</p>
|
||||
<pre>
|
||||
attended := map[string]bool{
|
||||
attended := map[string] bool {
|
||||
"Ann": true,
|
||||
"Joe": true,
|
||||
...
|
||||
@@ -1959,7 +1915,7 @@ initializer can be a general expression computed at run time.
|
||||
var (
|
||||
home = os.Getenv("HOME")
|
||||
user = os.Getenv("USER")
|
||||
gopath = os.Getenv("GOPATH")
|
||||
goRoot = os.Getenv("GOROOT")
|
||||
)
|
||||
</pre>
|
||||
|
||||
@@ -1988,11 +1944,11 @@ func init() {
|
||||
if home == "" {
|
||||
home = "/home/" + user
|
||||
}
|
||||
if gopath == "" {
|
||||
gopath = home + "/go"
|
||||
if goRoot == "" {
|
||||
goRoot = home + "/go"
|
||||
}
|
||||
// gopath may be overridden by --gopath flag on command line.
|
||||
flag.StringVar(&gopath, "gopath", gopath, "override default GOPATH")
|
||||
// goRoot may be overridden by --goroot flag on command line.
|
||||
flag.StringVar(&goRoot, "goroot", goRoot, "Go root directory")
|
||||
}
|
||||
</pre>
|
||||
|
||||
@@ -2056,22 +2012,10 @@ We pass the address of a <code>ByteSlice</code>
|
||||
because only <code>*ByteSlice</code> satisfies <code>io.Writer</code>.
|
||||
The rule about pointers vs. values for receivers is that value methods
|
||||
can be invoked on pointers and values, but pointer methods can only be
|
||||
invoked on pointers.
|
||||
invoked on pointers. This is because pointer methods can modify the
|
||||
receiver; invoking them on a copy of the value would cause those
|
||||
modifications to be discarded.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
This rule arises because pointer methods can modify the receiver; invoking
|
||||
them on a value would cause the method to receive a copy of the value, so
|
||||
any modifications would be discarded.
|
||||
The language therefore disallows this mistake.
|
||||
There is a handy exception, though. When the value is addressable, the
|
||||
language takes care of the common case of invoking a pointer method on a
|
||||
value by inserting the address operator automatically.
|
||||
In our example, the variable <code>b</code> is addressable, so we can call
|
||||
its <code>Write</code> method with just <code>b.Write</code>. The compiler
|
||||
will rewrite that to <code>(&b).Write</code> for us.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
By the way, the idea of using <code>Write</code> on a slice of bytes
|
||||
is central to the implementation of <code>bytes.Buffer</code>.
|
||||
@@ -2187,7 +2131,6 @@ A one-case type switch would do, but so would a <em>type assertion</em>.
|
||||
A type assertion takes an interface value and extracts from it a value of the specified explicit type.
|
||||
The syntax borrows from the clause opening a type switch, but with an explicit
|
||||
type rather than the <code>type</code> keyword:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
value.(typeName)
|
||||
@@ -2478,8 +2421,6 @@ It has uses beyond those we've seen already.
|
||||
<p>
|
||||
The use of a blank identifier in a <code>for</code> <code>range</code> loop is a
|
||||
special case of a general situation: multiple assignment.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If an assignment requires multiple values on the left side,
|
||||
but one of the values will not be used by the program,
|
||||
@@ -2595,7 +2536,7 @@ package, which defines a <code><a href="/pkg/encoding/json/#Marshaler">Marshaler
|
||||
interface. When the JSON encoder receives a value that implements that interface,
|
||||
the encoder invokes the value's marshaling method to convert it to JSON
|
||||
instead of doing the standard conversion.
|
||||
The encoder checks this property at run time with a <a href="#interface_conversions">type assertion</a> like:
|
||||
The encoder checks this property at run time with a <a href="interface_conversions">type assertion</a> like:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
@@ -2619,7 +2560,7 @@ One place this situation arises is when it is necessary to guarantee within the
|
||||
it actually satisfies the interface.
|
||||
If a type—for example,
|
||||
<code><a href="/pkg/encoding/json/#RawMessage">json.RawMessage</a></code>—needs
|
||||
a custom JSON representation, it should implement
|
||||
a custom its JSON representation, it should implement
|
||||
<code>json.Marshaler</code>, but there are no static conversions that would
|
||||
cause the compiler to verify this automatically.
|
||||
If the type inadvertently fails to satisfy the interface, the JSON encoder will still work,
|
||||
@@ -2954,19 +2895,26 @@ means waiting until some receiver has retrieved a value.
|
||||
<p>
|
||||
A buffered channel can be used like a semaphore, for instance to
|
||||
limit throughput. In this example, incoming requests are passed
|
||||
to <code>handle</code>, which sends a value into the channel, processes
|
||||
the request, and then receives a value from the channel
|
||||
to ready the “semaphore” for the next consumer.
|
||||
to <code>handle</code>, which receives a value from the channel, processes
|
||||
the request, and then sends a value back to the channel
|
||||
to ready the "semaphore" for the next consumer.
|
||||
The capacity of the channel buffer limits the number of
|
||||
simultaneous calls to <code>process</code>.
|
||||
simultaneous calls to <code>process</code>,
|
||||
so during initialization we prime the channel by filling it to capacity.
|
||||
</p>
|
||||
<pre>
|
||||
var sem = make(chan int, MaxOutstanding)
|
||||
|
||||
func handle(r *Request) {
|
||||
sem <- 1 // Wait for active queue to drain.
|
||||
process(r) // May take a long time.
|
||||
<-sem // Done; enable next request to run.
|
||||
<-sem // Wait for active queue to drain.
|
||||
process(r) // May take a long time.
|
||||
sem <- 1 // Done; enable next request to run.
|
||||
}
|
||||
|
||||
func init() {
|
||||
for i := 0; i < MaxOutstanding; i++ {
|
||||
sem <- 1
|
||||
}
|
||||
}
|
||||
|
||||
func Serve(queue chan *Request) {
|
||||
@@ -2978,9 +2926,10 @@ func Serve(queue chan *Request) {
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Once <code>MaxOutstanding</code> handlers are executing <code>process</code>,
|
||||
any more will block trying to send into the filled channel buffer,
|
||||
until one of the existing handlers finishes and receives from the buffer.
|
||||
Because data synchronization occurs on a receive from a channel
|
||||
(that is, the send "happens before" the receive; see
|
||||
<a href="/ref/mem">The Go Memory Model</a>),
|
||||
acquisition of the semaphore must be on a channel receive, not a send.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@@ -2991,77 +2940,21 @@ of them can run at any moment.
|
||||
As a result, the program can consume unlimited resources if the requests come in too fast.
|
||||
We can address that deficiency by changing <code>Serve</code> to
|
||||
gate the creation of the goroutines.
|
||||
Here's an obvious solution, but beware it has a bug we'll fix subsequently:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
func Serve(queue chan *Request) {
|
||||
for req := range queue {
|
||||
sem <- 1
|
||||
<-sem
|
||||
go func() {
|
||||
process(req) // Buggy; see explanation below.
|
||||
<-sem
|
||||
process(req)
|
||||
sem <- 1
|
||||
}()
|
||||
}
|
||||
}</pre>
|
||||
|
||||
<p>
|
||||
The bug is that in a Go <code>for</code> loop, the loop variable
|
||||
is reused for each iteration, so the <code>req</code>
|
||||
variable is shared across all goroutines.
|
||||
That's not what we want.
|
||||
We need to make sure that <code>req</code> is unique for each goroutine.
|
||||
Here's one way to do that, passing the value of <code>req</code> as an argument
|
||||
to the closure in the goroutine:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
func Serve(queue chan *Request) {
|
||||
for req := range queue {
|
||||
sem <- 1
|
||||
go func(req *Request) {
|
||||
process(req)
|
||||
<-sem
|
||||
}(req)
|
||||
}
|
||||
}</pre>
|
||||
|
||||
<p>
|
||||
Compare this version with the previous to see the difference in how
|
||||
the closure is declared and run.
|
||||
Another solution is just to create a new variable with the same
|
||||
name, as in this example:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
func Serve(queue chan *Request) {
|
||||
for req := range queue {
|
||||
req := req // Create new instance of req for the goroutine.
|
||||
sem <- 1
|
||||
go func() {
|
||||
process(req)
|
||||
<-sem
|
||||
}()
|
||||
}
|
||||
}</pre>
|
||||
|
||||
<p>
|
||||
It may seem odd to write
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
req := req
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
but it's a legal and idiomatic in Go to do this.
|
||||
You get a fresh version of the variable with the same name, deliberately
|
||||
shadowing the loop variable locally but unique to each goroutine.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Going back to the general problem of writing the server,
|
||||
another approach that manages resources well is to start a fixed
|
||||
Another solution that manages resources well is to start a fixed
|
||||
number of <code>handle</code> goroutines all reading from the request
|
||||
channel.
|
||||
The number of goroutines limits the number of simultaneous
|
||||
@@ -3214,7 +3107,7 @@ Although the concurrency features of Go can make some problems easy
|
||||
to structure as parallel computations, Go is a concurrent language,
|
||||
not a parallel one, and not all parallelization problems fit Go's model.
|
||||
For a discussion of the distinction, see the talk cited in
|
||||
<a href="//blog.golang.org/2013/01/concurrency-is-not-parallelism.html">this
|
||||
<a href="http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html">this
|
||||
blog post</a>.
|
||||
|
||||
<h3 id="leaky_buffer">A leaky buffer</h3>
|
||||
@@ -3287,18 +3180,9 @@ the garbage collector for bookkeeping.
|
||||
|
||||
<p>
|
||||
Library routines must often return some sort of error indication to
|
||||
the caller.
|
||||
As mentioned earlier, Go's multivalue return makes it
|
||||
the caller. As mentioned earlier, Go's multivalue return makes it
|
||||
easy to return a detailed error description alongside the normal
|
||||
return value.
|
||||
It is good style to use this feature to provide detailed error information.
|
||||
For example, as we'll see, <code>os.Open</code> doesn't
|
||||
just return a <code>nil</code> pointer on failure, it also returns an
|
||||
error value that describes what went wrong.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
By convention, errors have type <code>error</code>,
|
||||
return value. By convention, errors have type <code>error</code>,
|
||||
a simple built-in interface.
|
||||
</p>
|
||||
<pre>
|
||||
@@ -3310,12 +3194,7 @@ type error interface {
|
||||
A library writer is free to implement this interface with a
|
||||
richer model under the covers, making it possible not only
|
||||
to see the error but also to provide some context.
|
||||
As mentioned, alongside the usual <code>*os.File</code>
|
||||
return value, <code>os.Open</code> also returns an
|
||||
error value.
|
||||
If the file is opened successfully, the error will be <code>nil</code>,
|
||||
but when there is a problem, it will hold an
|
||||
<code>os.PathError</code>:
|
||||
For example, <code>os.Open</code> returns an <code>os.PathError</code>.
|
||||
</p>
|
||||
<pre>
|
||||
// PathError records an error and the operation and
|
||||
@@ -3375,7 +3254,7 @@ for try := 0; try < 2; try++ {
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The second <code>if</code> statement here is another <a href="#interface_conversions">type assertion</a>.
|
||||
The second <code>if</code> statement here is another <a href="#interface_conversion">type assertion</a>.
|
||||
If it fails, <code>ok</code> will be false, and <code>e</code>
|
||||
will be <code>nil</code>.
|
||||
If it succeeds, <code>ok</code> will be true, which means the
|
||||
@@ -3558,7 +3437,7 @@ the parse stack by hand:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
if pos == 0 {
|
||||
if pos==0 {
|
||||
re.error("'*' illegal at start of expression")
|
||||
}
|
||||
</pre>
|
||||
|
||||
@@ -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://code.google.com/p/gofrontend/source/browse/HACKING">the
|
||||
file HACKING</a> in the gofrontend repository.
|
||||
</p>
|
||||
|
||||
<h2>Legal Prerequisites</h2>
|
||||
@@ -30,7 +26,7 @@ contribution rules</a>.
|
||||
|
||||
<p>
|
||||
The master sources for the gccgo frontend may be found at
|
||||
<a href="//code.google.com/p/gofrontend">http://code.google.com/p/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
|
||||
@@ -40,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="//code.google.com/p/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>
|
||||
@@ -65,7 +61,7 @@ from <code>gcc/go/gofrontend</code> to <code>gcc/go</code>.
|
||||
|
||||
<p>
|
||||
The run-time library for gccgo is mostly the same as the library
|
||||
in <a href="//code.google.com/p/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>
|
||||
|
||||
@@ -32,18 +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.
|
||||
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>
|
||||
@@ -133,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>
|
||||
|
||||
@@ -157,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>
|
||||
@@ -295,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>
|
||||
@@ -319,7 +309,7 @@ gccgo. Both options take directories to search. The
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The gccgo compiler does not currently (2013-06-20) 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.
|
||||
</p>
|
||||
@@ -395,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
|
||||
@@ -467,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
|
||||
@@ -526,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>.
|
||||
|
||||
@@ -118,7 +118,7 @@ func (w *bufio.Writer, p []byte) (n int, err error) {
|
||||
<h3 id="return">Return requirements</h3>
|
||||
|
||||
<p>
|
||||
Before Go 1.1, a function that returned a value needed an explicit "return"
|
||||
Before Go 1.1, a function that returned a value needed an explicit "return"
|
||||
or call to <code>panic</code> at
|
||||
the end of the function; this was a simple way to make the programmer
|
||||
be explicit about the meaning of the function. But there are many cases
|
||||
@@ -129,9 +129,9 @@ only an infinite "for" loop.
|
||||
<p>
|
||||
In Go 1.1, the rule about final "return" statements is more permissive.
|
||||
It introduces the concept of a
|
||||
<a href="/ref/spec#Terminating_statements"><em>terminating statement</em></a>,
|
||||
<a href="/ref/spec/#Terminating_statements"><em>terminating statement</em></a>,
|
||||
a statement that is guaranteed to be the last one a function executes.
|
||||
Examples include
|
||||
Examples include
|
||||
"for" loops with no condition and "if-else"
|
||||
statements in which each half ends in a "return".
|
||||
If the final statement of a function can be shown <em>syntactically</em> to
|
||||
@@ -159,7 +159,7 @@ The GCC release schedule does not coincide with the Go release schedule, so some
|
||||
<code>gccgo</code>'s releases.
|
||||
The 4.8.0 version of GCC shipped in March, 2013 and includes a nearly-Go 1.1 version of <code>gccgo</code>.
|
||||
Its library is a little behind the release, but the biggest difference is that method values are not implemented.
|
||||
Sometime around July 2013, we expect 4.8.2 of GCC to ship with a <code>gccgo</code>
|
||||
Sometime around May 2013, we expect 4.8.1 of GCC to ship with a <code>gccgo</code>
|
||||
providing a complete Go 1.1 implementaiton.
|
||||
</p>
|
||||
|
||||
@@ -172,7 +172,7 @@ from the traditional Unix flag parsing. This may affect scripts that invoke
|
||||
the tool directly.
|
||||
For example,
|
||||
<code>go tool 6c -Fw -Dfoo</code> must now be written
|
||||
<code>go tool 6c -F -w -D foo</code>.
|
||||
<code>go tool 6c -F -w -D foo</code>.
|
||||
</p>
|
||||
|
||||
<h3 id="int">Size of int on 64-bit platforms</h3>
|
||||
@@ -191,13 +191,12 @@ more than 2 billion elements on 64-bit platforms.
|
||||
<em>Updating</em>:
|
||||
Most programs will be unaffected by this change.
|
||||
Because Go does not allow implicit conversions between distinct
|
||||
<a href="/ref/spec#Numeric_types">numeric types</a>,
|
||||
<a href="/ref/spec/#Numeric_types">numeric types</a>,
|
||||
no programs will stop compiling due to this change.
|
||||
However, programs that contain implicit assumptions
|
||||
that <code>int</code> is only 32 bits may change behavior.
|
||||
For example, this code prints a positive number on 64-bit systems and
|
||||
a negative one on 32-bit systems:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
x := ^uint32(0) // x is 0xffffffff
|
||||
@@ -295,7 +294,7 @@ variable, where at least one of the accesses is a write.
|
||||
This new facility is built into the <code>go</code> tool.
|
||||
For now, it is only available on Linux, Mac OS X, and Windows systems with
|
||||
64-bit x86 processors.
|
||||
To enable it, set the <code>-race</code> flag when building or testing your program
|
||||
To enable it, set the <code>-race</code> flag when building or testing your program
|
||||
(for instance, <code>go test -race</code>).
|
||||
The race detector is documented in <a href="/doc/articles/race_detector.html">a separate article</a>.
|
||||
</p>
|
||||
@@ -304,7 +303,7 @@ The race detector is documented in <a href="/doc/articles/race_detector.html">a
|
||||
|
||||
<p>
|
||||
Due to the change of the <a href="#int"><code>int</code></a> to 64 bits and
|
||||
a new internal <a href="//golang.org/s/go11func">representation of functions</a>,
|
||||
a new internal <a href="http://golang.org/s/go11func">representation of functions</a>,
|
||||
the arrangement of function arguments on the stack has changed in the gc tool chain.
|
||||
Functions written in assembly will need to be revised at least
|
||||
to adjust frame pointer offsets.
|
||||
@@ -332,7 +331,7 @@ including a list of paths searched, when a package cannot be located.
|
||||
$ go build foo/quxx
|
||||
can't load package: package foo/quxx: cannot find package "foo/quxx" in any of:
|
||||
/home/you/go/src/pkg/foo/quxx (from $GOROOT)
|
||||
/home/you/src/foo/quxx (from $GOPATH)
|
||||
/home/you/src/foo/quxx (from $GOPATH)
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
@@ -344,12 +343,12 @@ command, a <a href="/doc/code.html#GOPATH">valid <code>$GOPATH</code></a> is now
|
||||
|
||||
<pre>
|
||||
$ GOPATH= go get code.google.com/p/foo/quxx
|
||||
package code.google.com/p/foo/quxx: cannot download, $GOPATH not set. For more details see: go help gopath
|
||||
package code.google.com/p/foo/quxx: cannot download, $GOPATH not set. For more details see: go help gopath
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Finally, as a result of the previous change, the <code>go get</code> command will also fail
|
||||
when <code>$GOPATH</code> and <code>$GOROOT</code> are set to the same value.
|
||||
when <code>$GOPATH</code> and <code>$GOROOT</code> are set to the same value.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
@@ -428,7 +427,7 @@ To build a file only with Go 1.0.x, use the converse constraint:
|
||||
|
||||
<p>
|
||||
The Go 1.1 tool chain adds experimental support for <code>freebsd/arm</code>,
|
||||
<code>netbsd/386</code>, <code>netbsd/amd64</code>, <code>netbsd/arm</code>,
|
||||
<code>netbsd/386</code>, <code>netbsd/amd64</code>, <code>netbsd/arm</code>,
|
||||
<code>openbsd/386</code> and <code>openbsd/amd64</code> platforms.
|
||||
</p>
|
||||
|
||||
@@ -547,7 +546,7 @@ The Go 1.1 implementation instead returns a
|
||||
to allow reading and writing
|
||||
with its
|
||||
<a href="/pkg/net/#UnixConn.ReadFrom"><code>ReadFrom</code></a>
|
||||
and
|
||||
and
|
||||
<a href="/pkg/net/#UnixConn.WriteTo"><code>WriteTo</code></a>
|
||||
methods.
|
||||
</p>
|
||||
@@ -666,7 +665,6 @@ This function addresses a common source of confusion in the time API.
|
||||
<em>Updating</em>:
|
||||
Code that needs to read and write times using an external format with
|
||||
lower precision should be modified to use the new methods.
|
||||
</p>
|
||||
|
||||
<h3 id="exp_old">Exp and old subtrees moved to go.exp and go.text subrepositories</h3>
|
||||
|
||||
@@ -734,7 +732,7 @@ See the relevant package documentation for more information about each change.
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<li>
|
||||
The <a href="/pkg/bytes/"><code>bytes</code></a> package has two new functions,
|
||||
<a href="/pkg/bytes/#TrimPrefix"><code>TrimPrefix</code></a>
|
||||
and
|
||||
@@ -747,7 +745,7 @@ provides some control over memory allocation inside the buffer.
|
||||
Finally, the
|
||||
<a href="/pkg/bytes/#Reader"><code>Reader</code></a> type now has a
|
||||
<a href="/pkg/strings/#Reader.WriteTo"><code>WriteTo</code></a> method
|
||||
so it implements the
|
||||
so it implements the
|
||||
<a href="/pkg/io/#WriterTo"><code>io.WriterTo</code></a> interface.
|
||||
</li>
|
||||
|
||||
@@ -774,7 +772,7 @@ and a new function
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/database/sql/"><code>database/sql</code></a> package
|
||||
has a new
|
||||
has a new
|
||||
<a href="/pkg/database/sql/#DB.Ping"><code>Ping</code></a>
|
||||
method for its
|
||||
<a href="/pkg/database/sql/#DB"><code>DB</code></a>
|
||||
@@ -924,11 +922,11 @@ The <a href="/pkg/net/"><code>net</code></a> package adds
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/net/"><code>net</code></a> package adds protocol-specific
|
||||
The <a href="/pkg/net/"><code>net</code></a> package adds protocol-specific
|
||||
packet reading and writing methods to
|
||||
<a href="/pkg/net/#IPConn"><code>IPConn</code></a>
|
||||
(<a href="/pkg/net/#IPConn.ReadMsgIP"><code>ReadMsgIP</code></a>
|
||||
and <a href="/pkg/net/#IPConn.WriteMsgIP"><code>WriteMsgIP</code></a>) and
|
||||
and <a href="/pkg/net/#IPConn.WriteMsgIP"><code>WriteMsgIP</code></a>) and
|
||||
<a href="/pkg/net/#UDPConn"><code>UDPConn</code></a>
|
||||
(<a href="/pkg/net/#UDPConn.ReadMsgUDP"><code>ReadMsgUDP</code></a> and
|
||||
<a href="/pkg/net/#UDPConn.WriteMsgUDP"><code>WriteMsgUDP</code></a>).
|
||||
@@ -936,15 +934,15 @@ These are specialized versions of <a href="/pkg/net/#PacketConn"><code>PacketCon
|
||||
<code>ReadFrom</code> and <code>WriteTo</code> methods that provide access to out-of-band data associated
|
||||
with the packets.
|
||||
</li>
|
||||
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/net/"><code>net</code></a> package adds methods to
|
||||
<a href="/pkg/net/#UnixConn"><code>UnixConn</code></a> to allow closing half of the connection
|
||||
<a href="/pkg/net/#UnixConn"><code>UnixConn</code></a> to allow closing half of the connection
|
||||
(<a href="/pkg/net/#UnixConn.CloseRead"><code>CloseRead</code></a> and
|
||||
<a href="/pkg/net/#UnixConn.CloseWrite"><code>CloseWrite</code></a>),
|
||||
matching the existing methods of <a href="/pkg/net/#TCPConn"><code>TCPConn</code></a>.
|
||||
</li>
|
||||
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/net/http/"><code>net/http</code></a> package includes several new additions.
|
||||
<a href="/pkg/net/http/#ParseTime"><code>ParseTime</code></a> parses a time string, trying
|
||||
@@ -1022,7 +1020,7 @@ including disabling it altogether.
|
||||
<li>
|
||||
The <a href="/pkg/sort/"><code>sort</code></a> package has a new function,
|
||||
<a href="/pkg/sort/#Reverse"><code>Reverse</code></a>.
|
||||
Wrapping the argument of a call to
|
||||
Wrapping the argument of a call to
|
||||
<a href="/pkg/sort/#Sort"><code>sort.Sort</code></a>
|
||||
with a call to <code>Reverse</code> causes the sort order to be reversed.
|
||||
</li>
|
||||
|
||||
979
doc/go1.2.html
979
doc/go1.2.html
@@ -1,979 +0,0 @@
|
||||
<!--{
|
||||
"Title": "Go 1.2 Release Notes",
|
||||
"Path": "/doc/go1.2",
|
||||
"Template": true
|
||||
}-->
|
||||
|
||||
<h2 id="introduction">Introduction to Go 1.2</h2>
|
||||
|
||||
<p>
|
||||
Since the release of <a href="/doc/go1.1.html">Go version 1.1</a> in April, 2013,
|
||||
the release schedule has been shortened to make the release process more efficient.
|
||||
This release, Go version 1.2 or Go 1.2 for short, arrives roughly six months after 1.1,
|
||||
while 1.1 took over a year to appear after 1.0.
|
||||
Because of the shorter time scale, 1.2 is a smaller delta than the step from 1.0 to 1.1,
|
||||
but it still has some significant developments, including
|
||||
a better scheduler and one new language feature.
|
||||
Of course, Go 1.2 keeps the <a href="/doc/go1compat.html">promise
|
||||
of compatibility</a>.
|
||||
The overwhelming majority of programs built with Go 1.1 (or 1.0 for that matter)
|
||||
will run without any changes whatsoever when moved to 1.2,
|
||||
although the introduction of one restriction
|
||||
to a corner of the language may expose already-incorrect code
|
||||
(see the discussion of the <a href="#use_of_nil">use of nil</a>).
|
||||
</p>
|
||||
|
||||
<h2 id="language">Changes to the language</h2>
|
||||
|
||||
<p>
|
||||
In the interest of firming up the specification, one corner case has been clarified,
|
||||
with consequences for programs.
|
||||
There is also one new language feature.
|
||||
</p>
|
||||
|
||||
<h3 id="use_of_nil">Use of nil</h3>
|
||||
|
||||
<p>
|
||||
The language now specifies that, for safety reasons,
|
||||
certain uses of nil pointers are guaranteed to trigger a run-time panic.
|
||||
For instance, in Go 1.0, given code like
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
type T struct {
|
||||
X [1<<24]byte
|
||||
Field int32
|
||||
}
|
||||
|
||||
func main() {
|
||||
var x *T
|
||||
...
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
the <code>nil</code> pointer <code>x</code> could be used to access memory incorrectly:
|
||||
the expression <code>x.Field</code> could access memory at address <code>1<<24</code>.
|
||||
To prevent such unsafe behavior, in Go 1.2 the compilers now guarantee that any indirection through
|
||||
a nil pointer, such as illustrated here but also in nil pointers to arrays, nil interface values,
|
||||
nil slices, and so on, will either panic or return a correct, safe non-nil value.
|
||||
In short, any expression that explicitly or implicitly requires evaluation of a nil address is an error.
|
||||
The implementation may inject extra tests into the compiled program to enforce this behavior.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Further details are in the
|
||||
<a href="//golang.org/s/go12nil">design document</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<em>Updating</em>:
|
||||
Most code that depended on the old behavior is erroneous and will fail when run.
|
||||
Such programs will need to be updated by hand.
|
||||
</p>
|
||||
|
||||
<h3 id="three_index">Three-index slices</h3>
|
||||
|
||||
<p>
|
||||
Go 1.2 adds the ability to specify the capacity as well as the length when using a slicing operation
|
||||
on an existing array or slice.
|
||||
A slicing operation creates a new slice by describing a contiguous section of an already-created array or slice:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
var array [10]int
|
||||
slice := array[2:4]
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The capacity of the slice is the maximum number of elements that the slice may hold, even after reslicing;
|
||||
it reflects the size of the underlying array.
|
||||
In this example, the capacity of the <code>slice</code> variable is 8.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Go 1.2 adds new syntax to allow a slicing operation to specify the capacity as well as the length.
|
||||
A second
|
||||
colon introduces the capacity value, which must be less than or equal to the capacity of the
|
||||
source slice or array, adjusted for the origin. For instance,
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
slice = array[2:4:7]
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
sets the slice to have the same length as in the earlier example but its capacity is now only 5 elements (7-2).
|
||||
It is impossible to use this new slice value to access the last three elements of the original array.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In this three-index notation, a missing first index (<code>[:i:j]</code>) defaults to zero but the other
|
||||
two indices must always be specified explicitly.
|
||||
It is possible that future releases of Go may introduce default values for these indices.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Further details are in the
|
||||
<a href="//golang.org/s/go12slice">design document</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<em>Updating</em>:
|
||||
This is a backwards-compatible change that affects no existing programs.
|
||||
</p>
|
||||
|
||||
<h2 id="impl">Changes to the implementations and tools</h2>
|
||||
|
||||
<h3 id="preemption">Pre-emption in the scheduler</h3>
|
||||
|
||||
<p>
|
||||
In prior releases, a goroutine that was looping forever could starve out other
|
||||
goroutines on the same thread, a serious problem when GOMAXPROCS
|
||||
provided only one user thread.
|
||||
In Go 1.2, this is partially addressed: The scheduler is invoked occasionally
|
||||
upon entry to a function.
|
||||
This means that any loop that includes a (non-inlined) function call can
|
||||
be pre-empted, allowing other goroutines to run on the same thread.
|
||||
</p>
|
||||
|
||||
<h3 id="thread_limit">Limit on the number of threads</h3>
|
||||
|
||||
<p>
|
||||
Go 1.2 introduces a configurable limit (default 10,000) to the total number of threads
|
||||
a single program may have in its address space, to avoid resource starvation
|
||||
issues in some environments.
|
||||
Note that goroutines are multiplexed onto threads so this limit does not directly
|
||||
limit the number of goroutines, only the number that may be simultaneously blocked
|
||||
in a system call.
|
||||
In practice, the limit is hard to reach.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The new <a href="/pkg/runtime/debug/#SetMaxThreads"><code>SetMaxThreads</code></a> function in the
|
||||
<a href="/pkg/runtime/debug/"><code>runtime/debug</code></a> package controls the thread count limit.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<em>Updating</em>:
|
||||
Few functions will be affected by the limit, but if a program dies because it hits the
|
||||
limit, it could be modified to call <code>SetMaxThreads</code> to set a higher count.
|
||||
Even better would be to refactor the program to need fewer threads, reducing consumption
|
||||
of kernel resources.
|
||||
</p>
|
||||
|
||||
<h3 id="stack_size">Stack size</h3>
|
||||
|
||||
<p>
|
||||
In Go 1.2, the minimum size of the stack when a goroutine is created has been lifted from 4KB to 8KB.
|
||||
Many programs were suffering performance problems with the old size, which had a tendency
|
||||
to introduce expensive stack-segment switching in performance-critical sections.
|
||||
The new number was determined by empirical testing.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
At the other end, the new function <a href="/pkg/runtime/debug/#SetMaxStack"><code>SetMaxStack</code></a>
|
||||
in the <a href="/pkg/runtime/debug"><code>runtime/debug</code></a> package controls
|
||||
the <em>maximum</em> size of a single goroutine's stack.
|
||||
The default is 1GB on 64-bit systems and 250MB on 32-bit systems.
|
||||
Before Go 1.2, it was too easy for a runaway recursion to consume all the memory on a machine.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<em>Updating</em>:
|
||||
The increased minimum stack size may cause programs with many goroutines to use
|
||||
more memory. There is no workaround, but plans for future releases
|
||||
include new stack management technology that should address the problem better.
|
||||
</p>
|
||||
|
||||
<h3 id="cgo_and_cpp">Cgo and C++</h3>
|
||||
|
||||
<p>
|
||||
The <a href="/cmd/cgo/"><code>cgo</code></a> command will now invoke the C++
|
||||
compiler to build any pieces of the linked-to library that are written in C++;
|
||||
<a href="/cmd/cgo/">the documentation</a> has more detail.
|
||||
</p>
|
||||
|
||||
<h3 id="go_tools_godoc">Godoc and vet moved to the go.tools subrepository</h3>
|
||||
|
||||
<p>
|
||||
Both binaries are still included with the distribution, but the source code for the
|
||||
godoc and vet commands has moved to the
|
||||
<a href="//code.google.com/p/go.tools">go.tools</a> subrepository.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Also, the core of the godoc program has been split into a
|
||||
<a href="https://code.google.com/p/go/source/browse/?repo=tools#hg%2Fgodoc">library</a>,
|
||||
while the command itself is in a separate
|
||||
<a href="https://code.google.com/p/go/source/browse/?repo=tools#hg%2Fcmd%2Fgodoc">directory</a>.
|
||||
The move allows the code to be updated easily and the separation into a library and command
|
||||
makes it easier to construct custom binaries for local sites and different deployment methods.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<em>Updating</em>:
|
||||
Since godoc and vet are not part of the library,
|
||||
no client Go code depends on the their source and no updating is required.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The binary distributions available from <a href="//golang.org">golang.org</a>
|
||||
include these binaries, so users of these distributions are unaffected.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
When building from source, users must use "go get" to install godoc and vet.
|
||||
(The binaries will continue to be installed in their usual locations, not
|
||||
<code>$GOPATH/bin</code>.)
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ go get code.google.com/p/go.tools/cmd/godoc
|
||||
$ go get code.google.com/p/go.tools/cmd/vet
|
||||
</pre>
|
||||
|
||||
<h3 id="gccgo">Status of gccgo</h3>
|
||||
|
||||
<p>
|
||||
We expect the future GCC 4.9 release to include gccgo with full
|
||||
support for Go 1.2.
|
||||
In the current (4.8.2) release of GCC, gccgo implements Go 1.1.2.
|
||||
</p>
|
||||
|
||||
<h3 id="gc_changes">Changes to the gc compiler and linker</h3>
|
||||
|
||||
<p>
|
||||
Go 1.2 has several semantic changes to the workings of the gc compiler suite.
|
||||
Most users will be unaffected by them.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <a href="/cmd/cgo/"><code>cgo</code></a> command now
|
||||
works when C++ is included in the library being linked against.
|
||||
See the <a href="/cmd/cgo/"><code>cgo</code></a> documentation
|
||||
for details.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The gc compiler displayed a vestigial detail of its origins when
|
||||
a program had no <code>package</code> clause: it assumed
|
||||
the file was in package <code>main</code>.
|
||||
The past has been erased, and a missing <code>package</code> clause
|
||||
is now an error.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
On the ARM, the toolchain supports "external linking", which
|
||||
is a step towards being able to build shared libraries with the gc
|
||||
tool chain and to provide dynamic linking support for environments
|
||||
in which that is necessary.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In the runtime for the ARM, with <code>5a</code>, it used to be possible to refer
|
||||
to the runtime-internal <code>m</code> (machine) and <code>g</code>
|
||||
(goroutine) variables using <code>R9</code> and <code>R10</code> directly.
|
||||
It is now necessary to refer to them by their proper names.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Also on the ARM, the <code>5l</code> linker (sic) now defines the
|
||||
<code>MOVBS</code> and <code>MOVHS</code> instructions
|
||||
as synonyms of <code>MOVB</code> and <code>MOVH</code>,
|
||||
to make clearer the separation between signed and unsigned
|
||||
sub-word moves; the unsigned versions already existed with a
|
||||
<code>U</code> suffix.
|
||||
</p>
|
||||
|
||||
<h3 id="cover">Test coverage</h3>
|
||||
|
||||
<p>
|
||||
One major new feature of <a href="/pkg/go/"><code>go test</code></a> is
|
||||
that it can now compute and, with help from a new, separately installed
|
||||
"go tool cover" program, display test coverage results.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The cover tool is part of the
|
||||
<a href="https://code.google.com/p/go/source/checkout?repo=tools"><code>go.tools</code></a>
|
||||
subrepository.
|
||||
It can be installed by running
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ go get code.google.com/p/go.tools/cmd/cover
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The cover tool does two things.
|
||||
First, when "go test" is given the <code>-cover</code> flag, it is run automatically
|
||||
to rewrite the source for the package and insert instrumentation statements.
|
||||
The test is then compiled and run as usual, and basic coverage statistics are reported:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ go test -cover fmt
|
||||
ok fmt 0.060s coverage: 91.4% of statements
|
||||
$
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Second, for more detailed reports, different flags to "go test" can create a coverage profile file,
|
||||
which the cover program, invoked with "go tool cover", can then analyze.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Details on how to generate and analyze coverage statistics can be found by running the commands
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ go help testflag
|
||||
$ go tool cover -help
|
||||
</pre>
|
||||
|
||||
<h3 id="go_doc">The go doc command is deleted</h3>
|
||||
|
||||
<p>
|
||||
The "go doc" command is deleted.
|
||||
Note that the <a href="/cmd/godoc/"><code>godoc</code></a> tool itself is not deleted,
|
||||
just the wrapping of it by the <a href="/cmd/go/"><code>go</code></a> command.
|
||||
All it did was show the documents for a package by package path,
|
||||
which godoc itself already does with more flexibility.
|
||||
It has therefore been deleted to reduce the number of documentation tools and,
|
||||
as part of the restructuring of godoc, encourage better options in future.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<em>Updating</em>: For those who still need the precise functionality of running
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ go doc
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
in a directory, the behavior is identical to running
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ godoc .
|
||||
</pre>
|
||||
|
||||
<h3 id="gocmd">Changes to the go command</h3>
|
||||
|
||||
<p>
|
||||
The <a href="/cmd/go/"><code>go get</code></a> command
|
||||
now has a <code>-t</code> flag that causes it to download the dependencies
|
||||
of the tests run by the package, not just those of the package itself.
|
||||
By default, as before, dependencies of the tests are not downloaded.
|
||||
</p>
|
||||
|
||||
<h2 id="performance">Performance</h2>
|
||||
|
||||
<p>
|
||||
There are a number of significant performance improvements in the standard library; here are a few of them.
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/compress/bzip2/"><code>compress/bzip2</code></a>
|
||||
decompresses about 30% faster.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/crypto/des/"><code>crypto/des</code></a> package
|
||||
is about five times faster.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/encoding/json/"><code>encoding/json</code></a> package
|
||||
encodes about 30% faster.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
Networking performance on Windows and BSD systems is about 30% faster through the use
|
||||
of an integrated network poller in the runtime, similar to what was done for Linux and OS X
|
||||
in Go 1.1.
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
|
||||
<h2 id="library">Changes to the standard library</h2>
|
||||
|
||||
|
||||
<h3 id="archive_tar_zip">The archive/tar and archive/zip packages</h3>
|
||||
|
||||
<p>
|
||||
The
|
||||
<a href="/pkg/archive/tar/"><code>archive/tar</code></a>
|
||||
and
|
||||
<a href="/pkg/archive/zip/"><code>archive/zip</code></a>
|
||||
packages have had a change to their semantics that may break existing programs.
|
||||
The issue is that they both provided an implementation of the
|
||||
<a href="/pkg/os/#FileInfo"><code>os.FileInfo</code></a>
|
||||
interface that was not compliant with the specification for that interface.
|
||||
In particular, their <code>Name</code> method returned the full
|
||||
path name of the entry, but the interface specification requires that
|
||||
the method return only the base name (final path element).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<em>Updating</em>: Since this behavior was newly implemented and
|
||||
a bit obscure, it is possible that no code depends on the broken behavior.
|
||||
If there are programs that do depend on it, they will need to be identified
|
||||
and fixed manually.
|
||||
</p>
|
||||
|
||||
<h3 id="encoding">The new encoding package</h3>
|
||||
|
||||
<p>
|
||||
There is a new package, <a href="/pkg/encoding/"><code>encoding</code></a>,
|
||||
that defines a set of standard encoding interfaces that may be used to
|
||||
build custom marshalers and unmarshalers for packages such as
|
||||
<a href="/pkg/encoding/xml/"><code>encoding/xml</code></a>,
|
||||
<a href="/pkg/encoding/json/"><code>encoding/json</code></a>,
|
||||
and
|
||||
<a href="/pkg/encoding/binary/"><code>encoding/binary</code></a>.
|
||||
These new interfaces have been used to tidy up some implementations in
|
||||
the standard library.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The new interfaces are called
|
||||
<a href="/pkg/encoding/#BinaryMarshaler"><code>BinaryMarshaler</code></a>,
|
||||
<a href="/pkg/encoding/#BinaryUnmarshaler"><code>BinaryUnmarshaler</code></a>,
|
||||
<a href="/pkg/encoding/#TextMarshaler"><code>TextMarshaler</code></a>,
|
||||
and
|
||||
<a href="/pkg/encoding/#TextUnmarshaler"><code>TextUnmarshaler</code></a>.
|
||||
Full details are in the <a href="/pkg/encoding/">documentation</a> for the package
|
||||
and a separate <a href="//golang.org/s/go12encoding">design document</a>.
|
||||
</p>
|
||||
|
||||
<h3 id="fmt_indexed_arguments">The fmt package</h3>
|
||||
|
||||
<p>
|
||||
The <a href="/pkg/fmt/"><code>fmt</code></a> package's formatted print
|
||||
routines such as <a href="/pkg/fmt/#Printf"><code>Printf</code></a>
|
||||
now allow the data items to be printed to be accessed in arbitrary order
|
||||
by using an indexing operation in the formatting specifications.
|
||||
Wherever an argument is to be fetched from the argument list for formatting,
|
||||
either as the value to be formatted or as a width or specification integer,
|
||||
a new optional indexing notation <code>[</code><em>n</em><code>]</code>
|
||||
fetches argument <em>n</em> instead.
|
||||
The value of <em>n</em> is 1-indexed.
|
||||
After such an indexing operating, the next argument to be fetched by normal
|
||||
processing will be <em>n</em>+1.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For example, the normal <code>Printf</code> call
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
fmt.Sprintf("%c %c %c\n", 'a', 'b', 'c')
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
would create the string <code>"a b c"</code>, but with indexing operations like this,
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
fmt.Sprintf("%[3]c %[1]c %c\n", 'a', 'b', 'c')
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
the result is "<code>"c a b"</code>. The <code>[3]</code> index accesses the third formatting
|
||||
argument, which is <code>'c'</code>, <code>[1]</code> accesses the first, <code>'a'</code>,
|
||||
and then the next fetch accesses the argument following that one, <code>'b'</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The motivation for this feature is programmable format statements to access
|
||||
the arguments in different order for localization, but it has other uses:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
log.Printf("trace: value %v of type %[1]T\n", expensiveFunction(a.b[c]))
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
<em>Updating</em>: The change to the syntax of format specifications
|
||||
is strictly backwards compatible, so it affects no working programs.
|
||||
</p>
|
||||
|
||||
<h3 id="text_template">The text/template and html/template packages</h3>
|
||||
|
||||
<p>
|
||||
The
|
||||
<a href="/pkg/text/template/"><code>text/template</code></a> package
|
||||
has a couple of changes in Go 1.2, both of which are also mirrored in the
|
||||
<a href="/pkg/html/template/"><code>html/template</code></a> package.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
First, there are new default functions for comparing basic types.
|
||||
The functions are listed in this table, which shows their names and
|
||||
the associated familiar comparison operator.
|
||||
</p>
|
||||
|
||||
<table cellpadding="0" summary="Template comparison functions">
|
||||
<tr>
|
||||
<th width="50"></th><th width="100">Name</th> <th width="50">Operator</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td><code>eq</code></td> <td><code>==</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td><code>ne</code></td> <td><code>!=</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td><code>lt</code></td> <td><code><</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td><code>le</code></td> <td><code><=</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td><code>gt</code></td> <td><code>></code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td><code>ge</code></td> <td><code>>=</code></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<p>
|
||||
These functions behave slightly differently from the corresponding Go operators.
|
||||
First, they operate only on basic types (<code>bool</code>, <code>int</code>,
|
||||
<code>float64</code>, <code>string</code>, etc.).
|
||||
(Go allows comparison of arrays and structs as well, under some circumstances.)
|
||||
Second, values can be compared as long as they are the same sort of value:
|
||||
any signed integer value can be compared to any other signed integer value for example. (Go
|
||||
does not permit comparing an <code>int8</code> and an <code>int16</code>).
|
||||
Finally, the <code>eq</code> function (only) allows comparison of the first
|
||||
argument with one or more following arguments. The template in this example,
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
{{"{{"}}if eq .A 1 2 3 {{"}}"}} equal {{"{{"}}else{{"}}"}} not equal {{"{{"}}end{{"}}"}}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
reports "equal" if <code>.A</code> is equal to <em>any</em> of 1, 2, or 3.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The second change is that a small addition to the grammar makes "if else if" chains easier to write.
|
||||
Instead of writing,
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
{{"{{"}}if eq .A 1{{"}}"}} X {{"{{"}}else{{"}}"}} {{"{{"}}if eq .A 2{{"}}"}} Y {{"{{"}}end{{"}}"}} {{"{{"}}end{{"}}"}}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
one can fold the second "if" into the "else" and have only one "end", like this:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
{{"{{"}}if eq .A 1{{"}}"}} X {{"{{"}}else if eq .A 2{{"}}"}} Y {{"{{"}}end{{"}}"}}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The two forms are identical in effect; the difference is just in the syntax.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<em>Updating</em>: Neither the "else if" change nor the comparison functions
|
||||
affect existing programs. Those that
|
||||
already define functions called <code>eq</code> and so on through a function
|
||||
map are unaffected because the associated function map will override the new
|
||||
default function definitions.
|
||||
</p>
|
||||
|
||||
<h3 id="new_packages">New packages</h3>
|
||||
|
||||
<p>
|
||||
There are two new packages.
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
The <a href="/pkg/encoding/"><code>encoding</code></a> package is
|
||||
<a href="#encoding">described above</a>.
|
||||
</li>
|
||||
<li>
|
||||
The <a href="/pkg/image/color/palette/"><code>image/color/palette</code></a> package
|
||||
provides standard color palettes.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="minor_library_changes">Minor changes to the library</h3>
|
||||
|
||||
<p>
|
||||
The following list summarizes a number of minor changes to the library, mostly additions.
|
||||
See the relevant package documentation for more information about each change.
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/archive/zip/"><code>archive/zip</code></a> package
|
||||
adds the
|
||||
<a href="/pkg/archive/zip/#File.DataOffset"><code>DataOffset</code></a> accessor
|
||||
to return the offset of a file's (possibly compressed) data within the archive.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/bufio/"><code>bufio</code></a> package
|
||||
adds <a href="/pkg/bufio/#Reader.Reset"><code>Reset</code></a>
|
||||
methods to <a href="/pkg/bufio/#Reader"><code>Reader</code></a> and
|
||||
<a href="/pkg/bufio/#Writer"><code>Writer</code></a>.
|
||||
These methods allow the <a href="/pkg/io/#Reader"><code>Readers</code></a>
|
||||
and <a href="/pkg/io/#Writer"><code>Writers</code></a>
|
||||
to be re-used on new input and output readers and writers, saving
|
||||
allocation overhead.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/compress/bzip2/"><code>compress/bzip2</code></a>
|
||||
can now decompress concatenated archives.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/compress/flate/"><code>compress/flate</code></a>
|
||||
package adds a <a href="/pkg/compress/flate/#Writer.Reset"><code>Reset</code></a>
|
||||
method on the <a href="/pkg/compress/flate/#Writer"><code>Writer</code></a>,
|
||||
to make it possible to reduce allocation when, for instance, constructing an
|
||||
archive to hold multiple compressed files.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/compress/gzip/"><code>compress/gzip</code></a> package's
|
||||
<a href="/pkg/compress/gzip/#Writer"><code>Writer</code></a> type adds a
|
||||
<a href="/pkg/compress/gzip/#Writer.Reset"><code>Reset</code></a>
|
||||
so it may be reused.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/compress/zlib/"><code>compress/zlib</code></a> package's
|
||||
<a href="/pkg/compress/zlib/#Writer"><code>Writer</code></a> type adds a
|
||||
<a href="/pkg/compress/zlib/#Writer.Reset"><code>Reset</code></a>
|
||||
so it may be reused.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/container/heap/"><code>container/heap</code></a> package
|
||||
adds a <a href="/pkg/container/heap/#Fix"><code>Fix</code></a>
|
||||
method to provide a more efficient way to update an item's position in the heap.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/container/list/"><code>container/list</code></a> package
|
||||
adds the <a href="/pkg/container/list/#List.MoveBefore"><code>MoveBefore</code></a>
|
||||
and
|
||||
<a href="/pkg/container/list/#List.MoveAfter"><code>MoveAfter</code></a>
|
||||
methods, which implement the obvious rearrangement.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/crypto/cipher/"><code>crypto/cipher</code></a> package
|
||||
adds the a new GCM mode (Galois Counter Mode), which is almost always
|
||||
used with AES encryption.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The
|
||||
<a href="/pkg/crypto/md5/"><code>crypto/md5</code></a> package
|
||||
adds a new <a href="/pkg/crypto/md5/#Sum"><code>Sum</code></a> function
|
||||
to simplify hashing without sacrificing performance.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
Similarly, the
|
||||
<a href="/pkg/crypto/md5/"><code>crypto/sha1</code></a> package
|
||||
adds a new <a href="/pkg/crypto/sha1/#Sum"><code>Sum</code></a> function.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
Also, the
|
||||
<a href="/pkg/crypto/sha256/"><code>crypto/sha256</code></a> package
|
||||
adds <a href="/pkg/crypto/sha256/#Sum256"><code>Sum256</code></a>
|
||||
and <a href="/pkg/crypto/sha256/#Sum224"><code>Sum224</code></a> functions.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
Finally, the <a href="/pkg/crypto/sha512/"><code>crypto/sha512</code></a> package
|
||||
adds <a href="/pkg/crypto/sha512/#Sum512"><code>Sum512</code></a> and
|
||||
<a href="/pkg/crypto/sha512/#Sum384"><code>Sum384</code></a> functions.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/crypto/x509/"><code>crypto/x509</code></a> package
|
||||
adds support for reading and writing arbitrary extensions.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/crypto/tls/"><code>crypto/tls</code></a> package adds
|
||||
support for TLS 1.1, 1.2 and AES-GCM.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/database/sql/"><code>database/sql</code></a> package adds a
|
||||
<a href="/pkg/database/sql/#DB.SetMaxOpenConns"><code>SetMaxOpenConns</code></a>
|
||||
method on <a href="/pkg/database/sql/#DB"><code>DB</code></a> to limit the
|
||||
number of open connections to the database.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/encoding/csv/"><code>encoding/csv</code></a> package
|
||||
now always allows trailing commas on fields.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/encoding/gob/"><code>encoding/gob</code></a> package
|
||||
now treats channel and function fields of structures as if they were unexported,
|
||||
even if they are not. That is, it ignores them completely. Previously they would
|
||||
trigger an error, which could cause unexpected compatibility problems if an
|
||||
embedded structure added such a field.
|
||||
The package also now supports the generic <code>BinaryMarshaler</code> and
|
||||
<code>BinaryUnmarshaler</code> interfaces of the
|
||||
<a href="/pkg/encoding/"><code>encoding</code></a> package
|
||||
described above.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/encoding/json/"><code>encoding/json</code></a> package
|
||||
now will always escape ampersands as "\u0026" when printing strings.
|
||||
It will now accept but correct invalid UTF-8 in
|
||||
<a href="/pkg/encoding/json/#Marshal"><code>Marshal</code></a>
|
||||
(such input was previously rejected).
|
||||
Finally, it now supports the generic encoding interfaces of the
|
||||
<a href="/pkg/encoding/"><code>encoding</code></a> package
|
||||
described above.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/encoding/xml/"><code>encoding/xml</code></a> package
|
||||
now allows attributes stored in pointers to be marshaled.
|
||||
It also supports the generic encoding interfaces of the
|
||||
<a href="/pkg/encoding/"><code>encoding</code></a> package
|
||||
described above through the new
|
||||
<a href="/pkg/encoding/xml/#Marshaler"><code>Marshaler</code></a>,
|
||||
<a href="/pkg/encoding/xml/#Unmarshaler"><code>Unmarshaler</code></a>,
|
||||
and related
|
||||
<a href="/pkg/encoding/xml/#MarshalerAttr"><code>MarshalerAttr</code></a> and
|
||||
<a href="/pkg/encoding/xml/#UnmarshalerAttr"><code>UnmarshalerAttr</code></a>
|
||||
interfaces.
|
||||
The package also adds a
|
||||
<a href="/pkg/encoding/xml/#Encoder.Flush"><code>Flush</code></a> method
|
||||
to the
|
||||
<a href="/pkg/encoding/xml/#Encoder"><code>Encoder</code></a>
|
||||
type for use by custom encoders. See the documentation for
|
||||
<a href="/pkg/encoding/xml/#Encoder.EncodeToken"><code>EncodeToken</code></a>
|
||||
to see how to use it.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/flag/"><code>flag</code></a> package now
|
||||
has a <a href="/pkg/flag/#Getter"><code>Getter</code></a> interface
|
||||
to allow the value of a flag to be retrieved. Due to the
|
||||
Go 1 compatibility guidelines, this method cannot be added to the existing
|
||||
<a href="/pkg/flag/#Value"><code>Value</code></a>
|
||||
interface, but all the existing standard flag types implement it.
|
||||
The package also now exports the <a href="/pkg/flag/#CommandLine"><code>CommandLine</code></a>
|
||||
flag set, which holds the flags from the command line.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/go/ast/"><code>go/ast</code></a> package's
|
||||
<a href="/pkg/go/ast/#SliceExpr"><code>SliceExpr</code></a> struct
|
||||
has a new boolean field, <code>Slice3</code>, which is set to true
|
||||
when representing a slice expression with three indices (two colons).
|
||||
The default is false, representing the usual two-index form.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/go/build/"><code>go/build</code></a> package adds
|
||||
the <code>AllTags</code> field
|
||||
to the <a href="/pkg/go/build/#Package"><code>Package</code></a> type,
|
||||
to make it easier to process build tags.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/image/draw/"><code>image/draw</code></a> package now
|
||||
exports an interface, <a href="/pkg/image/draw/#Drawer"><code>Drawer</code></a>,
|
||||
that wraps the standard <a href="/pkg/image/draw/#Draw"><code>Draw</code></a> method.
|
||||
The Porter-Duff operators now implement this interface, in effect binding an operation to
|
||||
the draw operator rather than providing it explicitly.
|
||||
Given a paletted image as its destination, the new
|
||||
<a href="/pkg/image/draw/#FloydSteinberg"><code>FloydSteinberg</code></a>
|
||||
implementation of the
|
||||
<a href="/pkg/image/draw/#Drawer"><code>Drawer</code></a>
|
||||
interface will use the Floyd-Steinberg error diffusion algorithm to draw the image.
|
||||
To create palettes suitable for such processing, the new
|
||||
<a href="/pkg/image/draw/#Quantizer"><code>Quantizer</code></a> interface
|
||||
represents implementations of quantization algorithms that choose a palette
|
||||
given a full-color image.
|
||||
There are no implementations of this interface in the library.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/image/gif/"><code>image/gif</code></a> package
|
||||
can now create GIF files using the new
|
||||
<a href="/pkg/image/gif/#Encode"><code>Encode</code></a>
|
||||
and <a href="/pkg/image/gif/#EncodeAll"><code>EncodeAll</code></a>
|
||||
functions.
|
||||
Their options argument allows specification of an image
|
||||
<a href="/pkg/image/draw/#Quantizer"><code>Quantizer</code></a> to use;
|
||||
if it is <code>nil</code>, the generated GIF will use the
|
||||
<a href="/pkg/image/color/palette/#Plan9"><code>Plan9</code></a>
|
||||
color map (palette) defined in the new
|
||||
<a href="/pkg/image/color/palette/"><code>image/color/palette</code></a> package.
|
||||
The options also specify a
|
||||
<a href="/pkg/image/draw/#Drawer"><code>Drawer</code></a>
|
||||
to use to create the output image;
|
||||
if it is <code>nil</code>, Floyd-Steinberg error diffusion is used.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/io/#Copy"><code>Copy</code></a> method of the
|
||||
<a href="/pkg/io/"><code>io</code></a> package now prioritizes its
|
||||
arguments differently.
|
||||
If one argument implements <a href="/pkg/io/#WriterTo"><code>WriterTo</code></a>
|
||||
and the other implements <a href="/pkg/io/#ReaderFrom"><code>ReaderFrom</code></a>,
|
||||
<a href="/pkg/io/#Copy"><code>Copy</code></a> will now invoke
|
||||
<a href="/pkg/io/#WriterTo"><code>WriterTo</code></a> to do the work,
|
||||
so that less intermediate buffering is required in general.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/net/"><code>net</code></a> package requires cgo by default
|
||||
because the host operating system must in general mediate network call setup.
|
||||
On some systems, though, it is possible to use the network without cgo, and useful
|
||||
to do so, for instance to avoid dynamic linking.
|
||||
The new build tag <code>netgo</code> (off by default) allows the construction of a
|
||||
<code>net</code> package in pure Go on those systems where it is possible.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/net/"><code>net</code></a> package adds a new field
|
||||
<code>DualStack</code> to the <a href="/pkg/net/#Dialer"><code>Dialer</code></a>
|
||||
struct for TCP connection setup using a dual IP stack as described in
|
||||
<a href="http://tools.ietf.org/html/rfc6555">RFC 6555</a>.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/net/http/"><code>net/http</code></a> package will no longer
|
||||
transmit cookies that are incorrect according to
|
||||
<a href="http://tools.ietf.org/html/rfc6265">RFC 6265</a>.
|
||||
It just logs an error and sends nothing.
|
||||
Also,
|
||||
the <a href="/pkg/net/http/"><code>net/http</code></a> package's
|
||||
<a href="/pkg/net/http/#ReadResponse"><code>ReadResponse</code></a>
|
||||
function now permits the <code>*Request</code> parameter to be <code>nil</code>,
|
||||
whereupon it assumes a GET request.
|
||||
Finally, an HTTP server will now serve HEAD
|
||||
requests transparently, without the need for special casing in handler code.
|
||||
While serving a HEAD request, writes to a
|
||||
<a href="/pkg/net/http/#Handler"><code>Handler</code></a>'s
|
||||
<a href="/pkg/net/http/#ResponseWriter"><code>ResponseWriter</code></a>
|
||||
are absorbed by the
|
||||
<a href="/pkg/net/http/#Server"><code>Server</code></a>
|
||||
and the client receives an empty body as required by the HTTP specification.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/os/exec/"><code>os/exec</code></a> package's
|
||||
<a href="/pkg/os/exec/#Cmd.StdinPipe"><code>Cmd.StdinPipe</code></a> method
|
||||
returns an <code>io.WriteCloser</code>, but has changed its concrete
|
||||
implementation from <code>*os.File</code> to an unexported type that embeds
|
||||
<code>*os.File</code>, and it is now safe to close the returned value.
|
||||
Before Go 1.2, there was an unavoidable race that this change fixes.
|
||||
Code that needs access to the methods of <code>*os.File</code> can use an
|
||||
interface type assertion, such as <code>wc.(interface{ Sync() error })</code>.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/runtime/"><code>runtime</code></a> package relaxes
|
||||
the constraints on finalizer functions in
|
||||
<a href="/pkg/runtime/#SetFinalizer"><code>SetFinalizer</code></a>: the
|
||||
actual argument can now be any type that is assignable to the formal type of
|
||||
the function, as is the case for any normal function call in Go.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/sort/"><code>sort</code></a> package has a new
|
||||
<a href="/pkg/sort/#Stable"><code>Stable</code></a> function that implements
|
||||
stable sorting. It is less efficient than the normal sort algorithm, however.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/strings/"><code>strings</code></a> package adds
|
||||
an <a href="/pkg/strings/#IndexByte"><code>IndexByte</code></a>
|
||||
function for consistency with the <a href="/pkg/bytes/"><code>bytes</code></a> package.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/sync/atomic/"><code>sync/atomic</code></a> package
|
||||
adds a new set of swap functions that atomically exchange the argument with the
|
||||
value stored in the pointer, returning the old value.
|
||||
The functions are
|
||||
<a href="/pkg/sync/atomic/#SwapInt32"><code>SwapInt32</code></a>,
|
||||
<a href="/pkg/sync/atomic/#SwapInt64"><code>SwapInt64</code></a>,
|
||||
<a href="/pkg/sync/atomic/#SwapUint32"><code>SwapUint32</code></a>,
|
||||
<a href="/pkg/sync/atomic/#SwapUint64"><code>SwapUint64</code></a>,
|
||||
<a href="/pkg/sync/atomic/#SwapUintptr"><code>SwapUintptr</code></a>,
|
||||
and
|
||||
<a href="/pkg/sync/atomic/#SwapPointer"><code>SwapPointer</code></a>,
|
||||
which swaps an <code>unsafe.Pointer</code>.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/syscall/"><code>syscall</code></a> package now implements
|
||||
<a href="/pkg/syscall/#Sendfile"><code>Sendfile</code></a> for Darwin.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/testing/"><code>testing</code></a> package
|
||||
now exports the <a href="/pkg/testing/#TB"><code>TB</code></a> interface.
|
||||
It records the methods in common with the
|
||||
<a href="/pkg/testing/#T"><code>T</code></a>
|
||||
and
|
||||
<a href="/pkg/testing/#B"><code>B</code></a> types,
|
||||
to make it easier to share code between tests and benchmarks.
|
||||
Also, the
|
||||
<a href="/pkg/testing/#AllocsPerRun"><code>AllocsPerRun</code></a>
|
||||
function now quantizes the return value to an integer (although it
|
||||
still has type <code>float64</code>), to round off any error caused by
|
||||
initialization and make the result more repeatable.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/text/template/"><code>text/template</code></a> package
|
||||
now automatically dereferences pointer values when evaluating the arguments
|
||||
to "escape" functions such as "html", to bring the behavior of such functions
|
||||
in agreement with that of other printing functions such as "printf".
|
||||
</li>
|
||||
|
||||
<li>
|
||||
In the <a href="/pkg/time/"><code>time</code></a> package, the
|
||||
<a href="/pkg/time/#Parse"><code>Parse</code></a> function
|
||||
and
|
||||
<a href="/pkg/time/#Time.Format"><code>Format</code></a>
|
||||
method
|
||||
now handle time zone offsets with seconds, such as in the historical
|
||||
date "1871-01-01T05:33:02+00:34:08".
|
||||
Also, pattern matching in the formats for those routines is stricter: a non-lowercase letter
|
||||
must now follow the standard words such as "Jan" and "Mon".
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/unicode/"><code>unicode</code></a> package
|
||||
adds <a href="/pkg/unicode/#In"><code>In</code></a>,
|
||||
a nicer-to-use but equivalent version of the original
|
||||
<a href="/pkg/unicode/#IsOneOf"><code>IsOneOf</code></a>,
|
||||
to see whether a character is a member of a Unicode category.
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
608
doc/go1.3.html
608
doc/go1.3.html
@@ -1,608 +0,0 @@
|
||||
<!--{
|
||||
"Title": "Go 1.3 Release Notes",
|
||||
"Path": "/doc/go1.3",
|
||||
"Template": true
|
||||
}-->
|
||||
|
||||
<h2 id="introduction">Introduction to Go 1.3</h2>
|
||||
|
||||
<p>
|
||||
The latest Go release, version 1.3, arrives six months after 1.2,
|
||||
and contains no language changes.
|
||||
It focuses primarily on implementation work, providing
|
||||
precise garbage collection,
|
||||
a major refactoring of the compiler tool chain that results in
|
||||
faster builds, especially for large projects,
|
||||
significant performance improvements across the board,
|
||||
and support for DragonFly BSD, Solaris, Plan 9 and Google's Native Client architecture (NaCl).
|
||||
It also has an important refinement to the memory model regarding synchronization.
|
||||
As always, Go 1.3 keeps the <a href="/doc/go1compat.html">promise
|
||||
of compatibility</a>,
|
||||
and almost everything
|
||||
will continue to compile and run without change when moved to 1.3.
|
||||
</p>
|
||||
|
||||
<h2 id="os">Changes to the supported operating systems and architectures</h2>
|
||||
|
||||
<h3 id="win2000">Removal of support for Windows 2000</h3>
|
||||
|
||||
<p>
|
||||
Microsoft stopped supporting Windows 2000 in 2010.
|
||||
Since it has <a href="https://codereview.appspot.com/74790043">implementation difficulties</a>
|
||||
regarding exception handling (signals in Unix terminology),
|
||||
as of Go 1.3 it is not supported by Go either.
|
||||
</p>
|
||||
|
||||
<h3 id="dragonfly">Support for DragonFly BSD</h3>
|
||||
|
||||
<p>
|
||||
Go 1.3 now includes experimental support for DragonFly BSD on the <code>amd64</code> (64-bit x86) and <code>386</code> (32-bit x86) architectures.
|
||||
It uses DragonFly BSD 3.6 or above.
|
||||
</p>
|
||||
|
||||
<h3 id="freebsd">Support for FreeBSD</h3>
|
||||
|
||||
<p>
|
||||
It was not announced at the time, but since the release of Go 1.2, support for Go on FreeBSD
|
||||
requires FreeBSD 8 or above.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
As of Go 1.3, support for Go on FreeBSD requires that the kernel be compiled with the
|
||||
<code>COMPAT_FREEBSD32</code> flag configured.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In concert with the switch to EABI syscalls for ARM platforms, Go 1.3 will run only on FreeBSD 10.
|
||||
The x86 platforms, 386 and amd64, are unaffected.
|
||||
</p>
|
||||
|
||||
<h3 id="nacl">Support for Native Client</h3>
|
||||
|
||||
<p>
|
||||
Support for the Native Client virtual machine architecture has returned to Go with the 1.3 release.
|
||||
It runs on the 32-bit Intel architectures (<code>GOARCH=386</code>) and also on 64-bit Intel, but using
|
||||
32-bit pointers (<code>GOARCH=amd64p32</code>).
|
||||
There is not yet support for Native Client on ARM.
|
||||
Note that this is Native Client (NaCl), not Portable Native Client (PNaCl).
|
||||
Details about Native Client are <a href="https://developers.google.com/native-client/dev/">here</a>;
|
||||
how to set up the Go version is described <a href="//golang.org/wiki/NativeClient">here</a>.
|
||||
</p>
|
||||
|
||||
<h3 id="netbsd">Support for NetBSD</h3>
|
||||
|
||||
<p>
|
||||
As of Go 1.3, support for Go on NetBSD requires NetBSD 6.0 or above.
|
||||
</p>
|
||||
|
||||
<h3 id="openbsd">Support for OpenBSD</h3>
|
||||
|
||||
<p>
|
||||
As of Go 1.3, support for Go on OpenBSD requires OpenBSD 5.5 or above.
|
||||
</p>
|
||||
|
||||
<h3 id="plan9">Support for Plan 9</h3>
|
||||
|
||||
<p>
|
||||
Go 1.3 now includes experimental support for Plan 9 on the <code>386</code> (32-bit x86) architecture.
|
||||
It requires the <code>Tsemacquire</code> syscall, which has been in Plan 9 since June, 2012.
|
||||
</p>
|
||||
|
||||
<h3 id="solaris">Support for Solaris</h3>
|
||||
|
||||
<p>
|
||||
Go 1.3 now includes experimental support for Solaris on the <code>amd64</code> (64-bit x86) architecture.
|
||||
It requires illumos, Solaris 11 or above.
|
||||
</p>
|
||||
|
||||
<h2 id="memory">Changes to the memory model</h2>
|
||||
|
||||
<p>
|
||||
The Go 1.3 memory model <a href="https://codereview.appspot.com/75130045">adds a new rule</a>
|
||||
concerning sending and receiving on buffered channels,
|
||||
to make explicit that a buffered channel can be used as a simple
|
||||
semaphore, using a send into the
|
||||
channel to acquire and a receive from the channel to release.
|
||||
This is not a language change, just a clarification about an expected property of communication.
|
||||
</p>
|
||||
|
||||
<h2 id="impl">Changes to the implementations and tools</h2>
|
||||
|
||||
<h3 id="stacks">Stack</h3>
|
||||
|
||||
<p>
|
||||
Go 1.3 has changed the implementation of goroutine stacks away from the old,
|
||||
"segmented" model to a contiguous model.
|
||||
When a goroutine needs more stack
|
||||
than is available, its stack is transferred to a larger single block of memory.
|
||||
The overhead of this transfer operation amortizes well and eliminates the old "hot spot"
|
||||
problem when a calculation repeatedly steps across a segment boundary.
|
||||
Details including performance numbers are in this
|
||||
<a href="//golang.org/s/contigstacks">design document</a>.
|
||||
</p>
|
||||
|
||||
<h3 id="garbage_collector">Changes to the garbage collector</h3>
|
||||
|
||||
<p>
|
||||
For a while now, the garbage collector has been <em>precise</em> when examining
|
||||
values in the heap; the Go 1.3 release adds equivalent precision to values on the stack.
|
||||
This means that a non-pointer Go value such as an integer will never be mistaken for a
|
||||
pointer and prevent unused memory from being reclaimed.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Starting with Go 1.3, the runtime assumes that values with pointer type
|
||||
contain pointers and other values do not.
|
||||
This assumption is fundamental to the precise behavior of both stack expansion
|
||||
and garbage collection.
|
||||
Programs that use <a href="/pkg/unsafe/">package unsafe</a>
|
||||
to store integers in pointer-typed values are illegal and will crash if the runtime detects the behavior.
|
||||
Programs that use <a href="/pkg/unsafe/">package unsafe</a> to store pointers
|
||||
in integer-typed values are also illegal but more difficult to diagnose during execution.
|
||||
Because the pointers are hidden from the runtime, a stack expansion or garbage collection
|
||||
may reclaim the memory they point at, creating
|
||||
<a href="//en.wikipedia.org/wiki/Dangling_pointer">dangling pointers</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<em>Updating</em>: Code that uses <code>unsafe.Pointer</code> to convert
|
||||
an integer-typed value held in memory into a pointer is illegal and must be rewritten.
|
||||
Such code can be identified by <code>go vet</code>.
|
||||
</p>
|
||||
|
||||
<h3 id="map">Map iteration</h3>
|
||||
|
||||
<p>
|
||||
Iterations over small maps no longer happen in a consistent order.
|
||||
Go 1 defines that “<a href="//golang.org/ref/spec#For_statements">The iteration order over maps
|
||||
is not specified and is not guaranteed to be the same from one iteration to the next.</a>”
|
||||
To keep code from depending on map iteration order,
|
||||
Go 1.0 started each map iteration at a random index in the map.
|
||||
A new map implementation introduced in Go 1.1 neglected to randomize
|
||||
iteration for maps with eight or fewer entries, although the iteration order
|
||||
can still vary from system to system.
|
||||
This has allowed people to write Go 1.1 and Go 1.2 programs that
|
||||
depend on small map iteration order and therefore only work reliably on certain systems.
|
||||
Go 1.3 reintroduces random iteration for small maps in order to flush out these bugs.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<em>Updating</em>: If code assumes a fixed iteration order for small maps,
|
||||
it will break and must be rewritten not to make that assumption.
|
||||
Because only small maps are affected, the problem arises most often in tests.
|
||||
</p>
|
||||
|
||||
<h3 id="liblink">The linker</h3>
|
||||
|
||||
<p>
|
||||
As part of the general <a href="//golang.org/s/go13linker">overhaul</a> to
|
||||
the Go linker, the compilers and linkers have been refactored.
|
||||
The linker is still a C program, but now the instruction selection phase that
|
||||
was part of the linker has been moved to the compiler through the creation of a new
|
||||
library called <code>liblink</code>.
|
||||
By doing instruction selection only once, when the package is first compiled,
|
||||
this can speed up compilation of large projects significantly.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<em>Updating</em>: Although this is a major internal change, it should have no
|
||||
effect on programs.
|
||||
</p>
|
||||
|
||||
<h3 id="gccgo">Status of gccgo</h3>
|
||||
|
||||
<p>
|
||||
GCC release 4.9 will contain the Go 1.2 (not 1.3) version of gccgo.
|
||||
The release schedules for the GCC and Go projects do not coincide,
|
||||
which means that 1.3 will be available in the development branch but
|
||||
that the next GCC release, 4.10, will likely have the Go 1.4 version of gccgo.
|
||||
</p>
|
||||
|
||||
<h3 id="gocmd">Changes to the go command</h3>
|
||||
|
||||
<p>
|
||||
The <a href="/cmd/go/"><code>cmd/go</code></a> command has several new
|
||||
features.
|
||||
The <a href="/cmd/go/"><code>go run</code></a> and
|
||||
<a href="/cmd/go/"><code>go test</code></a> subcommands
|
||||
support a new <code>-exec</code> option to specify an alternate
|
||||
way to run the resulting binary.
|
||||
Its immediate purpose is to support NaCl.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The test coverage support of the <a href="/cmd/go/"><code>go test</code></a>
|
||||
subcommand now automatically sets the coverage mode to <code>-atomic</code>
|
||||
when the race detector is enabled, to eliminate false reports about unsafe
|
||||
access to coverage counters.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <a href="/cmd/go/"><code>go test</code></a> subcommand
|
||||
now always builds the package, even if it has no test files.
|
||||
Previously, it would do nothing if no test files were present.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <a href="/cmd/go/"><code>go build</code></a> subcommand
|
||||
supports a new <code>-i</code> option to install dependencies
|
||||
of the specified target, but not the target itself.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Cross compiling with <a href="/cmd/cgo/"><code>cgo</code></a> enabled
|
||||
is now supported.
|
||||
The CC_FOR_TARGET and CXX_FOR_TARGET environment
|
||||
variables are used when running all.bash to specify the cross compilers
|
||||
for C and C++ code, respectively.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Finally, the go command now supports packages that import Objective-C
|
||||
files (suffixed <code>.m</code>) through cgo.
|
||||
</p>
|
||||
|
||||
<h3 id="cgo">Changes to cgo</h3>
|
||||
|
||||
<p>
|
||||
The <a href="/cmd/cgo/"><code>cmd/cgo</code></a> command,
|
||||
which processes <code>import "C"</code> declarations in Go packages,
|
||||
has corrected a serious bug that may cause some packages to stop compiling.
|
||||
Previously, all pointers to incomplete struct types translated to the Go type <code>*[0]byte</code>,
|
||||
with the effect that the Go compiler could not diagnose passing one kind of struct pointer
|
||||
to a function expecting another.
|
||||
Go 1.3 corrects this mistake by translating each different
|
||||
incomplete struct to a different named type.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Given the C declaration <code>typedef struct S T</code> for an incomplete <code>struct S</code>,
|
||||
some Go code used this bug to refer to the types <code>C.struct_S</code> and <code>C.T</code> interchangeably.
|
||||
Cgo now explicitly allows this use, even for completed struct types.
|
||||
However, some Go code also used this bug to pass (for example) a <code>*C.FILE</code>
|
||||
from one package to another.
|
||||
This is not legal and no longer works: in general Go packages
|
||||
should avoid exposing C types and names in their APIs.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<em>Updating</em>: Code confusing pointers to incomplete types or
|
||||
passing them across package boundaries will no longer compile
|
||||
and must be rewritten.
|
||||
If the conversion is correct and must be preserved,
|
||||
use an explicit conversion via <a href="/pkg/unsafe/#Pointer"><code>unsafe.Pointer</code></a>.
|
||||
</p>
|
||||
|
||||
<h3 id="swig">SWIG 3.0 required for programs that use SWIG</h3>
|
||||
|
||||
<p>
|
||||
For Go programs that use SWIG, SWIG version 3.0 is now required.
|
||||
The <a href="/cmd/go"><code>cmd/go</code></a> command will now link the
|
||||
SWIG generated object files directly into the binary, rather than
|
||||
building and linking with a shared library.
|
||||
</p>
|
||||
|
||||
<h3 id="gc_flag">Command-line flag parsing</h3>
|
||||
|
||||
<p>
|
||||
In the gc tool chain, the assemblers now use the
|
||||
same command-line flag parsing rules as the Go flag package, a departure
|
||||
from the traditional Unix flag parsing.
|
||||
This may affect scripts that invoke the tool directly.
|
||||
For example,
|
||||
<code>go tool 6a -SDfoo</code> must now be written
|
||||
<code>go tool 6a -S -D foo</code>.
|
||||
(The same change was made to the compilers and linkers in <a href="/doc/go1.1#gc_flag">Go 1.1</a>.)
|
||||
</p>
|
||||
|
||||
<h3 id="godoc">Changes to godoc</h3>
|
||||
<p>
|
||||
When invoked with the <code>-analysis</code> flag,
|
||||
<a href="//godoc.org/code.google.com/p/go.tools/cmd/godoc">godoc</a>
|
||||
now performs sophisticated <a href="/lib/godoc/analysis/help.html">static
|
||||
analysis</a> of the code it indexes.
|
||||
The results of analysis are presented in both the source view and the
|
||||
package documentation view, and include the call graph of each package
|
||||
and the relationships between
|
||||
definitions and references,
|
||||
types and their methods,
|
||||
interfaces and their implementations,
|
||||
send and receive operations on channels,
|
||||
functions and their callers, and
|
||||
call sites and their callees.
|
||||
</p>
|
||||
|
||||
<h3 id="misc">Miscellany</h3>
|
||||
|
||||
<p>
|
||||
The program <code>misc/benchcmp</code> that compares
|
||||
performance across benchmarking runs has been rewritten.
|
||||
Once a shell and awk script in the main repository, it is now a Go program in the <code>go.tools</code> repo.
|
||||
Documentation is <a href="//godoc.org/code.google.com/p/go.tools/cmd/benchcmp">here</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For the few of us that build Go distributions, the tool <code>misc/dist</code> has been
|
||||
moved and renamed; it now lives in <code>misc/makerelease</code>, still in the main repository.
|
||||
</p>
|
||||
|
||||
<h2 id="performance">Performance</h2>
|
||||
|
||||
<p>
|
||||
The performance of Go binaries for this release has improved in many cases due to changes
|
||||
in the runtime and garbage collection, plus some changes to libraries.
|
||||
Significant instances include:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
|
||||
<li>
|
||||
The runtime handles defers more efficiently, reducing the memory footprint by about two kilobytes
|
||||
per goroutine that calls defer.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The garbage collector has been sped up, using a concurrent sweep algorithm,
|
||||
better parallelization, and larger pages.
|
||||
The cumulative effect can be a 50-70% reduction in collector pause time.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The race detector (see <a href="/doc/articles/race_detector.html">this guide</a>)
|
||||
is now about 40% faster.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The regular expression package <a href="/pkg/regexp/"><code>regexp</code></a>
|
||||
is now significantly faster for certain simple expressions due to the implementation of
|
||||
a second, one-pass execution engine.
|
||||
The choice of which engine to use is automatic;
|
||||
the details are hidden from the user.
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Also, the runtime now includes in stack dumps how long a goroutine has been blocked,
|
||||
which can be useful information when debugging deadlocks or performance issues.
|
||||
</p>
|
||||
|
||||
<h2 id="library">Changes to the standard library</h2>
|
||||
|
||||
<h3 id="new_packages">New packages</h3>
|
||||
|
||||
<p>
|
||||
A new package <a href="/pkg/debug/plan9obj/"><code>debug/plan9obj</code></a> was added to the standard library.
|
||||
It implements access to Plan 9 <a href="http://plan9.bell-labs.com/magic/man2html/6/a.out">a.out</a> object files.
|
||||
</p>
|
||||
|
||||
<h3 id="major_library_changes">Major changes to the library</h3>
|
||||
|
||||
<p>
|
||||
A previous bug in <a href="/pkg/crypto/tls/"><code>crypto/tls</code></a>
|
||||
made it possible to skip verification in TLS inadvertently.
|
||||
In Go 1.3, the bug is fixed: one must specify either ServerName or
|
||||
InsecureSkipVerify, and if ServerName is specified it is enforced.
|
||||
This may break existing code that incorrectly depended on insecure
|
||||
behavior.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
There is an important new type added to the standard library: <a href="/pkg/sync/#Pool"><code>sync.Pool</code></a>.
|
||||
It provides an efficient mechanism for implementing certain types of caches whose memory
|
||||
can be reclaimed automatically by the system.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <a href="/pkg/testing/"><code>testing</code></a> package's benchmarking helper,
|
||||
<a href="/pkg/testing/#B"><code>B</code></a>, now has a
|
||||
<a href="/pkg/testing/#B.RunParallel"><code>RunParallel</code></a> method
|
||||
to make it easier to run benchmarks that exercise multiple CPUs.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<em>Updating</em>: The crypto/tls fix may break existing code, but such
|
||||
code was erroneous and should be updated.
|
||||
</p>
|
||||
|
||||
<h3 id="minor_library_changes">Minor changes to the library</h3>
|
||||
|
||||
<p>
|
||||
The following list summarizes a number of minor changes to the library, mostly additions.
|
||||
See the relevant package documentation for more information about each change.
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
|
||||
<li> In the <a href="/pkg/crypto/tls/"><code>crypto/tls</code></a> package,
|
||||
a new <a href="/pkg/crypto/tls/#DialWithDialer"><code>DialWithDialer</code></a>
|
||||
function lets one establish a TLS connection using an existing dialer, making it easier
|
||||
to control dial options such as timeouts.
|
||||
The package also now reports the TLS version used by the connection in the
|
||||
<a href="/pkg/crypto/tls/#ConnectionState"><code>ConnectionState</code></a>
|
||||
struct.
|
||||
</li>
|
||||
|
||||
<li> The <a href="/pkg/crypto/x509/#CreateCertificate"><code>CreateCertificate</code></a>
|
||||
function of the <a href="/pkg/crypto/tls/"><code>crypto/tls</code></a> package
|
||||
now supports parsing (and elsewhere, serialization) of PKCS #10 certificate
|
||||
signature requests.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The formatted print functions of the <code>fmt</code> package now define <code>%F</code>
|
||||
as a synonym for <code>%f</code> when printing floating-point values.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/math/big/"><code>math/big</code></a> package's
|
||||
<a href="/pkg/math/big/#Int"><code>Int</code></a> and
|
||||
<a href="/pkg/math/big/#Rat"><code>Rat</code></a> types
|
||||
now implement
|
||||
<a href="/pkg/encoding/#TextMarshaler"><code>encoding.TextMarshaler</code></a> and
|
||||
<a href="/pkg/encoding/#TextUnmarshaler"><code>encoding.TextUnmarshaler</code></a>.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The complex power function, <a href="/pkg/math/cmplx/#Pow"><code>Pow</code></a>,
|
||||
now specifies the behavior when the first argument is zero.
|
||||
It was undefined before.
|
||||
The details are in the <a href="/pkg/math/cmplx/#Pow">documentation for the function</a>.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/net/http/"><code>net/http</code></a> package now exposes the
|
||||
properties of a TLS connection used to make a client request in the new
|
||||
<a href="/pkg/net/http/#Response"><code>Response.TLS</code></a> field.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/net/http/"><code>net/http</code></a> package now
|
||||
allows setting an optional server error logger
|
||||
with <a href="/pkg/net/http/#Server"><code>Server.ErrorLog</code></a>.
|
||||
The default is still that all errors go to stderr.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/net/http/"><code>net/http</code></a> package now
|
||||
supports disabling HTTP keep-alive connections on the server
|
||||
with <a href="/pkg/net/http/#Server.SetKeepAlivesEnabled"><code>Server.SetKeepAlivesEnabled</code></a>.
|
||||
The default continues to be that the server does keep-alive (reuses
|
||||
connections for multiple requests) by default.
|
||||
Only resource-constrained servers or those in the process of graceful
|
||||
shutdown will want to disable them.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/net/http/"><code>net/http</code></a> package adds an optional
|
||||
<a href="/pkg/net/http/#Transport"><code>Transport.TLSHandshakeTimeout</code></a>
|
||||
setting to cap the amount of time HTTP client requests will wait for
|
||||
TLS handshakes to complete.
|
||||
It's now also set by default
|
||||
on <a href="/pkg/net/http#DefaultTransport"><code>DefaultTransport</code></a>.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/net/http/"><code>net/http</code></a> package's
|
||||
<a href="/pkg/net/http/#DefaultTransport"><code>DefaultTransport</code></a>,
|
||||
used by the HTTP client code, now
|
||||
enables <a href="http://en.wikipedia.org/wiki/Keepalive#TCP_keepalive">TCP
|
||||
keep-alives</a> by default.
|
||||
Other <a href="/pkg/net/http/#Transport"><code>Transport</code></a>
|
||||
values with a nil <code>Dial</code> field continue to function the same
|
||||
as before: no TCP keep-alives are used.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/net/http/"><code>net/http</code></a> package
|
||||
now enables <a href="http://en.wikipedia.org/wiki/Keepalive#TCP_keepalive">TCP
|
||||
keep-alives</a> for incoming server requests when
|
||||
<a href="/pkg/net/http/#ListenAndServe"><code>ListenAndServe</code></a>
|
||||
or
|
||||
<a href="/pkg/net/http/#ListenAndServeTLS"><code>ListenAndServeTLS</code></a>
|
||||
are used.
|
||||
When a server is started otherwise, TCP keep-alives are not enabled.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/net/http/"><code>net/http</code></a> package now
|
||||
provides an
|
||||
optional <a href="/pkg/net/http/#Server"><code>Server.ConnState</code></a>
|
||||
callback to hook various phases of a server connection's lifecycle
|
||||
(see <a href="/pkg/net/http/#ConnState"><code>ConnState</code></a>).
|
||||
This can be used to implement rate limiting or graceful shutdown.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/net/http/"><code>net/http</code></a> package's HTTP
|
||||
client now has an
|
||||
optional <a href="/pkg/net/http/#Client"><code>Client.Timeout</code></a>
|
||||
field to specify an end-to-end timeout on requests made using the
|
||||
client.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/net/http/"><code>net/http</code></a> package's
|
||||
<a href="/pkg/net/http/#Request.ParseMultipartForm"><code>Request.ParseMultipartForm</code></a>
|
||||
method will now return an error if the body's <code>Content-Type</code>
|
||||
is not <code>mutipart/form-data</code>.
|
||||
Prior to Go 1.3 it would silently fail and return <code>nil</code>.
|
||||
Code that relies on the previous behavior should be updated.
|
||||
</li>
|
||||
|
||||
<li> In the <a href="/pkg/net/"><code>net</code></a> package,
|
||||
the <a href="/pkg/net/#Dialer"><code>Dialer</code></a> struct now
|
||||
has a <code>KeepAlive</code> option to specify a keep-alive period for the connection.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/net/http/"><code>net/http</code></a> package's
|
||||
<a href="/pkg/net/http/#Transport"><code>Transport</code></a>
|
||||
now closes <a href="/pkg/net/http/#Request"><code>Request.Body</code></a>
|
||||
consistently, even on error.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/os/exec/"><code>os/exec</code></a> package now implements
|
||||
what the documentation has always said with regard to relative paths for the binary.
|
||||
In particular, it only calls <a href="/pkg/os/exec/#LookPath"><code>LookPath</code></a>
|
||||
when the binary's file name contains no path separators.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/reflect/#Value.SetMapIndex"><code>SetMapIndex</code></a>
|
||||
function in the <a href="/pkg/reflect/"><code>reflect</code></a> package
|
||||
no longer panics when deleting from a <code>nil</code> map.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
If the main goroutine calls
|
||||
<a href="/pkg/runtime/#Goexit"><code>runtime.Goexit</code></a>
|
||||
and all other goroutines finish execution, the program now always crashes,
|
||||
reporting a detected deadlock.
|
||||
Earlier versions of Go handled this situation inconsistently: most instances
|
||||
were reported as deadlocks, but some trivial cases exited cleanly instead.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The runtime/debug package now has a new function
|
||||
<a href="/pkg/runtime/debug/#WriteHeapDump"><code>debug.WriteHeapDump</code></a>
|
||||
that writes out a description of the heap.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/strconv/#CanBackquote"><code>CanBackquote</code></a>
|
||||
function in the <a href="/pkg/strconv/"><code>strconv</code></a> package
|
||||
now considers the <code>DEL</code> character, <code>U+007F</code>, to be
|
||||
non-printing.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/syscall/"><code>syscall</code></a> package now provides
|
||||
<a href="/pkg/syscall/#SendmsgN"><code>SendmsgN</code></a>
|
||||
as an alternate version of
|
||||
<a href="/pkg/syscall/#Sendmsg"><code>Sendmsg</code></a>
|
||||
that returns the number of bytes written.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
On Windows, the <a href="/pkg/syscall/"><code>syscall</code></a> package now
|
||||
supports the cdecl calling convention through the addition of a new function
|
||||
<a href="/pkg/syscall/#NewCallbackCDecl"><code>NewCallbackCDecl</code></a>
|
||||
alongside the existing function
|
||||
<a href="/pkg/syscall/#NewCallback"><code>NewCallback</code></a>.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/testing/"><code>testing</code></a> package now
|
||||
diagnoses tests that call <code>panic(nil)</code>, which are almost always erroneous.
|
||||
Also, tests now write profiles (if invoked with profiling flags) even on failure.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/unicode/"><code>unicode</code></a> package and associated
|
||||
support throughout the system has been upgraded from
|
||||
Unicode 6.2.0 to <a href="http://www.unicode.org/versions/Unicode6.3.0/">Unicode 6.3.0</a>.
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
818
doc/go1.4.html
818
doc/go1.4.html
@@ -1,818 +0,0 @@
|
||||
<!--{
|
||||
"Title": "Go 1.4 Release Notes",
|
||||
"Path": "/doc/go1.4",
|
||||
"Template": true
|
||||
}-->
|
||||
|
||||
<h2 id="introduction">Introduction to Go 1.4</h2>
|
||||
|
||||
<p>
|
||||
The latest Go release, version 1.4, arrives as scheduled six months after 1.3
|
||||
and contains only one tiny language change,
|
||||
a possibly breaking change to the compiler,
|
||||
a backwards-compatible simple form of <code>for</code>-<code>range</code> loop.
|
||||
The release focuses primarily on implementation work, improving the garbage collector
|
||||
and preparing the ground for a fully concurrent collector to be rolled out in the
|
||||
next few releases.
|
||||
Stacks are now contiguous, reallocated when necessary rather than linking on new
|
||||
"segments";
|
||||
this release therefore eliminates the notorious "hot stack split" problem.
|
||||
There are some new tools available including support in the <code>go</code> command
|
||||
for build-time source code generation.
|
||||
The release also adds support for ARM processors on Android and Native Client (NaCl)
|
||||
and AMD64 on Plan 9.
|
||||
As always, Go 1.4 keeps the <a href="/doc/go1compat.html">promise
|
||||
of compatibility</a>,
|
||||
and almost everything
|
||||
will continue to compile and run without change when moved to 1.4.
|
||||
</p>
|
||||
|
||||
<h2 id="language">Changes to the language</h2>
|
||||
|
||||
<h3 id="forrange">For-range loops</h3>
|
||||
<p>
|
||||
Up until Go 1.3, <code>for</code>-<code>range</code> loop had two forms
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
for k, v := range x {
|
||||
...
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
and
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
for k := range x {
|
||||
...
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
If one was not interested in the loop values, only the iteration itself, it was still
|
||||
necessary to mention a variable (probably the <a href="/ref/spec#Blank_identifier">blank identifier</a>, as in
|
||||
<code>for</code> <code>_</code> <code>=</code> <code>range</code> <code>x</code>), because
|
||||
the form
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
for range x {
|
||||
...
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
was not syntactically permitted.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
This situation seemed awkward, so as of Go 1.4 the variable-free form is now legal.
|
||||
The pattern arises rarely but the code can be cleaner when it does.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<em>Updating</em>: The change is strictly backwards compatible to existing Go
|
||||
programs, but tools that analyze Go parse trees may need to be modified to accept
|
||||
this new form as the
|
||||
<code>Key</code> field of <a href="/pkg/go/ast/#RangeStmt"><code>RangeStmt</code></a>
|
||||
may now be <code>nil</code>.
|
||||
</p>
|
||||
|
||||
<h3 id="methodonpointertopointer">Method calls on **T</h3>
|
||||
|
||||
<p>
|
||||
Given these declarations,
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
type T int
|
||||
func (T) M() {}
|
||||
var x **T
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
both <code>gc</code> and <code>gccgo</code> accepted the method call
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
x.M()
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
which is a double dereference of the pointer-to-pointer <code>x</code>.
|
||||
The Go specification allows a single dereference to be inserted automatically,
|
||||
but not two, so this call is erroneous according to the language definition.
|
||||
It has therefore been disallowed in Go 1.4, which is a breaking change,
|
||||
although very few programs will be affected.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<em>Updating</em>: Code that depends on the old, erroneous behavior will no longer
|
||||
compile but is easy to fix by adding an explicit dereference.
|
||||
</p>
|
||||
|
||||
<h2 id="os">Changes to the supported operating systems and architectures</h2>
|
||||
|
||||
<h3 id="android">Android</h3>
|
||||
|
||||
<p>
|
||||
Go 1.4 can build binaries for ARM processors running the Android operating system.
|
||||
It can also build a <code>.so</code> library that can be loaded by an Android application
|
||||
using the supporting packages in the <a href="http://code.google.com/p/go.mobile">go.mobile</a> repository.
|
||||
A brief description of the plans for this experimental port are available
|
||||
<a href="/s/go14android">here</a>.
|
||||
</p>
|
||||
|
||||
<h3 id="naclarm">NaCl on ARM</h3>
|
||||
|
||||
<p>
|
||||
The previous release introduced Native Client (NaCl) support for the 32-bit x86
|
||||
(<code>GOARCH=386</code>)
|
||||
and 64-bit x86 using 32-bit pointers (GOARCH=amd64p32).
|
||||
The 1.4 release adds NaCl support for ARM (GOARCH=arm).
|
||||
</p>
|
||||
|
||||
<h3 id="plan9amd64">Plan9 on AMD64</h3>
|
||||
|
||||
<p>
|
||||
This release adds support for the Plan 9 operating system on AMD64 processors,
|
||||
provided the kernel supports the <code>nsec</code> system call and uses 4K pages.
|
||||
</p>
|
||||
|
||||
<h2 id="compatibility">Changes to the compatibility guidelines</h2>
|
||||
|
||||
<p>
|
||||
The <a href="/pkg/unsafe/"><code>unsafe</code></a> package allows one
|
||||
to defeat Go's type system by exploiting internal details of the implementation
|
||||
or machine representation of data.
|
||||
It was never explicitly specified what use of <code>unsafe</code> meant
|
||||
with respect to compatibility as specified in the
|
||||
<a href="go1compat.html">Go compatibility guidelines</a>.
|
||||
The answer, of course, is that we can make no promise of compatibility
|
||||
for code that does unsafe things.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
We have clarified this situation in the documentation included in the release.
|
||||
The <a href="go1compat.html">Go compatibility guidelines</a> and the
|
||||
docs for the <a href="/pkg/unsafe/"><code>unsafe</code></a> package
|
||||
are now explicit that unsafe code is not guaranteed to remain compatible.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<em>Updating</em>: Nothing technical has changed; this is just a clarification
|
||||
of the documentation.
|
||||
</p>
|
||||
|
||||
|
||||
<h2 id="impl">Changes to the implementations and tools</h2>
|
||||
|
||||
<h3 id="runtime">Changes to the runtime</h3>
|
||||
|
||||
<p>
|
||||
Up to Go 1.4, the runtime (garbage collector, concurrency support, interface management,
|
||||
maps, slices, strings, ...) was mostly written in C, with some assembler support.
|
||||
In 1.4, much of the code has been translated to Go so that the garbage collector can scan
|
||||
the stacks of programs in the runtime and get accurate information about what variables
|
||||
are active.
|
||||
This change was large but should have no semantic effect on programs.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
This rewrite allows the garbage collector in 1.4 to be fully precise,
|
||||
meaning that it is aware of the location of all active pointers in the program.
|
||||
This means the heap will be smaller as there will be no false positives keeping non-pointers alive.
|
||||
Other related changes also reduce the heap size, which is smaller by 10%-30% overall
|
||||
relative to the previous release.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A consequence is that stacks are no longer segmented, eliminating the "hot split" problem.
|
||||
When a stack limit is reached, a new, larger stack is allocated, all active frames for
|
||||
the goroutine are copied there, and any pointers into the stack are updated.
|
||||
Performance can be noticeably better in some cases and is always more predictable.
|
||||
Details are available in <a href="/s/contigstacks">the design document</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The use of contiguous stacks means that stacks can start smaller without triggering performance issues,
|
||||
so the default starting size for a goroutine's stack in 1.4 has been reduced to 2048 bytes from 8192 bytes.
|
||||
TODO: It may be bumped to 4096 for the release.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
As preparation for the concurrent garbage collector scheduled for the 1.5 release,
|
||||
writes to pointer values in the heap are now done by a function call,
|
||||
called a write barrier, rather than directly from the function updating the value.
|
||||
In this next release, this will permit the garbage collector to mediate writes to the heap while it is running.
|
||||
This change has no semantic effect on programs in 1.4, but was
|
||||
included in the release to test the compiler and the resulting performance.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The implementation of interface values has been modified.
|
||||
In earlier releases, the interface contained a word that was either a pointer or a one-word
|
||||
scalar value, depending on the type of the concrete object stored.
|
||||
This implementation was problematical for the garbage collector,
|
||||
so as of 1.4 interface values always hold a pointer.
|
||||
In running programs, most interface values were pointers anyway,
|
||||
so the effect is minimal, but programs that store integers (for example) in
|
||||
interfaces will see more allocations.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
As of Go 1.3, the runtime crashes if it finds a memory word that should contain
|
||||
a valid pointer but instead contains an obviously invalid pointer (for example, the value 3).
|
||||
Programs that store integers in pointer values may run afoul of this check and crash.
|
||||
In Go 1.4, setting the <a href="/pkg/runtime/"><code>GODEBUG</code></a> variable
|
||||
<code>invalidptr=0</code> disables
|
||||
the crash as a workaround, but we cannot guarantee that future releases will be
|
||||
able to avoid the crash; the correct fix is to rewrite code not to alias integers and pointers.
|
||||
</p>
|
||||
|
||||
<h3 id="asm">Assembly</h3>
|
||||
|
||||
<p>
|
||||
The language accepted by the assemblers <code>cmd/5a</code>, <code>cmd/6a</code>
|
||||
and <code>cmd/8a</code> has had several changes,
|
||||
mostly to make it easier to deliver type information to the runtime.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
First, the <code>textflag.h</code> file that defines flags for <code>TEXT</code> directives
|
||||
has been copied from the linker source directory to a standard location so it can be
|
||||
included with the simple directive
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
#include "textflag.h"
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The more important changes are in how assembler source can define the necessary
|
||||
type information.
|
||||
For most programs it will suffice to move data
|
||||
definitions (<code>DATA</code> and <code>GLOBL</code> directives)
|
||||
out of assembly into Go files
|
||||
and to write a Go declaration for each assembly function.
|
||||
The <a href="/doc/asm#runtime">assembly document</a> describes what to do.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<em>Updating</em>:
|
||||
Assembly files that include <code>textflag.h</code> from its old
|
||||
location will still work, but should be updated.
|
||||
For the type information, most assembly routines will need no change,
|
||||
but all should be examined.
|
||||
Assembly source files that define data,
|
||||
functions with non-empty stack frames, or functions that return pointers
|
||||
need particular attention.
|
||||
A description of the necessary (but simple) changes
|
||||
is in the <a href="/doc/asm#runtime">assembly document</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
More information about these changes is in the <a href="/doc/asm">assembly document</a>.
|
||||
</p>
|
||||
|
||||
<h3 id="gccgo">Status of gccgo</h3>
|
||||
|
||||
<p>
|
||||
The release schedules for the GCC and Go projects do not coincide.
|
||||
GCC release 4.9 contains the Go 1.2 version of gccgo.
|
||||
The next release, GCC 5, will likely have the Go 1.4 version of gccgo.
|
||||
</p>
|
||||
|
||||
<h3 id="internalpackages">Internal packages</h3>
|
||||
|
||||
<p>
|
||||
Go's package system makes it easy to structure programs into components with clean boundaries,
|
||||
but there are only two forms of access: local (unexported) and global (exported).
|
||||
Sometimes one wishes to have components that are not exported,
|
||||
for instance to avoid acquiring clients of interfaces to code that is part of a public repository
|
||||
but not intended for use outside the program to which it belongs.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The Go language does not have the power to enforce this distinction, but as of Go 1.4 the
|
||||
<a href="/cmd/go/"><code>go</code></a> command introduces
|
||||
a mechanism to define "internal" packages that may not be imported by packages outside
|
||||
the source subtree in which they reside.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To create such a package, place it in a directory named <code>internal</code> or in a subdirectory of a directory
|
||||
named internal.
|
||||
When the <code>go</code> command sees an import of a package with <code>internal</code> in its path,
|
||||
it verifies that the package doing the import
|
||||
is within the tree rooted at the parent of the <code>internal</code> directory.
|
||||
For example, a package <code>.../a/b/c/internal/d/e/f</code>
|
||||
can be imported only by code in the directory tree rooted at <code>.../a/b/c</code>.
|
||||
It cannot be imported by code in <code>.../a/b/g</code> or in any other repository.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For Go 1.4, the internal package mechanism is enforced for the main Go repository;
|
||||
from 1.5 and onward it will be enforced for any repository.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Full details of the mechanism are in
|
||||
<a href="http://golang.org/s/go14internal">the design document</a>.
|
||||
</p>
|
||||
|
||||
<h3 id="canonicalimports">Canonical import paths</h3>
|
||||
|
||||
<p>
|
||||
Code often lives in repositories hosted by public services such as <code>github.com</code>,
|
||||
meaning that the import paths for packages begin with the name of the hosting service,
|
||||
<code>github.com/rsc/pdf</code> for example.
|
||||
One can use
|
||||
<a href="/cmd/go/#hdr-Remote_import_paths">an existing mechanism</a>
|
||||
to provide a "custom" or "vanity" import path such as
|
||||
<code>rsc.io/pdf</code>, but
|
||||
that creates two valid import paths for the package.
|
||||
That is a problem: one may inadvertently import the package through the two
|
||||
distinct paths in a single program, which is wasteful;
|
||||
miss an update to a package because the path being used is not recognized to be
|
||||
out of date;
|
||||
or break clients using the old path by moving the package to a different hosting service.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Go 1.4 introduces an annotation for package clauses in Go source that identify a canonical
|
||||
import path for the package.
|
||||
If an import is attempted using a path that is not canonical,
|
||||
the <a href="/cmd/go/"><code>go</code></a> command
|
||||
will refuse to compile the importing package.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The syntax is simple: put an identifying comment on the package line.
|
||||
For our example, the package clause would read:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
package pdf // import "rsc.io/pdf"
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
With this in place,
|
||||
the <code>go</code> command will
|
||||
refuse to compile a package that imports <code>github.com/rsc/pdf</code>,
|
||||
ensuring that the code can be moved without breaking users.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The check is at build time, not download time, so if <code>go</code> <code>get</code>
|
||||
fails because of this check, the mis-imported package has been copied to the local machine
|
||||
and should be removed manually.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To complement this new feature, a check has been added at update time to verify
|
||||
that the local package's remote repository matches that of its custom import.
|
||||
The <code>go</code> <code>get</code> <code>-u</code> command will fail to
|
||||
update a package if its remote repository has changed since it was first
|
||||
downloaded.
|
||||
The new <code>-f</code> flag overrides this check.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Further information is in
|
||||
<a href="http://golang.org/s/go14customimport">the design document</a>.
|
||||
</p>
|
||||
|
||||
<h3 id="gogenerate">The go generate subcommand</h3>
|
||||
|
||||
<p>
|
||||
The <a href="/cmd/go/"><code>go</code></a> command has a new subcommand,
|
||||
<a href="/cmd/go/#hdr-Generate_Go_files_by_processing_source"><code>go generate</code></a>,
|
||||
to automate the running of tools to generate source code before compilation.
|
||||
For example, it can be used to run the <a href="/cmd/yacc"><code>yacc</code></a>
|
||||
compiler-compiler on a <code>.y</code> file to produce the Go source file implementing the grammar,
|
||||
or to automate the generation of <code>String</code> methods for typed constants using the new
|
||||
<a href="http://godoc.org/code.google.com/p/go.tools/cmd/stringer">stringer</a>
|
||||
tool in the <code>go.tools</code> repository.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For more information, see the
|
||||
<a href="http://golang.org/s/go1.4-generate">design document</a>.
|
||||
</p>
|
||||
|
||||
<h3 id="filenames">Change to file name handling</h3>
|
||||
|
||||
<p>
|
||||
Build constraints, also known as build tags, control compilation by including or excluding files
|
||||
(see the documentation <a href="/pkg/go/build/"><code>/go/build</code></a>).
|
||||
Compilation can also be controlled by the name of the file itself by "tagging" the file with
|
||||
a suffix (before the <code>.go</code> or <code>.s</code> extension) with an underscore
|
||||
and the name of the architecture or operating system.
|
||||
For instance, the file <code>gopher_arm.go</code> will only be compiled if the target
|
||||
processor is an ARM.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Before Go 1.4, a file called just <code>arm.go</code> was similarly tagged, but this behavior
|
||||
can break sources when new architectures are added, causing files to suddenly become tagged.
|
||||
In 1.4, therefore, a file will be tagged in this manner only if the tag (architecture or operating
|
||||
system name) is preceded by an underscore.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<em>Updating</em>: Packages that depend on the old behavior will no longer compile correctly.
|
||||
Files with names like <code>windows.go</code> or <code>amd64.go</code> should either
|
||||
have explicit build tags added to the source or be renamed to something like
|
||||
<code>os_windows.go</code> or <code>support_amd64.go</code>.
|
||||
</p>
|
||||
|
||||
<h3 id="gocmd">Other changes to the go command</h3>
|
||||
|
||||
<p>
|
||||
There were a number of minor changes to the
|
||||
<a href="/cmd/go/"><code>cmd/go</code></a>
|
||||
command worth noting.
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
|
||||
<li>
|
||||
Unless <a href="/cmd/cgo/"><code>cgo</code></a> is being used to build the package,
|
||||
the <code>go</code> command now refuses to compile C source files,
|
||||
since the relevant C compilers
|
||||
(<a href="/cmd/6c/"><code>6c</code></a> etc.)
|
||||
are intended to be removed from the installation in some future release.
|
||||
(They are used today only to build part of the runtime.)
|
||||
It is difficult to use them correctly in any case, so any extant uses are likely incorrect,
|
||||
so we have disabled them.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/cmd/go/#hdr-Test_packages"><code>go</code> <code>test</code></a>
|
||||
subcommand has a new flag, <code>-o</code>, to set the name of the resulting binary,
|
||||
corresponding to the same flag in other subcommands.
|
||||
The non-functional <code>-file</code> flag has been removed.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/cmd/go/#hdr-Test_packages"><code>go</code> <code>test</code></a>
|
||||
subcommand will compile and link all <code>*_test.go</code> files in the package,
|
||||
even when there are no <code>Test</code> functions in them.
|
||||
It previously ignored such files.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The behavior of the
|
||||
<a href="/cmd/go/#hdr-Test_packages"><code>go</code> <code>build</code></a>
|
||||
subcommand's
|
||||
<code>-a</code> flag has been changed for non-development installations.
|
||||
For installations running a released distribution, the <code>-a</code> flag will no longer
|
||||
rebuild the standard library and commands, to avoid overwriting the installation's files.
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
|
||||
<h3 id="pkg">Changes to package source layout</h3>
|
||||
|
||||
<p>
|
||||
In the main Go source repository, the source code for the packages was kept in
|
||||
the directory <code>src/pkg</code>, which made sense but differed from
|
||||
other repositories, including the Go sub-repositories such as <code>go.tools</code>.
|
||||
In Go 1.4, the<code> pkg</code> level of the source tree is now gone, so for example
|
||||
the <a href="/pkg/fmt/"><code>fmt</code></a> package's source, once kept in
|
||||
directory <code>src/pkg/fmt</code>, now lives one level higher in <code>src/fmt</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<em>Updating</em>: Tools like <code>godoc</code> that discover source code
|
||||
need to know about the new location. All tools and services maintained by the Go team
|
||||
have been updated.
|
||||
</p>
|
||||
|
||||
|
||||
<h3 id="swig">SWIG</h3>
|
||||
|
||||
<p>
|
||||
Due to the runtime changes in this release, Go 1.4 will require SWIG 3.0.3.
|
||||
At time of writing that has not yet been released, but we expect it to be by
|
||||
Go 1.4's release date.
|
||||
TODO
|
||||
</p>
|
||||
|
||||
<h3 id="misc">Miscellany</h3>
|
||||
|
||||
<p>
|
||||
The standard repository's top-level <code>misc</code> directory used to contain
|
||||
Go support for editors and IDEs: plugins, initialization scripts and so on.
|
||||
Maintaining these was becoming time-consuming
|
||||
and needed external help because many of the editors listed were not used by
|
||||
members of the core team.
|
||||
It also required us to make decisions about which plugin was best for a given
|
||||
editor, even for editors we do not use.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The Go community at large is much better suited to managing this information.
|
||||
In Go 1.4, therefore, this support has been removed from the repository.
|
||||
Instead, there is a curated, informative list of what's available on
|
||||
a <a href="https://code.google.com/p/go-wiki/wiki/IDEsAndTextEditorPlugins">wiki page</a>.
|
||||
</p>
|
||||
|
||||
<h2 id="performance">Performance</h2>
|
||||
|
||||
<p>
|
||||
Most programs will run about the same speed or slightly faster in 1.4 than in 1.3;
|
||||
some will be slightly slower.
|
||||
There are many changes, making it hard to be precise about what to expect.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
As mentioned above, much of the runtime was translated to Go from C,
|
||||
which led to some reduction in heap sizes.
|
||||
It also improved performance slightly because the Go compiler is better
|
||||
at optimization, due to things like inlining, than the C compiler used to build
|
||||
the runtime.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The garbage collector was sped up, leading to measurable improvements for
|
||||
garbage-heavy programs.
|
||||
On the other hand, the new write barriers slow things down again, typically
|
||||
by about the same amount but, depending on their behavior, some programs
|
||||
may be somewhat slower or faster.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Library changes that affect performance are documented below.
|
||||
</p>
|
||||
|
||||
<h2 id="library">Changes to the standard library</h2>
|
||||
|
||||
<h3 id="new_packages">New packages</h3>
|
||||
|
||||
<p>
|
||||
There are no new packages in this release.
|
||||
</p>
|
||||
|
||||
<h3 id="major_library_changes">Major changes to the library</h3>
|
||||
|
||||
<h4 id="scanner">bufio.Scanner</h4>
|
||||
|
||||
<p>
|
||||
The <a href="/pkg/bufio/#Scanner"><code>Scanner</code></a> type in the
|
||||
<a href="/pkg/bufio/"><code>bufio</code></a> package
|
||||
has had a bug fixed that may require changes to custom
|
||||
<a href="/pkg/bufio/#SplitFunc"><code>split functions</code></a>.
|
||||
The bug made it impossible to generate an empty token at EOF; the fix
|
||||
changes the end conditions seen by the split function.
|
||||
Previously, scanning stopped at EOF if there was no more data.
|
||||
As of 1.4, the split function will be called once at EOF after input is exhausted,
|
||||
so the split function can generate a final empty token
|
||||
as the documentation already promised.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<em>Updating</em>: Custom split functions may need to be modified to
|
||||
handle empty tokens at EOF as desired.
|
||||
</p>
|
||||
|
||||
<h4 id="syscall">syscall</h4>
|
||||
|
||||
<p>
|
||||
The <a href="/pkg/syscall/"><code>syscall</code></a> package is now frozen except
|
||||
for changes needed to maintain the core repository.
|
||||
In particular, it will no longer be extended to support new or different system calls
|
||||
that are not used by the core.
|
||||
The reasons are described at length in <a href="http://golang.org/s/go1.4-syscall">a
|
||||
separate document</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A new subrepository, <a href="http://code.google.com/p/go.sys">go.sys</a>,
|
||||
has been created to serve as the location for new developments to support system
|
||||
calls on all kernels.
|
||||
It has a nicer structure, with three packages that each hold the implementation of
|
||||
system calls for one of
|
||||
<a href="http://godoc.org/code.google.com/p/go.sys/unix">Unix</a>,
|
||||
<a href="http://godoc.org/code.google.com/p/go.sys/windows">Windows</a> and
|
||||
<a href="http://godoc.org/code.google.com/p/go.sys/plan9">Plan 9</a>.
|
||||
These packages will be curated more generously, accepting all reasonable changes
|
||||
that reflect kernel interfaces in those operating systems.
|
||||
See the documentation and the article mentioned above for more information.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<em>Updating</em>: Existing programs are not affected as the <code>syscall</code>
|
||||
package is largely unchanged from the 1.3 release.
|
||||
Future development that requires system calls not in the <code>syscall</code> package
|
||||
should build on <code>go.sys</code> instead.
|
||||
</p>
|
||||
|
||||
<h3 id="minor_library_changes">Minor changes to the library</h3>
|
||||
|
||||
<p>
|
||||
The following list summarizes a number of minor changes to the library, mostly additions.
|
||||
See the relevant package documentation for more information about each change.
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/compress/flate/"><code>compress/flate</code></a>,
|
||||
<a href="/pkg/compress/gzip/"><code>compress/gzip</code></a>,
|
||||
and <a href="/pkg/compress/zlib/"><code>compress/zlib</code></a>
|
||||
packages now support a <code>Reset</code> method
|
||||
for the decompressors, allowing them to reuse buffers and improve performance.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/crypto/tls/"><code>crypto/tls</code></a> package
|
||||
now supports ALPN as defined in <a href="http://tools.ietf.org/html/rfc7301">RFC 7301</a>.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/crypto/tls/"><code>crypto/tls</code></a> package
|
||||
now supports programmatic selection of server certificates
|
||||
through the new <a href="/pkg/crypto/tls/#Config.CertificateForName"><code>CertificateForName</code></a> function
|
||||
of the <a href="/pkg/crypo/tls/#Config"><code>Config</code></a> struct.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
Also in the crypto/tls package, the server now supports
|
||||
<a href="https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00">TLS_FALLBACK_SCSV</a>
|
||||
to help clients detect fallback attacks.
|
||||
(The Go client does not support fallback at all, so it is not vulnerable to
|
||||
those attacks.)
|
||||
</li>
|
||||
|
||||
<li>
|
||||
In the <a href="/pkg/encoding/asn1/"><code>encoding/asn1</code></a> package,
|
||||
optional elements with a default value will now only be omitted if they have that value.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/encoding/csv/"><code>encoding/csv</code></a> package no longer
|
||||
quotes empty strings but does quote the end-of-data marker <code>\.</code> (backslash dot).
|
||||
This is permitted by the definition of CSV and allows it to work better with Postgres.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/encoding/gob/"><code>encoding/gob</code></a> package has been rewritten to eliminate
|
||||
the use of unsafe operations, allowing it to be used in environments that do not permit use of the
|
||||
<a href="/pkg/unsafe/"><code>unsafe</code></a> package.
|
||||
For typical uses it will be 10-30% slower, but the delta is dependent on the type of the data and
|
||||
in some cases, especially involving arrays, it can be faster.
|
||||
There is no functional change.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
In the <a href="/pkg/fmt/"><code>fmt</code></a> package,
|
||||
formatting of pointers to maps has changed to be consistent with that of pointers
|
||||
to structs, arrays, and so on.
|
||||
For instance, <code>&map[string]int{"one":</code> <code>1}</code> now prints by default as
|
||||
<code>&map[one:</code> <code>1]</code> rather than as a hexadecimal pointer value.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/net/http/"><code>net/http</code></a> package's
|
||||
<a href="/pkg/net/http/#Request"><code>Request</code></a> type
|
||||
has a new <a href="/pkg/net/http/#Request.BasicAuth"><code>BasicAuth</code></a> method
|
||||
that returns the username and password from authenticated requests using the
|
||||
HTTP Basic Authentication
|
||||
Scheme.
|
||||
</li>
|
||||
|
||||
<li>The <a href="/pkg/net/http/"><code>net/http</code></a> package's
|
||||
<a href="/pkg/net/http/#Request"><code>Transport</code></a> type
|
||||
has a new <a href="/pkg/net/http/#Transport.DialTLS"><code>DialTLS</code></a> hook
|
||||
that allows customizing the behavior of outbound TLS connections.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/net/http/httputil/"><code>net/http/httputil</code></a> package's
|
||||
<a href="/pkg/net/http/httputil/#ReverseProxy"><code>ReverseProxy</code></a> type
|
||||
has a new field,
|
||||
<a href="/pkg/net/http/#ReverseProxy.ErrorLog"><code>ErrorLog</code></a>, that
|
||||
provides user control of logging.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/os/"><code>os</code></a> package
|
||||
now implements symbolic links on the Windows operating system
|
||||
through the <a href="/pkg/os/#Symlink"><code>Symlink</code></a> function.
|
||||
Other operating systems already have this functionality.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/reflect/"><code>reflect</code></a> package's
|
||||
<a href="/pkg/reflect/#Type"><code>Type</code></a> interface
|
||||
has a new method, <a href="/pkg/reflect/#type.Comparable"><code>Comparable</code></a>,
|
||||
that reports whether the type implements general comparisons.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
Also in the <a href="/pkg/reflect/"><code>reflect</code></a> package, the
|
||||
<a href="/pkg/reflect/#Value"><code>Value</code></a> interface is now three instead of four words
|
||||
because of changes to the implementation of interfaces in the runtime.
|
||||
This saves memory but has no semantic effect.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/runtime/"><code>runtime</code></a> package
|
||||
now implements monotonic clocks on Windows,
|
||||
as it already did for the other systems.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/runtime/"><code>runtime</code></a> package's
|
||||
<a href="/pkg/runtime/#MemStats.Mallocs"><code>Mallocs</code></a> counter
|
||||
now counts very small allocations that were missed in Go 1.3.
|
||||
This may break tests using <a href="/pkg/runtime/#ReadMemStats"><code>ReadMemStats</code></a>
|
||||
or <a href="/pkg/testing/#AllocsPerRun"><code>AllocsPerRun</code></a>
|
||||
due to the more accurate answer.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
In the <a href="/pkg/runtime/"><code>runtime</code></a> package,
|
||||
an array <a href="/pkg/runtime/#MemStats.PauseEnd"><code>PauseEnd</code></a>
|
||||
has been added to the
|
||||
<a href="/pkg/runtime/#MemStats"><code>MemStats</code></a>
|
||||
and <a href="/pkg/runtime/#GCStats"><code>GCStats</code></a> structs.
|
||||
This array is a circular buffer of times when garbage collection pauses ended.
|
||||
The corresponding pause durations are already recorded in
|
||||
<a href="/pkg/runtime/#MemStats.PauseNs"><code>PauseNs</code></a>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/runtime/race/"><code>runtime/race</code></a> package
|
||||
now supports FreeBSD, which means the
|
||||
<a href="/pkg/cmd/go/"><code>go</code></a> command's <code>-race</code>
|
||||
flag now works on FreeBSD.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/sync/atomic/"><code>sync/atomic</code></a> package
|
||||
has a new type, <a href="/pkg/sync/atomic/#Value"><code>Value</code></a>.
|
||||
<code>Value</code> provides an efficient mechanism for atomic loads and
|
||||
stores of values of arbitrary type.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
In the <a href="/pkg/syscall/"><code>syscall</code></a> package's
|
||||
implementation on Linux, the
|
||||
<a href="/pkg/syscall/#Setuid"><code>Setuid</code></a>
|
||||
and <a href="/pkg/syscall/#Setgid"><code>Setgid</code></a> have been disabled
|
||||
because those system calls operate on the calling thread, not the whole process, which is
|
||||
different from other platforms and not the expected result.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/testing/"><code>testing</code></a> package
|
||||
has a new facility to provide more control over running a set of tests.
|
||||
If the test code contains a function
|
||||
<pre>
|
||||
func TestMain(m *<a href="/pkg/testing/#M"><code>testing.M</code></a>)
|
||||
</pre>
|
||||
|
||||
that function will be called instead of running the tests directly.
|
||||
The <code>M</code> struct contains methods to access and run the tests.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
Also in the <a href="/pkg/testing/"><code>testing</code></a> package,
|
||||
a new <a href="/pkg/testing/#Coverage"><code>Coverage</code></a>
|
||||
function reports the current test coverage fraction,
|
||||
enabling individual tests to report how much they are contributing to the
|
||||
overall coverage.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/text/scanner/"><code>text/scanner</code></a> package's
|
||||
<a href="/pkg/text/scanner/#Scanner"><code>Scanner</code></a> type
|
||||
has a new function,
|
||||
<a href="/pkg/text/scanner/#Scanner.IsIdentRune"><code>IsIdentRune</code></a>,
|
||||
allowing one to control the definition of an identifier when scanning.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <a href="/pkg/text/template/"><code>text/template</code></a> package's boolean
|
||||
functions <code>eq</code>, <code>lt</code>, and so on have been generalized to allow comparison
|
||||
of signed and unsigned integers, simplifying their use in practice.
|
||||
(Previously one could only compare values of the same signedness.)
|
||||
All negative values compare less than all unsigned values.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <code>time</code> package now uses the standard symbol for the micro prefix,
|
||||
the micro symbol (U+00B5 'µ'), to print microsecond durations.
|
||||
<a href="/pkg/time/#ParseDuration"><code>ParseDuration</code></a> still accepts <code>us</code>
|
||||
but the package no longer prints microseconds as <code>us</code>.
|
||||
<br>
|
||||
<em>Updating</em>: Code that depends on the output format of durations
|
||||
but does not use ParseDuration will need to be updated.
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
15
doc/go1.html
15
doc/go1.html
@@ -1,6 +1,5 @@
|
||||
<!--{
|
||||
"Title": "Go 1 Release Notes",
|
||||
"Path": "/doc/go1",
|
||||
"Template": true
|
||||
}-->
|
||||
|
||||
@@ -486,7 +485,7 @@ into subdirectories. For instance, <code>utf8</code> and
|
||||
<code>utf16</code> now occupy subdirectories of <code>unicode</code>.
|
||||
Also, <a href="#subrepo">some packages</a> have moved into
|
||||
subrepositories of
|
||||
<a href="//code.google.com/p/go"><code>code.google.com/p/go</code></a>
|
||||
<a href="http://code.google.com/p/go"><code>code.google.com/p/go</code></a>
|
||||
while <a href="#deleted">others</a> have been deleted outright.
|
||||
</p>
|
||||
|
||||
@@ -565,7 +564,7 @@ by hand.
|
||||
<p>
|
||||
Because they are not standardized, the packages under the <code>exp</code> directory will not be available in the
|
||||
standard Go 1 release distributions, although they will be available in source code form
|
||||
in <a href="//code.google.com/p/go/">the repository</a> for
|
||||
in <a href="http://code.google.com/p/go/">the repository</a> for
|
||||
developers who wish to use them.
|
||||
</p>
|
||||
|
||||
@@ -651,7 +650,7 @@ and also the command <code>gotry</code>.
|
||||
<em>Updating</em>:
|
||||
Code that uses <code>container/vector</code> should be updated to use
|
||||
slices directly. See
|
||||
<a href="//code.google.com/p/go-wiki/wiki/SliceTricks">the Go
|
||||
<a href="http://code.google.com/p/go-wiki/wiki/SliceTricks">the Go
|
||||
Language Community Wiki</a> for some suggestions.
|
||||
Code that uses the other packages (there should be almost zero) will need to be rethought.
|
||||
</p>
|
||||
@@ -660,7 +659,7 @@ Code that uses the other packages (there should be almost zero) will need to be
|
||||
|
||||
<p>
|
||||
Go 1 has moved a number of packages into other repositories, usually sub-repositories of
|
||||
<a href="//code.google.com/p/go/">the main Go repository</a>.
|
||||
<a href="http://code.google.com/p/go/">the main Go repository</a>.
|
||||
This table lists the old and new import paths:
|
||||
|
||||
<table class="codetable" frame="border" summary="Sub-repositories">
|
||||
@@ -1695,7 +1694,7 @@ The compiler will catch code using the old interface.
|
||||
The <a href="/pkg/regexp/"><code>regexp</code></a> package has been rewritten.
|
||||
It has the same interface but the specification of the regular expressions
|
||||
it supports has changed from the old "egrep" form to that of
|
||||
<a href="//code.google.com/p/re2/">RE2</a>.
|
||||
<a href="http://code.google.com/p/re2/">RE2</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@@ -1912,7 +1911,7 @@ package <a href="/pkg/reflect/"><code>reflect</code></a>.
|
||||
<em>Updating</em>:
|
||||
Code using these functions must be rewritten to use
|
||||
package <a href="/pkg/reflect/"><code>reflect</code></a>.
|
||||
The changes to <a href="//golang.org/change/2646dc956207">encoding/gob</a> and the <a href="//code.google.com/p/goprotobuf/source/detail?r=5340ad310031">protocol buffer library</a>
|
||||
The changes to <a href="http://code.google.com/p/go/source/detail?r=2646dc956207">encoding/gob</a> and the <a href="http://code.google.com/p/goprotobuf/source/detail?r=5340ad310031">protocol buffer library</a>
|
||||
may be helpful as examples.
|
||||
</p>
|
||||
|
||||
@@ -2035,4 +2034,4 @@ They are available for many combinations of architecture and operating system
|
||||
Installation details are described on the
|
||||
<a href="/doc/install">Getting Started</a> page, while
|
||||
the distributions themselves are listed on the
|
||||
<a href="https://golang.org/dl/">downloads page</a>.
|
||||
<a href="http://code.google.com/p/go/downloads/list">downloads page</a>.
|
||||
|
||||
@@ -1,6 +1,5 @@
|
||||
<!--{
|
||||
"Title": "Go 1 and the Future of Go Programs",
|
||||
"Path": "/doc/go1compat"
|
||||
"Title": "Go 1 and the Future of Go Programs"
|
||||
}-->
|
||||
|
||||
<h2 id="introduction">Introduction</h2>
|
||||
@@ -83,16 +82,16 @@ break if the bug is fixed. We reserve the right to fix such bugs.
|
||||
<li>
|
||||
Struct literals. For the addition of features in later point
|
||||
releases, it may be necessary to add fields to exported structs in
|
||||
the API. Code that uses unkeyed struct literals (such as pkg.T{3,
|
||||
the API. Code that uses untagged struct literals (such as pkg.T{3,
|
||||
"x"}) to create values of these types would fail to compile after
|
||||
such a change. However, code that uses keyed literals (pkg.T{A:
|
||||
such a change. However, code that uses tagged literals (pkg.T{A:
|
||||
3, B: "x"}) will continue to compile after such a change. We will
|
||||
update such data structures in a way that allows keyed struct
|
||||
literals to remain compatible, although unkeyed literals may fail
|
||||
update such data structures in a way that allows tagged struct
|
||||
literals to remain compatible, although untagged literals may fail
|
||||
to compile. (There are also more intricate cases involving nested
|
||||
data structures or interfaces, but they have the same resolution.)
|
||||
We therefore recommend that composite literals whose type is defined
|
||||
in a separate package should use the keyed notation.
|
||||
in a separate package should use the tagged notation.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
@@ -104,14 +103,6 @@ outside of tests, and using it may cause a program to fail
|
||||
to compile in future releases.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
Use of package <code>unsafe</code>. Packages that import
|
||||
<a href="/pkg/unsafe/"><code>unsafe</code></a>
|
||||
may depend on internal properties of the Go implementation.
|
||||
We reserve the right to make changes to the implementation
|
||||
that may break such programs.
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
@@ -153,28 +144,13 @@ developed software based on Go 1.
|
||||
|
||||
<p>
|
||||
Code in sub-repositories of the main go tree, such as
|
||||
<a href="//code.google.com/p/go.net">code.google.com/p/go.net</a>,
|
||||
<a href="http://code.google.com/p/go.net">code.google.com/p/go.net</a>,
|
||||
may be developed under
|
||||
looser compatibility requirements. However, the sub-repositories
|
||||
will be tagged as appropriate to identify versions that are compatible
|
||||
with the Go 1 point releases.
|
||||
</p>
|
||||
|
||||
<h2 id="operating_systems">Operating systems</h2>
|
||||
|
||||
<p>
|
||||
It is impossible to guarantee long-term compatibility with operating
|
||||
system interfaces, which are changed by outside parties.
|
||||
The <a href="/pkg/syscall/"><code>syscall</code></a> package
|
||||
is therefore outside the purview of the guarantees made here.
|
||||
As of Go version 1.4, the <code>syscall</code> package is frozen.
|
||||
Any evolution of the system call interface must be supported elsewhere,
|
||||
such as in the
|
||||
<a href="http://godoc.org/code.google.com/p/go.sys">go.sys</a> subrepository.
|
||||
For details and background, see
|
||||
<a href="https://golang.org/s/go1.4-syscall">this document</a>.
|
||||
</p>
|
||||
|
||||
<h2 id="tools">Tools</h2>
|
||||
|
||||
<p>
|
||||
|
||||
183
doc/go_faq.html
183
doc/go_faq.html
@@ -1,5 +1,5 @@
|
||||
<!--{
|
||||
"Title": "Frequently Asked Questions (FAQ)",
|
||||
"Title": "FAQ",
|
||||
"Path": "/doc/faq"
|
||||
}-->
|
||||
|
||||
@@ -55,18 +55,13 @@ By its design, Go proposes an approach for the construction of system
|
||||
software on multicore machines.
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
A much more expansive answer to this question is available in the article,
|
||||
<a href="//talks.golang.org/2012/splash.article">Go at Google:
|
||||
Language Design in the Service of Software Engineering</a>.
|
||||
|
||||
<h3 id="What_is_the_status_of_the_project">
|
||||
What is the status of the project?</h3>
|
||||
|
||||
<p>
|
||||
Go became a public open source project on November 10, 2009.
|
||||
After a couple of years of very active design and development, stability was called for and
|
||||
Go 1 was <a href="//blog.golang.org/2012/03/go-version-1-is-released.html">released</a>
|
||||
Go 1 was <a href="http://blog.golang.org/2012/03/go-version-1-is-released.html">released</a>
|
||||
on March 28, 2012.
|
||||
Go 1, which includes a <a href="/ref/spec">language specification</a>,
|
||||
<a href="/pkg/">standard libraries</a>,
|
||||
@@ -163,7 +158,7 @@ language was called for.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The article <a href="//talks.golang.org/2012/splash.article">Go at Google</a>
|
||||
The article <a href="http://talks.golang.org/2012/splash.article">Go at Google</a>
|
||||
discusses the background and motivation behind the design of the Go language,
|
||||
as well as providing more detail about many of the answers presented in this FAQ.
|
||||
</p>
|
||||
@@ -221,7 +216,7 @@ easier to understand what happens when things combine.
|
||||
<p>
|
||||
Yes. There are now several Go programs deployed in
|
||||
production inside Google. A public example is the server behind
|
||||
<a href="//golang.org">golang.org</a>.
|
||||
<a href="http://golang.org">http://golang.org</a>.
|
||||
It's just the <a href="/cmd/godoc"><code>godoc</code></a>
|
||||
document server running in a production configuration on
|
||||
<a href="https://developers.google.com/appengine/">Google App Engine</a>.
|
||||
@@ -260,7 +255,7 @@ Does Go support Google's protocol buffers?</h3>
|
||||
<p>
|
||||
A separate open source project provides the necessary compiler plugin and library.
|
||||
It is available at
|
||||
<a href="//code.google.com/p/goprotobuf/">code.google.com/p/goprotobuf/</a>
|
||||
<a href="http://code.google.com/p/goprotobuf/">http://code.google.com/p/goprotobuf/</a>
|
||||
</p>
|
||||
|
||||
|
||||
@@ -270,9 +265,9 @@ Can I translate the Go home page into another language?</h3>
|
||||
<p>
|
||||
Absolutely. We encourage developers to make Go Language sites in their own languages.
|
||||
However, if you choose to add the Google logo or branding to your site
|
||||
(it does not appear on <a href="//golang.org/">golang.org</a>),
|
||||
(it does not appear on <a href="http://golang.org/">golang.org</a>),
|
||||
you will need to abide by the guidelines at
|
||||
<a href="//www.google.com/permissions/guidelines.html">www.google.com/permissions/guidelines.html</a>
|
||||
<a href="http://www.google.com/permissions/guidelines.html">http://www.google.com/permissions/guidelines.html</a>
|
||||
</p>
|
||||
|
||||
<h2 id="Design">Design</h2>
|
||||
@@ -426,20 +421,18 @@ When a coroutine blocks, such as by calling a blocking system call,
|
||||
the run-time automatically moves other coroutines on the same operating
|
||||
system thread to a different, runnable thread so they won't be blocked.
|
||||
The programmer sees none of this, which is the point.
|
||||
The result, which we call goroutines, can be very cheap: they have little
|
||||
overhead beyond the memory for the stack, which is just a few kilobytes.
|
||||
The result, which we call goroutines, can be very cheap: unless they spend a lot of time
|
||||
in long-running system calls, they cost little more than the memory
|
||||
for the stack, which is just a few kilobytes.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To make the stacks small, Go's run-time uses resizable, bounded stacks. A newly
|
||||
To make the stacks small, Go's run-time uses segmented stacks. A newly
|
||||
minted goroutine is given a few kilobytes, which is almost always enough.
|
||||
When it isn't, the run-time grows (and shrinks) the memory for storing
|
||||
the stack automatically, allowing many goroutines to live in a modest
|
||||
amount of memory.
|
||||
The CPU overhead averages about three cheap instructions per function call.
|
||||
When it isn't, the run-time allocates (and frees) extension segments automatically.
|
||||
The overhead averages about three cheap instructions per function call.
|
||||
It is practical to create hundreds of thousands of goroutines in the same
|
||||
address space.
|
||||
If goroutines were just threads, system resources would
|
||||
address space. If goroutines were just threads, system resources would
|
||||
run out at a much smaller number.
|
||||
</p>
|
||||
|
||||
@@ -448,7 +441,7 @@ Why are map operations not defined to be atomic?</h3>
|
||||
|
||||
<p>
|
||||
After long discussion it was decided that the typical use of maps did not require
|
||||
safe access from multiple goroutines, and in those cases where it did, the map was
|
||||
safe access from multiple threads, and in those cases where it did, the map was
|
||||
probably part of some larger data structure or computation that was already
|
||||
synchronized. Therefore requiring that all map operations grab a mutex would slow
|
||||
down most programs and add safety to few. This was not an easy decision,
|
||||
@@ -466,7 +459,7 @@ Will you accept my language change?</h3>
|
||||
|
||||
<p>
|
||||
People often suggest improvements to the language—the
|
||||
<a href="//groups.google.com/group/golang-nuts">mailing list</a>
|
||||
<a href="http://groups.google.com/group/golang-nuts">mailing list</a>
|
||||
contains a rich history of such discussions—but very few of these changes have
|
||||
been accepted.
|
||||
</p>
|
||||
@@ -482,9 +475,9 @@ to start talking about what that might be.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Even if your proposal is compatible with the Go 1 spec, it might
|
||||
Even if your proposal is compatible with the Go 1 spec, it may be
|
||||
not be in the spirit of Go's design goals.
|
||||
The article <i><a href="//talks.golang.org/2012/splash.article">Go
|
||||
The article <i><a href="http://talks.golang.org/2012/splash.article">Go
|
||||
at Google: Language Design in the Service of Software Engineering</a></i>
|
||||
explains Go's origins and the motivation behind its design.
|
||||
</p>
|
||||
@@ -708,7 +701,7 @@ A related example goes the other way:
|
||||
|
||||
<pre>
|
||||
type Opener interface {
|
||||
Open() Reader
|
||||
Open(name) Reader
|
||||
}
|
||||
|
||||
func (t T3) Open() *os.File
|
||||
@@ -889,11 +882,6 @@ type is generic; if you care about how many bits an integer holds, Go
|
||||
encourages you to be explicit.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A blog post, title <a href="http://blog.golang.org/constants">Constants</a>,
|
||||
explores this topic in more detail.
|
||||
</p>
|
||||
|
||||
<h3 id="builtin_maps">
|
||||
Why are maps built in?</h3>
|
||||
<p>
|
||||
@@ -945,9 +933,9 @@ How are libraries documented?</h3>
|
||||
There is a program, <code>godoc</code>, written in Go, that extracts
|
||||
package documentation from the source code. It can be used on the
|
||||
command line or on the web. An instance is running at
|
||||
<a href="/pkg/">golang.org/pkg/</a>.
|
||||
<a href="http://golang.org/pkg/">http://golang.org/pkg/</a>.
|
||||
In fact, <code>godoc</code> implements the full site at
|
||||
<a href="/">golang.org/</a>.
|
||||
<a href="http://golang.org/">http://golang.org/</a>.
|
||||
</p>
|
||||
|
||||
<h3 id="Is_there_a_Go_programming_style_guide">
|
||||
@@ -964,19 +952,11 @@ compendium of do's and don'ts that allows interpretation.
|
||||
All the Go code in the repository has been run through <code>gofmt</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The document titled
|
||||
<a href="//golang.org/s/comments">Go Code Review Comments</a>
|
||||
is a collection of very short essays about details of Go idiom that are often
|
||||
missed by programmers.
|
||||
It is a handy reference for people doing code reviews for Go projects.
|
||||
</p>
|
||||
|
||||
<h3 id="How_do_I_submit_patches_to_the_Go_libraries">
|
||||
How do I submit patches to the Go libraries?</h3>
|
||||
|
||||
<p>
|
||||
The library sources are in the <code>src</code> directory of the repository.
|
||||
The library sources are in <code>go/src/pkg</code>.
|
||||
If you want to make a significant change, please discuss on the mailing list before embarking.
|
||||
</p>
|
||||
|
||||
@@ -991,14 +971,14 @@ Why does the project use Mercurial and not git?</h3>
|
||||
|
||||
<p>
|
||||
The Go project, hosted by Google Code at
|
||||
<a href="//code.google.com/p/go">code.google.com/p/go</a>,
|
||||
<a href="http://code.google.com/p/go">code.google.com/p/go</a>,
|
||||
uses Mercurial as its version control system.
|
||||
When the project launched,
|
||||
Google Code supported only Subversion and Mercurial.
|
||||
Mercurial was a better choice because of its plugin mechanism
|
||||
that allowed us to create the "codereview" plugin to connect
|
||||
the project to the excellent code review tools at
|
||||
<a href="//codereview.appspot.com">codereview.appspot.com</a>.
|
||||
<a href="http://codereview.appspot.com">codereview.appspot.com</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@@ -1044,37 +1024,6 @@ these two lines to <code>~/.gitconfig</code>:
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="get_version">
|
||||
How should I manage package versions using "go get"?</h3>
|
||||
|
||||
<p>
|
||||
"Go get" does not have any explicit concept of package versions.
|
||||
Versioning is a source of significant complexity, especially in large code bases,
|
||||
and we are unaware of any approach that works well at scale in a large enough
|
||||
variety of situations to be appropriate to force on all Go users.
|
||||
What "go get" and the larger Go toolchain do provide is isolation of
|
||||
packages with different import paths.
|
||||
For example, the standard library's <code>html/template</code> and <code>text/template</code>
|
||||
coexist even though both are "package template".
|
||||
This observation leads to some advice for package authors and package users.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Packages intended for public use should try to maintain backwards compatibility as they evolve.
|
||||
The <a href="/doc/go1compat.html">Go 1 compatibility guidelines</a> are a good reference here:
|
||||
don't remove exported names, encourage tagged composite literals, and so on.
|
||||
If different functionality is required, add a new name instead of changing an old one.
|
||||
If a complete break is required, create a new package with a new import path.</p>
|
||||
|
||||
<p>
|
||||
If you're using an externally supplied package and worry that it might change in
|
||||
unexpected ways, the simplest solution is to copy it to your local repository.
|
||||
(This is the approach Google takes internally.)
|
||||
Store the copy under a new import path that identifies it as a local copy.
|
||||
For example, you might copy "original.com/pkg" to "you.com/external/original.com/pkg".
|
||||
Keith Rarick's <a href="https://github.com/kr/goven">goven</a> is one tool to help automate this process.
|
||||
</p>
|
||||
|
||||
<h2 id="Pointers">Pointers and Allocation</h2>
|
||||
|
||||
<h3 id="pass_by_value">
|
||||
@@ -1115,7 +1064,7 @@ error but the situation can still be confusing, because sometimes a
|
||||
<a href="#different_method_sets">pointer
|
||||
is necessary to satisfy an interface</a>.
|
||||
The insight is that although a pointer to a concrete type can satisfy
|
||||
an interface, with one exception <em>a pointer to an interface can never satisfy an interface</em>.
|
||||
an interface, with one exception <em>a pointer to an interface can never satisfy a interface</em>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@@ -1309,7 +1258,7 @@ Do not communicate by sharing memory. Instead, share memory by communicating.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
See the <a href="/doc/codewalk/sharemem/">Share Memory By Communicating</a> code walk and its <a href="//blog.golang.org/2010/07/share-memory-by-communicating.html">associated article</a> for a detailed discussion of this concept.
|
||||
See the <a href="/doc/codewalk/sharemem/">Share Memory By Communicating</a> code walk and its <a href="http://blog.golang.org/2010/07/share-memory-by-communicating.html">associated article</a> for a detailed discussion of this concept.
|
||||
</p>
|
||||
|
||||
<h3 id="Why_no_multi_CPU">
|
||||
@@ -1326,7 +1275,7 @@ run-time support to utilize more than one OS thread.
|
||||
Programs that perform parallel computation should benefit from an increase in
|
||||
<code>GOMAXPROCS</code>.
|
||||
However, be aware that
|
||||
<a href="//blog.golang.org/2013/01/concurrency-is-not-parallelism.html">concurrency
|
||||
<a href="http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html">concurrency
|
||||
is not parallelism</a>.
|
||||
</p>
|
||||
|
||||
@@ -1356,14 +1305,14 @@ to speed it up.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Go's goroutine scheduler is not as good as it needs to be. In the future, it
|
||||
Go's goroutine scheduler is not as good as it needs to be. In future, it
|
||||
should recognize such cases and optimize its use of OS threads. For now,
|
||||
<code>GOMAXPROCS</code> should be set on a per-application basis.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For more detail on this topic see the talk entitled,
|
||||
<a href="//blog.golang.org/2013/01/concurrency-is-not-parallelism.html">Concurrency
|
||||
<a href="http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html">Concurrency
|
||||
is not Parallelism</a>.
|
||||
|
||||
<h2 id="Functions_methods">Functions and Methods</h2>
|
||||
@@ -1442,7 +1391,7 @@ each closure shares that single variable. When the closure runs, it prints the
|
||||
value of <code>v</code> at the time <code>fmt.Println</code> is executed,
|
||||
but <code>v</code> may have been modified since the goroutine was launched.
|
||||
To help detect this and other problems before they happen, run
|
||||
<a href="/cmd/go/#hdr-Run_go_tool_vet_on_packages"><code>go vet</code></a>.
|
||||
<a href="http://golang.org/cmd/go/#hdr-Run_go_tool_vet_on_packages"><code>go vet</code></a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@@ -1576,7 +1525,7 @@ table-driven, iterating over a list of inputs and outputs defined
|
||||
in a data structure (Go has excellent support for data structure literals).
|
||||
The work to write a good test and good error messages will then be amortized over many
|
||||
test cases. The standard Go library is full of illustrative examples, such as in
|
||||
<a href="/src/fmt/fmt_test.go">the formatting tests for the <code>fmt</code> package</a>.
|
||||
<a href="/src/pkg/fmt/fmt_test.go">the formatting tests for the <code>fmt</code> package</a>.
|
||||
</p>
|
||||
|
||||
|
||||
@@ -1595,46 +1544,35 @@ and uses a variant of the Plan 9 loader to generate ELF/Mach-O/PE binaries.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
We considered using LLVM for <code>gc</code> but we felt it was too large and
|
||||
slow to meet our performance goals.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
We also considered writing <code>gc</code>, the original Go compiler, in Go itself but
|
||||
We considered writing <code>gc</code>, the original Go compiler, in Go itself but
|
||||
elected not to do so because of the difficulties of bootstrapping and
|
||||
especially of open source distribution—you'd need a Go compiler to
|
||||
set up a Go environment. <code>Gccgo</code>, which came later, makes it possible to
|
||||
consider writing a compiler in Go.
|
||||
A plan to do that by machine translation of the existing compiler is under development.
|
||||
<a href="http://golang.org/s/go13compiler">A separate document</a>
|
||||
explains the reason for this approach.
|
||||
consider writing a compiler in Go, which might well happen.
|
||||
(Go would be a
|
||||
fine language in which to implement a compiler; a native lexer and
|
||||
parser are already available in the <a href="/pkg/go/"><code>go</code></a> package
|
||||
and a type checker is in the works.)
|
||||
</p>
|
||||
|
||||
<p>
|
||||
That plan aside,
|
||||
Go is a
|
||||
fine language in which to implement a self-hosting compiler: a native lexer and
|
||||
parser are already available in the <a href="/pkg/go/"><code>go</code></a> package
|
||||
and a separate type checking
|
||||
<a href="http://godoc.org/code.google.com/p/go.tools/go/types">package</a>
|
||||
has also been written.
|
||||
We also considered using LLVM for <code>gc</code> but we felt it was too large and
|
||||
slow to meet our performance goals.
|
||||
</p>
|
||||
|
||||
<h3 id="How_is_the_run_time_support_implemented">
|
||||
How is the run-time support implemented?</h3>
|
||||
|
||||
<p>
|
||||
Again due to bootstrapping issues, the run-time code was originally written mostly in C (with a
|
||||
tiny bit of assembler) although much of it has been translated to Go since then
|
||||
and one day all of it might be (except for the assembler bits).
|
||||
<code>Gccgo</code>'s run-time support uses <code>glibc</code>.
|
||||
<code>Gc</code> uses a custom C library to keep the footprint under
|
||||
Again due to bootstrapping issues, the run-time code is mostly in C (with a
|
||||
tiny bit of assembler) although Go is capable of implementing most of
|
||||
it now. <code>Gccgo</code>'s run-time support uses <code>glibc</code>.
|
||||
<code>Gc</code> uses a custom library to keep the footprint under
|
||||
control; it is
|
||||
compiled with a version of the Plan 9 C compiler that supports
|
||||
resizable stacks for goroutines.
|
||||
The <code>gccgo</code> compiler implements these on Linux only,
|
||||
using a technique called segmented stacks,
|
||||
supported by recent modifications to the gold linker.
|
||||
segmented stacks for goroutines.
|
||||
The <code>gccgo</code> compiler implements segmented
|
||||
stacks on Linux only, supported by recent modifications to the gold linker.
|
||||
</p>
|
||||
|
||||
<h3 id="Why_is_my_trivial_program_such_a_large_binary">
|
||||
@@ -1652,8 +1590,8 @@ A simple C "hello, world" program compiled and linked statically using gcc
|
||||
on Linux is around 750 kB,
|
||||
including an implementation of <code>printf</code>.
|
||||
An equivalent Go program using <code>fmt.Printf</code>
|
||||
is around 1.9 MB, but
|
||||
that includes more powerful run-time support and type information.
|
||||
is around 1.2 MB, but
|
||||
that includes more powerful run-time support.
|
||||
</p>
|
||||
|
||||
<h3 id="unused_variables_and_imports">
|
||||
@@ -1661,17 +1599,14 @@ Can I stop these complaints about my unused variable/import?</h3>
|
||||
|
||||
<p>
|
||||
The presence of an unused variable may indicate a bug, while
|
||||
unused imports just slow down compilation,
|
||||
an effect that can become substantial as a program accumulates
|
||||
code and programmers over time.
|
||||
For these reasons, Go refuses to compile programs with unused
|
||||
variables or imports,
|
||||
trading short-term convenience for long-term build speed and
|
||||
program clarity.
|
||||
unused imports just slow down compilation.
|
||||
Accumulate enough unused imports in your code tree and
|
||||
things can get very slow.
|
||||
For these reasons, Go allows neither.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Still, when developing code, it's common to create these situations
|
||||
When developing code, it's common to create these situations
|
||||
temporarily and it can be annoying to have to edit them out before the
|
||||
program will compile.
|
||||
</p>
|
||||
@@ -1713,14 +1648,6 @@ func main() {
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Nowadays, most Go programmers use a tool,
|
||||
<a href="http://godoc.org/code.google.com/p/go.tools/cmd/goimports">goimports</a>,
|
||||
which automatically rewrites a Go source file to have the correct imports,
|
||||
eliminating the unused imports issue in practice.
|
||||
This program is easily connected to most editors to run automatically when a Go source file is written.
|
||||
</p>
|
||||
|
||||
<h2 id="Performance">Performance</h2>
|
||||
|
||||
<h3 id="Why_does_Go_perform_badly_on_benchmark_x">
|
||||
@@ -1762,7 +1689,7 @@ In any case, Go can often be very competitive.
|
||||
There has been significant improvement in the performance of many programs
|
||||
as the language and tools have developed.
|
||||
See the blog post about
|
||||
<a href="//blog.golang.org/2011/06/profiling-go-programs.html">profiling
|
||||
<a href="http://blog.golang.org/2011/06/profiling-go-programs.html">profiling
|
||||
Go programs</a> for an informative example.
|
||||
|
||||
<h2 id="change_from_c">Changes from C</h2>
|
||||
@@ -1921,7 +1848,7 @@ considerable control over memory layout and allocation, much more than
|
||||
is typical in garbage-collected languages. A careful programmer can reduce
|
||||
the garbage collection overhead dramatically by using the language well;
|
||||
see the article about
|
||||
<a href="//blog.golang.org/2011/06/profiling-go-programs.html">profiling
|
||||
<a href="http://blog.golang.org/2011/06/profiling-go-programs.html">profiling
|
||||
Go programs</a> for a worked example, including a demonstration of Go's
|
||||
profiling tools.
|
||||
</p>
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
<!--{
|
||||
"Title": "The Go Memory Model",
|
||||
"Subtitle": "Version of May 31, 2014",
|
||||
"Subtitle": "Version of March 6, 2012",
|
||||
"Path": "/ref/mem"
|
||||
}-->
|
||||
|
||||
@@ -21,29 +21,6 @@ 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>
|
||||
|
||||
|
||||
<h2>Advice</h2>
|
||||
|
||||
<p>
|
||||
Programs that modify data being simultaneously accessed by multiple goroutines
|
||||
must serialize such access.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To serialize access, protect the data with channel operations or other synchronization primitives
|
||||
such as those in the <a href="/pkg/sync/"><code>sync</code></a>
|
||||
and <a href="/pkg/sync/atomic/"><code>sync/atomic</code></a> packages.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If you must read the rest of this document to understand the behavior of your program,
|
||||
you are being too clever.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Don't be clever.
|
||||
</p>
|
||||
|
||||
<h2>Happens Before</h2>
|
||||
|
||||
<p>
|
||||
@@ -297,41 +274,6 @@ then the program would not be guaranteed to print
|
||||
crash, or do something else.)
|
||||
</p>
|
||||
|
||||
<p class="rule">
|
||||
The <i>k</i>th receive on a channel with capacity <i>C</i> happens before the <i>k</i>+<i>C</i>th send from that channel completes.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
This rule generalizes the previous rule to buffered channels.
|
||||
It allows a counting semaphore to be modeled by a buffered channel:
|
||||
the number of items in the channel corresponds to the number of active uses,
|
||||
the capacity of the channel corresponds to the maximum number of simultaneous uses,
|
||||
sending an item acquires the semaphore, and receiving an item releases
|
||||
the semaphore.
|
||||
This is a common idiom for limiting concurrency.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
This program starts a goroutine for every entry in the work list, but the
|
||||
goroutines coordinate using the <code>limit</code> channel to ensure
|
||||
that at most three are running work functions at a time.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
var limit = make(chan int, 3)
|
||||
|
||||
func main() {
|
||||
for _, w := range work {
|
||||
go func() {
|
||||
limit <- 1
|
||||
w()
|
||||
<-limit
|
||||
}()
|
||||
}
|
||||
select{}
|
||||
}
|
||||
</pre>
|
||||
|
||||
<h3>Locks</h3>
|
||||
|
||||
<p>
|
||||
@@ -419,7 +361,7 @@ func twoprint() {
|
||||
|
||||
<p>
|
||||
calling <code>twoprint</code> causes <code>"hello, world"</code> to be printed twice.
|
||||
The first call to <code>doprint</code> runs <code>setup</code> once.
|
||||
The first call to <code>twoprint</code> runs <code>setup</code> once.
|
||||
</p>
|
||||
|
||||
<h2>Incorrect synchronization</h2>
|
||||
|
||||
1614
doc/go_spec.html
1614
doc/go_spec.html
File diff suppressed because it is too large
Load Diff
203
doc/godocs.js
Normal file
203
doc/godocs.js
Normal file
@@ -0,0 +1,203 @@
|
||||
// Copyright 2012 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.
|
||||
|
||||
/* A little code to ease navigation of these documents.
|
||||
*
|
||||
* On window load we:
|
||||
* + Bind search box hint placeholder show/hide events (bindSearchEvents)
|
||||
* + Generate a table of contents (generateTOC)
|
||||
* + Bind foldable sections (bindToggles)
|
||||
* + Bind links to foldable sections (bindToggleLinks)
|
||||
*/
|
||||
|
||||
(function() {
|
||||
'use strict';
|
||||
|
||||
function bindSearchEvents() {
|
||||
|
||||
var search = $('#search');
|
||||
if (search.length === 0) {
|
||||
return; // no search box
|
||||
}
|
||||
|
||||
function clearInactive() {
|
||||
if (search.is('.inactive')) {
|
||||
search.val('');
|
||||
search.removeClass('inactive');
|
||||
}
|
||||
}
|
||||
|
||||
function restoreInactive() {
|
||||
if (search.val() !== '') {
|
||||
return;
|
||||
}
|
||||
search.val(search.attr('placeholder'));
|
||||
search.addClass('inactive');
|
||||
}
|
||||
|
||||
search.on('focus', clearInactive);
|
||||
search.on('blur', restoreInactive);
|
||||
|
||||
restoreInactive();
|
||||
}
|
||||
|
||||
/* Generates a table of contents: looks for h2 and h3 elements and generates
|
||||
* links. "Decorates" the element with id=="nav" with this table of contents.
|
||||
*/
|
||||
function generateTOC() {
|
||||
if ($('#manual-nav').length > 0) {
|
||||
return;
|
||||
}
|
||||
|
||||
var nav = $('#nav');
|
||||
if (nav.length === 0) {
|
||||
return;
|
||||
}
|
||||
|
||||
var toc_items = [];
|
||||
$(nav).nextAll('h2, h3').each(function() {
|
||||
var node = this;
|
||||
if (node.id == '')
|
||||
node.id = 'tmp_' + toc_items.length;
|
||||
var link = $('<a/>').attr('href', '#' + node.id).text($(node).text());
|
||||
var item;
|
||||
if ($(node).is('h2')) {
|
||||
item = $('<dt/>');
|
||||
} else { // h3
|
||||
item = $('<dd/>');
|
||||
}
|
||||
item.append(link);
|
||||
toc_items.push(item);
|
||||
});
|
||||
if (toc_items.length <= 1) {
|
||||
return;
|
||||
}
|
||||
|
||||
var dl1 = $('<dl/>');
|
||||
var dl2 = $('<dl/>');
|
||||
|
||||
var split_index = (toc_items.length / 2) + 1;
|
||||
if (split_index < 8) {
|
||||
split_index = toc_items.length;
|
||||
}
|
||||
for (var i = 0; i < split_index; i++) {
|
||||
dl1.append(toc_items[i]);
|
||||
}
|
||||
for (/* keep using i */; i < toc_items.length; i++) {
|
||||
dl2.append(toc_items[i]);
|
||||
}
|
||||
|
||||
var tocTable = $('<table class="unruled"/>').appendTo(nav);
|
||||
var tocBody = $('<tbody/>').appendTo(tocTable);
|
||||
var tocRow = $('<tr/>').appendTo(tocBody);
|
||||
|
||||
// 1st column
|
||||
$('<td class="first"/>').appendTo(tocRow).append(dl1);
|
||||
// 2nd column
|
||||
$('<td/>').appendTo(tocRow).append(dl2);
|
||||
}
|
||||
|
||||
function bindToggle(el) {
|
||||
$('.toggleButton', el).click(function() {
|
||||
if ($(el).is('.toggle')) {
|
||||
$(el).addClass('toggleVisible').removeClass('toggle');
|
||||
} else {
|
||||
$(el).addClass('toggle').removeClass('toggleVisible');
|
||||
}
|
||||
});
|
||||
}
|
||||
function bindToggles(selector) {
|
||||
$(selector).each(function(i, el) {
|
||||
bindToggle(el);
|
||||
});
|
||||
}
|
||||
|
||||
function bindToggleLink(el, prefix) {
|
||||
$(el).click(function() {
|
||||
var href = $(el).attr('href');
|
||||
var i = href.indexOf('#'+prefix);
|
||||
if (i < 0) {
|
||||
return;
|
||||
}
|
||||
var id = '#' + prefix + href.slice(i+1+prefix.length);
|
||||
if ($(id).is('.toggle')) {
|
||||
$(id).find('.toggleButton').first().click();
|
||||
}
|
||||
});
|
||||
}
|
||||
function bindToggleLinks(selector, prefix) {
|
||||
$(selector).each(function(i, el) {
|
||||
bindToggleLink(el, prefix);
|
||||
});
|
||||
}
|
||||
|
||||
function setupDropdownPlayground() {
|
||||
if (!$('#page').is('.wide')) {
|
||||
return; // don't show on front page
|
||||
}
|
||||
var button = $('#playgroundButton');
|
||||
var div = $('#playground');
|
||||
var setup = false;
|
||||
button.toggle(function() {
|
||||
button.addClass('active');
|
||||
div.show();
|
||||
if (setup) {
|
||||
return;
|
||||
}
|
||||
setup = true;
|
||||
playground({
|
||||
'codeEl': $('.code', div),
|
||||
'outputEl': $('.output', div),
|
||||
'runEl': $('.run', div),
|
||||
'fmtEl': $('.fmt', div),
|
||||
'shareEl': $('.share', div),
|
||||
'shareRedirect': 'http://play.golang.org/p/'
|
||||
});
|
||||
},
|
||||
function() {
|
||||
button.removeClass('active');
|
||||
div.hide();
|
||||
});
|
||||
button.show();
|
||||
$('#menu').css('min-width', '+=60');
|
||||
}
|
||||
|
||||
// fixFocus tries to put focus to div#page so that keyboard navigation works.
|
||||
function fixFocus() {
|
||||
var page = $('div#page');
|
||||
var topbar = $('div#topbar');
|
||||
page.css('outline', 0); // disable outline when focused
|
||||
page.attr('tabindex', -1); // and set tabindex so that it is focusable
|
||||
$(window).resize(function (evt) {
|
||||
// only focus page when the topbar is at fixed position (that is, it's in
|
||||
// front of page, and keyboard event will go to the former by default.)
|
||||
// by focusing page, keyboard event will go to page so that up/down arrow,
|
||||
// space, etc. will work as expected.
|
||||
if (topbar.css('position') == "fixed")
|
||||
page.focus();
|
||||
}).resize();
|
||||
}
|
||||
|
||||
function toggleHash() {
|
||||
var hash = $(window.location.hash);
|
||||
if (hash.is('.toggle')) {
|
||||
hash.addClass('toggleVisible').removeClass('toggle');
|
||||
}
|
||||
}
|
||||
|
||||
$(document).ready(function() {
|
||||
bindSearchEvents();
|
||||
generateTOC();
|
||||
bindToggles(".toggle");
|
||||
bindToggles(".toggleVisible");
|
||||
bindToggleLinks(".exampleLink", "example_");
|
||||
bindToggleLinks(".overviewLink", "");
|
||||
bindToggleLinks(".examplesLink", "");
|
||||
bindToggleLinks(".indexLink", "");
|
||||
setupDropdownPlayground();
|
||||
fixFocus();
|
||||
toggleHash();
|
||||
});
|
||||
|
||||
})();
|
||||
@@ -1,3 +0,0 @@
|
||||
The Go gopher was designed by Renee French. (http://reneefrench.blogspot.com/)
|
||||
The design is licensed under the Creative Commons 3.0 Attributions license.
|
||||
Read this article for more details: http://blog.golang.org/gopher
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 199 KiB |
@@ -11,20 +11,17 @@ Need help with Go? Try these resources.
|
||||
|
||||
<div id="manual-nav"></div>
|
||||
|
||||
<h3 id="faq"><a href="/doc/faq">Frequently Asked Questions (FAQ)</a></h3>
|
||||
<h3 id="go_faq"><a href="/doc/go_faq.html">Frequently Asked Questions (FAQ)</a></h3>
|
||||
<p>Answers to common questions about Go.</p>
|
||||
|
||||
<h3 id="playground"><a href="/play">The Go Playground</a></h3>
|
||||
<p>A place to write, run, and share Go code.</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>
|
||||
|
||||
<h3 id="mailinglist"><a href="//groups.google.com/group/golang-nuts">Go Nuts Mailing List</a></h3>
|
||||
<h3 id="mailinglist"><a href="http://groups.google.com/group/golang-nuts">Go Nuts Mailing List</a></h3>
|
||||
<p>
|
||||
Search the <a href="//groups.google.com/group/golang-nuts">golang-nuts</a>
|
||||
Search the <a href="http://groups.google.com/group/golang-nuts">golang-nuts</a>
|
||||
archives and consult the <a href="/doc/go_faq.html">FAQ</a> and
|
||||
<a href="//code.google.com/p/go-wiki/wiki">wiki</a> before posting.
|
||||
<a href="http://code.google.com/p/go-wiki/wiki">wiki</a> before posting.
|
||||
</p>
|
||||
|
||||
<h3 id="irc"><a href="irc:irc.freenode.net/go-nuts">Go IRC Channel</a></h3>
|
||||
@@ -37,14 +34,11 @@ 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="//twitter.com/golang">@golang at Twitter</a></h3>
|
||||
<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>
|
||||
<p>Tweeting about your problem with the <code>#golang</code> hashtag usually
|
||||
<p>Tweeting your about problem with the <code>#golang</code> hashtag usually
|
||||
generates some helpful responses.</p>
|
||||
|
||||
<h3 id="go_user_groups"><a href="/wiki/GoUserGroups">Go User Groups</a></h3>
|
||||
<p>
|
||||
Each month in places around the world, groups of Go programmers ("gophers")
|
||||
meet to talk about Go. Find a chapter near you.
|
||||
</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>
|
||||
|
||||
@@ -57,7 +57,7 @@ architectures.
|
||||
<code>arm</code> (a.k.a. <code>ARM</code>); <code>5g,5l,5c,5a</code>
|
||||
</dt>
|
||||
<dd>
|
||||
Supports Linux, FreeBSD and NetBSD binaries. Less widely used than the other ports.
|
||||
Supports only Linux binaries. Less widely used than the other ports and therefore not as thoroughly tested.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
@@ -69,8 +69,8 @@ goroutines, such as stacks that grow and shrink on demand.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The compilers can target the DragonFly BSD, FreeBSD, Linux, NetBSD, OpenBSD,
|
||||
OS X (Darwin), Plan 9, Solaris and Windows operating systems.
|
||||
The compilers can target the FreeBSD, Linux, NetBSD, OpenBSD, OS X (Darwin),
|
||||
and Windows operating systems.
|
||||
The full set of supported combinations is listed in the discussion of
|
||||
<a href="#environment">environment variables</a> below.
|
||||
</p>
|
||||
@@ -81,7 +81,7 @@ The full set of supported combinations is listed in the discussion of
|
||||
|
||||
<p>
|
||||
The Go tool chain is written in C. To build it, you need a C compiler installed.
|
||||
Please refer to the <a href="//golang.org/wiki/InstallFromSource#Install_C_tools">InstallFromSource</a>
|
||||
Please refer to the <a href="http://code.google.com/p/go-wiki/wiki/InstallFromSource#Install_C_tools">InstallFromSource</a>
|
||||
page on the Go community Wiki for operating system specific instructions.
|
||||
</p>
|
||||
|
||||
@@ -95,7 +95,7 @@ have an <code>hg</code> command.)
|
||||
<p>
|
||||
If you do not have a working Mercurial installation,
|
||||
follow the instructions on the
|
||||
<a href="http://mercurial.selenic.com/downloads">Mercurial downloads</a> page.
|
||||
<a href="http://mercurial.selenic.com/downloads/">Mercurial downloads</a> page.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@@ -176,10 +176,6 @@ architecture, and root directory used during the install.
|
||||
<p>
|
||||
For more information about ways to control the build, see the discussion of
|
||||
<a href="#environment">environment variables</a> below.
|
||||
<code>all.bash</code> (or <code>all.bat</code>) runs important tests for Go,
|
||||
which can take more time than simply building Go. If you do not want to run
|
||||
the test suite use <code>make.bash</code> (or <code>make.bat</code>)
|
||||
instead.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
@@ -220,61 +216,8 @@ If you see the "hello, world" message then Go is installed correctly.
|
||||
<h2 id="gopath">Set up your work environment</h2>
|
||||
|
||||
<p>
|
||||
You're almost done.
|
||||
You just need to do a little more setup.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="/doc/code.html" class="download" id="start">
|
||||
<span class="big">How to Write Go Code</span>
|
||||
<span class="desc">Learn how to set up and use the Go tools</span>
|
||||
</a>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <a href="/doc/code.html">How to Write Go Code</a> document
|
||||
provides <b>essential setup instructions</b> for using the Go tools.
|
||||
</p>
|
||||
|
||||
|
||||
<h2 id="tools">Install additional tools</h2>
|
||||
|
||||
<p>
|
||||
The source code for several Go tools (including <a href="/cmd/godoc/">godoc</a>)
|
||||
is kept in <a href="https://code.google.com/p/go.tools">the go.tools repository</a>.
|
||||
To install all of them, run the <code>go</code> <code>get</code> command:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ go get code.google.com/p/go.tools/cmd/...
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Or if you just want to install a specific command (<code>godoc</code> in this case):
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ go get code.google.com/p/go.tools/cmd/godoc
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
To install these tools, the <code>go</code> <code>get</code> command requires
|
||||
that <a href="#mercurial">Mercurial</a> be installed locally.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
You must also have a workspace (<code>GOPATH</code>) set up;
|
||||
see <a href="/doc/code.html">How to Write Go Code</a> for the details.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Note</b>: The <code>go</code> command will install the <code>godoc</code>
|
||||
binary to <code>$GOROOT/bin</code> (or <code>$GOBIN</code>) and the
|
||||
<code>cover</code> and <code>vet</code> binaries to
|
||||
<code>$GOROOT/pkg/tool/$GOOS_$GOARCH</code>.
|
||||
You can access the latter commands with
|
||||
"<code>go</code> <code>tool</code> <code>cover</code>" and
|
||||
"<code>go</code> <code>tool</code> <code>vet</code>".
|
||||
The document <a href="/doc/code.html">How to Write Go Code</a> explains how to
|
||||
set up a work environment in which to build and test Go code.
|
||||
</p>
|
||||
|
||||
<h2 id="community">Community resources</h2>
|
||||
@@ -283,16 +226,16 @@ You can access the latter commands with
|
||||
The usual community resources such as
|
||||
<code>#go-nuts</code> on the <a href="http://freenode.net/">Freenode</a> IRC server
|
||||
and the
|
||||
<a href="//groups.google.com/group/golang-nuts">Go Nuts</a>
|
||||
<a href="http://groups.google.com/group/golang-nuts">Go Nuts</a>
|
||||
mailing list have active developers that can help you with problems
|
||||
with your installation or your development work.
|
||||
For those who wish to keep up to date,
|
||||
there is another mailing list, <a href="//groups.google.com/group/golang-checkins">golang-checkins</a>,
|
||||
there is another mailing list, <a href="http://groups.google.com/group/golang-checkins">golang-checkins</a>,
|
||||
that receives a message summarizing each checkin to the Go repository.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Bugs can be reported using the <a href="//code.google.com/p/go/issues/list">Go issue tracker</a>.
|
||||
Bugs can be reported using the <a href="http://code.google.com/p/go/issues/list">Go issue tracker</a>.
|
||||
</p>
|
||||
|
||||
|
||||
@@ -306,7 +249,7 @@ The Go project maintains a stable tag in its Mercurial repository:
|
||||
<p>
|
||||
The <code>release</code> tag refers to the current stable release of Go.
|
||||
Most Go users should use this version. New releases are announced on the
|
||||
<a href="//groups.google.com/group/golang-announce">golang-announce</a>
|
||||
<a href="http://groups.google.com/group/golang-announce">golang-announce</a>
|
||||
mailing list.
|
||||
</p>
|
||||
|
||||
@@ -330,8 +273,9 @@ The Go compilation environment can be customized by environment variables.
|
||||
to override the defaults.
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li><code>$GOROOT</code>
|
||||
<blockquote>
|
||||
|
||||
<p><code>$GOROOT</code></p>
|
||||
<p>
|
||||
The root of the Go tree, often <code>$HOME/go</code>.
|
||||
Its value is built into the tree when it is compiled, and
|
||||
@@ -340,7 +284,7 @@ There is no need to set this unless you want to switch between multiple
|
||||
local copies of the repository.
|
||||
</p>
|
||||
|
||||
<li><code>$GOROOT_FINAL</code>
|
||||
<p><code>$GOROOT_FINAL</code></p>
|
||||
<p>
|
||||
The value assumed by installed binaries and scripts when
|
||||
<code>$GOROOT</code> is not set explicitly.
|
||||
@@ -350,7 +294,7 @@ but move it elsewhere after the build, set
|
||||
<code>$GOROOT_FINAL</code> to the eventual location.
|
||||
</p>
|
||||
|
||||
<li><code>$GOOS</code> and <code>$GOARCH</code>
|
||||
<p><code>$GOOS</code> and <code>$GOARCH</code></p>
|
||||
<p>
|
||||
The name of the target operating system and compilation architecture.
|
||||
These default to the values of <code>$GOHOSTOS</code> and
|
||||
@@ -358,16 +302,16 @@ These default to the values of <code>$GOHOSTOS</code> and
|
||||
|
||||
<p>
|
||||
Choices for <code>$GOOS</code> are
|
||||
<code>darwin</code> (Mac OS X 10.6 and above), <code>dragonfly</code>, <code>freebsd</code>,
|
||||
<code>darwin</code> (Mac OS X 10.6 and above), <code>freebsd</code>,
|
||||
<code>linux</code>, <code>netbsd</code>, <code>openbsd</code>,
|
||||
<code>plan9</code>, <code>solaris</code> and <code>windows</code>.
|
||||
<code>plan9</code>, and <code>windows</code>.
|
||||
Choices for <code>$GOARCH</code> are
|
||||
<code>amd64</code> (64-bit x86, the most mature port),
|
||||
<code>386</code> (32-bit x86), and <code>arm</code> (32-bit ARM).
|
||||
The valid combinations of <code>$GOOS</code> and <code>$GOARCH</code> are:
|
||||
<table cellpadding="0">
|
||||
<tr>
|
||||
<th width="50"></th><th align="left" width="100"><code>$GOOS</code></th> <th align="left" width="100"><code>$GOARCH</code></th>
|
||||
<th width="50"><th align="left" width="100"><code>$GOOS</code></th> <th align="left" width="100"><code>$GOARCH</code></th> <th align="left"></th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td><code>darwin</code></td> <td><code>386</code></td>
|
||||
@@ -376,21 +320,12 @@ The valid combinations of <code>$GOOS</code> and <code>$GOARCH</code> are:
|
||||
<td></td><td><code>darwin</code></td> <td><code>amd64</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td><code>dragonfly</code></td> <td><code>386</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td><code>dragonfly</code></td> <td><code>amd64</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td><code>freebsd</code></td> <td><code>386</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td><code>freebsd</code></td> <td><code>amd64</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td><code>freebsd</code></td> <td><code>arm</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td><code>linux</code></td> <td><code>386</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
@@ -406,9 +341,6 @@ The valid combinations of <code>$GOOS</code> and <code>$GOARCH</code> are:
|
||||
<td></td><td><code>netbsd</code></td> <td><code>amd64</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td><code>netbsd</code></td> <td><code>arm</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td><code>openbsd</code></td> <td><code>386</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
@@ -418,12 +350,6 @@ The valid combinations of <code>$GOOS</code> and <code>$GOARCH</code> are:
|
||||
<td></td><td><code>plan9</code></td> <td><code>386</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td><code>plan9</code></td> <td><code>amd64</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td><code>solaris</code></td> <td><code>amd64</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td><code>windows</code></td> <td><code>386</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
@@ -431,7 +357,7 @@ The valid combinations of <code>$GOOS</code> and <code>$GOARCH</code> are:
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<li><code>$GOHOSTOS</code> and <code>$GOHOSTARCH</code>
|
||||
<p><code>$GOHOSTOS</code> and <code>$GOHOSTARCH</code></p>
|
||||
<p>
|
||||
The name of the host operating system and compilation architecture.
|
||||
These default to the local system's operating system and
|
||||
@@ -446,7 +372,7 @@ For example, you should not set <code>$GOHOSTARCH</code> to
|
||||
<code>arm</code> on an x86 system.
|
||||
</p>
|
||||
|
||||
<li><code>$GOBIN</code>
|
||||
<p><code>$GOBIN</code>
|
||||
<p>
|
||||
The location where Go binaries will be installed.
|
||||
The default is <code>$GOROOT/bin</code>.
|
||||
@@ -456,38 +382,15 @@ If <code>$GOBIN</code> is set, the <a href="/cmd/go">go command</a>
|
||||
installs all commands there.
|
||||
</p>
|
||||
|
||||
<li><code>$GO386</code> (for <code>386</code> only, default is auto-detected
|
||||
if built on either <code>386</code> or <code>amd64</code>, <code>387</code> otherwise)
|
||||
<p><code>$GOARM</code> (arm, default=6)</p>
|
||||
<p>
|
||||
This controls the code generated by 8g to use either the 387 floating-point unit
|
||||
(set to <code>387</code>) or SSE2 instructions (set to <code>sse2</code>) for
|
||||
floating point computations.
|
||||
</p>
|
||||
<ul>
|
||||
<li><code>GO386=387</code>: use x87 for floating point operations; should support all x86 chips (Pentium MMX or later).
|
||||
<li><code>GO386=sse2</code>: use SSE2 for floating point operations; has better performance than 387, but only available on Pentium 4/Opteron/Athlon 64 or later.
|
||||
</ul>
|
||||
|
||||
<li><code>$GOARM</code> (for <code>arm</code> only; default is auto-detected if building
|
||||
on the target processor, 6 if not)
|
||||
<p>
|
||||
This sets the ARM floating point co-processor architecture version the run-time
|
||||
should target. If you are compiling on the target system, its value will be auto-detected.
|
||||
</p>
|
||||
<ul>
|
||||
<li><code>GOARM=5</code>: use software floating point; when CPU doesn't have VFP co-processor
|
||||
<li><code>GOARM=6</code>: use VFPv1 only; default if cross compiling; usually ARM11 or better cores (VFPv2 or better is also supported)
|
||||
<li><code>GOARM=7</code>: use VFPv3; usually Cortex-A cores
|
||||
</ul>
|
||||
<p>
|
||||
If in doubt, leave this variable unset, and adjust it if required
|
||||
when you first run the Go executable.
|
||||
The <a href="//golang.org/wiki/GoArm">GoARM</a> page
|
||||
on the <a href="//golang.org/wiki">Go community wiki</a>
|
||||
contains further details regarding Go's ARM support.
|
||||
The ARM architecture version the run-time libraries should target.
|
||||
Setting <code>$GOARM</code> to 5 causes the linker to emit calls
|
||||
to a software floating point implementation instead of using
|
||||
hardware floating point support.
|
||||
</p>
|
||||
|
||||
</ul>
|
||||
</blockquote>
|
||||
|
||||
<p>
|
||||
Note that <code>$GOARCH</code> and <code>$GOOS</code> identify the
|
||||
|
||||
207
doc/install.html
207
doc/install.html
@@ -6,29 +6,34 @@
|
||||
<h2 id="download">Download the Go distribution</h2>
|
||||
|
||||
<p>
|
||||
<a href="https://golang.org/dl/" id="start" class="download" target="_blank">
|
||||
<a href="http://code.google.com/p/go/downloads" id="start" class="download" target="_blank">
|
||||
<span class="big">Download Go</span>
|
||||
<span class="desc">Click here to visit the downloads page</span>
|
||||
</a>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="https://golang.org/dl/" target="_blank">Official binary
|
||||
distributions</a> are available for the FreeBSD (release 8 and above), Linux, Mac OS X (Snow Leopard
|
||||
and above), and Windows operating systems and the 32-bit (<code>386</code>) and
|
||||
64-bit (<code>amd64</code>) x86 processor architectures.
|
||||
Click the link above to visit the
|
||||
<a href="http://code.google.com/p/go/downloads">Go project's downloads page</a>
|
||||
and select the binary distribution that matches your operating system and
|
||||
processor architecture.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Official binary distributions are available for the FreeBSD, Linux, Mac OS X
|
||||
(Snow Leopard, Lion, and Mountain Lion), NetBSD, and Windows operating systems
|
||||
and the 32-bit (<code>386</code>) and 64-bit (<code>amd64</code>) x86 processor
|
||||
architectures.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If a binary distribution is not available for your combination of operating
|
||||
system and architecture, try
|
||||
system and architecture you may want to try
|
||||
<a href="/doc/install/source">installing from source</a> or
|
||||
<a href="/doc/install/gccgo">installing gccgo instead of gc</a>.
|
||||
</p>
|
||||
|
||||
|
||||
<h2 id="requirements">System requirements</h2>
|
||||
|
||||
<p>
|
||||
The <code>gc</code> compiler supports the following operating systems and
|
||||
architectures. Please ensure your system meets these requirements before
|
||||
@@ -39,15 +44,16 @@ proceeding. If your OS or architecture is not on the list, it's possible that
|
||||
|
||||
<table class="codetable" frame="border" summary="requirements">
|
||||
<tr>
|
||||
<th align="center">Operating system</th>
|
||||
<th align="center">Architectures</th>
|
||||
<th align="center">Notes</th>
|
||||
<th align="middle">Operating system</th>
|
||||
<th align="middle">Architectures</th>
|
||||
<th align="middle">Notes</th>
|
||||
</tr>
|
||||
<tr><td colspan="3"><hr></td></tr>
|
||||
<tr><td>FreeBSD 8 or later</td> <td>amd64, 386, arm</td> <td>Debian GNU/kFreeBSD not supported; FreeBSD/ARM needs FreeBSD 10 or later</td></tr>
|
||||
<tr><td>FreeBSD 7 or later</td> <td>amd64, 386, arm</td> <td>Debian GNU/kFreeBSD not supported; FreeBSD/ARM needs FreeBSD 10 or later</td></tr>
|
||||
<tr><td>Linux 2.6.23 or later with glibc</td> <td>amd64, 386, arm</td> <td>CentOS/RHEL 5.x not supported; no binary distribution for ARM yet</td></tr>
|
||||
<tr><td>Mac OS X 10.6 or later</td> <td>amd64, 386</td> <td>use the gcc<sup>†</sup> that comes with Xcode<sup>‡</sup></td></tr>
|
||||
<tr><td>Windows XP or later</td> <td>amd64, 386</td> <td>use MinGW gcc<sup>†</sup>. No need for cgywin or msys.</td></tr>
|
||||
<tr><td>Mac OS X 10.6/10.7</td> <td>amd64, 386</td> <td>use the gcc<sup>†</sup> that comes with Xcode<sup>‡</sup></td></tr>
|
||||
<tr><td>Windows 2000 or later</td> <td>amd64, 386</td> <td>use mingw gcc<sup>†</sup>; cygwin or msys is not needed</td></tr>
|
||||
<tr><td>NetBSD 6 or later</td> <td>amd64, 386</td> <td></td></tr>
|
||||
</table>
|
||||
|
||||
<p>
|
||||
@@ -59,30 +65,55 @@ installed Xcode 4.3+, you can install it from the Components tab of the
|
||||
Downloads preferences panel.
|
||||
</p>
|
||||
|
||||
|
||||
<h2 id="install">Install the Go tools</h2>
|
||||
|
||||
<p>
|
||||
If you are upgrading from an older version of Go you must
|
||||
first <a href="#uninstall">remove the existing version</a>.
|
||||
The Go binary distributions assume they will be installed in
|
||||
<code>/usr/local/go</code> (or <code>c:\Go</code> under Windows),
|
||||
but it is possible to install them in a different
|
||||
location. If you do this, you will need to set the <code>GOROOT</code>
|
||||
environment variable to that directory when using the Go tools.
|
||||
</p>
|
||||
|
||||
<h3 id="tarball">Linux, Mac OS X, and FreeBSD tarballs</h3>
|
||||
|
||||
<p>
|
||||
<a href="https://golang.org/dl/">Download the archive</a>
|
||||
and extract it into <code>/usr/local</code>, creating a Go tree in
|
||||
<code>/usr/local/go</code>. For example:
|
||||
For example, if you installed Go to your home directory you should add the
|
||||
following commands to <code>$HOME/.profile</code>:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz
|
||||
export GOROOT=$HOME/go
|
||||
export PATH=$PATH:$GOROOT/bin
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Choose the archive file appropriate for your installation.
|
||||
For instance, if you are installing Go version 1.2.1 for 64-bit x86 on Linux,
|
||||
the archive you want is called <code>go1.2.1.linux-amd64.tar.gz</code>.
|
||||
Windows users should read the section about <a href="#windows_env">setting
|
||||
environment variables under Windows</a>.
|
||||
</p>
|
||||
|
||||
<h3 id="bsd_linux">FreeBSD, Linux, Mac OS X and NetBSD tarballs</h3>
|
||||
|
||||
<p>
|
||||
If you are upgrading from an older version of Go you must
|
||||
first remove the existing version from <code>/usr/local/go</code>:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
rm -r /usr/local/go
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Extract <a href="http://code.google.com/p/go/downloads/list?q=OpSys-FreeBSD+OR+OpSys-Linux+OR+OpSys-OSX+OR+OpSys-NetBSD+Type-Archive">the archive</a>
|
||||
into <code>/usr/local</code>, creating a Go tree in <code>/usr/local/go</code>.
|
||||
For example:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
tar -C /usr/local -xzf go1.0.3.linux-amd64.tar.gz
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The name of the archive may differ, depending on the version of Go you are
|
||||
installing and your system's operating system and processor architecture.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@@ -99,36 +130,11 @@ variable. You can do this by adding this line to your <code>/etc/profile</code>
|
||||
export PATH=$PATH:/usr/local/go/bin
|
||||
</pre>
|
||||
|
||||
<h4 id="tarball_non_standard">Installing to a custom location</h4>
|
||||
|
||||
<p>
|
||||
The Go binary distributions assume they will be installed in
|
||||
<code>/usr/local/go</code> (or <code>c:\Go</code> under Windows),
|
||||
but it is possible to install the Go tools to a different location.
|
||||
In this case you must set the <code>GOROOT</code> environment variable
|
||||
to point to the directory in which it was installed.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For example, if you installed Go to your home directory you should add the
|
||||
following commands to <code>$HOME/.profile</code>:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
export GOROOT=$HOME/go
|
||||
export PATH=$PATH:$GOROOT/bin
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
<b>Note</b>: <code>GOROOT</code> must be set only when installing to a custom
|
||||
location.
|
||||
</p>
|
||||
|
||||
<h3 id="osx">Mac OS X package installer</h3>
|
||||
|
||||
<p>
|
||||
<a href="https://golang.org/dl/">Download the package file</a>,
|
||||
open it, and follow the prompts to install the Go tools.
|
||||
Open the <a href="http://code.google.com/p/go/downloads/list?q=OpSys-OSX+Type-Installer">package file</a>
|
||||
and follow the prompts to install the Go tools.
|
||||
The package installs the Go distribution to <code>/usr/local/go</code>.
|
||||
</p>
|
||||
|
||||
@@ -144,13 +150,29 @@ Terminal sessions for the change to take effect.
|
||||
The Go project provides two installation options for Windows users
|
||||
(besides <a href="/doc/install/source">installing from source</a>):
|
||||
a zip archive that requires you to set some environment variables and an
|
||||
MSI installer that configures your installation automatically.
|
||||
experimental MSI installer that configures your installation automatically.
|
||||
</p>
|
||||
|
||||
<h4 id="windows_msi">MSI installer</h4>
|
||||
<h4 id="windows_zip">Zip archive</h4>
|
||||
|
||||
<p>
|
||||
Open the <a href="https://golang.org/dl/">MSI file</a>
|
||||
Extract the <a href="http://code.google.com/p/go/downloads/list?q=OpSys-Windows+Type%3DArchive">zip file</a>
|
||||
to the directory of your choice (we suggest <code>c:\Go</code>).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If you chose a directory other than <code>c:\Go</code>, you must set
|
||||
the <code>GOROOT</code> environment variable to your chosen path.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Add the <code>bin</code> subdirectory of your Go root (for example, <code>c:\Go\bin</code>) to your <code>PATH</code> environment variable.
|
||||
</p>
|
||||
|
||||
<h4 id="windows_msi">MSI installer (experimental)</h4>
|
||||
|
||||
<p>
|
||||
Open the <a href="http://code.google.com/p/go/downloads/list?q=OpSys-Windows+Type%3DInstaller">MSI file</a>
|
||||
and follow the prompts to install the Go tools.
|
||||
By default, the installer puts the Go distribution in <code>c:\Go</code>.
|
||||
</p>
|
||||
@@ -161,21 +183,6 @@ The installer should put the <code>c:\Go\bin</code> directory in your
|
||||
command prompts for the change to take effect.
|
||||
</p>
|
||||
|
||||
<h4 id="windows_zip">Zip archive</h4>
|
||||
|
||||
<p>
|
||||
<a href="https://golang.org/dl/">Download the zip file</a> and extract it into the directory of your choice (we suggest <code>c:\Go</code>).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If you chose a directory other than <code>c:\Go</code>,
|
||||
you must set the <code>GOROOT</code> environment variable to your chosen path.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Add the <code>bin</code> subdirectory of your Go root (for example, <code>c:\Go\bin</code>) to your <code>PATH</code> environment variable.
|
||||
</p>
|
||||
|
||||
<h4 id="windows_env">Setting environment variables under Windows</h4>
|
||||
|
||||
<p>
|
||||
@@ -185,7 +192,6 @@ versions of Windows provide this control panel through the "Advanced System
|
||||
Settings" option inside the "System" control panel.
|
||||
</p>
|
||||
|
||||
|
||||
<h2 id="testing">Test your installation</h2>
|
||||
|
||||
<p>
|
||||
@@ -219,54 +225,53 @@ hello, world
|
||||
If you see the "hello, world" message then your Go installation is working.
|
||||
</p>
|
||||
|
||||
|
||||
<h2 id="gopath">Set up your work environment</h2>
|
||||
|
||||
<p>
|
||||
You're almost done.
|
||||
You just need to set up your environment.
|
||||
The document <a href="/doc/code.html">How to Write Go Code</a> explains how to
|
||||
set up a work environment in which to build and test Go code.
|
||||
</p>
|
||||
|
||||
<h2 id="next">What's next</h2>
|
||||
|
||||
<p>
|
||||
Start by taking <a href="http://code.google.com/p/go-tour/">A Tour of Go</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Read the <a href="/doc/code.html">How to Write Go Code</a> document,
|
||||
which provides <b>essential setup instructions</b> for using the Go tools.
|
||||
</p>
|
||||
|
||||
|
||||
<h2 id="uninstall">Uninstalling Go</h2>
|
||||
|
||||
<p>
|
||||
To remove an existing Go installation from your system delete the
|
||||
<code>go</code> directory. This is usually <code>/usr/local/go</code>
|
||||
under Linux, Mac OS X, and FreeBSD or <code>c:\Go</code>
|
||||
under Windows.
|
||||
Build a web application by following the <a href="/doc/articles/wiki/">Wiki
|
||||
Tutorial</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
You should also remove the Go <code>bin</code> directory from your
|
||||
<code>PATH</code> environment variable.
|
||||
Under Linux and FreeBSD you should edit <code>/etc/profile</code> or
|
||||
<code>$HOME/.profile</code>.
|
||||
If you installed Go with the <a href="#osx">Mac OS X package</a> then you
|
||||
should remove the <code>/etc/paths.d/go</code> file.
|
||||
Windows users should read the section about <a href="#windows_env">setting
|
||||
environment variables under Windows</a>.
|
||||
Read <a href="/doc/effective_go.html">Effective Go</a> to learn about writing
|
||||
idiomatic Go code.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For the full story, consult Go's extensive <a href="/doc/">documentation</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Subscribe to the
|
||||
<a href="http://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="help">Getting help</h2>
|
||||
<h2 id="community">Community resources</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.
|
||||
For real-time help, there may be users or developers on
|
||||
<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>.
|
||||
<a href="http://groups.google.com/group/golang-nuts">Go Nuts</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Report bugs using the
|
||||
<a href="//golang.org/issue">Go issue tracker</a>.
|
||||
Bugs should be reported using the
|
||||
<a href="http://code.google.com/p/go/issues/list">Go issue tracker</a>.
|
||||
</p>
|
||||
|
||||
2
doc/jquery.js
vendored
Normal file
2
doc/jquery.js
vendored
Normal file
File diff suppressed because one or more lines are too long
113
doc/play/life.go
113
doc/play/life.go
@@ -1,113 +0,0 @@
|
||||
// An implementation of Conway's Game of Life.
|
||||
package main
|
||||
|
||||
import (
|
||||
"bytes"
|
||||
"fmt"
|
||||
"math/rand"
|
||||
"time"
|
||||
)
|
||||
|
||||
// Field represents a two-dimensional field of cells.
|
||||
type Field struct {
|
||||
s [][]bool
|
||||
w, h int
|
||||
}
|
||||
|
||||
// NewField returns an empty field of the specified width and height.
|
||||
func NewField(w, h int) *Field {
|
||||
s := make([][]bool, h)
|
||||
for i := range s {
|
||||
s[i] = make([]bool, w)
|
||||
}
|
||||
return &Field{s: s, w: w, h: h}
|
||||
}
|
||||
|
||||
// Set sets the state of the specified cell to the given value.
|
||||
func (f *Field) Set(x, y int, b bool) {
|
||||
f.s[y][x] = b
|
||||
}
|
||||
|
||||
// Alive reports whether the specified cell is alive.
|
||||
// If the x or y coordinates are outside the field boundaries they are wrapped
|
||||
// toroidally. For instance, an x value of -1 is treated as width-1.
|
||||
func (f *Field) Alive(x, y int) bool {
|
||||
x += f.w
|
||||
x %= f.w
|
||||
y += f.h
|
||||
y %= f.h
|
||||
return f.s[y][x]
|
||||
}
|
||||
|
||||
// Next returns the state of the specified cell at the next time step.
|
||||
func (f *Field) Next(x, y int) bool {
|
||||
// Count the adjacent cells that are alive.
|
||||
alive := 0
|
||||
for i := -1; i <= 1; i++ {
|
||||
for j := -1; j <= 1; j++ {
|
||||
if (j != 0 || i != 0) && f.Alive(x+i, y+j) {
|
||||
alive++
|
||||
}
|
||||
}
|
||||
}
|
||||
// Return next state according to the game rules:
|
||||
// exactly 3 neighbors: on,
|
||||
// exactly 2 neighbors: maintain current state,
|
||||
// otherwise: off.
|
||||
return alive == 3 || alive == 2 && f.Alive(x, y)
|
||||
}
|
||||
|
||||
// Life stores the state of a round of Conway's Game of Life.
|
||||
type Life struct {
|
||||
a, b *Field
|
||||
w, h int
|
||||
}
|
||||
|
||||
// NewLife returns a new Life game state with a random initial state.
|
||||
func NewLife(w, h int) *Life {
|
||||
a := NewField(w, h)
|
||||
for i := 0; i < (w * h / 4); i++ {
|
||||
a.Set(rand.Intn(w), rand.Intn(h), true)
|
||||
}
|
||||
return &Life{
|
||||
a: a, b: NewField(w, h),
|
||||
w: w, h: h,
|
||||
}
|
||||
}
|
||||
|
||||
// Step advances the game by one instant, recomputing and updating all cells.
|
||||
func (l *Life) Step() {
|
||||
// Update the state of the next field (b) from the current field (a).
|
||||
for y := 0; y < l.h; y++ {
|
||||
for x := 0; x < l.w; x++ {
|
||||
l.b.Set(x, y, l.a.Next(x, y))
|
||||
}
|
||||
}
|
||||
// Swap fields a and b.
|
||||
l.a, l.b = l.b, l.a
|
||||
}
|
||||
|
||||
// String returns the game board as a string.
|
||||
func (l *Life) String() string {
|
||||
var buf bytes.Buffer
|
||||
for y := 0; y < l.h; y++ {
|
||||
for x := 0; x < l.w; x++ {
|
||||
b := byte(' ')
|
||||
if l.a.Alive(x, y) {
|
||||
b = '*'
|
||||
}
|
||||
buf.WriteByte(b)
|
||||
}
|
||||
buf.WriteByte('\n')
|
||||
}
|
||||
return buf.String()
|
||||
}
|
||||
|
||||
func main() {
|
||||
l := NewLife(40, 15)
|
||||
for i := 0; i < 300; i++ {
|
||||
l.Step()
|
||||
fmt.Print("\x0c", l) // Clear screen and print field.
|
||||
time.Sleep(time.Second / 30)
|
||||
}
|
||||
}
|
||||
296
doc/play/playground.js
Normal file
296
doc/play/playground.js
Normal file
@@ -0,0 +1,296 @@
|
||||
// Copyright 2012 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.
|
||||
|
||||
// opts is an object with these keys
|
||||
// codeEl - code editor element
|
||||
// outputEl - program output element
|
||||
// runEl - run button element
|
||||
// fmtEl - fmt button element (optional)
|
||||
// shareEl - share button element (optional)
|
||||
// shareURLEl - share URL text input element (optional)
|
||||
// shareRedirect - base URL to redirect to on share (optional)
|
||||
// toysEl - toys select element (optional)
|
||||
// enableHistory - enable using HTML5 history API (optional)
|
||||
function playground(opts) {
|
||||
var code = $(opts['codeEl']);
|
||||
|
||||
// autoindent helpers.
|
||||
function insertTabs(n) {
|
||||
// find the selection start and end
|
||||
var start = code[0].selectionStart;
|
||||
var end = code[0].selectionEnd;
|
||||
// split the textarea content into two, and insert n tabs
|
||||
var v = code[0].value;
|
||||
var u = v.substr(0, start);
|
||||
for (var i=0; i<n; i++) {
|
||||
u += "\t";
|
||||
}
|
||||
u += v.substr(end);
|
||||
// set revised content
|
||||
code[0].value = u;
|
||||
// reset caret position after inserted tabs
|
||||
code[0].selectionStart = start+n;
|
||||
code[0].selectionEnd = start+n;
|
||||
}
|
||||
function autoindent(el) {
|
||||
var curpos = el.selectionStart;
|
||||
var tabs = 0;
|
||||
while (curpos > 0) {
|
||||
curpos--;
|
||||
if (el.value[curpos] == "\t") {
|
||||
tabs++;
|
||||
} else if (tabs > 0 || el.value[curpos] == "\n") {
|
||||
break;
|
||||
}
|
||||
}
|
||||
setTimeout(function() {
|
||||
insertTabs(tabs);
|
||||
}, 1);
|
||||
}
|
||||
|
||||
function keyHandler(e) {
|
||||
if (e.keyCode == 9) { // tab
|
||||
insertTabs(1);
|
||||
e.preventDefault();
|
||||
return false;
|
||||
}
|
||||
if (e.keyCode == 13) { // enter
|
||||
if (e.shiftKey) { // +shift
|
||||
run();
|
||||
e.preventDefault();
|
||||
return false;
|
||||
} else {
|
||||
autoindent(e.target);
|
||||
}
|
||||
}
|
||||
return true;
|
||||
}
|
||||
code.unbind('keydown').bind('keydown', keyHandler);
|
||||
var output = $(opts['outputEl']);
|
||||
|
||||
function body() {
|
||||
return $(opts['codeEl']).val();
|
||||
}
|
||||
function setBody(text) {
|
||||
$(opts['codeEl']).val(text);
|
||||
}
|
||||
function origin(href) {
|
||||
return (""+href).split("/").slice(0, 3).join("/");
|
||||
}
|
||||
function loading() {
|
||||
output.removeClass("error").html(
|
||||
'<div class="loading">Waiting for remote server...</div>'
|
||||
);
|
||||
}
|
||||
var playbackTimeout;
|
||||
function playback(pre, events) {
|
||||
function show(msg) {
|
||||
// ^L clears the screen.
|
||||
var msgs = msg.split("\x0c");
|
||||
if (msgs.length == 1) {
|
||||
pre.text(pre.text() + msg);
|
||||
return;
|
||||
}
|
||||
pre.text(msgs.pop());
|
||||
}
|
||||
function next() {
|
||||
if (events.length == 0) {
|
||||
var exit = $('<span class="exit"/>');
|
||||
exit.text("\nProgram exited.");
|
||||
exit.appendTo(pre);
|
||||
return;
|
||||
}
|
||||
var e = events.shift();
|
||||
if (e.Delay == 0) {
|
||||
show(e.Message);
|
||||
next();
|
||||
} else {
|
||||
playbackTimeout = setTimeout(function() {
|
||||
show(e.Message);
|
||||
next();
|
||||
}, e.Delay / 1000000);
|
||||
}
|
||||
}
|
||||
next();
|
||||
}
|
||||
function stopPlayback() {
|
||||
clearTimeout(playbackTimeout);
|
||||
}
|
||||
function setOutput(events, error) {
|
||||
stopPlayback();
|
||||
output.empty();
|
||||
$(".lineerror").removeClass("lineerror");
|
||||
|
||||
// Display errors.
|
||||
if (error) {
|
||||
output.addClass("error");
|
||||
var regex = /prog.go:([0-9]+)/g;
|
||||
var r;
|
||||
while (r = regex.exec(error)) {
|
||||
$(".lines div").eq(r[1]-1).addClass("lineerror");
|
||||
}
|
||||
$("<pre/>").text(error).appendTo(output);
|
||||
return;
|
||||
}
|
||||
|
||||
// Display image output.
|
||||
if (events.length > 0 && events[0].Message.indexOf("IMAGE:") == 0) {
|
||||
var out = "";
|
||||
for (var i = 0; i < events.length; i++) {
|
||||
out += events[i].Message;
|
||||
}
|
||||
var url = "data:image/png;base64," + out.substr(6);
|
||||
$("<img/>").attr("src", url).appendTo(output);
|
||||
return;
|
||||
}
|
||||
|
||||
// Play back events.
|
||||
if (events !== null) {
|
||||
var pre = $("<pre/>").appendTo(output);
|
||||
playback(pre, events);
|
||||
}
|
||||
}
|
||||
|
||||
var pushedEmpty = (window.location.pathname == "/");
|
||||
function inputChanged() {
|
||||
if (pushedEmpty) {
|
||||
return;
|
||||
}
|
||||
pushedEmpty = true;
|
||||
|
||||
$(opts['shareURLEl']).hide();
|
||||
window.history.pushState(null, "", "/");
|
||||
}
|
||||
|
||||
function popState(e) {
|
||||
if (e == null) {
|
||||
return;
|
||||
}
|
||||
|
||||
if (e && e.state && e.state.code) {
|
||||
setBody(e.state.code);
|
||||
}
|
||||
}
|
||||
|
||||
var rewriteHistory = false;
|
||||
|
||||
if (window.history &&
|
||||
window.history.pushState &&
|
||||
window.addEventListener &&
|
||||
opts['enableHistory']) {
|
||||
rewriteHistory = true;
|
||||
code[0].addEventListener('input', inputChanged);
|
||||
window.addEventListener('popstate', popState)
|
||||
}
|
||||
|
||||
var seq = 0;
|
||||
function run() {
|
||||
loading();
|
||||
seq++;
|
||||
var cur = seq;
|
||||
var data = {
|
||||
"version": 2,
|
||||
"body": body()
|
||||
};
|
||||
$.ajax("/compile", {
|
||||
data: data,
|
||||
type: "POST",
|
||||
dataType: "json",
|
||||
success: function(data) {
|
||||
if (seq != cur) {
|
||||
return;
|
||||
}
|
||||
if (!data) {
|
||||
return;
|
||||
}
|
||||
if (data.Errors) {
|
||||
setOutput(null, data.Errors);
|
||||
return;
|
||||
}
|
||||
setOutput(data.Events, false);
|
||||
},
|
||||
error: function() {
|
||||
output.addClass("error").text(
|
||||
"Error communicating with remote server."
|
||||
);
|
||||
}
|
||||
});
|
||||
}
|
||||
$(opts['runEl']).click(run);
|
||||
|
||||
$(opts['fmtEl']).click(function() {
|
||||
loading();
|
||||
$.ajax("/fmt", {
|
||||
data: {"body": body()},
|
||||
type: "POST",
|
||||
dataType: "json",
|
||||
success: function(data) {
|
||||
if (data.Error) {
|
||||
setOutput(null, data.Error);
|
||||
return;
|
||||
}
|
||||
setBody(data.Body);
|
||||
setOutput(null);
|
||||
}
|
||||
});
|
||||
});
|
||||
|
||||
if (opts['shareEl'] != null && (opts['shareURLEl'] != null || opts['shareRedirect'] != null)) {
|
||||
var shareURL;
|
||||
if (opts['shareURLEl']) {
|
||||
shareURL = $(opts['shareURLEl']).hide();
|
||||
}
|
||||
var sharing = false;
|
||||
$(opts['shareEl']).click(function() {
|
||||
if (sharing) return;
|
||||
sharing = true;
|
||||
var sharingData = body();
|
||||
$.ajax("/share", {
|
||||
processData: false,
|
||||
data: sharingData,
|
||||
type: "POST",
|
||||
complete: function(xhr) {
|
||||
sharing = false;
|
||||
if (xhr.status != 200) {
|
||||
alert("Server error; try again.");
|
||||
return;
|
||||
}
|
||||
if (opts['shareRedirect']) {
|
||||
window.location = opts['shareRedirect'] + xhr.responseText;
|
||||
}
|
||||
if (shareURL) {
|
||||
var path = "/p/" + xhr.responseText
|
||||
var url = origin(window.location) + path;
|
||||
shareURL.show().val(url).focus().select();
|
||||
|
||||
if (rewriteHistory) {
|
||||
var historyData = {
|
||||
"code": sharingData,
|
||||
};
|
||||
window.history.pushState(historyData, "", path);
|
||||
pushedEmpty = false;
|
||||
}
|
||||
}
|
||||
}
|
||||
});
|
||||
});
|
||||
}
|
||||
|
||||
if (opts['toysEl'] != null) {
|
||||
$(opts['toysEl']).bind('change', function() {
|
||||
var toy = $(this).val();
|
||||
$.ajax("/doc/play/"+toy, {
|
||||
processData: false,
|
||||
type: "GET",
|
||||
complete: function(xhr) {
|
||||
if (xhr.status != 200) {
|
||||
alert("Server error; try again.")
|
||||
return;
|
||||
}
|
||||
setBody(xhr.responseText);
|
||||
}
|
||||
});
|
||||
});
|
||||
}
|
||||
}
|
||||
@@ -12,12 +12,12 @@ import "C"
|
||||
|
||||
// STOP OMIT
|
||||
func Random() int {
|
||||
return int(C.rand())
|
||||
return int(C.random())
|
||||
}
|
||||
|
||||
// STOP OMIT
|
||||
func Seed(i int) {
|
||||
C.srand(C.uint(i))
|
||||
C.srandom(C.uint(i))
|
||||
}
|
||||
|
||||
// END OMIT
|
||||
|
||||
@@ -11,13 +11,13 @@ package rand2
|
||||
import "C"
|
||||
|
||||
func Random() int {
|
||||
var r C.int = C.rand()
|
||||
var r C.long = C.random()
|
||||
return int(r)
|
||||
}
|
||||
|
||||
// STOP OMIT
|
||||
func Seed(i int) {
|
||||
C.srand(C.uint(i))
|
||||
C.srandom(C.uint(i))
|
||||
}
|
||||
|
||||
// END OMIT
|
||||
|
||||
@@ -50,9 +50,6 @@ fi
|
||||
if [ "$goos" == "openbsd" ]; then
|
||||
c_go_cgo="cgo1 cgo2"
|
||||
fi
|
||||
if [ "$CGO_ENABLED" != 1 ]; then
|
||||
c_go_cgo=""
|
||||
fi
|
||||
|
||||
timeout="
|
||||
timeout1
|
||||
|
||||
@@ -28,7 +28,7 @@ func AppendByte(slice []byte, data ...byte) []byte {
|
||||
// STOP OMIT
|
||||
|
||||
// Filter returns a new slice holding only
|
||||
// the elements of s that satisfy fn.
|
||||
// the elements of s that satisfy f()
|
||||
func Filter(s []int, fn func(int) bool) []int {
|
||||
var p []int // == nil
|
||||
for _, i := range s {
|
||||
|
||||
64
doc/reference.html
Normal file
64
doc/reference.html
Normal file
@@ -0,0 +1,64 @@
|
||||
<!--{
|
||||
"Title": "References",
|
||||
"Path": "/ref/"
|
||||
}-->
|
||||
|
||||
<img class="gopher" src="/doc/gopher/ref.png" />
|
||||
|
||||
<p>Good bedtime reading.</p>
|
||||
|
||||
<div>
|
||||
|
||||
<h3 id="pkg"><a href="/pkg/">Package Documentation</a></h3>
|
||||
<p>
|
||||
The documentation for the Go standard library.
|
||||
</p>
|
||||
|
||||
<h3 id="cmd"><a href="/doc/cmd">Command Documentation</a></h3>
|
||||
<p>
|
||||
The documentation for the Go tools.
|
||||
</p>
|
||||
|
||||
<h3 id="spec"><a href="/ref/spec">Language Specification</a></h3>
|
||||
<p>
|
||||
The official Go Language specification.
|
||||
</p>
|
||||
|
||||
<h3 id="appengine"><a href="https://developers.google.com/appengine/docs/go/">App Engine Go Runtime Documentation</a></h3>
|
||||
<p>
|
||||
The documentation for
|
||||
<a href="https://developers.google.com/appengine/">Google App Engine</a>'s Go runtime.
|
||||
</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>
|
||||
|
||||
<h4 id="subrepos">Sub-repositories</h4>
|
||||
|
||||
<p>
|
||||
These packages are part of the Go Project but outside the main Go tree.
|
||||
They are developed under looser <a href="/doc/go1compat.html">compatibility
|
||||
requirements</a> than the Go core.
|
||||
Install them with "<code><a href="/cmd/go/#hdr-Download_and_install_packages_and_dependencies">go get</a></code>".
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li><a href="http://code.google.com/p/go/source/browse?repo=codereview"><code>code.google.com/p/go.codereview</code></a> [<a href="http://godoc.org/code.google.com/p/go.codereview">docs</a>]
|
||||
<li><a href="http://code.google.com/p/go/source/browse?repo=crypto"><code>code.google.com/p/go.crypto</code></a> [<a href="http://godoc.org/code.google.com/p/go.crypto">docs</a>]
|
||||
<li><a href="http://code.google.com/p/go/source/browse?repo=image"><code>code.google.com/p/go.image</code></a> [<a href="http://godoc.org/code.google.com/p/go.image">docs</a>]
|
||||
<li><a href="http://code.google.com/p/go/source/browse?repo=net"><code>code.google.com/p/go.net</code></a> [<a href="http://godoc.org/code.google.com/p/go.net">docs</a>]
|
||||
<li><a href="http://code.google.com/p/go/source/browse?repo=text"><code>code.google.com/p/go.text</code></a> [<a href="http://godoc.org/code.google.com/p/go.text">docs</a>]
|
||||
<li><a href="http://code.google.com/p/go/source/browse?repo=exp"><code>code.google.com/p/go.exp</code></a> [<a href="http://godoc.org/code.google.com/p/go.exp">docs</a>]
|
||||
<li><a href="http://code.google.com/p/go/source/browse?repo=talks"><code>code.google.com/p/go.talks</code></a> [<a href="http://godoc.org/code.google.com/p/go.talks">docs</a>]
|
||||
<li><a href="http://code.google.com/p/go/source/browse?repo=blog"><code>code.google.com/p/go.blog</code></a> [<a href="http://godoc.org/code.google.com/p/go.blog">docs</a>]
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
See the <a href="/doc/">documents page</a> for more documentation.
|
||||
</p>
|
||||
|
||||
</div>
|
||||
@@ -5,7 +5,7 @@
|
||||
<div class="left">
|
||||
|
||||
<div id="learn">
|
||||
<a class="popout share">Pop-out</a>
|
||||
<img class="icon share" src="/doc/share.png" alt="View full screen" title="View full screen">
|
||||
<div class="rootHeading">Try Go</div>
|
||||
<div class="input">
|
||||
<textarea spellcheck="false" class="code">// You can edit this code!
|
||||
@@ -26,12 +26,11 @@ Hello, 世界
|
||||
<div class="buttons">
|
||||
<a class="run" href="#" title="Run this code [shift-enter]">Run</a>
|
||||
<a class="share" href="#" title="Share this code">Share</a>
|
||||
<a class="tour" href="//tour.golang.org/" title="Learn Go from your browser">Tour</a>
|
||||
<a class="tour" href="http://tour.golang.org/" title="Learn Go from your browser">Tour</a>
|
||||
</div>
|
||||
<div class="toys">
|
||||
<select>
|
||||
<option value="hello.go">Hello, World!</option>
|
||||
<option value="life.go">Conway's Game of Life</option>
|
||||
<option value="fib.go">Fibonacci Closure</option>
|
||||
<option value="peano.go">Peano Integers</option>
|
||||
<option value="pi.go">Concurrent pi</option>
|
||||
@@ -47,7 +46,7 @@ Hello, 世界
|
||||
<div class="right">
|
||||
|
||||
<div id="about">
|
||||
Go is an open source programming language that makes it easy to build
|
||||
Go is an open source programming environment that makes it easy to build
|
||||
simple, reliable, and efficient software.
|
||||
</div>
|
||||
|
||||
@@ -69,7 +68,7 @@ Linux, Mac OS X, Windows, and more.
|
||||
|
||||
<div id="video">
|
||||
<div class="rootHeading">Featured video</div>
|
||||
<iframe width="415" height="241" src="//www.youtube.com/embed/ytEkHepK08c" frameborder="0" allowfullscreen></iframe>
|
||||
<iframe width="415" height="241" src="http://www.youtube.com/embed/ytEkHepK08c" frameborder="0" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
@@ -78,7 +77,7 @@ Linux, Mac OS X, Windows, and more.
|
||||
|
||||
<div id="blog">
|
||||
<div class="rootHeading">Featured articles</div>
|
||||
<div class="read"><a href="//blog.golang.org/">Read more</a></div>
|
||||
<div class="read"><a href="http://blog.golang.org/">Read more</a></div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
@@ -116,34 +115,21 @@ function feedLoaded(result) {
|
||||
}
|
||||
}
|
||||
|
||||
window.initFuncs.push(function() {
|
||||
// Set up playground if enabled.
|
||||
if (window.playground) {
|
||||
window.playground({
|
||||
"codeEl": "#learn .code",
|
||||
"outputEl": "#learn .output",
|
||||
"runEl": "#learn .run",
|
||||
"shareEl": "#learn .share",
|
||||
"shareRedirect": "//play.golang.org/p/",
|
||||
"toysEl": "#learn .toys select"
|
||||
});
|
||||
} else {
|
||||
$('#learn').hide()
|
||||
}
|
||||
$(function() {
|
||||
// Set up playground.
|
||||
playground({
|
||||
"codeEl": "#learn .code",
|
||||
"outputEl": "#learn .output",
|
||||
"runEl": "#learn .run",
|
||||
"shareEl": "#learn .share",
|
||||
"shareRedirect": "http://play.golang.org/p/",
|
||||
"toysEl": "#learn .toys select"
|
||||
});
|
||||
|
||||
// Load blog feed.
|
||||
$('<script/>').attr('text', 'text/javascript')
|
||||
.attr('src', '//blog.golang.org/.json?jsonp=feedLoaded')
|
||||
.attr('src', 'http://blog.golang.org/.json?jsonp=feedLoaded')
|
||||
.appendTo('body');
|
||||
|
||||
// Set the video at random.
|
||||
var videos = [
|
||||
{h: 241, s: "//www.youtube.com/embed/ytEkHepK08c"}, // Tour of Go
|
||||
{h: 241, s: "//www.youtube.com/embed/f6kdp27TYZs"}, // Concurrency Patterns
|
||||
{h: 233, s: "//player.vimeo.com/video/69237265"} // Simple environment
|
||||
];
|
||||
var v = videos[Math.floor(Math.random()*videos.length)];
|
||||
$('#video iframe').attr('height', v.h).attr('src', v.s);
|
||||
});
|
||||
|
||||
</script>
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user