├── .gitignore ├── .travis.yml ├── LICENSE ├── Makefile ├── README.md ├── _robots.txt ├── doc ├── articles │ └── go_command.html ├── asm.html ├── cmd.html ├── code.html ├── contrib.html ├── contribute.html ├── docs.html ├── go1.3.html ├── go_mem.html ├── help.html ├── install-source.html ├── install.html ├── root.html └── tos.html ├── misc └── goplay │ └── doc.go ├── refresh.sh └── src ├── cmd ├── 5a │ └── doc.go ├── 5c │ └── doc.go ├── 5g │ └── doc.go ├── 5l │ └── doc.go ├── 6a │ └── doc.go ├── 6c │ └── doc.go ├── 6g │ └── doc.go ├── 6l │ └── doc.go ├── 8a │ └── doc.go ├── 8c │ └── doc.go ├── 8g │ └── doc.go ├── 8l │ └── doc.go ├── cgo │ └── doc.go ├── fix │ └── doc.go ├── gc │ └── doc.go ├── go │ └── doc.go ├── gofmt │ └── doc.go ├── pack │ └── doc.go └── prof │ └── doc.go ├── code.google.com └── p │ └── go.tools │ └── cmd │ ├── godoc │ └── doc.go │ ├── goimports │ └── doc.go │ └── vet │ └── doc.go ├── fmt └── doc.go ├── go └── build │ └── doc.go ├── net └── http │ └── doc.go ├── os └── file.go ├── runtime └── race │ └── doc.go ├── testing └── testing.go └── text └── template └── doc.go /.gitignore: -------------------------------------------------------------------------------- 1 | # Compiled Object files, Static and Dynamic libs (Shared Objects) 2 | *.o 3 | *.a 4 | *.so 5 | 6 | # Folders 7 | _obj 8 | _test 9 | 10 | # Architecture specific extensions/prefixes 11 | *.[568vq] 12 | [568vq].out 13 | 14 | *.cgo1.go 15 | *.cgo2.c 16 | _cgo_defun.c 17 | _cgo_gotypes.go 18 | _cgo_export.* 19 | 20 | _testmain.go 21 | 22 | *.exe 23 | 24 | # OSX 25 | .DS_Store 26 | 27 | _tmp 28 | -------------------------------------------------------------------------------- /.travis.yml: -------------------------------------------------------------------------------- 1 | language: go 2 | 3 | go: 4 | - tip 5 | 6 | before_install: 7 | 8 | install: 9 | - echo "none" 10 | 11 | script: 12 | - ./refresh.sh -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gophersjp/go/bfcd2c86e6be6df59ad75235db7a4d2ce741dc22/LICENSE -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | GODOC_REV=11bd89d4e1e9a84d4d66c88b7eccfecd66e8f6c9 2 | GO_VER=go1.3 3 | 4 | WORKSPACE:=$(shell pwd)/_tmp 5 | export GOPATH=${WORKSPACE}/sub 6 | export PATH:=${GOPATH}/bin:${PATH} 7 | 8 | _GOROOT:=${WORKSPACE}/go 9 | GOREPO=code.google.com/p 10 | APP=${GOPATH}/src/godoc 11 | APP_CONTENTS=${APP}/doc/godoc.zip 12 | 13 | .PHONY: all 14 | all: update build_doc 15 | 16 | .PHONY: clean 17 | clean: 18 | rm -rf ${APP} 19 | rm -rf ${_GOROOT}/* 20 | 21 | tr_status:=${_GOROOT}/status/translate.html 22 | tr_tool:=github.com/atotto/gophersjp-go-util/cmd/translate-status 23 | ${tr_status}: ${_GOROOT} ${GOPATH}/src/${GOREPO}/go.tools 24 | go get -u ${tr_tool} 25 | mkdir -p ${_GOROOT}/status 26 | translate-status -docroot=$(shell pwd) -goroot=${_GOROOT} -o=$@ 27 | 28 | build_doc: update_doc ${tr_status} ${APP_CONTENTS} 29 | 30 | .PHONY: update_doc 31 | update_doc: ${_GOROOT} ${GOPATH}/src/${GOREPO}/go.tools 32 | #cd ${GOPATH}/src; find code.google.com/p/go.tools -type d -not -path '*/.hg/*'\ 33 | # -exec mkdir -p '${_GOROOT}/src/{}' ';' 34 | #cd ${GOPATH}/src; find code.google.com/p/go.tools -type f -not -path '*/.hg/*'\ 35 | # -exec cp '{}' '${_GOROOT}/src/{}' ';' 36 | find */ -type d -not -path '.*' -not -path '_tmp/*' \ 37 | -exec mkdir -p '${_GOROOT}/{}' ';' 38 | find */ -type f -not -path '.*' -not -path '_tmp/*' \ 39 | -exec cp '{}' '${_GOROOT}/{}' ';' 40 | 41 | ${APP_CONTENTS}: update_doc 42 | which zip || sudo apt-get install zip 43 | mkdir -p ${APP}/doc 44 | cd ${_GOROOT}/../;\ 45 | zip -q -r $@ go/* 46 | 47 | public: 48 | cp _robots.txt ${_GOROOT}/robots.txt 49 | cd ${_GOROOT}/../;\ 50 | zip -f -r ${APP_CONTENTS} go/* 51 | 52 | .PHONY: run 53 | run: update_doc 54 | GOPATH="";godoc -http=:6060 -play -goroot=${_GOROOT} 55 | 56 | .PHONY: godep 57 | godep: 58 | which godep ||go get -u github.com/kr/godep 59 | 60 | ${APP}/godeps: godep 61 | cd ${GOPATH}/src/${GOREPO}/go.tools; hg checkout ${GODOC_REV} 62 | 63 | mkdir -p ${APP} 64 | cd ${APP};\ 65 | cp -r ${GOPATH}/src/${GOREPO}/go.tools/cmd/godoc/* ${APP};\ 66 | git init;\ 67 | git add -A;\ 68 | git commit -a -m "Add godoc app";\ 69 | echo 'web: godoc -http=:$$PORT -play -zip=doc/godoc.zip -goroot=/go' > Procfile;\ 70 | git add -A;\ 71 | git commit -a -m "Add Procfile";\ 72 | godep save;\ 73 | git add -A .;\ 74 | git commit -a -m "Save godep";\ 75 | cat Godeps/Godeps.json | jq -a '.GoVersion = "${GO_VER}"' > Godeps.json;\ 76 | mv Godeps.json Godeps/Godeps.json;\ 77 | git commit -a -m "go version ${GO_VER}" 78 | 79 | 80 | deploy: ${APP_CONTENTS} ${APP}/godeps 81 | cd ${APP};\ 82 | git remote add heroku-deploy ${HEROKU};\ 83 | git push -f heroku-deploy master;\ 84 | 85 | update: ${_GOROOT} ${GOPATH}/src/${GOREPO}/go.tools 86 | cd ${_GOROOT};\ 87 | rm -rf ${_GOROOT}/src/${GOREPO};\ 88 | hg checkout tip -C;\ 89 | hg --config extensions.purge= clean;\ 90 | hg pull; hg update tip 91 | cd ${GOPATH}/src/${GOREPO}/go.tools; hg pull; hg update tip 92 | 93 | ${_GOROOT}: 94 | hg clone -u tip https://code.google.com/p/go $@ 95 | 96 | ${GOPATH}/src/${GOREPO}/go.tools: 97 | hg clone -u tip https://code.google.com/p/go.tools $@ 98 | 99 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # golang [![Build Status](https://travis-ci.org/gophersjp/go.png)](https://travis-ci.org/gophersjp/go) 2 | 3 | 日本語ドキュメントはこちら: 4 | * http://golang-jp.org/ （試験運用中） 5 | * http://godoc.org/github.com/gophersjp/go （doc.goのみ） 6 | 7 | 方針(2014/04現在): 8 | 9 | * tip版を翻訳する 10 | * 誰でも翻訳に参加できるようにする(PullRequestでも可) 11 | * 基本的にコマンドの使い方などを示したdoc.go/*.htmlを翻訳する(パッケージドキュメントは今は対象外で。) 12 | * 本家のリポジトリと同じディレクトリ構成にする 13 | * 翻訳は本家の文章の内容にできるだけ従う 14 | * 翻訳時点のリポジトリのチェンジ番号を含むURLをドキュメントの最初or最後に含める 15 | 16 | 詳細は「wiki/翻訳協力フロー」を御覧ください。 17 | 18 | ## ライセンス 19 | 20 | 本家 http://golang.org/ https://code.google.com/p/go に従います。 21 | 22 | ## 免責事項 23 | 24 | 日本語訳の記述内容により生じたいかなる損害についても 著作権所有者および翻訳者は責任を負いません。 25 | 26 | ## 協力者募集! 27 | 28 | 詳細は「wiki/翻訳協力フロー」を御覧ください。 29 | 30 | 31 | -------------------------------------------------------------------------------- /_robots.txt: -------------------------------------------------------------------------------- 1 | User-agent: * 2 | Disallow: /search 3 | 4 | Disallow: /status/ 5 | Disallow: /*.go$ 6 | Disallow: /api/ 7 | Disallow: /include/ 8 | Disallow: /lib/ 9 | Disallow: /src/ 10 | Disallow: /test/ 11 | -------------------------------------------------------------------------------- /doc/articles/go_command.html: -------------------------------------------------------------------------------- 1 | 4 | 5 | 8 | 9 |

10 | Goディストリビューションは、"go" 11 | と呼ばれるコマンドを含んでいます。 12 | これは、Goパッケージやコマンドの自動ダウンロード、ビルド、インストール、テストを行います。 13 | 本ドキュメントでは、なぜこの新しいコマンドを作ったのか、これは何で、何ではないのか、どのように使うのかについて話します。 14 |

15 | 16 |

動機

17 | 18 |

19 | Goの初期の講演でRob Pikeが大規模なGoogleのサーバをコンパイルするのを待っている間に 20 | Goのアイディアが生まれたというジョークを聞いたことがあるかもしれません。 21 | Goの本当の動機は、Googleが作り、実行する大規模なソフトウェアのビルドをより良くする言語を作ることです。 22 | このような言語には、コードライブラリ間の依存関係をきちんと表現する方法（パッケージ(package)のグループ化と明示的なインポート(import)ブロック）を提供しなければならないことは最初から分かっていました。 23 | インポートしたコードを表すために好きな書き方をしたいことも明らかでした。インポートパスが文字列リテラルである理由はこのためです。 24 |

25 | 26 |

27 | 最初からあるGoの目標は、MakefileやMakefileに変わる様々な現代的な構成ファイルを書く必要をなくし、 28 | ソースコード自体にある情報のみを使ってGoのコードをビルドできるようにすることでした。 29 | もしGoが、プログラムをビルドする方法を記述するために構成ファイルを必要としたなら、Goは失敗していたことでしょう。 30 |

31 | 32 |

33 | 最初はGoコンパイラはありませんでしたので、初期の開発ではGoを構築することと、ライブラリを構築することにフォーカスしていました。 34 | 便宜上、makeを使い、Makefileを書くことでGoのビルドの自動化を延ばしていました。 35 | Goコンパイラを複数呼び出す単一のパッケージをコンパイルするときにも、自分たちのためにMakefileを書くためのプログラムを使っていました。 36 | リポジトリの歴史を辿る際には、これを見つけることができるでしょう。 37 |

38 | 39 |

40 | 新しいGoコマンドの目標は、Goプログラムは必要なインポート文を書くということ以上に開発者側で構成ファイルや追加の作業をせずにコンパイルできるようにする必要がある。という、私たちの理想へ回帰しています。 41 |

42 | 43 |

構成 vs 規則

44 | 45 |

46 | 構成不要なシステム(configuration-free system)のシンプルさを実現するための方法は、規則(convention)を確立することです。 47 | システムはこれらの規則に従うだけで動作します。 48 | Goを最初にローンチしたとき、多くの人は、利用するために、特定の場所から、特定の名前で、特定のビルドツールを使ってインストールしなければならないパッケージを公開しました。 49 | これはよくわかります。というのも、他のほとんどの言語でおこなう方法なのです。 50 | ここ数年、私たちは一貫して 51 | goinstall(現在はgo getに置き換わっています)とその規則を普及させてきました： 52 |

53 |
    54 |
  1. インポートパスは、ソースコードのURLから分かりやすい方法で取り出せること
    2. 55 |
  2. ローカルのファイルシステムに保存する場所は、インポートパスから分かりやすい方法で取り出せること
    3. 56 |
  3. ソースツリー内の各ディレクトリは、単一のパッケージに対応していること
    4. 57 |
  4. パッケージは、ソースコード内の情報だけでビルドされていること
    5. 58 |
59 |

60 | 今日では、ほとんどのパッケージはこれらの規則に従っています。 61 | 結果として、Goのエコシステム(ecosystem)は、シンプルでより強力なものになっています。 62 |

63 | 64 |

65 | パッケージディレクトリ内のMakefileが、ソースコード内に書かれている内容以上のことをする構成を提供することを認めるよう、リクエストされました。 66 | しかし、新しいルールを導入することにしました。 67 | このような要求に応じないことで、goコマンドを作ることができ、makeやほかのビルドシステムの利用を排除できました。 68 |

69 | 70 |

71 | goコマンドは、一般的なビルドツールではないことを理解することが重要です。 72 | 設定はできませんし、Goパッケージ以外のものはビルドできません。 73 | これらは、重要な単純さへの仮説で、 74 | それは実装だけでなく、重要なのはツール自体の利用もシンプルになるということです。 75 |

76 | 77 |

Goの規則

78 | 79 |

80 | goコマンドは、いくつかの重要でよく確立された規則に従っています。 81 |

82 | 83 |

84 | はじめに、インポートパスは、ソースコードのURLから既知の方法で取り出せます。 85 | Bitbucket、GitHub、Google Code、Launchpadは、 86 | リポジトリのメインURLをhttp://なしで識別できます。 87 | サブディレクトリは、そのパスの後ろに付け加えることで名前をつけられます。 88 | たとえば、Goのための補助的なネットワークライブラリは次を実行することで取得できます： 89 |

90 | 91 | 
 92 | hg clone http://code.google.com/p/go.net
 93 |
94 | 95 |

96 | このリポジトリのルートディレクトリのインポートパスは、 97 | "code.google.com/p/go.net"です。 98 | websocketパッケージはサブディレクトリにあるので、インポートパスは、 99 | "code.google.com/p/go.net/websocket"です。 100 |

101 | 102 |

103 | これらのパスは長くなりますが、それと引き換えに、インポートパスでのネームスペースの自動的な管理と、インポートパスを見てソースコードを取得する場所を推定することができ、goコマンドのようなツールのための機能性を得ました。 104 |

105 | 106 |

107 | ２つ目に、ローカルのファイルシステム内のソースを格納する場所は、インポートパスから既知の方法で取得できます。 108 | 具体的には、最初の選択は$GOPATH/src/<import-path>です。 109 | もし$GOPATHが設定されていなければ、goコマンドは標準のGoパッケージと一緒に$GOROOT/src/pkg/<import-path>へソースコードを保存することになります。 110 | もし$GOPATHが設定されているなら、goコマンドは<dir>/src/<import-path>以下になります。 111 |

112 | 113 |

114 | 規則で、トップディレクトリのツリーには以下があります： 115 |

116 | 121 |

122 | コンパイルしたものとソースコードが常に近くにあるこの構造にすることで、これらのディレクトリツリーのそれぞれを自己完結して維持することができます。 123 |

124 | 125 |

126 | これらの命名規則は、ディレクトリ名からインポートパスへ逆方向に操作できます。 127 | この対応関係は、goコマンドのサブコマンドの多くで重要になります。以下を参照ください。 128 |

129 | 130 |

131 | ３つ目に、ソースツリーの各ディレクトリは、ひとつのパッケージに対応します。 132 | ひとつのパッケージをディレクトリに制限することで、 133 | 最初のディレクトリを指定し、そのディレクトリ内にパッケージを指定するといった混合したインポートパスを作る必要はありません。 134 | また、ほとんどのファイル管理ツールとUIは、基本単位としてディレクトリで動きます。 135 | ファイルシステムの構造は、基本的なGoの単位「パッケージ」と結びつき、ファイルシステムツールがGoパッケージツールになることを意味します。 136 | パッケージのコピー、移動、削除は、ディレクトリのコピー、移動、削除に対応するようになります。 137 |

138 | 139 |

140 | ４つ目に、各パッケージはソースファイル中にある情報だけでビルドされます。 141 | ツールは、ビルドの環境や条件の変化に適応することができる可能性がより高くなります。 142 | たとえば、コンパイルフラグやコマンドラインのレシピのようなもので追加の設定が許されている場合、 143 | その構成は、ビルドツールが変更されるたびに更新される必要があるでしょう。 144 | それはまた、本質的に特定のツールチェーンの利用に縛られることにもなります。 145 |

146 | 147 |

goコマンドことはじめ

148 | 149 |

150 | 最後に、Goコードの書き方（最初に読んだほうがいいかもしれません）に書かれている情報を補足するために、goコマンドの使い方のクイックツアーをやりましょう。 151 | 書いたGoのソースコードを、Goのディストリビューションのソースツリーとは別に管理したいと仮定すると、 152 | まずはじめに、goコマンドが必要とするグローバルな構成のひとつの$GOPATHを設定します。 153 | $GOPATHはディレクトリのリストを指定訳注1できますが、今のところ最も一般的な利用方法に従い、単一のディレクトリを指定すべきです。 154 | 具体的に言うと、プロジェクトごとに$GOPATHを個別に指定する必要はありません。 155 | １つの$GOPATHは、多くのプロジェクトをサポートすることができます。 156 |

157 | 158 |

159 | 次は簡単な例です。 160 | $HOME/mygoディレクトリにGoコード保存することを決めたとしましょう。 161 | そのディレクトリを作成し、それに応じて$GOPATHをセットします。 162 |

163 | 164 | 
165 | $ mkdir $HOME/mygo
166 | $ export GOPATH=$HOME/mygo
167 | $
168 |
169 | 170 |

171 | このディレクトリに入り、いくつかソースコードを追加しましょう。 172 | 173 | left-leaning red-black treeと一緒にcodesearchプロジェクトのライブラリを使いたいとします。 174 | "go get"サブコマンドで両方インストールしましょう： 175 |

176 | 177 | 
178 | $ go get code.google.com/p/codesearch/index
179 | $ go get github.com/petar/GoLLRB/llrb
180 | $
181 |
182 | 183 |

184 | これらのプロジェクトは、セットした$GOPATHへダウンロードされインストールされます。 185 | ディレクトリツリーには２つのディレクトリ 186 | src/code.google.com/p/codesearch/index/と 187 | src/github.com/petar/GoLLRB/llrb/、 188 | ライブラリをコンパイルしたパッケージ（pkg/に入ります）とそれらへの依存関係が一緒に含まれます。 189 |

190 | 191 |

192 | チェックアウトにはバージョン管理システム(MercurialやGit)を使っています。 193 | ソースツリーには、関連のパッケージとして対応するリポジトリ内の他のファイルが含まれていることがあります。 194 | "go list"サブコマンドは、引数に対応してインポートパスをリストします。 195 | "./..."は現在のディレクトリ("./")以下すべて("...")のパッケージを見つけることができます： 196 |

197 | 198 | 
199 | $ go list ./...
200 | code.google.com/p/codesearch/cmd/cgrep
201 | code.google.com/p/codesearch/cmd/cindex
202 | code.google.com/p/codesearch/cmd/csearch
203 | code.google.com/p/codesearch/index
204 | code.google.com/p/codesearch/regexp
205 | code.google.com/p/codesearch/sparse
206 | github.com/petar/GoLLRB/example
207 | github.com/petar/GoLLRB/llrb
208 | $
209 |
210 | 211 |

また、これらのパッケージをテストすることもできます：

212 | 213 | 
214 | $ go test ./...
215 | ?       code.google.com/p/codesearch/cmd/cgrep   [no test files]
216 | ?       code.google.com/p/codesearch/cmd/cindex  [no test files]
217 | ?       code.google.com/p/codesearch/cmd/csearch [no test files]
218 | ok      code.google.com/p/codesearch/index       0.239s
219 | ok      code.google.com/p/codesearch/regexp      0.021s
220 | ?       code.google.com/p/codesearch/sparse      [no test files]
221 | ?       github.com/petar/GoLLRB/example          [no test files]
222 | ok      github.com/petar/GoLLRB/llrb             0.231s
223 | $
224 |
225 | 226 |

227 | goサブコマンドにパスを渡さずに起動した場合、現在のディレクトリに対して操作します： 228 |

229 | 230 | 
231 | $ cd $GOPATH/src/code.google.com/p/codesearch/regexp
232 | $ go list
233 | code.google.com/p/codesearch/regexp
234 | $ go test -v
235 | === RUN TestNstateEnc
236 | --- PASS: TestNstateEnc (0.00 seconds)
237 | === RUN TestMatch
238 | --- PASS: TestMatch (0.01 seconds)
239 | === RUN TestGrep
240 | --- PASS: TestGrep (0.00 seconds)
241 | PASS
242 | ok      code.google.com/p/codesearch/regexp     0.021s
243 | $ go install
244 | $
245 |
246 | 247 |

248 | "go install"サブコマンドは、pkgディレクトリへパッケージの最新版をインストールます。 249 | goコマンドが依存関係を解析することができますので、"go install"も、パッケージのインストールでパッケージインポートが古くなっているパッケージを再帰的にインストールします。 250 |

251 | 252 |

253 | "go install"は、ディレクトリの命名の規則で、現在のディレクトリでパッケージのインポートパスの名前を知ることができたことに注目してください。 254 | 普通、このような長い名前にはせず、ソースコードを格納するディレクトリの名前を選べれば便利でしょう。 255 | しかし、そうすればツールに追加の構成と複雑さを必要とします。 256 | 多少、追加でディレクトリ名を入れることは、シンプルさと能力を増やすことを思えば大したことはありません。 257 |

258 | 259 |

260 | 例で見せたように、ひとつの$GOPATHのディレクトリで、一度に多くの異なるプロジェクトがあってもうまく動作します。 261 |

262 | 263 |

264 | 訳注1：ディレクトリのリストを指定とは、GOPATH=/home/gopher/myworkspace,/home/gopher/mygopackageといった形で複数のパスを設定できるということ 265 |

266 | 267 |

制約事項

268 | 269 |

270 | これまでに述べたように、goコマンドは汎用的ななビルドツールではありません。 271 | 特に、ビルドでGoのソースコードを生成するための機能はありません。 272 | yaccやプロトコルバッファのようなツールを使いたいときは、代わりにMakefile（または、任意のビルドツールの構成ファイル）でGoのファイルを生成し、それらの生成されたソースファイルをコミットするためのリポジトリが必要です。 273 | これは、パッケージの作者にとっては手間がかかりますが、ユーザが追加のツールを利用してビルドすることなく、"go get"だけを利用することができ、ユーザへのメリットになります。 274 |

275 | 276 |

詳細情報

277 | 278 |

279 | より詳しく見るには、Goコードの書き方と 280 | go command documentationを見てみてください。 281 |

282 | 283 | -------------------------------------------------------------------------------- /doc/asm.html: -------------------------------------------------------------------------------- 1 | 5 | 6 | 9 | 10 |

Goアセンブラ入門

11 | 14 | 15 |

16 | このドキュメントでは、Goコンパイラ(6gや8gなど)であるgcスイートで使われている、風変わりなアセンブリ言語について紹介します。 17 | ただし、このドキュメントはあまり包括的なものにはなっていません。 18 | 23 |

24 | 25 |

26 | Goアセンブラは、Plan 9アセンブラへの入力に基づいています。このアセンブラについては、Plan 9のサイトで詳しく解説されています。 27 | もしアセンブリ言語で書こうとしているなら、Plan 9固有のものではありますが、上記ドキュメントを読むことをお勧めします。 28 | このドキュメントでは、アセンブリ言語の文法の概要と、Goと相互にやりとりをするアセンブリコードを書く際に独特な部分についてのみ紹介します。 29 | 36 |

37 | 38 |

39 | Goアセンブラでまず気をつけなければいけないのは、それは計算機を直接表現したものではないということです。 40 | いくらかの部分は正確に計算機上で実行されることになりますが、一部はそうではありません。 41 | これは、コンパイラスイート(こちらの説明もどうぞ)は通常の処理過程ではアセンブラを処理しないためです。 42 | かわりに、コンパイラは未完成の命令をバイナリ形式で出力します。そして、リンカがそれを完成させます。 43 | とりわけ、リンカは命令の選択をします。そのため、もしMOVのような命令があっても、リンカが実際に生成する命令はメモリ転送の命令ではなく、クリアやロードの命令かもしれません。 44 | もちろん、まったく同じ名前の命令を生成することもあります。 45 | 一般に、その計算機固有の演算はそのまま生成される傾向がありますが、一方でメモリ転送のような一般的なものや、サブルーチン呼び出し、リターンのような抽象的なものはそのままは生成されない傾向にあります。 46 | これについてはアーキテクチャによっても変わり、不正確で申し訳ないのですが、明確な定義はありません。 47 | 62 |

63 | 64 |

65 | アセンブラのプログラムはこのような中間的で不完全な命令を生成し、リンカへの入力とすることができます。 66 | もし命令が特定のアーキテクチャのアセンブリでどのようになるかを知りたければ、標準ライブラリのruntimeやmath/bigパッケージのソースコードが参考になるでしょう。 67 | また、コンパイラがどのようなアセンブリコードを出力するかを調べることもできます: 68 | 77 |

78 | 79 | 
 80 | $ cat x.go
 81 | package main
 82 | 
 83 | func main() {
 84 | 	println(3)
 85 | }
 86 | $ go tool 6g -S x.go        # or: go build -gcflags -S x.go
 87 | 
 88 | --- prog list "main" ---
 89 | 0000 (x.go:3) TEXT    main+0(SB),$8-0
 90 | 0001 (x.go:3) FUNCDATA $0,gcargs·0+0(SB)
 91 | 0002 (x.go:3) FUNCDATA $1,gclocals·0+0(SB)
 92 | 0003 (x.go:4) MOVQ    $3,(SP)
 93 | 0004 (x.go:4) PCDATA  $0,$8
 94 | 0005 (x.go:4) CALL    ,runtime.printint+0(SB)
 95 | 0006 (x.go:4) PCDATA  $0,$-1
 96 | 0007 (x.go:4) PCDATA  $0,$0
 97 | 0008 (x.go:4) CALL    ,runtime.printnl+0(SB)
 98 | 0009 (x.go:4) PCDATA  $0,$-1
 99 | 0010 (x.go:5) RET     ,
100 | ...
101 |
102 | 103 |

104 | FUNCDATAとPCDATAディレクティブは、ガーベッジコレクタによって使用される情報を含みます。これはコンパイラによって挿入されます。 105 | 109 |

110 | 111 | 112 | 143 | 144 |

シンボル

145 | 148 | 149 |

150 | いくつかのシンボル、例えばPCやR0、SPは予め定義されており、レジスタを指しています。他にもSB (static base)とFP (frame pointer)という二つのシンボルがあります。 151 | ユーザーが定義したジャンプラベル以外のシンボルは、これらの擬似レジスタのオフセットとして使用できます。 152 | 157 |

158 | 159 | 160 |

161 | SB擬似レジスタは、メモリの基点として考えることができます。そのため、シンボルfoo(SB)は名前fooのメモリ内のアドレスとなります。 162 | 166 |

167 | 168 |

169 | FP擬似レジスタは仮想的なフレームポインタで、関数の引数を指すために使われています。 170 | コンパイラは仮想的なフレームポインタを管理し、スタック中の引数を擬似レジスタからのオフセットで指します。 171 | つまり、0(FP)は関数の第一引数になり、8(FP)は第二引数(64ビット環境では)になり、以下同様です。 172 | この方法で関数の引数を指すときは、はじめにfirst_arg+0(FP)やsecond_arg+8(FP)のようにして、名前をつけるのがよいでしょう。 173 | いくつかのアセンブラはこれを強制し、単なる0(FP)や8(FP)を拒否します。 174 | Goのプロトタイプをもつアセンブリ関数なら、go vetが引数名とオフセットが一致しているかどうかをチェックします。 175 | 187 |

188 | 189 |

190 | SP擬似レジスタは仮想的なスタックポインタで、フレームのローカル変数と関数呼び出しの際に用意された引数を指すのに使われています。 191 | これはローカルスタックフレームの先頭を指すので、参照する際は負のオフセット範囲 [-framesize, 0): x-8(SP), y-4(SP) を使う必要があります 192 | 実際にSPという名前のレジスタがあるアーキテクチャでは、名前プリフィックスによって、この仮想スタックポインタとそのアーキテクチャのSPレジスタを区別して指すことができます。 193 | つまり、x-8(SP)と-8(SP)は違うメモリの場所を指します: 194 | 前者は仮想スタックポインタ擬似レジスタを指しますが、後者はハードウェアのSPレジスタを指します。 195 | 208 |

209 | 210 |

211 | 命令、レジスタ、アセンブラのディレクティブは常に大文字で書かれており、アセンブリプログラミングはやっかいなものであることを彷彿とさせることでしょう。 212 | (例外: ARMでのmとgのレジスタリネーム) 213 | 218 |

219 | 220 |

221 | Goのオブジェクトファイルとバイナリでは、シンボルの厳密な名前はパッケージパスとシンボルの名前をピリオドで繋いだものです: 222 | fmt.Printfやmath/rand.Intなど。 223 | アセンブラのパーサーはピリオドやスラッシュを区切り文字として扱うので、これらの文字列を識別名として使うことはできません。 224 | かわりに、アセンブラは識別子中の中黒文字(MIDDLE DOT: U+00B7)と割り算文字(DIVISION SLASH: U+2215)を普通のピリオドとスラッシュに置換します。 225 | アセンブラのソースファイルでは、上記シンボルは次のように書く必要があります: fmt·Printfやmath∕rand·Int。 226 | コンパイラに-Sフラグを与えたときに生成されるアセンブリコードは、ピリオドとスラッシュがそのまま出力されており、アセンブラから必要とされるUnicode文字への置き換えはされていません。 227 | 242 |

243 | 244 |

245 | 手で書かれたほとんどのアセンブリファイルはシンボル名の中に完全なパッケージパスが入ることはないでしょう。 246 | これは、ピリオドで始まる名前に対してオブジェクトファイルのパッケージパスをリンカが挿入するためです。 247 | 例えばmath/randパッケージの実装のアセンブリソースファイルは、パッケージのInt関数を·Intで参照することができます。 248 | これによってソースコードにパッケージのインポートパスをハードコードすることを避けられ、他の場所にコードを移動しやすくなります。 249 | 258 |

259 | 260 |

ディレクティブ

261 | 264 | 265 |

266 | アセンブラは、テキストやデータをシンボルと結びつけるために、いくつかのディレクティブを使うことができます。 267 | 例えば、次の簡単な関数では、 TEXTディレクティブはシンボル runtime·profileloopを宣言し、その関数の中身の命令がそのあとに続きます。 268 | TEXTブロックの最後の命令は何らかのジャンプ命令でなければなりません。通常は、RET(擬似)命令です。 269 | (もしなければ、リンカが自分自身へジャンプする命令を挿入します。TEXTにfallthroughはありません。) 270 | さきほどのシンボルのあとには、引数としてフラグとフレームサイズの定数が入ります: 271 | 281 |

282 | 283 | 
284 | TEXT runtime·profileloop(SB),NOSPLIT,$8
285 | 	MOVQ	$runtime·profileloop1(SB), CX
286 | 	MOVQ	CX, 0(SP)
287 | 	CALL	runtime·externalthreadhandler(SB)
288 | 	RET
289 |
290 | 291 |

292 | 通常の場合、フレームサイズの後ろには引数のサイズがマイナス記号で区切られて配置されます。(これは引き算ではなく、特有の記法です。) 293 | フレームサイズ$24-8は、この関数は24バイトのフレームをもち、呼び出し元のフレームにある8バイトの引数で呼ばれることを宣言しています。 294 | もしNOSPLITがTEXTで指定されていなければ、引数のサイズをかならず指定する必要があります。 295 | 303 |

304 | 305 |

306 | このシンボルの名前は中黒を使ってコンポーネントを分離し、擬似レジスタSBからのオフセットとして指定されます。 307 | パッケージruntimeのGoのソースからは、この関数は単にprofileloopという名前で呼び出すことができます。 308 | 314 |

315 | 316 |

317 | DATAディレクティブは、シンボルのあとにスラッシュとこのシンボルが占めるバイト数を書きます。 318 | 引数はオプションのフラグとデータ自体です。 319 | 例えば、 320 | 326 |

327 | 328 | 
329 | DATA  runtime·isplan9(SB)/4, $1
330 |
331 | 332 |

333 | は局所シンボルruntime·isplan9がサイズ4で値は1であることを宣言しています。 334 | そして、このシンボルは中黒をもち、オフセットはSBがもとになります。 335 | 339 |

340 | 341 |

342 | GLOBLディレクティブはシンボルがグローバルであることを宣言します。 343 | 引数はオプションのフラグとグローバルなものとして宣言されるデータのサイズで、DATAディレクティブで初期化しない限りはゼロが初期値となります。 344 | GLOBLディレクティブは対応するDATAディレクティブの後に宣言される必要があります。 345 | 例えば、 346 | 354 |

355 | 356 | 
357 | GLOBL runtime·tlsoffset(SB),$4
358 |
359 | 360 |

361 | はruntime·tlsoffsetがサイズ4をもつことを示します。 362 | 365 |

366 | 367 |

368 | ディレクティブは一つか二つの引数をもつことができます。 369 | もし二つの場合は、最初の一つはフラグのビットマスクで、数値式として加算や論理和とったり、人間が読みやすいようにシンボルで設定することもできます。 370 | これらの値は、ファイルsrc/cmd/ld/textflag.hで定義されています: 371 | 378 |

379 | 380 | 448 | 449 |

アーキテクチャ固有の情報

450 | 453 | 454 |

455 | それぞれの計算機の命令や詳細をすべて書き下すことはあまり現実的ではありません。 456 | ある計算機でどのような命令が定義されているかは、対応するリンカのヘッダファイルを見てください。 457 | たとえば32ビットIntel x86では、8lリンカのファイル$GOROOT/src/cmd/8l/8.out.hはCの列挙体asがあり、このアーキテクチャで解釈できる命令とそのスペルを含んでいます。 458 | このファイルには、次の宣言があります 459 | 467 |

468 | 469 | 
470 | enum	as
471 | {
472 | 	AXXX,
473 | 	AAAA,
474 | 	AAAD,
475 | 	AAAM,
476 | 	AAAS,
477 | 	AADCB,
478 | 	...
479 |
480 | 481 |

482 | それぞれの命令は大文字のAで始まっており、AADCBはADCB(add carry byte: キャリー付きバイト加算)命令を示しています。 483 | この列挙はアルファベット順ですが、いくつか後から追加されたものもあります(AXXXは無効な命令としてゼロ値になっています)。 484 | 順番は実際の計算機命令のエンコーディングとは無関係です。 485 | そして、リンカがこれらの詳細な処理を行います。 486 | 494 |

495 | 496 |

497 | 前の章の例からもわかるとおり、命令中のデータは左から右へ流れます: MOVQ $0, CXはCXをクリアします。 498 | この規則は、この逆が通常のモードであるアーキテクチャにおいても適用されます。 499 | 504 |

505 | 506 |

507 | 次は、サポートされているアーキテクチャについて、Go固有のことを説明します。 508 | 511 |

512 | 513 |

32ビット Intel 386

514 | 517 | 518 |

519 | mおよびg構造体へのランタイムポインタは、MMUの(Goが関与する範囲においては)未使用レジスタの値として管理されています。 520 | アセンブラのためのOS依存マクロget_tlsはアーキテクチャ依存ヘッダファイルを次のようにインクルードしている場合に定義されます: 521 | 527 |

528 | 529 | 
530 | #include "zasm_GOOS_GOARCH.h"
531 |
532 | 533 |

534 | ランタイムでは、get_tlsマクロは引数レジスタからgとmを指すポインタペアへのポインタを読み込みます。 535 | CXを使ってgとmを読み込むのは、次のようになっています: 536 | 541 |

542 | 543 | 
544 | get_tls(CX)
545 | MOVL	g(CX), AX	// Move g into AX.
546 | MOVL	m(CX), BX	// Move m into BX.
547 |
548 | 549 |

64ビット Intel 386 (別名: amd64)

550 | 553 | 554 |

555 | mとgへのポインタにアクセスするアセンブリコードは386の場合と同じですが、MOVLのかわりにMOVQを使います: 556 | 561 |

562 | 563 | 
564 | get_tls(CX)
565 | MOVQ	g(CX), AX	// Move g into AX.
566 | MOVQ	m(CX), BX	// Move m into BX.
567 |
568 | 569 |

ARM

570 | 571 |

572 | レジスタR9とR10、R11はコンパイラとリンカに予約されています。 573 | 577 |

578 | 579 |

580 | R9とR10はm (machine)とg (goroutine)構造体を指します。 581 | アセンブリコード内では、これらのポインタはmおよびgとして参照されなければなりません。 582 | R9とR10という名前は認識されません。 583 | 589 |

590 | 591 |

592 | アセンブリを簡単に書くために、ARMリンカは汎用アドレス形式やDIVやMODのような擬似命令を受け付けます。 593 | これらは単一のハードウェア命令では表現されません。 594 | これらの形式を複数命令で実装するために、一時領域としてR11レジスタが使われることがあります。 595 | 手動でアセンブリを書く場合にはR11を使用することもできますが、そのためには、その関数内でリンカがほかの命令を実装するためにR11を使用しないことを確認する必要があります。 596 | 606 |

607 | 608 |

609 | TEXTを定義する際にフレームサイズ$-4を指定すると、リンカはこの関数を実行時にLRを保存しなくてよい末端の関数とみなします。 610 | 614 |

615 | 616 |

617 | SPは常に仮想スタックポインタを指します。 618 | ハードウェアのレジスタを指すには、R13を使ってください。 619 | 623 |

624 | 625 |

未対応の命令コード

626 | 629 | 630 |

631 | アセンブラはコンパイラをサポートするように設計されているため、すべてのアーキテクチャのすべてハードウェア命令が定義されているわけではありません: もしコンパイラが生成しないものなら、ない可能性があります。 632 | 存在しない命令を使いたい場合は、二つの方法があります。 633 | 一つはその命令が使えるようにアセンブラを変更することです。これは正統な方法ですが、その命令を今後も使いたい場合だけ価値があります。 634 | かわりに、単に一度だけ使いたいだけであれば、BYTEとWORDディレクティブを使ってTEXTのなかに命令コードを直接書くことも出来ます。 635 | これは、386用のランタイムが64ビットアトミックロード関数を定義している方法です。 636 | 647 |

648 | 649 | 
650 | // uint64 atomicload64(uint64 volatile* addr);
651 | // so actually
652 | // void atomicload64(uint64 *res, uint64 volatile *addr);
653 | TEXT runtime·atomicload64(SB), NOSPLIT, $0-8
654 | 	MOVL	4(SP), BX
655 | 	MOVL	8(SP), AX
656 | 	// MOVQ (%EAX), %MM0
657 | 	BYTE $0x0f; BYTE $0x6f; BYTE $0x00
658 | 	// MOVQ %MM0, 0(%EBX)
659 | 	BYTE $0x0f; BYTE $0x7f; BYTE $0x03
660 | 	// EMMS
661 | 	BYTE $0x0F; BYTE $0x77
662 | 	RET
663 |
664 | -------------------------------------------------------------------------------- /doc/cmd.html: -------------------------------------------------------------------------------- 1 | 5 | 6 | 9 | 10 |

11 | Goのソースコードをビルドしたり処理するプログラム一式はあります。 12 | これらは直接起動するよりも、goプログラムによって起動されることがほとんどです。 13 |

14 | 15 |

16 | これらのプログラムを起動する一般的な方法は、例えばgo fmtのように、goプログラムのサブコマンドとしてです。 17 | このように起動すると、コマンドはGoのソースコードのパッケージ群全体に対して、パッケージごとに基となるバイナリを引数付きで起動し、適切に処理されます。 18 |

19 | 20 |

21 | プログラムは単独のバイナリとしても起動できます。 22 | go toolサブコマンドを使うことで、例えばgo tool vetのように、引数を変えずに起動できます。 23 | この実行スタイルを使うことで、例えばパッケージ全体ではなく、一つのソースファイルをチェックすることができます: 24 | go vet mypackageに対して、go tool vet myprogram.go。 25 | いくつかのコマンド、例えばyaccなどは、go toolサブコマンドからのみ使用可能です。 26 |

27 | 28 |

29 | 最後に、fmtとgodocコマンドはよく使用されるため、 30 | gofmtとgodocという普通のバイナリとしてインストールされています。 31 |

32 | 33 |

34 | より詳細なドキュメントや起動方法、使用方法をみるには、リンクをクリックしてください。 35 |

36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 |
名前    概要
go     48 | goプログラムはGoのソースコードを処理し、ここに列挙しているコマンドを実行します。 49 | 使い方の詳細は、コマンドのドキュメントをみてください。 50 |

51 |
cgo    CgoはCのコードを呼び出すGoパッケージの作成を可能にします。
cover    Coverは"go test -coverprofile"によって生成されるカバレッジプロファイルを解析するプログラムです。
fix    Fixは古い言語機能やライブラリを見つけ、新しいものに書き換えるGoプログラムです。
fmt    FmtはGoパッケージのフォーマットを整えます。 76 | これは独立したgofmtコマンドとしても使用でき、より汎用的なオプションを指定できます。
godoc    GodocはGoパッケージのドキュメントを抽出し、生成します。
vet    VetはGoのソースコードを調査し、怪しい構文、例えば引数がフォーマット文字列と揃っていないPrintf呼び出しを報告します。
yacc    YaccはGoで実装されたパーサーを出力するバージョンのyaccです。
98 | 99 |

100 | このリストは要約版です。 101 | コンパイラなどのドキュメントは、全コマンドのリファレンスをみてください。 102 |

103 | -------------------------------------------------------------------------------- /doc/code.html: -------------------------------------------------------------------------------- 1 | 4 | 5 | 8 | 9 |

イントロダクション

10 | 11 |

12 | このドキュメントでは簡単なGoパッケージの開発の説明、goツール、Goパッケージとコマンドの標準的なフェッチ・ビルド・インストールの方法を紹介しています。 13 |

14 | 15 |

16 | goツールの利用に際しては、コードを特定の方法で構成する必要があります。このドキュメントを注意深く読みましょう。最も簡単にGoをインストールし、使い始める方法を説明しています。 17 |

18 | 19 |

20 | 同様の説明をスクリーンキャストで見ることができます。 21 |

22 | 23 | 24 |

コードの構成

25 | 26 |

ワークスペース

27 | 28 |

29 | goツールは、公開レポジトリでメンテナンスされているオープンソースコードを扱うことを想定して設計されています。実際にコードを公開する必要はありませんが、公開する場合もしない場合も同じ方法で環境の設定を行うことができます。 30 |

31 | 32 |

33 | Goコードはワークスペース内に置いておく必要があります。ワークスペースはルートに以下の3つのディレクトリを持つディレクトリ階層です。 34 |

35 | 36 | 41 | 42 |

43 | goツールはソースパッケージをビルドし、その結果生成されるバイナリをpkgおよびbinにインストールします。 44 |

45 | 46 |

47 | srcサブディレクトリは一般的に1つ以上のソースパッケージの開発を追跡するバージョンコントロールレポジトリ（Git、Mercurialなど）を複数内包します。 48 |

49 | 50 |

51 | 実際にワークスペースがどのようになっているか把握していただくために、次の例をご覧ください。 52 |

53 | 54 | 
 55 | bin/
 56 |     streak                         # コマンド実行形式ファイル
 57 |     todo                           # コマンド実行形式ファイル
 58 | pkg/
 59 |     linux_amd64/
 60 |         code.google.com/p/goauth2/
 61 |             oauth.a                # パッケージオブジェクト
 62 |         github.com/nf/todo/
 63 |             task.a                 # パッケージオブジェクト
 64 | src/
 65 |     code.google.com/p/goauth2/
 66 |         .hg/                       # mercurialレポジトリメタデータ
 67 |         oauth/
 68 |             oauth.go               # パッケージソース
 69 |             oauth_test.go          # テストソース
 70 |     github.com/nf/
 71 |         streak/
 72 |             .git/                  # gitレポジトリメタデータ
 73 |             oauth.go               # コマンドソース
 74 |             streak.go              # コマンドソース
 75 |         todo/
 76 |             .git/                  # gitレポジトリメタデータ
 77 |             task/
 78 |                 task.go            # パッケージソース
 79 |             todo.go                # コマンドソース
 80 |
81 | 82 |

83 | このワークスペースには2つのコマンド（streak and todo）と2つのライブラリ（oauth and task）から成る3つのレポジトリ（goauth2、streak、todo）が入っています。 84 |

85 | 86 |

87 | コマンド、ライブラリは異なる種類のソースパッケージからビルドされます。この区別は以降で議論します。 88 |

89 | 90 | 91 |

GOPATH環境変数

92 | 93 |

94 | GOPATH環境変数はワークスペースの場所を示してします。これがGoコードを開発する際に設定が必要な唯一の環境変数のはずです。 95 |

96 | 97 |

98 | 始めるにあたっては、ワークスペースディレクトリを作成し、適宜GOPATHをセットしてください。ワークスペースはどこでも好きな場所に置いてよいですが、このドキュメントでは$HOME/goとして説明しています。Goをインストールしたパスを指定してはいけないことを注意してください。 99 |

100 | 101 | 
102 | $ mkdir $HOME/go
103 | $ export GOPATH=$HOME/go
104 |
105 | 106 |

107 | 利便性向上のため、以下のようにワークスペースのbinサブディレクトリをPATHに追加してください。 108 |

109 | 110 | 
111 | $ export PATH=$PATH:$GOPATH/bin
112 |
113 | 114 | 115 |

パッケージパス

116 | 117 |

118 | 標準ライブラリのパッケージは、"fmt"や"net/http"のように短いパスを与えられています。自分で作ったパッケージについては、将来追加されるライブラリやその他の外部ライブラリと衝突しないであろうベースパスを選ぶ必要があります。 119 |

120 | 121 |

122 | コードをどこかのソースレポジトリに置く場合は、ベースパスとしてソースレポジトリのルートを利用する必要があります。例えば、github.com/userにあるGitHubアカウントを利用している場合には、これがベースパスとなります。 123 |

124 | 125 |

126 | ビルドができる状態になる前にコードをリモートレポジトリに公開する必要はないことに留意してください。いつの日にか公開することを見越してコードを構成することはよい行いです。実質的には、標準ライブラリや大Goエコシステムに対してユニークである限り、いずれの任意のパス名も選ぶことができます。 127 |

128 | 129 |

130 | github.com/userをベースパスに利用します。ソースコードを置くワークスペースの中に以下のようにディレクトリを作成してください。 131 |

132 | 133 | 
134 | $ mkdir -p $GOPATH/src/github.com/user
135 |
136 | 137 | 138 |

初めてのプログラム

139 | 140 |

141 | 簡単なプログラムをコンパイルし実行するために、まずパッケージパスを選び（ここではgithub.com/user/helloを利用します）、以下のようにワークスペースに対応するパッケージディレクトリを作成します。 142 |

143 | 144 | 
145 | $ mkdir $GOPATH/src/github.com/user/hello
146 |
147 | 148 |

149 | 次に、作成したディレクトリにhello.goという名前のファイルを作成し、以下のGoコードを記述します。 150 |

151 | 152 | 
153 | package main
154 | 
155 | import "fmt"
156 | 
157 | func main() {
158 | 	fmt.Printf("Hello, world.\n")
159 | }
160 |
161 | 162 |

163 | これで以下のようにgoツールでプログラムをビルドし、インストールできるようになります。 164 |

165 | 166 | 
167 | $ go install github.com/user/hello
168 |
169 | 170 |

171 | システムのどこからでもこのコマンドを実行することができます。goツールはGOPATHで指定されたワークスペース内のgithub.com/user/helloパッケージを検索することでソースコードを見つけ出します。 172 |

173 | 174 |

175 | 以下のように、対象のパッケージディレクトリからgo installを実行する場合にはパッケージパスを省略することもできます。 176 |

177 | 178 | 
179 | $ cd $GOPATH/src/github.com/user/hello
180 | $ go install
181 |
182 | 183 |

184 | このコマンドはhelloコマンドをビルドし、実行可能バイナリを生成します。さらにそのバイナリをhelloという名前（Windowsではhello.exe）でワークスペースのbinディレクトリにインストールします。上記の例では、$GOPATH/bin/hello（つまり、$HOME/go/bin/hello）となります。 185 |

186 | 187 |

188 | goツールはエラーが発生した際にのみ出力をプリントします。つまり、これらのコマンドで何も出力されなかった場合には正しく実行されたことになります。 189 |

190 | 191 |

192 | これで以下のようにコマンドラインにフルパスを入力することでプログラムを実行できるようになります。 193 |

194 | 195 | 
196 | $ $GOPATH/bin/hello
197 | Hello, world.
198 |
199 | 200 |

201 | もしくは、$GOPATH/binがPATHに追加されていれば、以下のようにバイナリ名を入力するだけです。 202 |

203 | 204 | 
205 | $ hello
206 | Hello, world.
207 |
208 | 209 |

210 | ソース管理システムを利用している場合は、このときがレポジトリを初期化し、ファイルを追加し、最初の変更をコミットするのに適したタイミングです。もう一度確認しておきますが、このステップは任意です。Goコードを書くのにソース管理が必要だということではありません。 211 |

212 | 213 | 
214 | $ cd $GOPATH/src/github.com/user/hello
215 | $ git init
216 | Initialized empty Git repository in /home/user/go/src/github.com/user/hello/.git/
217 | $ git add hello.go
218 | $ git commit -m "initial commit"
219 | [master (root-commit) 0b4507d] initial commit
220 |  1 file changed, 1 insertion(+)
221 |   create mode 100644 hello.go
222 |
223 | 224 |

225 | リモートレポジトリへのコードのプッシュの方法は、読者の皆さんへの演習課題として残しておきます。 226 |

227 | 228 | 229 |

初めてのライブラリ

230 | 231 |

232 | ライブラリを書いて、それをhelloプログラムで利用しましょう。 233 |

234 | 235 |

236 | ここでも、最初のステップはパッケージパスを選び（ここではgithub.com/user/newmathとします）、以下のようにパッケージディレクトリを作成することです。 237 |

238 | 239 | 
240 | $ mkdir $GOPATH/src/github.com/user/newmath
241 |
242 | 243 |

244 | 次に、このディレクトリにsqrt.goという名前のファイルを作成し、以下の内容を記述します。 245 |

246 | 247 | 
248 | // newmathパッケージはちょっとしたサンプルパッケージです。
249 | package newmath
250 | 
251 | // Sqrtはxの平方根の近似値を返します。
252 | func Sqrt(x float64) float64 {
253 | 	z := 1.0
254 | 	for i := 0; i < 1000; i++ {
255 | 		z -= (z*z - x) / (2 * z)
256 | 	}
257 | 	return z
258 | }
259 |
260 | 261 |

262 | そして、go buildでパッケージがコンパイルできることをテストします。 263 |

264 | 265 | 
266 | $ go build github.com/user/newmath
267 |
268 | 269 |

270 | もしくは、パッケージのソースディレクトリで作業している場合には、単に以下のようにします。 271 |

272 | 273 | 
274 | $ go build
275 |
276 | 277 |

278 | このコマンドはファイルの出力を行いません。ファイルを出力するには、go installを用いる必要があります。これにより、ワークスペースのpkgディレクトリにパッケージオブジェクトが生成されます。 279 |

280 | 281 |

282 | newmathパッケージがビルドされたことを確認してから、元のhello.go（$GOPATH/src/github.com/user/helloにある）を以下のように修正してこのパッケージを利用するようにします。 283 |

284 | 285 | 
286 | package main
287 | 
288 | import (
289 | 	"fmt"
290 | 
291 | 	"github.com/user/newmath"
292 | )
293 | 
294 | func main() {
295 | 	fmt.Printf("Hello, world.  Sqrt(2) = %v\n", newmath.Sqrt(2))
296 | }
297 |
298 | 299 |

300 | goツールがパッケージやバイナリをインストールする際には必ず、それらが持つすべての依存関係がインストールされます。ですので以下のようにhelloプログラムをインストールする場合には、 301 |

302 | 303 | 
304 | $ go install github.com/user/hello
305 |
306 | 307 |

308 | newmathが同時に自動でインストールされます。 309 |

310 | 311 |

312 | この新しいバージョンのプログラムを実行すると、以下のように何らかの数値が出力されることを確認できるはずです。 313 |

314 | 315 | 
316 | $ hello
317 | Hello, world.  Sqrt(2) = 1.414213562373095
318 |
319 | 320 |

321 | 上記のステップを行うと、ワークスペースは以下のような状態になっているはずです。 322 |

323 | 324 | 
325 | bin/
326 |     hello              # コマンド実行形式ファイル
327 | pkg/
328 |     linux_amd64/       # ここはOSとアーキテクチャ名が反映されます
329 |         github.com/user/
330 |             newmath.a  # パッケージオブジェクト
331 | src/
332 |     github.com/user/
333 |         hello/
334 |             hello.go   # コマンドソース
335 |         newmath/
336 |             sqrt.go    # パッケージソース
337 |
338 | 339 |

340 | go installを実行すると、newmath.aオブジェクトがpkg/linux_amd64の中にソースディレクトリと同じ階層で置かれます。これは、今後のgoツールの呼び出しの際、既存のパッケージオブジェクトを検索することで不必要なパッケージの再コンパイルを避けるようにするためです。linux_amd64の部分はクロスコンパイルを可能にするためにあり、利用しているオペレーティングシステムとアーキテクチャの名前が反映されます。 341 |

342 | 343 |

344 | Goのコマンド実行形式ファイルは静的リンクされており、Goプログラムの実行にパッケージオブジェクトは必要ありません。 345 |

346 | 347 | 348 |

パッケージ名

349 | 350 |

351 | Goソースファイルの最初のステートメントは以下のようでなければなりません。 352 |

353 | 354 | 
355 | package name
356 |
357 | 358 |

359 | nameの部分にはインポートするパッケージのデフォルト名が入ります。（パッケージ内のすべてのファイルで同じnameを利用します。） 360 |

361 | 362 |

363 | Goの規則ではパッケージ名はインポートパスの最後の要素となります。例えば、"crypto/rot13"というパッケージをインポートする場合は、rot13とします。 364 |

365 | 366 |

367 | 実行形式ファイルのコマンドは常にpackage mainとする必要があります。 368 |

369 | 370 |

371 | パッケージ名は、ある1つのバイナリにリンクされたすべてのパッケージを通じて一意である必要はありません。インポートパス（完全ファイル名）のみ一意である必要があります。 372 |

373 | 374 |

375 | Goの命名規則についてさらに詳しく学びたい場合は、Effective Goをご覧ください。 376 |

377 | 378 | 379 |

テスティング

380 | 381 |

382 | Goはgo testコマンドとtestingパッケージで構成される軽量なテストフレームワークを提供します。 383 |

384 | 385 |

386 | テストを書くには、_test.goで終わる名前のファイルを作成し、func (t *testing.T)というシグネチャのTestXXXという名前の関数を作成します。テストフレームワークはこれらの関数を一つ一つ実行し、t.Errorやt.Failといったフェイル関数が呼ばれると、テストが失敗したとみなします。 387 |

388 | 389 |

390 | newmathパッケージのテストを追加しましょう。$GOPATH/src/github.com/user/newmath/sqrt_test.goというファイルを作成し、以下のGoコードを記述してください。 391 |

392 | 393 | 
394 | package newmath
395 | 
396 | import "testing"
397 | 
398 | func TestSqrt(t *testing.T) {
399 | 	const in, out = 4, 2
400 | 	if x := Sqrt(in); x != out {
401 | 		t.Errorf("Sqrt(%v) = %v, want %v", in, x, out)
402 | 	}
403 | }
404 |
405 | 406 |

407 | そして、go testでテストを実行しましょう。 408 |

409 | 410 | 
411 | $ go test github.com/user/newmath
412 | ok  	github.com/user/newmath 0.165s
413 |
414 | 415 |

416 | いつもどおり、goツールをパッケージのディレクトリで実行する場合は、パッケージのパスを省略できます。 417 |

418 | 419 | 
420 | $ go test
421 | ok  	github.com/user/newmath 0.165s
422 |
423 | 424 |

425 | さらに詳しい情報については、go help testを実行し、testingパッケージドキュメントをご覧ください。 426 |

427 | 428 | 429 |

リモートパッケージ

430 | 431 |

432 | GitやMercurialといったリビジョン管理システムを利用したパッケージのソースコードを利用する場合、インポートパスにはどのリビジョン管理システムから取得するかを記述するようにします。goはこのプロパティを利用してリモートレポジトリからパッケージを自動的にフェッチします。例えば、このドキュメントに記述されている例はGoogle Codeにホストされているcode.google.com/p/go.example Mercurialレポジトリにも収録されています。パッケージインポートパスにレポジトリのURLが含まれている場合は、以下のようにgo getで自動的にフェッチ、ビルド、インストールができます。 433 |

434 | 435 | 
436 | $ go get code.google.com/p/go.example/hello
437 | $ $GOPATH/bin/hello
438 | Hello, world.  Sqrt(2) = 1.414213562373095
439 |
440 | 441 |

442 | 指定されたパッケージがワークスペースに存在しない場合、go getはGOPATHで最初に指定されているワークスペース内に配置します。（パッケージがすでに存在する場合、go getはリモートからのフェッチをスキップし、go installと同じように振る舞います。） 443 |

444 | 445 |

446 | 上記のgo getコマンドを発行すると、ワークスペースのディレクトリツリーは以下のようになります。 447 |

448 | 449 | 
450 | bin/
451 |     hello                 # コマンド実行形式ファイル
452 | pkg/
453 |     linux_amd64/
454 |         code.google.com/p/go.example/
455 |             newmath.a     # パッケージオブジェクト
456 |         github.com/user/
457 |             newmath.a     # パッケージオブジェクト
458 | src/
459 |     code.google.com/p/go.example/
460 |         hello/
461 |             hello.go      # コマンドソース
462 |         newmath/
463 |             sqrt.go       # パッケージソース
464 |             sqrt_test.go  # テストソース
465 |     github.com/user/
466 |         hello/
467 |             hello.go      # コマンドソース
468 |         newmath/
469 |             sqrt.go       # パッケージソース
470 |             sqrt_test.go  # テストソース
471 |
472 | 473 |

474 | Google Codeにホストされているhelloは同じレポジトリ内のnewmathパッケージに依存しています。hello.goファイル内のインポートには同じインポートパスの規則を用います。そのため、go getコマンドは依存するパッケージも同様に場所の特定・インストールをすることができます。 475 |

476 | 477 | 
478 | import "code.google.com/p/go.example/newmath"
479 |
480 | 481 |

482 | この規則により、自分で作ったGoパッケージを他の人が非常に容易に使えるようになります。Go Wikiやgodoc.orgに外部のGoプロジェクトの一覧があります。 483 |

484 | 485 |

486 | goツールでリモートレポジトリを利用する際のさらに詳しい情報は、go help importpathをご覧ください。 487 |

488 | 489 | 490 |

次のステップ

491 | 492 |

493 | Goの新しい安定バージョンのリリース通知を受け取るにはgolang-announceメーリングリストを購読しましょう。 494 |

495 | 496 |

497 | きれいで慣用的なGoコードを書くためのティップスはEffective Goをご覧ください。 498 |

499 | 500 |

501 | きちんと言語を学ぶにはA Tour of Goを利用しましょう。 502 |

503 | 504 |

505 | Go言語とライブラリ、ツールに関するさらに詳細な記事についてはdocumentation pageをご覧ください。 506 |

507 | 508 | 509 |

ヘルプを得るには

510 | 511 |

512 | リアルタイムヘルプについては、Freenode IRCサーバの#go-nutsで協力的なGopher達に質問してください。 513 |

514 | 515 |

516 | Go言語のディスカッションのためのオフィシャルメーリングリストはGo Nutsです。 517 |

518 | 519 |

520 | バグのレポートにはGo issue trackerを利用してください。 521 |

522 | -------------------------------------------------------------------------------- /doc/contrib.html: -------------------------------------------------------------------------------- 1 | 5 | 6 | 9 | 10 | 11 | 12 |
13 | 14 |

15 | GoはGoogleのチームと、 16 | オープンソースコミュニティの多くの貢献者(contributors)達の手で開発されているオープンソースプロジェクトです。 17 |

18 | 19 |

20 | GoはBSD-style license下で配布できます。 21 |

22 | 23 |

アナウンス専用のメーリングリスト

24 |

25 | 重要なアナウンス（最新版のリリースなど）だけを専門とするメーリングリストがあります。 26 |

27 |

28 | Goのユーザであれば、golang-announceのメーリングリストを購読しておくことをオススメします。 29 |

30 | 31 | 32 |

更新履歴

33 | 34 |

リリースの歴史

35 |

36 | これまでリリースされたGoの各変更点の概要をまとめています。 37 |

38 | 39 |

Go 1 リリースノート

40 |

41 | Go 1へコードを更新するためのガイドです。 42 |

43 | 44 |

Go 1.1 リリースノート

45 | 54 |

55 | Go 1.1の重要な変更点と、コードの更新方法などがあります。 56 | リリースの各ポイントはGo 1.2, Go 1.3などの適切なドキュメントに記載しています。 57 |

58 | 59 |

Go 1 and the Future of Go Programs

60 |

61 | Go 1の定義と、Go 1が成長する過程で期待できる後方互換性の保証について。 62 |

63 | 64 | 65 |

開発者用のリソース

66 | 67 |

ソースコード

68 |

69 | Goのソースコードはリポジトリからチェックアウトできます。 70 |

71 | 72 |

開発者 と 73 | コードレビュー用メーリングリスト

74 | 80 |

81 | golang-dev 82 | メーリングリストは、Goプロジェクトへのコード修正について議論しています。 83 | golang-codereviews 84 | メーリングリストは、コード修正(CLs)のレビューを実施しています。 85 |

86 |

87 | Goプログラミングの一般的な議論については、 88 | golang-nutsを利用してください。 89 |

90 | 91 |

チェックイン通知のメーリングリスト

92 |

93 | Goリポジトリへの各チェックイン（push）の概要を受け取るためのメーリングリストです。 94 |

95 | 96 |

バグ用メーリングリスト

97 |

Goのissue trackerの更新状況のメーリングリストです。

98 | 99 |

ビルドステータス

100 |

101 | サポートされているOSとアーキテクチャのGoのビルドステータスを一望できます。 102 |

103 | 104 |

翻訳ステータス

105 |

106 | gophersjp/goで翻訳しているドキュメントの翻訳状況について一望できます。 107 |

108 | 109 | 110 |

支援するには

111 | 112 |

問題(issue)を報告するには

113 | 114 |

115 | Goプロジェクトのコードやドキュメント（訳注1）でバグ・ミス・不整合を発見した場合、 116 | issue trackerで 117 | チケットを登録してください。 118 | （もちろん、新しいissueを作成する前に既に登録されていないかチェックしておいてください。） 119 |

120 | 121 |

122 | 私たちは、細部にまで誇りをもって取り組んでいます。ですから、issueが小さすぎるということはありません。 123 |

124 | 125 |

126 | 訳注1: 日本語版のドキュメントについては、gophersjp/goでissueを登録してください。 127 |

128 | 129 |

Goへ貢献するには

130 | 131 |

132 | Goはオープンソースプロジェクトで、コミュニティからの貢献を歓迎しています。 133 |

134 |

135 | はじめるためには、デザイン、テスト、私たちのコードレビューのプロセスを理解するために 136 | contribution guidelinesを読んでください。 137 |

138 |

139 | あなたの興味のあるopenになっているissueをissue trackerでチェックしてみてください。 140 | HelpWantedとラベルされているものは、特に外部の助けを必要としています。 141 |

142 | 143 |

Goの日本語訳へ貢献するには

144 | 145 |

146 | golang.orgのドキュメントを日本語へ翻訳する活動をgithub上でおこなっています。 147 | この活動に参加していただける方は、 148 | 翻訳フロー 149 | を一読の上、 150 | gophersjp/goへ気軽にPull Requestをしてみてください。 151 |

152 | -------------------------------------------------------------------------------- /doc/contribute.html: -------------------------------------------------------------------------------- 1 | 4 | 5 |

Introduction

6 | 7 |

8 | このドキュメントは、Goプロジェクトへ貢献するための方法を説明します。 9 | ここでは、installation instructions 10 | でGoをソースからインストールし、 11 | 書いた自分のソースコードをテストする術 12 | を既に修得しているものと仮定します。 13 | （gccgoは別のガイド: 14 | Contributing to gccgo 15 | を参照ください。） 16 |

17 | 18 |

Discuss your design

19 | 20 |

21 | Goプロジェクトではコミットを歓迎します、が、Goのメインリポジトリに取り込みたいのであれば、 22 | あなたが取り組んでいることをみんなに知らせてください。 23 |

24 | 25 |

26 | 何か新しいことへ取り組む前に、 27 | メーリングリスト 28 | へメールを送り、計画について議論してください。 29 | これは、デザインを検証する機会をみんなに与え、同じことをしてしまうことを避け、 30 | そして、言語やツールの目標に沿ったアイディアにしていく活動です。 31 | また、コードが書かれる前にデザインが有効であることを保証します。 32 | コードレビューツールは詳細な議論をする場ではありません。 33 |

34 | 35 |

36 | 要するに、コードの前にメールを送ってください。 37 | そして、変更するためにチェンジリスト(change list)のメールで議論を始めないようにしてください。 38 |

39 | 40 |

Testing redux

41 | 42 |

43 | あなたが書いたコードとテストは、 44 | レビューに送る前に、他のパッケージやプログラムを破壊しない変更であることを 45 | 確かめるために、ツリー全体で全てのテストを実行します: 46 |

47 | 48 | 
 49 | cd $GOROOT/src
 50 | ./all.bash    # On Windows, run all.bat
 51 |
52 | 53 |

54 | 全体のテストを実施して、"ALL TESTS PASSED"が表示されればOKです。 55 |

56 | 57 |

Code review

58 | 59 |

60 | Goへの変更は、誰が変更したとしても、 61 | それがリポジトリへコミットされる前にレビューされる必要性があります。 62 | （例外として、ビルドの修正のような場合は 63 | レビューはコミット後に手短にフォローします） 64 | Mercurialの拡張は、コードレビューのプロセスを管理するのに役に立ちます。 65 | この拡張はGoのソースツリーに含んでいますので、 66 | 以下の手順に従ってMercurialの設定に追加してください。 67 |

68 | 69 |

Caveat for Mercurial aficionados

70 | 71 |

72 | 注意:コードレビュー拡張で拡張したMercurialの使い方と、標準のMercurialの使い方は異なります。 73 |

74 | 75 |

76 | Goのリポジトリは、レビューした変更点の単一ラインとして管理されています。 77 | Mercurialでの変更グラフの複雑さを避けることを目的としています。 78 | コードレビュー拡張で便利なのは: hg submit コマンドで、 79 | リモートリポジトリと比較してローカルリポジトリが古くなっているか自動的にチェックし、警告します。 80 | また、hg submitコマンドはGoリポジトリの他の項目について検証します。 81 | 例えば、Goのコードがgofmtで定義されている 82 | 標準スタイルでフォーマットされているか、 83 | また、コードの著作がcopyright purposes 84 | に沿って適切に記載されているかをチェックします。 85 |

86 | 87 |

88 | hg submitで作成された変更のみを確実に支援するために、 89 | 標準のhg commitコマンドは無効になります。 90 |

91 | 92 |

Configure the extension

93 | 94 |

$GOROOT/.hg/hgrcへ以下を追加します:

95 | 96 | 
 97 | [extensions]
 98 | codereview = $GOROOT/lib/codereview/codereview.py
 99 | 
100 | [ui]
101 | username = Your Name <you@server.dom>
102 |
103 | 104 |

105 | usernameの情報は、あなたがコミッター（下のセクションを参照）ではない限り利用されませんが、 106 | これがないとMercurialから文句を言われます。 107 |

108 | 109 |

Understanding the extension

110 | 111 |

112 | コードレビューの拡張を追加した後、まずは: 113 |

114 | 115 | 
116 | $ hg help codereview
117 |
118 | 119 |

120 | として、このコマンドを修得してください。 121 | 特定のコードレビューコマンド（例えばchange）について学ぶためには次のように実行します: 122 |

123 | 124 | 
125 | $ hg help change
126 |
127 | 128 |

129 | コードレビュー拡張は、$GOROOTの自分のチェックアウトだけで有効です。 130 | よって、このドキュメントでのコマンドの実行は、$GOROOT内と想定しています。 131 |

132 | 133 |

134 | Windowsユーザは、コードレビューの拡張を動作するために 135 | 追加の作業が必要です。 136 | Go Wikiの 137 | CodeReview pageを参照してください。 138 |

139 | 140 |

Log in to the code review site.

141 | 142 |

143 | コードレビューサーバは、認証のためGoogleアカウントが必要です。 144 | （もしsign in at google.comでログインできるなら、コードレビューサーバへサインインできます。） 145 | emailアドレスは、コードレビューサイト上で使え、 146 | Mercurial change log 147 | と 148 | CONTRIBUTORSファイルへ記録されます。 149 | なお、あなたが受信している任意のアドレスで 150 | Google Accountを作成 151 | することもできます。 152 | 二段階認証を有効にしている場合、アプリケーション固有のパスワードを生成し、 153 | プロンプトでパスワードを使うことを忘れないようにしてください。 154 |

155 | 156 | 
157 | $ cd $GOROOT
158 | $ hg code-login
159 | Email (login for uploading to codereview.appspot.com): rsc@golang.org
160 | Password for rsc@golang.org:
161 | 
162 | Saving authentication cookies to /Users/rsc/.codereview_upload_cookies_codereview.appspot.com
163 |
164 | 165 |

Configure your account settings.

166 | 167 |

168 | 自分のcode review settingsを編集し、 169 | ニックネームを取得してください。 170 | レビュー時に多くの内容を受け取るために、 171 | Contextオプションに“Whole file”をセットしておくのがオススメです。 172 |

173 | 174 |

175 | 一度、設定ページでニックネームを選んでおくと、 176 | 他の人は、レビュアーやCCリストへ、そのニックネームを使うことができるようになります。 177 |

178 | 179 |

Switch to the default branch

180 | 181 |

182 | ほとんどのGoインストールは、releaseブランチを使っていますが、 183 | 新しい変更はdefaultブランチだけにすべきです。 184 | （ただ、リリースプロセスの一部としてreleaseブランチへ後で適用することもあります） 185 | 変更を入れる前に、必ずdefaultブランチを使ってください: 186 |

187 | 188 | 
189 | $ hg update default
190 |
191 | 192 |

Make a change

193 | 194 |

195 | チェックアウトしたツリー全体は、どこでも書き込み可能です。 196 | ファイルを編集する必要があれば、単にそれを編集するだけです。 197 | Mercurialは、その変更を把握しています。 198 | なお、ファイルを追加(add)、削除(remove)、コピー(copy)、リネーム(rename)は、 199 | Mercurialへ知らせるために、 200 | hg add、 201 | hg rm、 202 | hg cp、 203 | hg mv 204 | を使ってください。 205 |

206 | 207 |

208 | 変更をレビューへ送る準備ができたら、自分のGoリポジトリの任意の場所から: 209 |

210 | 211 | 
212 | $ hg change
213 |
214 | 215 |

216 | を実行します。 217 | するとMercurialは、あなたのエディタで変更の説明を書くためのファイルを開きます 218 | （これは、環境変数の$EDITORに設定してあるエディタを使います。 219 | デフォルトではviです）。 220 | 例えば、開かれたファイルはこのようなものです: 221 |

222 | 223 | 
224 | # Change list.
225 | # Lines beginning with # are ignored.
226 | # Multi-line values should be indented.
227 | 
228 | Reviewer:
229 | CC:
230 | 
231 | Description:
232 | 	<enter description here>
233 | 
234 | Files:
235 | 	src/pkg/math/sin.go
236 | 	src/pkg/math/tan.go
237 | 	src/pkg/regexp/regexp.go
238 |
239 | 240 |

241 | Reviewerは、この変更へアサインするレビュアーをリストし、 242 | CCは、変更について知らせたい人をリストします。 243 | これらは、コードレビューのニックネームや、任意のemailアドレスを使えます。 244 | チェンジリスト(change list)を送るに至るまでの議論で 245 | 明示的に言われない限り、 246 | レビュアーは空欄のままにします。 247 | これは、レビュアーとして 248 | golang-codereviews@googlegroups.com 249 | のメーリングリストを使うことを意味します。 250 |

251 | 252 |

253 | “<enter description here>” 254 | を、あなたの変更の説明で置き換えてください。 255 | 説明の最初の行は、影響するパッケージを先頭に、一行で変更の要約を書くようにします。 256 | コードレビューのメールのための議題としても使われます。 257 | 次の行からは詳しい内容をすきなだけ書いてください。 258 |

259 | 260 |

261 | Filesセクションは、 262 | あなたの変更のすべてのファイルをリストしています。 263 | 関連のない変更は、他のチェンジリストにしましょう。 264 | 例では、 265 | regexp.goの行を削除することで、 266 | mathパッケージへの変更だけにしています。 267 |

268 | 269 |

270 | 編集後、テンプレートはこのようになりました: 271 |

272 | 273 | 
274 | # Change list.
275 | # Lines beginning with # are ignored.
276 | # Multi-line values should be indented.
277 | 
278 | Reviewer: golang-codereviews@googlegroups.com
279 | CC: math-nuts@swtch.com
280 | 
281 | Description:
282 | 	math: improved Sin, Cos and Tan precision for very large arguments.
283 | 
284 | 	See Bimmler and Shaney, ``Extreme sinusoids,'' J. Math 3(14).
285 | 	Fixes issue 159.
286 | 
287 | Files:
288 | 	src/pkg/math/sin.go
289 | 	src/pkg/math/tan.go
290 |
291 | 292 |

293 | “Fixes issue 159.” 294 | というのは、 295 | Go issue tracker 296 | の 297 | issue 159 298 | に関連する変更であることを意味する特別な文です。 299 | この変更が最終的に投稿されたとき、 300 | issue trackerはissueをfixedとして自動的に記録します 301 | （この詳細な使い方については、 302 | Google Project Hosting Issue Tracker documentation 303 | に記載されています）。 304 |

305 | 306 |

307 | それでは、ファイルを保存して、エディタを終了します。 308 |

309 | 310 |

311 | hg changeで、 312 | コードレビューサーバはあなたの変更へissue番号とURLを割り当て、 313 | 次のように出力します: 314 |

315 | 316 | 
317 | CL created: https://codereview.appspot.com/99999
318 |
319 | 320 |

Adding or removing files from an existing change

321 | 322 |

323 | もし、チェンジリスト(CL)を再編集したり、CLへ更新ファイルを追加する必要がある時は、 324 | hg change 99999 325 | を実行します。 326 |

327 | 328 |

329 | 他の方法は、 330 |

331 | 332 | 
333 | $ hg file 99999 somefile
334 |
335 | 336 |

337 | で、CL 99999へsomefileを追加し、 338 |

339 | 340 | 
341 | $ hg file -d 99999 somefile
342 |
343 | 344 |

345 | で、CLからsomefileを削除します。 346 |

347 | 348 |

349 | ファイルは、ひとつのアクティブなCLだけへ属すことができます。 350 | hg fileは、 351 | もしファイルが変更の間で移動される際に警告を出すでしょう。 352 |

353 | 354 |

Synchronize your client

355 | 356 |

357 | あなたが作業している間に、他の人からリポジトリへ変更のコミットがあることでしょう。 358 | クライアントでアップデートするためには: 359 |

360 | 361 | 
362 | $ hg sync
363 |
364 | 365 |

366 | を実行します。 367 | （Mercurialユーザのために補足すると、 368 | hg sync 369 | は 370 | hg pull -u 371 | を実行しますが、 372 | 新しいデータに対し、ローカルのチェンジリストの状態も同期しています） 373 |

374 | 375 |

376 | あなたが編集していたファイルが変更されている場合、 377 | Mercurialはローカルの変更に対し、リモートの変更をマージ（merge） 378 | を試みます。 379 | いくつかのファイルは人の手でマージするために残るかもしれません。 380 |

381 | 382 |

383 | 例えば、 384 | あなたの手元に編集したflag_test.goがあるとします。 385 | しかし、他の誰かが別の変更をコミットしました。 386 | hg syncを実行すると、次のような（ヒドイ）結果を得る（強調を追加しています）でしょう: 387 |

388 | 389 | 
390 | $ hg sync
391 | adding changesets
392 | adding manifests
393 | adding file changes
394 | added 1 changeset with 2 changes to 2 files
395 | getting src/pkg/flag/flag.go
396 | couldn't find merge tool hgmerge
397 | merging src/pkg/flag/flag_test.go
398 | warning: conflicts during merge.
399 | merging src/pkg/flag/flag_test.go failed!
400 | 1 file updated, 0 files merged, 0 files removed, 1 file unresolved
401 | use 'hg resolve' to retry unresolved file merges
402 | $
403 |
404 | 405 |

406 | 重要な部分はイタリックの行で、 407 | 「Mercurialは別の変更であなたの変更をマージすることに失敗した」 408 | ということを伝えています。 409 | これが発生すると、 410 | Mercurialは、ファイルに両方の編集内容を 411 | <<<<<<<と 412 | >>>>>>>のマークで記録します。 413 | マージするために、このファイルの編集が必要です。 414 | 例で話を続けると、 415 | flag_test.goでこれら文字列を検索すると 416 | 次のようになっているかもしれません: 417 |

418 | 419 | 
420 | 	VisitAll(visitor);
421 | <<<<<<< local
422 | 	if len(m) != 7 {
423 | =======
424 | 	if len(m) != 8 {
425 | >>>>>>> other
426 | 		t.Error("VisitAll misses some flags");
427 |
428 | 429 |

430 | Mercurialは 431 | 432 | オリジナルのテキストは6で、あなたは1追加し、別の変更では2追加しています。 433 | ですので、正しい修正は9と考えることができます。 434 | では、マークを取り除き、正しいコードを書きます: 435 |

436 | 437 | 
438 | 	VisitAll(visitor);
439 | 	if len(m) != 9 {
440 | 		t.Error("VisitAll misses some flags");
441 |
442 | 443 |

444 | そして、Mercurialへコンフリクト(conflict)を解決(resolve)したことを伝えます: 445 |

446 | 447 | 
448 | $ hg resolve -m flag_test.go
449 |
450 | 451 |

452 | デバッグのためにファイルを編集してしまっても 453 | 編集内容を保管することを気にしなくても大丈夫です。 454 | 編集内容を破棄するためには 455 | hg revert flag_test.go 456 | が利用できますが、 457 | hg resolve -m 458 | をコンフリクトを解決したことを記録するために実行する必要があります。 459 |

460 | 461 |

Mail the change for review

462 | 463 |

464 | 変更の作成、更新の操作は、コードレビューサーバへdiffのコピーをアップロードしますが、 465 | これについては誰にも通知しません。 466 | 通知するためには、 467 | hg mail 468 | を実行する必要があります)。 469 |

470 | 471 |

472 | 変更をレビューへ送るために、 473 | hg change 474 | の時に割り当てられたチェンジリストの番号を使って 475 | hg mail 476 | を実行します: 477 |

478 | 479 | 
480 | $ hg mail 99999
481 |
482 | 483 |

484 | Reviewer:と 485 | CC:は、 486 | それぞれオプションの 487 | -rと 488 | --ccで追加することができます。 489 | 上の例では、 490 | Reviewerと 491 | CCの行を空っぽにして次のように実行できます: 492 |

493 | 494 | 
495 | $ hg mail -r golang-codereviews@googlegroups.com --cc math-nuts@swtch.com 99999
496 |
497 | 498 |

499 | これで同じ意味になります。 500 |

501 | 502 |

503 | -rと 504 | --ccは、 505 | --rや 506 | -ccのスペルでは使用できないことに注意してください。 507 |

508 | 509 |

510 | あなたの変更が未解決(open)のissueに関連している場合は、 511 | issueへあなたの提案した修正を 512 | CLへのリンクを含め、 513 | issueのアナウンスへ 514 | コメントを追加してください。 515 |

516 | 517 |

Reviewing code

518 | 519 |

520 | hg mailは、 521 | issueへのURLと変更へコメントをレビュアーに求めるための内容を 522 | あなたとレビュアーへemailで送ります（訳注1）。 523 | レビューを完了したら、レビュアーはページにある 524 | “Publish and Mail comments” 525 | をクリックしてコメントを返します。 526 |

527 | 528 | 529 |

Revise and upload

530 | 531 |

532 | おそらく、レビュアーのコメントに応じてコードを見直すと思います。 533 | 見直しが終われば、 534 | hg change 535 | で割り当てられたチェンジリストの番号を使って 536 | hg upload 537 | で通知せずに 538 | コードレビューサーバへ変更をアップロードします。 539 |

540 | 541 | 
542 | $ hg upload 99999
543 |
544 | 545 |

546 | コードの見直しが完了し、レビューの準備が整ったなら: 547 |

548 | 549 | 
550 | $ hg mail 99999
551 |
552 | 553 |

554 | で再び最新のコードをアップロードし、レビュアーへ 555 | please take another look (PTAL) 556 | 依頼をメールします。 557 | コードレビューのウェブページへ訪れ、 558 | あなたがそれに対処してきたことをレビュアーへ知らせたり、また、なぜそうしなかったのかについて 559 | コメントを返信するほうがいいかもしれません。 560 | 返信が終われば、 561 | “Publish and Mail comments” 562 | をクリックして、行へ返信したり他のコメントを返したりします。 563 |

564 |

565 | レビュアーは、新しいコピーへコメントでき、このプロセスを繰り返すことができます。 566 | そして、レビュアーは、LGTM(looks good to me)と言ってメールを返すことで 567 | 変更内容を受け入れます。 568 |

569 | 570 |

571 | hg pending (hg p) 572 | を実行して、あなたの保留中(pending)のリストを表示できます。 573 |

574 | 575 |

Reviewing code by others

576 | 577 |

578 | hg clpatchコマンド 579 | で、誰かのチェンジリストを自分のMercurialクライアントへインポートすることができます。 580 | 例えば: 581 |

582 | 583 | 
584 | $ hg clpatch 99999
585 |
586 | 587 |

588 | で、 589 | CL 99999 590 | の最新の差分が手元へ適用されます。 591 | CL 99999 592 | で参照しているファイルのいずれかへ、既に手元のファイルへ変更がある場合、 593 | clpatchは全体への適用を中止します。 594 | 一度適用すると、 595 | hg pending 596 | などの出力へ 597 | CL 99999 598 | が表示されるようになります。 599 |

600 | 601 |

602 | 手元に適用したCLを元に戻す(revert)なら、 603 | hg revert 604 | コマンドを使います。 605 |

606 | 607 | 
608 | $ hg revert @99999
609 |
610 | 611 |

612 | として、 613 | CL 99999 614 | のオリジナルの状態へファイルを戻せます。 615 | これは、CLのリビジョンを戻したり、他のを適用してみたりする際に効果を発揮します。 616 |

617 | 618 |

619 | CLをコミットし終わった後、 620 | hg sync 621 | を実行すると、ローカルの保留中(pending)のリストからそれが削除されます。 622 | ときどき、提案を取りやめていたり、放棄されているCLの同期をやめたいことがあります。 623 | そんなときは、 624 | hg change -D 99999 625 | で 626 | CL 99999 627 | への参照を除去できます。 628 |

629 | 630 |

Submit the change after the review

631 | 632 |

633 | LGTM 634 | としてもらえたら、いよいよMercurialリポジトリへ入れる時です。 635 |

636 | 637 |

638 | もしあなたがコミッター(committer)でなければ、 639 | 変更を直接コミットできません。 640 | 代わりに、コミッターがレビュアーから 641 | LGTM 642 | としてもらったものに対して: 643 |

644 | 645 | 
646 | $ hg clpatch 99999
647 | $ hg submit 99999
648 |
649 | 650 |

651 | とします。 652 | submitは、コードをリポジトリへ入れるコマンドです。 653 | コミットのAutherはあなたの名前で、誰がコミッターだったかを示すメッセージがログに記録されます。 654 | 次に 655 | hg sync 656 | を実行したときに、変更がコミットされたことを知らせてくれます。 657 |

658 | 659 |

660 | もし、あなたがコミッターなら: 661 |

662 | 663 | 
664 | $ hg submit 99999
665 |
666 | 667 |

668 | を実行します。 669 | これで、変更内容にコードレビューのリンクが記載され、 670 | コードレビュー上は、リポジトリへコミットされた内容のリンクで更新されます。 671 |

672 | 673 |

674 | ローカルが古くなっている場合、 675 | hg submitはsyncするように促してきます: 676 |

677 | 678 | 
679 | $ hg submit 99999
680 | local repository out of date; must sync before submit
681 |
682 | 683 | 684 | 685 |

686 | Goのリポジトリ内のファイルには作者(author)の名前を記載しません。 687 | これは、最新のリストを維持することで混乱してしまうことを避けるためです。 688 | 代わりに、あなたの名前は 689 | Mercurialのチェンジログ 690 | に記載され、さらに 691 | CONTRIBUTORS 692 | ファイルと 693 | AUTHORS 694 | に記載されるようになります。 695 |

696 | 697 |

698 | CONTRIBUTORS 699 | ファイルは、Goへ貢献した人たちが誰かを定義し、 700 | AUTHORS 701 | ファイルは、Goの著作の保有者たちが誰かを定義しています。 702 | GoogleのGoのデベロッパーにより、これらのファイルは、あなたの初めてのコミットで更新されます。 703 | これをできるようにするために、以下のcontributor license agreementsのいずれかをしておく必要があります。 704 |

716 | （既に、別のGoogleのオープンソースプロジェクトで実施している場合は、再度同意する必要はありません。） 717 |

718 | 719 |

720 | この面倒な手続きは、初めてのコミットにだけ必要です。 721 |

722 | 723 |

724 | 標準の著作表示のヘッダは、以下を使うようにしてください: 725 |

726 | 727 | 
728 | // Copyright 2014 The Go Authors. All rights reserved.
729 | // Use of this source code is governed by a BSD-style
730 | // license that can be found in the LICENSE file.
731 |
732 | 733 |

734 | ファイルをリポジトリへ追加した年を入れます。 735 | ファイルを更新する度に年を更新する必要はありません。 736 |

737 | 738 | 739 |

740 | 翻訳メモ: 741 | 742 | submit=コミットと翻訳しています 743 |

744 | 745 |

746 | 訳注1: emailはコードレビューサーバから送信されます。 747 |

748 | 749 | 750 |

751 | 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/doc/contribute.html?r=086daa1d2552d1aa3a6ec3c6d61f72ddc107e52c 752 |

753 | -------------------------------------------------------------------------------- /doc/docs.html: -------------------------------------------------------------------------------- 1 | 5 | 6 | 9 | 10 |

11 | プログラミング言語Goは、プログラマの生産性をより向上させるためのオープンソースプロジェクトです。 12 |

13 | 14 |

15 | Goは表現豊かでシンプルできれいで効率的です。並行処理のメカニズムは、革新的な型システムによる柔軟でモジュール化されたプログラム構造を実現しつつ、マルチコアやネットワーク機器にほとんど特別な考慮をすることなく容易にプログラムを書くことを可能にします。Goは素早く機械語にコンパイルでき、さらにガーベッジコレクションの利便性とランタイムリフレクションのパワーを併せ持ちます。動的形付けを持つインタプリタ型言語と感じられるほどに速い、静的型付けを持つコンパイル言語です。 16 |

17 | 18 |
19 | 20 |

Goのインストール

21 | 22 |

インストール

23 |

24 | Goコンパイラ、ツール、ライブラリをダウンロードしインストールする手順です。

25 | 26 | 27 |

Goを学ぶ

28 | 29 | 30 | 31 |

A Tour of Go

32 |

33 | 3つのセクションから成るインタラクティブなGoのイントロダクションです。最初のセクションでは基本的な文法・データ構造を扱い、次にメソッドとインタフェースについて議論し、最後に並行化基本命令を紹介します。各セクションの終わりには練習問題がありますので、学習した内容の復習ができます。利用には、オンラインツアーとローカルへインストールする方法があります。 34 |

35 | 36 |

Goの書き方

37 |

38 | このドキュメントではどのようにgoコマンドでパッケージやコマンドをフェッチ・ビルド・インストールし、テストを実行するのかを説明しています。スクリーンキャスト（英語）も利用できます。 39 |

40 | 41 |

Effective Go

42 |

43 | きれいで慣用的なコードを書くtipsを記したドキュメントです。すべての入門Goプログラマーにとって必読な記事です。最初に読むツアー・言語仕様の内容を補助する位置づけのものです。 44 |

45 | 46 |

よくある質問 (FAQ)

47 |

48 | Goについての一般的な質問に対する回答です。 49 |

50 | 51 |

The Go Wiki

52 |

GoコミュニティがメンテナンスしているWikiです。

53 | 54 |

もっと読みたい

55 |

56 | その他のGoの学習素材を利用するにはWikiのLearnページを参照ください。 57 |

58 | 59 | 60 |

リファレンス

61 | 62 |

パッケージドキュメント

63 |

64 | Goの標準ライブラリの説明書です。 65 |

66 | 67 |

コマンドドキュメント

68 |

69 | Go toolの説明書です。 70 |

71 | 72 |

言語仕様

73 |

74 | 公式のGo言語仕様です。 75 |

76 | 77 |

Goメモリモデル

78 |

79 | あるgoroutineの変数の読み出しをする際に、他のgoroutineからその変数へ書き込んだ値が読み込まれることを保証する条件を記したドキュメントです。 80 |

81 | 82 | 83 |

特集記事

84 | 85 |

The Go Blog

86 |

Goプロジェクトのオフィシャルブログです。ニュースやGoチームやゲストによる特集記事を掲載しています。（英語）

87 | 88 |

コードウォーク

89 |

90 | Goプログラムのガイドツアー 91 |

92 | 98 | 99 |

言語

100 | 110 | 111 |

パッケージ

112 | 119 | 120 |

ツール

121 | 130 | 131 |

もっと読みたい

132 |

133 | Goの記事をさらに読みたい場合は、WikiのArticlesページをご覧ください。 134 |

135 | 136 | 137 |

講演資料

138 | 139 | 140 | 141 |

Goビデオツアー

142 |

143 | Goの速さ、楽しさ、生産性を実現する3つの要素（インタフェース、リフレクション、並行処理）。簡単なWebクローラを構築しながらこれらの要素を説明します。 144 |

145 | 146 |

美しく成熟するコード

147 |

148 | 鍵となるGo設計のゴールはコードの順応性です。簡素な設計ができ明確で自然な方法でビルドできることです。この講演では、送信されてくるTCPコネクションのペアを引き合わせ、Goの並行処理メカニズム、インタフェース、標準ライブラリを使ってWebインタフェース等の機能を拡張する簡単な「チャットルーレット」サーバをAndrew Gerrandが説明します。プログラムの機能が劇的に変化する一方で、プログラムの機能が成熟するにつれてGoの柔軟性が元々のプログラムの設計の維持に寄与していく様子をご覧いただけます。 149 |

150 | 151 |

Go並行処理パターン

152 |

153 | 並行処理はハイパフォーマンスなネットワークサービスを設計する鍵となります。Goの並行化基本命令（goroutines、チャネル）は並行処理の実行を実現するシンプルで効率的な方法を提供します。この講演では、難解な並行性の問題がシンプルなGoのコードでうまく解決できることをご覧いただけます。 154 |

155 | 156 |

高度なGo並行処理パターン

157 |

158 | この講演ではGo並行処理パターンでの話題を、さらにディープなGoの並行化基本命令に広げます。 159 |

160 | 161 |

もっと見たい

162 |

163 | Goに関する講演内容をもっと見るには、Goの講演資料、wikiページをご覧ください。 164 |

165 | 166 | 167 |

他の言語のドキュメント

168 | 169 |

170 | 他の言語へ翻訳されたドキュメントを見るにはWikiのNonEnglishページをご覧ください。 171 |

172 | -------------------------------------------------------------------------------- /doc/go1.3.html: -------------------------------------------------------------------------------- 1 | 6 | 7 | 10 | 11 |

Go1.3のイントロダクション

12 | 13 |

14 | Go1.3のリリースは、Go1.2をリリースしてから6ヶ月後を予定しています。 15 | そして、いかなる言語仕様の変更もありません。 16 | Go1.3では、ガーベッジコレクションやコンパイラツールチェーンの改善に集中しています。 17 | 特に大規模なプロジェクトにおいて、ビルドが高速になるでしょう。 18 | 他にも全体的にパフォーマンスの大幅な改善やサポート環境の追加(DragonFly BSD, Solaris, Plan9)、 19 | GoogleのNative Client architecture(NaCl)のサポートが含まれます。 20 | また同期に関連したメモリモデルの改良もありますが、これも重要です。 21 | 当然、後方互換性は保っています。 22 | Go1.3に移行しても、大抵は変更なしでも問題ないはずです。 23 |

24 | 25 |

サポート対象OSに関する変更点

26 | 27 | 37 |

Windows 2000のサポート終了

38 | 39 |

40 | マイクロソフトは2010年にWindows 2000をサポートを終了しました。 41 | 例外機構(Unixにおけるシグナル)の実装が難しいため、 42 | Go1.3でも同様にサポートを終了します。 43 |

44 | 45 | 53 |

DragonFly BSDのサポート

54 | 55 |

56 | Go1.3では、試験的にamd64 (64-bit x86)と386 (32-bit x86) アーキテクチャ上で動作するDragonFly BSDをサポートします。DragonFly BSD 3.6以上が必要です。 57 |

58 | 59 | 77 |

Free BSDのサポート

78 | 79 |

80 | これまで公式にアナウンスしていませんでしたが、Go1.2からFreeBSD 8以上のFreeBSDをサポートします。 81 |

82 | 83 |

84 | Go1.3をFreeBSDで使用するためには、kernelにCOMPAT_FREEBSD32 flagを 85 | 設定してコンパイルしなければいけません。 86 |

87 | 88 |

89 | ARMプラットフォーム用EABIのシステムコールへの切り替えと協調して、 90 | Go1.3はFreeBSD 10のみで実行されます。 91 | x86プラットフォーム、386およびamd64は、影響を受けません。 92 |

93 | 94 | 107 |

Native Clientのサポート

108 | 109 |

110 | Go1.3で、Native Clientの仮想マシンアーキテクチャのサポートが復活します。 111 | 32ビットインテルアーキテクチャ(GOARCH=386)、 112 | または64ビットでポインタは32ビット(GARCH=amd64p32)のどちらかの環境で動作します。 113 | ARMはまだサポートしていません。Portable Native Client (PNaCl)と混同しないように注意して下さい。 114 | Navite Clinetについての詳細はここを参照してください。 115 | またGoのバージョンを指定する方法についてはここに記載があります。 116 |

117 | 118 | 125 |

NetBSDのサポート

126 | 127 |

128 | Go1.3では、NetBSD 6.0以上でNetBSDをサポートします。 129 |

130 | 131 | 138 |

OpenBSDのサポート

139 | 140 |

141 | Go1.3では、OpenBSD 5.5以上でOpenBSDをサポートします。 142 |

143 | 144 | 152 |

Plan 9のサポート

153 | 154 |

155 | Go1.3では、試験的に386 (32-bit x86) アーキテクチャ上で動作するPlan9をサポートします。 156 | 2012-06以降のPlan 9のTsemacquire syscall が必要です。 157 |

158 | 159 | 167 |

Solarisのサポート

168 | 169 |

170 | Go1.3では、試験的にamd64 (64-bit x86) アーキテクチャ上で動作するSolarisをサポートします。 171 | illumos、Solaris 11以上が必要です。 172 |

173 | 174 |

メモリモデルの変更点

175 | 176 |

177 | Go1.3では、メモリモデルに新しい規約を追加しました。 178 | これはバッファ付きチャネルの送受信に関するもので、それが簡易なセマフォとして使用できることを明示しました。 179 | チャネルへの送信は資源を獲得し、チャネルからの受信は資源を開放します。 180 | 言語仕様の変更ではなく、コミュニケーションに期待される性質を明らかにしただけです。 181 |

182 | 183 |

実装とツールの変更点

184 | 185 |

スタック

186 | 187 |

188 | Go1.3では、ゴルーチンのスタック実装が以前のセグメント方式からcontiguous方式に変更されています。 189 | 実行中のゴルーチンがさらにスタック領域を必要としたとき、スタックはメモリ上のより大きな単一領域に転送されます。 190 | セグメント境界を跨いで計算を繰り返すようなケースでは、転送操作のオーバーヘッドは無視できるし、 191 | さらに”ホットスポット”問題も解消できます。 192 | パフォーマンスの詳細は、design documentを見て下さい。 193 |

194 | 195 |

ガーベッジコレクタの変更点

196 | 197 |

198 | これまで、ガーベッジコレクタがヒープ領域の値の評価は正確でした。 199 | Go1.3では、スタック上の値も同様に正確に評価されます。 200 | つまり、ポインタでないint型の値がポインタに間違われたり、未使用メモリとして再利用されるようなことはありません。 201 |

202 | 203 |

204 | 217 | Go1.3以降では、ランタイムはポインタ型の値はポインタを含み、他の値ではないと仮定します。 218 | この仮定は、スタックの拡大とガーベッジコレクションの両方の正確な振る舞いの基本です。 219 | ポインタ型の値に整数を格納するために、 package unsafe を使用するプログラムは不正であり、ランタイムがこの振る舞いを検出した場合にはクラッシュします。 220 | 整数型の値にポインタを格納するために、 package unsafe を使用するプログラムもまた不正ですが、実行時に検出することは困難です。 221 | ポインタはランタイムから隠されているため、スタックの拡大や、ガーベッジコレクションは、ダングリングポインタ(dangling pointer)を作成し、これらが指すメモリを再利用することができます。 222 |

223 | 224 |

225 | 230 | 更新: 231 | ポインタにメモリへ保持する整数型の値を変換するために、 unsafe.Pointer を使用するコードは不正であり、書き直す必要があります。 232 | このようなコードは go vet で識別することができます。 233 |

234 | 235 |

Map iteration

236 | 237 |

238 | 251 | 小規模なmapのイテレーションは、もう一貫した順序では動きません。 252 | Go1では 253 | “map上のイテレーション順序は指定されず、次のイテレーションで同じになることは保証されない” 254 | と定義されています。 255 | mapのイテレーション順序の依存からコードを守るために、Go1.0以降はmapのランダムなインデックスでmapのイテレーションをします。 256 | イテレーションの順序はシステムによって異なりますが、Go1.1で導入された新しいmapの実装では、8個以下のエントリを持つmapのイテレーション順序はランダムではありませんでした。 257 | そのためGo1.1とGo1.2では、小さいmapのイテレーション順序に依存した、特定のシステムでだけ安定して動作するプログラムを書くことができました。 258 | Go1.3では、これらのバグを洗い出すために、小さいmapでもイテレーション順序はランダムになりました。 259 |

260 | 261 |

262 | 267 | 更新: 268 | 小さなmapでイテレーション順序が固定されていることを仮定しているコードは、 269 | そのような仮定をしないように書き直す必要があります。 270 | 小さなmapだけが影響を受けるため、この問題はテストで多く発生します。 271 |

272 | 273 | 274 | 275 |

276 | Goリンカのオーバーホールの一環で、 277 | コンパイラとリンカはリファクタリングされました。 278 | リンカは依然としてCで実装されています。しかし、リンカの一部だった命令選択は、 279 | liblinkと呼ばれる新しいライブラリを実装して、コンパイラで実行されるようになりました。 280 | パッケージの初回コンパイルで命令選択を一度しか行わないので、大規模なプロジェクトのコンパイルは大幅に高速になります。 281 |

282 | 283 |

284 | 更新: これは大きな内部変更ですが、プログラムには影響しないはずです。 285 |

286 | 287 |

gccgoのステータス

288 | 289 |

290 | GCC4.9では、Go1.2(1.3ではなく)をサポートする予定です。GCCとGoのリリース計画は同期していません。 291 | よってGo1.3は開発ブランチで使用可能ですが、おそらく次のGCC4.10ではGo1.4がサポートされる予定です。 292 |

293 | 294 |

Goコマンドの変更点

295 | 296 |

297 | cmd/goコマンドに新しい機能がいくつか追加されました。 298 | 新たに、go runとgo testサブコマンドは 299 | -execオプションをサポートしました。 300 | これは、ビルドしたバイナリを実行するための別の方法を指定できます。直接の目的は、NaClをサポートすることです。 301 |

302 | 303 |

304 | 競合ディテクタが有効になっているとき、go testサブコマンドのカバレッジサポートは 305 | 自動的にカバレッジモードに-atomicを指定します。 306 | これは、カバレッジカウンタへの安全でないアクセスが誤って検出されてしまうことを防ぐためです。 307 |

308 | 309 |

310 | go testサブコマンドは、 311 | テストファイルがない場合でもパッケージを全てビルドするようになりました。 312 | 以前は、テストファイルがない場合は何もしませんでした。 313 |

314 | 315 |

316 | 321 | go buildサブコマンドは、 322 | ターゲット自体ではなく、指定したターゲットの依存をインストールするために新しい-iオプションをサポートします。 323 |

324 | 325 |

326 | 332 | cgoでクロスコンパイルがサポートされるようになりました。 333 | all.bashを実行する際、それぞれCとC++のコード用のクロスコンパイラを指定するために CC_FOR_TARGET と CXX_FOR_TARGET の環境変数が使われます。 334 |

335 | 336 |

337 | 最後に、goコマンドは、cgoを通じてObjective-Cファイル(ファイル拡張子が.m)をインポートする 338 | パッケージをサポートしています。 339 |

340 | 341 |

cgoの変更点

342 | 343 |

344 | Goのパッケージでimport "C"宣言を処理するcmd/cgoコマンドは、 345 | いくつかのパッケージでコンパイルが停止する深刻なバグが修正されました。 346 | 以前は、不完全な構造体型へのポインタはGoの*[0]byte型に変換され、Goコンパイラは構造体へのポインタを違うものを期待している関数へ渡していることを検出できませんでした。 347 | Go 1.3ではこの誤りを修正し、不完全な構造体はそれぞれ違う名前の型へ変換されるようになりました。 348 |

349 | 350 |

351 | Cの宣言としてtypedef struct S Tが不完全な構造体struct Sとともに与えられたとき、 352 | 一部のGoのコードはこのバグを、C.struct_SとC.Tをお互いに入れ替えるために使っていました。 353 | Cgoはこのような使い方を、完全な構造体型でも明確に許すようになりました。 354 | しかし、一部のGoのコードはこのバグを(たとえば)*C.FILEをあるパッケージから別のパッケージへ渡すために使っています。 355 | これは正しくなく、動作しなくなりました: 一般に、GoのパッケージはCの型と名前をAPI上で公開するべきではありません。 356 |

357 | 358 |

359 | 更新: 不完全な型へのポインタを混同しているコードや、パッケージ境界を跨いで渡しているコードはコンパイルできなくなりました。書き直す必要があります。 360 | もしその変換が正しく、かつそのままにしたいのであれば、unsafe.Pointerを使って明示的に変換してください。 361 |

362 | 363 |

SWIGを使用しているプログラムはSWIG 3.0が必要

364 | 365 |

366 | SWIGを使用しているGoのプログラムは、SWIGバージョン3.0が必要になりました。 367 | cmd/goコマンドはSWIGで生成されたオブジェクトファイルを、共有ライブラリをビルドしてリンクするのではなく、バイナリに直接リンクするようなりました。 368 |

369 | 370 |

コマンドライン引数の解析

371 | 372 |

373 | Goコマンドツールチェーンで、アセンブラはGo flagパッケージと同じコマンドライン引数解析ルールを使用するようになりました。 374 | これは伝統的なUnixコマンドライン引数解析を元にしています。もしスクリプト内で直接ツールを呼び出している場合には影響を受けるかもしれません。 375 | 例えば、go tool 6a -SDfooはgo tool 6a -S -D fooと書かなければいけません。 376 | (同様の変更は、Go 1.1のときにリンカとコンパイラにもありました。) 377 |

378 | 379 |

godocの変更

380 |

381 | godocを 382 | -analysisフラグつきで実行すると、 383 | コードに対して高度な静的解析をするようになりました。 384 | 解析結果はソースビューとドキュメントビューのどちらでもみることができ、パッケージごとの関数の呼び出しグラフ、 385 | 定義と参照、型とそのメソッド、インタフェースとその実装、チャネルの送信と受信、関数とその呼び出し元、 386 | 呼び出す場所と呼び出されるもの同士の関連性が含まれています。 387 |

388 | 389 |

その他

390 | 391 |

392 | ベンチマーク結果のパフォーマンスを比較するためのツールmisc/benchcmpが書き直されました。 393 | shellとawkで書かれたスクリプトがメインレポジトリに存在しましたが、現在はGoで実装されていてgo.toolsレポジトリに含まれています。 394 | ドキュメントはここにあります。 395 |

396 | 397 |

398 | Goのディストリビューションを構築する人のため、misc/distに存在したツールを移動しました。 399 | これらのツールは、現在はmisc/makereleaseにあります。 400 |

401 | 402 | 403 |

パフォーマンス

404 | 405 |

406 | Go1.3では、ランタイムやガーベッジコレクション、さらに標準ライブラリにもいくつか変更が入っています。 407 | そのため、たくさんのケースで性能が改善されています。 408 | 重要な点を上げると、 409 |

410 | 411 | 434 | 435 |

436 | また、ランタイムはスタックダンプにゴルーチンのブロックされた時間を含むようになりました。 437 | これは、デッドロックやパフォーマンス問題をデバッグするときに役立ちます。 438 |

439 | 440 |

標準ライブラリの変更点

441 | 442 |

新しいパッケージ

443 | 444 |

445 | 新たにdebug/plan9objパッケージが追加されました。 446 | これは、Plan9のa.outオブジェクトファイル向けの実装です。 447 |

448 | 449 |

大規模な変更点

450 | 451 |

452 | crypto/tlsに存在していたバグによって、気づかないうちにTLS認証をスキップできてしまいました。 453 | Go1.3で、このバグは修正されています。ServerNameかInsecureSkipVerifyのどちらかは必ず指定しなければいけません。 454 | ServerNameが指定されている場合、ServerNameの使用が強制されます。 455 | これは破壊的変更です。もしこれまでの安全でない振る舞いに依存したコードを書いている場合は、コードの変更が必要です。 456 |

457 | 458 |

459 | 標準ライブラリにsync.Poolという重要な型が追加されました。 460 | これを利用することで、自動でメモリが再利用されるようなキャッシュ機構のようなものを簡単に実装できます。 461 |

462 | 463 |

464 | testingパッケージのベンチマーキングヘルパー、 465 | BにRunParallelメソッドが追加されました。 466 | これを使用すると、複数のCPUで簡単にベンチマークが実行できるようになります。 467 |

468 | 469 |

470 | 更新: crypto/tlsパッケージの修正は既存のコードを壊してしまうかもしれません。 471 | しかし、そのようなコードにはバグがあるので、更新すべきです。 472 |

473 | 474 |

小規模な変更点

475 | 476 |

477 | 以下に、標準ライブラリへの小規模な変更点をまとめます。そのほとんどは新たに追加されたものです。 478 | より詳細な情報は関係するパッケージのドキュメントを参照して下さい。 479 |

480 | 481 | 653 | -------------------------------------------------------------------------------- /doc/go_mem.html: -------------------------------------------------------------------------------- 1 | 6 | 7 | 10 | 11 | 19 | 20 |

はじめに

21 | 22 |

23 | Goのメモリモデルは、あるゴルーチンで変数を読み取り中に他のゴルーチンから同じ変数に書き込みがあった場合、 24 | 書き込みされた結果を読み取り側から観測することが保証できる条件を指定します。 25 |

26 | 27 |

前事象

28 | 29 |

30 | 1つのゴルーチン中では、読み取りと書き込みはプログラムで指定された順序で実行されたかのように振る舞わなければいけません。 31 | すなわち、1つのゴルーチン中での読み取りと書き込みの実行順の変更が言語仕様によって定義された振る舞いを変えない限り、 32 | コンパイラとプロセッサは、読み取りと書き込みの実行順を変更する可能性があります。 33 | そのため、それぞれのゴルーチンで観測される実行順は違うかもしれません。 34 | 例えば、あるゴルーチンでa = 1; b = 2;を実行するとしましょう。 35 | 他のゴルーチンでは、aの更新よりも先に、bの更新を観測することがあります。 36 |

37 | 38 |

39 | 読み取りと書き込みの要件を指定するため、前事象、つまりGoにおけるメモリ操作の半順序を定義します。 40 | もし、イベントe1がイベントe2の前に起きる場合、 41 | これをe2がe1の後に起きると呼びます。 42 | また、もしe1がe2の前にも後にも起きない場合、 43 | これをe1とe2が同時に起きると呼びます。 44 |

45 | 46 |

47 | 1つのゴルーチン中では、前事象の順序はプログラムに記述された順序と同様となる。 48 |

49 | 50 |

51 | 次の条件が両方満たされる場合、変数vの読み込みrは、変数vへの書き込みwを観測することを許可されます。 52 |

53 | 54 |
    55 |
  1. rは、wの前に起こらない。
    2. 56 |
  2. wとrの間に、他のvへの書き込みw'がない。
    3. 57 |
58 | 59 |

60 | 変数vの読み込みrが特定の変数vの書き込みwを観測することを保証するためには、 61 | rから観測できる書き込みがwだけであることを確認します。 62 | すなわち、次の条件が両方満たされる場合、rがwを観測することを保証します。 63 |

64 | 65 |
    66 |
  1. wがrの前に起こる。
    2. 67 |
  2. 共有変数vへの他のいかなる書き込みも、wの前かrの後に起こる。
    3. 68 |
69 | 70 |

71 | この2つの条件は、最初の条件よりも強い制約です。 72 | これは、wまたはrと同時に他の書き込みが行われないことを要求します。 73 |

74 | 75 |

76 | 1つのゴルーチン内では並行性がないので、以下の2つの定義は同値です。 77 | 読み込みrは、最も最近のvへの書き込みwによって書き込まれた値を観測します。 78 | 複数のゴルーチンから共有変数vにアクセスする場合、同期イベントを使用して望んだ書き込み結果を観測できるように前事象条件を満たす必要があります。 79 |

80 | 81 |

82 | 変数vはv型のゼロ値で初期化されますが、これはメモリモデルの書き込みと同様に振る舞います。 83 |

84 | 85 |

86 | マシンのワードサイズより大きい値の読み込みと書き込みは、複数のマシンワードサイズ単位の操作として処理されます。 87 | その際、操作の実行順は規定されていません。 88 |

89 | 90 |

同期

91 | 92 |

初期化

93 | 94 |

95 | プログラムの初期化は、1つのゴルーチンで実行されます。そのゴルーチンから他のゴルーチンを実行した場合は、並行に初期化が実行されます。 96 |

97 | 98 |

99 | もし、パッケージpがパッケージqをインポートしているとすると、 100 | qの初期化関数の実行が完了するまで、pのいかなる処理も実行されません。 101 |

102 | 103 |

104 | main.main関数は、全てのinit関数が完了した後で実行されます。 105 |

106 | 107 |

ゴルーチンの起動

108 | 109 |

110 | 新たにゴルーチンを起動するgo文は、ゴルーチンの実行がはじまる前に起きます。 111 |

112 | 113 |

114 | 例として、次のプログラムを見て下さい。 115 |

116 | 117 | 
118 | var a string
119 | 
120 | func f() {
121 | 	print(a)
122 | }
123 | 
124 | func hello() {
125 | 	a = "hello, world"
126 | 	go f()
127 | }
128 |
129 | 130 |

131 | hello関数を呼び出すと、いずれかの時点で"hello, world"がコンソールに出力されます 132 | (おそらく、hello関数の呼び出しが終了した後に出力されるでしょう)。 133 |

134 | 135 |

ゴルーチンの破棄

136 | 137 |

138 | ゴルーチンの終了前に、プログラム中のどの処理も先に実行されることは保証されません。 139 | 例えば、次のプログラムを見て下さい。 140 |

141 | 142 | 
143 | var a string
144 | 
145 | func hello() {
146 | 	go func() { a = "hello" }()
147 | 	print(a)
148 | }
149 |
150 | 151 |

152 | 同期イベントがないため、他のゴルーチンからaへの代入結果("hello")を観測できるかどうかは保証されません。 153 | 実際、コンパイラによってはgo文全体を削除することもあるでしょう。 154 |

155 | 156 |

157 | ゴルーチン内での変更を他のゴルーチンからも観測したければ、ロックやチャネルのような同期メカニズムを使用して、 158 | 相対的な実行順を確立しましょう。 159 |

160 | 161 |

チャネルによる通信

162 | 163 |

164 | ゴルーチン間の同期させるため、よく使われる方法はチャネルによる通信です。 165 | 特定のチャネルへの送信は、そのチャネルから受信に対応づけられます。 166 | 送信と受信は、通常は異なるゴルーチンで行われます。 167 |

168 | 169 |

170 | チャネルへの送信は、チャネルからの受信が完了する前に起こる。 171 |

172 | 173 |

174 | 次のプログラムを見て下さい。 175 |

176 | 177 | 
178 | var c = make(chan int, 10)
179 | var a string
180 | 
181 | func f() {
182 | 	a = "hello, world"
183 | 	c <- 0
184 | }
185 | 
186 | func main() {
187 | 	go f()
188 | 	<-c
189 | 	print(a)
190 | }
191 |
192 | 193 |

194 | 上記プログラムは、"hello, world"が必ず表示されます。 195 | 変数aへの書き込みはチャネルcへの送信の前に起こります。 196 | 一方でチャネルcからの受信は、チャネルcへの送信が行われるまで完了しないため、 197 | printは必ず実行されます。 198 |

199 | 200 |

201 | チャネルの閉じられた後で、チャネルからチャネルが閉じられたことを示すゼロ値を受信する。 202 |

203 | 204 |

205 | 先ほどの例では、c <- 0をclose(c)に置き換えても、同じ結果になります。 206 |

207 | 208 |

209 | バッファなしチャネルは、チャネルへの送信が完了する前に、チャネルからの受信が起こる。 210 |

211 | 212 |

213 | 次のプログラムを見て下さい(先ほどの例とほとんど同じですが、バッファなしチャネルを使用している点と、受信と送信の順番が入れ替わっている点が異なります)。 214 |

215 | 216 | 
217 | var c = make(chan int)
218 | var a string
219 | 
220 | func f() {
221 | 	a = "hello, world"
222 | 	<-c
223 | }
224 |
225 | 226 | 
227 | func main() {
228 | 	go f()
229 | 	c <- 0
230 | 	print(a)
231 | }
232 |
233 | 234 |

235 | 上記プログラムも、必ず"hello, world"が表示されます。 236 | 変数aへの書き込みはチャネルcからの受信の前に起こります。 237 | 一方でチャネルcへの送信は、チャネルcからの受信が行われるまで完了しないため、 238 | printは必ず実行されます。 239 |

240 | 241 |

242 | チャネルにバッファがあると(例えば、c = make(chan, int, 1)に変更する)、 243 | 上記プログラムは常に"hello, world"を出力するとは限りません(空文字を出力したり、あるいは異常終了してしまうなど挙動が不安定になります)。 244 |

245 | 246 |

247 | 容量Cのチャネルからのk回目の受信は、そのチャネルへのk+C回目の送信が完了する前に起こる。 248 |

249 | 250 |

251 | このルールは、先ほどのバッファつきチャネルのルールを一般化したものです。 252 | バッファつきチャネルを使って、カウンタセマフォを実装できます。 253 | 具体的には、チャネル内のアイテム数が現在の使用数、チャネルの容量が最大同時使用数を表しているとし、 254 | チャネルへの送信をセマフォの取得、チャネルからの受信をセマフォからの解放に対応させます。 255 | これは、並行性を制限したいときによく使う書き方です。 256 |

257 | 258 |

259 | 次のプログラムはworkリストの要素毎にゴルーチンを実行します。 260 | ゴルーチンの同時実行数は、limitチャネルを使って最大でも3つに収まるように調整されます。 261 |

262 | 263 | 
264 | var limit = make(chan int, 3)
265 | 
266 | func main() {
267 | 	for _, w := range work {
268 | 		go func() {
269 | 			limit <- 1
270 | 			w()
271 | 			<-limit
272 | 		}()
273 | 	}
274 | 	select{}
275 | }
276 |
277 | 278 |

ロック

279 | 280 |

281 | syncパッケージには、sync.Mutexとsync.RWMutexの2つロックのデータ型が実装されています。 282 |

283 | 284 |

285 | sync.Mutexまたはsync.RWMutex型の変数lがあって、n < mとする。 286 | このとき、n回目のl.Unlock()呼び出しは、m回目のl.Lock()呼び出しから応答が返る前に起こる。 287 |

288 | 289 |

290 | 次のプログラムを見て下さい。 291 |

292 | 293 | 
294 | var l sync.Mutex
295 | var a string
296 | 
297 | func f() {
298 | 	a = "hello, world"
299 | 	l.Unlock()
300 | }
301 | 
302 | func main() {
303 | 	l.Lock()
304 | 	go f()
305 | 	l.Lock()
306 | 	print(a)
307 | }
308 |
309 | 310 |

311 | 上記プログラムは、必ず"hello, world"を表示します。 312 | 最初のl.Unlock()呼び出し(関数f中)は、2つ目のl.Lock()呼び出し(関数main中)の前に起こるので、 313 | printは必ず実行されます。 314 |

315 | 316 |

317 | sync.RWMutex型の変数lへのl.RLock呼び出しはどれも、 318 | 以下のようなnが存在し、l.RLockはn回目のl.Unlock呼び出しの後で起き、 319 | l.RUnlockはn+1回目のl.Lock呼び出しの前に起こる。 320 |

321 | 322 |

Once

323 | 324 |

325 | syncパッケージは、Once型を使用した、複数のゴルーチンの下で安全に初期化を行う方法を提供します。 326 | 複数のスレッドから、特定のfに対してonce.Do(f)を実行することができます。 327 | しかし、f()は1つのスレッドからしか実行されず、他の呼び出しはf()呼び出しが完了するまでブロックします。 328 |

329 | 330 |

331 | once.Do(f)からのf()の唯一の呼び出しは、どのonce.Do(f)から呼び出し元に戻るよりも前に起こる。 332 |

333 | 334 |

335 | 次のプログラムを見て下さい。 336 |

337 | 338 | 
339 | var a string
340 | var once sync.Once
341 | 
342 | func setup() {
343 | 	a = "hello, world"
344 | }
345 | 
346 | func doprint() {
347 | 	once.Do(setup)
348 | 	print(a)
349 | }
350 | 
351 | func twoprint() {
352 | 	go doprint()
353 | 	go doprint()
354 | }
355 |
356 | 357 |

358 | twoprintを呼び出すと、"hello, world"を2回表示します。 359 | 最初の呼び出しで、doprintはsetupを一度だけ実行します。 360 |

361 | 362 |

誤った同期

363 | 364 |

365 | 読み込みrは、並行して実行された書き込みwを観測するかもしれないことに注意してください。 366 | このような場合でも、これはwの前に起こることを、 367 | rの後に起こることが観測可能だということは意味していません。 368 |

369 | 370 |

371 | 次のプログラムを見て下さい。 372 |

373 | 374 | 
375 | var a, b int
376 | 
377 | func f() {
378 | 	a = 1
379 | 	b = 2
380 | }
381 | 
382 | func g() {
383 | 	print(b)
384 | 	print(a)
385 | }
386 | 
387 | func main() {
388 | 	go f()
389 | 	g()
390 | }
391 |
392 | 393 |

394 | 上記プログラムは、gが2を表示した後に、0を表示することがあります。 395 |

396 | 397 |

398 | この事実により、いくつかの一般的によく使われる書き方は意図した通りに動作しません。 399 |

400 | 401 |

402 | ダブルチェックロッキングは、同期のオーバーヘッドを回避しようとする試みです。 403 | 例えば、twoprintプログラムは、以下のように誤った書き方をされることがあります。 404 |

405 | 406 | 
407 | var a string
408 | var done bool
409 | 
410 | func setup() {
411 | 	a = "hello, world"
412 | 	done = true
413 | }
414 | 
415 | func doprint() {
416 | 	if !done {
417 | 		once.Do(setup)
418 | 	}
419 | 	print(a)
420 | }
421 | 
422 | func twoprint() {
423 | 	go doprint()
424 | 	go doprint()
425 | }
426 |
427 | 428 |

429 | doprint中で、doneへの書き込みが観測できれば、 430 | 暗黙的にaへの書き込みも観測できるだろうと考えてはいけません。 431 | このようなことは、保証されていません。 432 | このプログラムは、"hello, world"ではなく空文字列を表示することがあります。 433 |

434 | 435 |

436 | 別の誤った書き方は、以下のようにビジーループを使用することです。 437 |

438 | 439 | 
440 | var a string
441 | var done bool
442 | 
443 | func setup() {
444 | 	a = "hello, world"
445 | 	done = true
446 | }
447 | 
448 | func main() {
449 | 	go setup()
450 | 	for !done {
451 | 	}
452 | 	print(a)
453 | }
454 |
455 | 456 |

457 | これも、mainからdoneへの書き込みが観測できれば、 458 | 暗黙的にaへの書き込みも観測できるだろうと考えてはいけません。 459 | このようなことは、保証されていません。 460 | このプログラムも同様に、空文字列を表示することがあります。 461 | さらに悪いことに、2つのスレッド間で同期をとっていないため、 462 | mainがdoneへの書き込みを観測することも保証されません。 463 | そのため、main中のループは終了しないかもしれません。 464 |

465 | 466 |

467 | このテーマには、次のプログラムのように微妙なパターンがあります。 468 |

469 | 470 | 
471 | type T struct {
472 | 	msg string
473 | }
474 | 
475 | var g *T
476 | 
477 | func setup() {
478 | 	t := new(T)
479 | 	t.msg = "hello, world"
480 | 	g = t
481 | }
482 | 
483 | func main() {
484 | 	go setup()
485 | 	for g == nil {
486 | 	}
487 | 	print(g.msg)
488 | }
489 |
490 | 491 |

492 | たとえmainがg != nilを観測してループを終了したとしても、 493 | g.msgの初期値を観測できる保証はありません。 494 |

495 | 496 |

497 | 全ての例における解決策は、明示的な同期方式を使用することです。 498 |

499 | -------------------------------------------------------------------------------- /doc/help.html: -------------------------------------------------------------------------------- 1 | 5 | 6 | 9 | 10 | 11 | 12 |

13 | Goに関する情報は以下を参考にしてみてください。 14 |

15 | 16 |
17 | 18 |

よくある質問 (FAQ)

19 |

Goに関する一般的な内容の回答があります。

20 | 21 |

The Go Playground

22 |

Goのコードをオンラインで書く、実行する、共有する場所です。

23 | 24 |

The Go Wiki

25 |

Goコミュニティによってメンテナンスされているwikiです。

26 | 27 |

Go Nuts メーリングリスト

28 |

29 | golang-nutsへ投稿する前に、まずgolang-nutsのアーカイブを検索し、 30 | FAQと 31 | wiki 32 | を参照してみてください。 33 |

34 | 35 |

Go IRC Channel

36 |

GoのオフィシャルのIRCチャネル（ irc.freenode.net の #go-nuts ）（英語）があります。

37 | 38 |

Go言語（Lingr）

39 |

日本Gopherのたまり場です。

40 | 41 |

The Go+ community

42 |

Google+のコミュニティ（英語）です。

43 | 44 |

Golang JP（Google+コミュニティ）

45 |

Google+の日本語コミュニティです。

46 | 47 |

The Go Programming Language at Google+

48 |

GoプロジェクトのGoogle+のページ（英語）です。

49 | 50 |

@golang at Twitter

51 |

GoプロジェクトのオフィシャルTwitterアカウント（英語）です。

52 |

#golang ハッシュタグでつぶやくと返事があるかもしれません。

53 | 54 |

@golangjp at Twitter

55 |

日本のGoの情報収集をしているTwitterアカウントです。

56 |

日本語でつぶやく際は #golangjp や #Go言語 ハッシュタグを使いましょう。

57 | 58 |

Goユーザーグループ

59 |

60 | 世界中にGoプログラマ("gophers")のグループがあります。 61 |

62 | 63 | -------------------------------------------------------------------------------- /doc/install-source.html: -------------------------------------------------------------------------------- 1 | 5 | 6 | 9 | 10 |

はじめに

11 | 12 |

13 | Goはオープンソースプロジェクトで、BSD-style licenseのもと配布されています。 14 | このドキュメントではソースコードを取得し、あなたのマシンでビルドし、実行する方法を説明します。 15 |

16 | 17 |

18 | ほとんどのユーザーはこのようなことをする必要はありません。かわりに、インストールで説明されているすでにコンパイルされたバイナリパッケージをインストールほうがより簡単な作業でしょう。 19 | もしあなたがこのようなプリコンパイルパッケージの中身の開発を手伝いたいなら、さあどうぞ、続けてください。 20 |

21 | 22 |
23 | 24 |

25 | 二つの公式なGoコンパイラツールチェインがあります。 26 | このドキュメントでは、gc Goコンパイラおよびツール(6g、8gなど)について解説します。 27 | 従来のGCCバックエンドによるgccgoを使いたい場合は、Setting up and using gccgoを見てください。 28 |

29 | 30 |

31 | Goコンパイラは三つの命令セットをサポートしています。 32 | アーキテクチャによって、コンパイラの品質には差があります。 33 |

34 | 35 |
36 |
37 | amd64 (別名: x86-64); 6g,6l,6c,6a 38 |
39 |
40 | 成熟した実装です。コンパイラは効果的な最適化(レジスタ化)をおこない、良いコードを生成します(ただし、gccgoのほうがより良い場合もあります)。 41 |
42 |
43 | 386 (別名: x86もしくはx86-32); 8g,8l,8c,8a 44 |
45 |
46 | amd64ポーティングと同等です。 47 |
48 |
49 | arm (別名: ARM); 5g,5l,5c,5a 50 |
51 |
52 | LinuxとFreeBSD、NetBSDバイナリをサポートします。ほかのポーティングと比べ、あまり使用されていません。 53 |
54 |
55 | 56 |

57 | 低レベルのOSインターフェイスコードを除き、ランタイムはすべてのポーティングで同じで、mark-and-sweepガーベッジコレクタや効率的な配列と文字列のスライス、必要に応じて成長および縮小するスタックなど効率的なゴルーチンをサポートしています。 58 |

59 | 60 |

61 | コンパイラはDragonFly BSDやFreeBSD、Linux、NetBSD、OpenBSD、 62 | OS X (Darwin)、Plan 9、Solaris、Windowsをターゲットにすることができます。 63 | サポートされているすべての組み合わせは、下記の環境変数に書かれています。 64 |

65 | 66 |
67 | 68 |

C言語ツールをインストールする

69 | 70 |

71 | GoツールチェインはC言語で書かれています。ビルドするには、Cコンパイラがインストールされている必要があります。 72 | OS固有の手順については、GoコミュニティウィキページのInstallFromSourceを参照してください。 73 |

74 | 75 |

Mercurialをインストールする

76 | 77 |

78 | 次の手順を実行するためには、Mercurialがインストールされている必要があります。(hgコマンドがあるかどうかを確かめてください。) 79 |

80 | 81 |

82 | もしMercurialがインストールされていなければ、Mercurial downloadsのページにある手順を実行してください。 83 |

84 | 85 |

86 | Mercurialのバージョンが1.7.x以上であれば、Certification Authoritiesの設定が必要になります。エラーメッセージは次のようなものです: 87 |

88 | 89 | 
 90 | warning: code.google.com certificate with fingerprint b1:af: ... bc not verified (check hostfingerprints or web.cacerts config setting)
 91 |
92 | 93 |

94 | MercurialからCAがないことを指摘されている場合は、Mercurialのバージョンを確認(hg --version)し、 95 | 必要に応じてCAを設定してください。 96 |

97 | 98 | 99 |

リポジトリの取得

100 | 101 |

Goはgoというディレクトリにインストールされます。 102 | 親となるディレクトリに移動し、goというディレクトリがないことを確認してください。 103 | そして、リポジトリを取得してください:

104 | 105 | 
106 | $ hg clone -u release https://code.google.com/p/go
107 |
108 | 109 | 110 | 111 |

もしGoのソースコードを変更し、このプロジェクトへ貢献するなら、リポジトリに移動し、releaseブランチから開発用のdefaultブランチへ切り替えてください。 112 | そうでなければ、この手順は無視してください。 113 |

114 | 115 | 
116 | $ hg update default
117 |
118 | 119 |

Goをインストールする

120 | 121 |

122 | Goディストリビューションをビルドするには、次を実行してください。 123 |

124 | 125 | 
126 | $ cd go/src
127 | $ ./all.bash
128 |
129 | 130 |

131 | (Windowsでビルドするには、all.batを使用してください。) 132 |

133 | 134 |

135 | もしすべて上手くいったなら、次のような出力を表示して終了します: 136 |

137 | 138 | 
139 | ALL TESTS PASSED
140 | 
141 | ---
142 | Installed Go for linux/amd64 in /home/you/go.
143 | Installed commands in /home/you/go/bin.
144 | *** You need to add /home/you/go/bin to your $PATH. ***
145 |
146 | 147 |

148 | 最後の数行の詳細はOSやアーキテクチャ、インストールに使用したディレクトリによって異なります。 149 |

150 | 151 |
152 |

153 | ビルドを制御する詳細な方法については、環境変数の項目を参照してください。 154 | all.bash (もしくはall.bat)はGoの重要なテストを実行します。これは単にGoをビルドするより時間がかかります。 155 | テストスイートを実行したくない場合は、make.bash (もしくはmake.bat)を代わりに使ってください。 156 |

157 |
158 | 159 | 160 |

インストールをテストする

161 | 162 |

163 | Goが正しくインストールされたかどうかは、簡単なプログラムをビルドすることで確かめられます。 164 |

165 | 166 |

167 | hello.goというファイルを作り、次のプログラムを記述してください: 168 |

169 | 170 | 
171 | package main
172 | 
173 | import "fmt"
174 | 
175 | func main() {
176 |     fmt.Printf("hello, world\n")
177 | }
178 |
179 | 180 |

181 | そして、goツールで実行してください: 182 |

183 | 184 | 
185 | $ go run hello.go
186 | hello, world
187 |
188 | 189 |

190 | "hello, world"というメッセージが表示されていれば、Goは正常にインストールされています。 191 |

192 | 193 |

開発環境をセットアップする

194 | 195 |

196 | ほとんどは完了しましたが、もう少しセットアップが必要です。 197 |

198 | 199 |

200 | 201 | Goコードの書き方 202 | Goツールのセットアップ方法と使い方を学びましょう 203 | 204 |

205 | 206 |

207 | Goコードの書き方のドキュメントは、Goツールを使うための必須のセットアップ手順を紹介しています。 208 |

209 | 210 | 211 |

追加のツールをインストールする

212 | 213 |

214 | いくつかのGoツールのソースコード(godocを含む)はgo.toolsリポジトリにあります。 215 | これらをすべてインストールするには、go getコマンドを実行してください: 216 |

217 | 218 | 
219 | $ go get code.google.com/p/go.tools/cmd/...
220 |
221 | 222 |

223 | もしくは、特定のコマンド(この場合はgodoc)だけインストールしたい場合: 224 |

225 | 226 | 
227 | $ go get code.google.com/p/go.tools/cmd/godoc
228 |
229 | 230 |

231 | これらのツールをインストールするには、go getコマンドはMercurialがその環境でインストールされていることを必要とします。 232 |

233 | 234 |

235 | ワークスペース(GOPATH)をセットアップする必要もあります。 236 | 詳細は、Goコードの書き方をみてください。 237 |

238 | 239 |

240 | 注記: goコマンドはgodocバイナリを$GOROOT/bin (もしくは$GOBIN)に、 241 | coverとvetバイナリを 242 | $GOROOT/pkg/tool/$GOOS_$GOARCHにインストールします。 243 | 後半のコマンドは、 244 | "go tool cover"と、 245 | "go tool vet"で実行できます。 246 |

247 | 248 |

コミュニティの情報

249 | 250 |

251 | 一般的なコミュニティとして、 252 | #go-nutsがFreenode IRCサーバーにあり、 253 | Go Nutsメーリングリストは 254 | あなたのインストールや開発作業の問題を手助けしてくれます。 255 | 最新情報についていきたい場合には他のメーリングリストもあります。 256 | golang-checkinsではGoのリポジトリが更新されるたびに要約されたメッセージを受け取ることができます。 257 |

258 | 259 |

260 | バグは、Go issue trackerから報告することが出来ます。 261 |

262 | 263 | 264 |

リリースについていく

265 | 266 |

267 | Goプロジェクトは安定版のタグをMercurialリポジトリにつけています: release。 268 |

269 | 270 |

271 | releaseタグはGoの現在の安定リリースを指しています。 272 | ほとんどのGoのユーザはこのバージョンを使うべきです。新しいリリースは、 273 | golang-announce 274 | メーリングリストでアナウンスされます。 275 |

276 | 277 |

278 | 現在のソースツリーを最新リリースに更新するには、次を実行してください: 279 |

280 | 281 | 
282 | $ cd go/src
283 | $ hg pull
284 | $ hg update release
285 | $ ./all.bash
286 |
287 | 288 | 289 |

環境変数

290 | 291 |

292 | Goのコンパイル環境は環境変数でカスタマイズすることができます。 293 | ビルドに必須のものはありませんが、初期値を上書きすることもできます。 294 |

295 | 296 | 436 | 437 |

438 | $GOARCHと$GOOSは 439 | ターゲット環境を識別します、実行している環境ではありません。 440 | 実際、常にクロスコンパイルします。 441 | アーキテクチャによって、ターゲット環境が実行できるバイナリの種類を示します: 442 | x86-64システムで32ビットのOS動かしている場合は、GOARCHを386に設定する必要があります。 443 | amd64ではありません。 444 |

445 | 446 |

447 | もしこれらの初期値を上書きしたい場合には、シェルのプロファイル($HOME/.bashrcや 448 | $HOME/.profileなど)で設定してください。 449 | 例えば次のようになります: 450 |

451 | 452 | 
453 | export GOROOT=$HOME/go
454 | export GOARCH=amd64
455 | export GOOS=linux
456 |
457 | 458 |

459 | 繰り返しになりますが、ビルドやインストール、開発時にこれらの設定値が必要になることはありません。 460 |

461 | -------------------------------------------------------------------------------- /doc/install.html: -------------------------------------------------------------------------------- 1 | 5 | 6 | 9 | 10 |

Goディストリビューションのダウンロード

11 | 12 |

13 | 14 | Download Go 15 | クリックしてダウンロードページに移動します 16 | 17 |

18 | 19 |

20 | 21 | 公式バイナリディストリビューションは32ビット（386）、64ビット（amd64）x86プロセッサアーキテクチャのFreeBSD（release 8以降）、Linux、Mac OS X（Snow Leopard以降）、Windowsオペレーティングシステムに対応しています。 22 |

23 | 24 |

25 | バイナリディストリビューションがお使いのオペレーティングシステム、アーキテクチャの組み合わせに対応していない場合は、ソースからのインストールやgcの代わりにgccgoをインストールをお試しください。 26 |

27 | 28 | 29 |

システム要件

30 | 31 |

32 | gcコンパイラは下記のオペレーティングシステム、アーキテクチャをサポートします。始める前に、これらの要件がお使いのシステムに合致していることをお確かめください。お使いのOSやアーキテクチャがリストにない場合は、gccgoを利用できることがあります。詳細はセットアップとgccgoの利用をご覧ください。 33 |

34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 |
オペレーティングシステムアーキテクチャ備考
FreeBSD 8以降 amd64, 386, arm Debian GNU/kFreeBSDはサポートなし　FreeBSD/ARMはFreeBSD 10以降
Linux 2.6.23以降（glibcが必要) amd64, 386, arm CentOS/RHEL 5.xはサポートなし　ARMのバイナリディストリビューションは現在なし
Mac OS X 10.6以降 amd64, 386 Xcode‡同梱のgcc†を利用
Windows XP以降 amd64, 386 MinGW gcc†を利用　cygwin、msysは不要
47 | 48 |

49 | †gccはcgoを利用したい場合のみ必要です。
50 | ‡必要となるのはXcodeのコマンドラインツールのインストールのみです。すでにXcode 4.3以降をインストール済みの場合は、ダウンロード環境設定パネルのコンポーネントタブからインストールできます。 51 |

52 | 53 | 54 |

Goツールのインストール

55 | 56 |

57 | 古いバージョンのGoからアップグレードする場合は、まず既存バージョンを削除する必要があります。 58 |

59 | 60 |

Linux、Mac OS X、FreeBSD tarball

61 | 62 |

63 | アーカイブをダウンロードし、/usr/localに解凍してGoツリーを/usr/local/goに作成してください。例えば、以下のとおりです。 64 |

65 | 66 | 
 67 | tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz
 68 |
69 | 70 |

71 | インストールに適切なアーカイブファイルを選択してください。例えば、64ビットx86のLinuxにGoバージョン1.2.1をインストールする場合は、go1.2.1.linux-amd64.tar.gzというアーカイブをダウンロードしてください。 72 |

73 | 74 |

75 | （一般的に、これらのコマンドはrootととして、またはsudoを通じて実行する必要があります。） 76 |

77 | 78 |

79 | /usr/local/go/binをPATH環境変数に追加してください。/etc/profile（システム全体へ反映）または$HOME/.profileに以下の行を追加することで設定が完了します。 80 |

81 | 82 | 
 83 | export PATH=$PATH:/usr/local/go/bin
 84 |
85 | 86 |

カスタムの場所へのインストール

87 | 88 |

89 | Goバイナリディストリビューションは/usr/local/go（Windowsの場合はc:\Go）にインストールすることを想定していますが、Goツールを他の場所にインストールすることも可能です。その場合は、インストールするディレクトリを示すGOROOT環境変数を設定する必要があります。 90 |

91 | 92 |

93 | 例えば、Goをホームディレクトリにインストールする場合は、以下のコマンドを$HOME/.profileに追加します。 94 |

95 | 96 | 
 97 | export GOROOT=$HOME/go
 98 | export PATH=$PATH:$GOROOT/bin
 99 |
100 | 101 |

102 | 備考：GOROOTはカスタムの場所にインストールする場合のみ設定します。 103 |

104 | 105 |

Mac OS Xパッケージインストーラ

106 | 107 |

108 | パッケージファイルをダウンロードし、ファイルを開いてプロンプトにしたがってGoツールをインストールします。パッケージは/usr/local/goにGoディストリビューションをインストールします。 109 |

110 | 111 |

112 | パッケージはPATH環境変数に/usr/local/go/binを自動的に追加します。開いているターミナルのセッションがある場合には、再起動して変更を有効にします。 113 |

114 | 115 |

Windows

116 | 117 |

118 | GoプロジェクトはWindowsユーザのために（ソースからのインストールの他に）2種類のインストール方法を提供しています。環境変数を手動で設定する必要があるzipアーカイブと、自動でインストールの環境設定を行うMSIインストーラです。 119 |

120 | 121 |

MSIインストーラ

122 | 123 |

124 | MSIファイルを開き、プロンプトにしたがってGoツールをインストールしてください。デフォルトでは、c:\GoにGoディストリビューションをインストールします。 125 |

126 | 127 |

128 | インストーラはPATH環境変数にc:\Go\binを自動的に追加します。開いているコマンドプロンプトがある場合には、再起動して変更を有効にします。 129 |

130 | 131 |

zipアーカイブ

132 | 133 |

134 | zipファイルをダウンロードし、任意のディレクトリに解凍します。（c:\Goをお薦めします。） 135 |

136 | 137 |

138 | c:\Go以外のディレクトリに解凍する場合は、そのパスにGOROOT環境変数を設定する必要があります。 139 |

140 | 141 |

142 | Goのルート（例えばc:\Go\bin）のbinサブディレクトリをPATH環境変数に追加してください。 143 |

144 | 145 |

Windowsの環境変数の設定

146 | 147 |

148 | Windowsの場合、「システム」コントロールパネルの「詳細」タブの「環境変数」ボタンから環境変数の設定をすることができます。Windosのバージョンによっては、このコントロールパネルは「システム」コントロールパネルの「システムの詳細設定」となっている場合があります。 149 |

150 | 151 | 152 |

インストールのテスト

153 | 154 |

155 | 以下のように、簡単なプログラムを構築することで、Goが正しくインストールされていることをチェックします。 156 |

157 | 158 |

159 | hello.goという名前のファイルを作成し、下記のプログラムを書き込みます。 160 |

161 | 162 | 
163 | package main
164 | 
165 | import "fmt"
166 | 
167 | func main() {
168 |     fmt.Printf("hello, world\n")
169 | }
170 |
171 | 172 |

173 | 次に、goツールで実行します。 174 |

175 | 176 | 
177 | $ go run hello.go
178 | hello, world
179 |
180 | 181 |

182 | 「hello, world」メッセージが表示されれば、正しくGoがインストールされていることになります。 183 |

184 | 185 | 186 |

作業環境のセットアップ

187 | 188 |

189 | これでほとんど完了ですが、あともう少しだけセットアップが必要です。 190 |

191 | 192 |

193 | 194 | Goコードの書き方 195 | Goツールのセットアップ・利用方法を学びます 196 | 197 |

198 | 199 |

200 | Goコードの書き方ドキュメントにGoツールを利用する際の基本的なセットアップの説明を記載しています。 201 |

202 | 203 | 204 |

Goのアンインストール

205 | 206 |

207 | システムから既存のGoインストールを削除する場合には、goディレクトリを削除してください。通常は、Linux、Mac OS X、FreeBSDの場合は/usr/local/go、Windowsの場合はc:\Goです。 208 |

209 | 210 |

211 | また、PATH環境変数からGoのbinディレクトリを削除する必要があります。Linux、FreeBSDの場合は/etc/profileまたは$HOME/.profileを編集してください。Mac OS XパッケージでGoをインストールした場合は/etc/paths.d/goのファイルを削除してください。Windowsユーザの方はWindowsの環境変数の設定のセクションをお読みください。 212 |

213 | 214 | 215 |

ヘルプを得る

216 | 217 |

218 | リアルタイムヘルプについては、Freenode IRCサーバの#go-nutsで協力的なGopher達に質問してください。 219 |

220 | 221 |

222 | Go言語のディスカッションのためのオフィシャルメーリングリストはGo Nutsです。 223 |

224 | 225 |

226 | バグのレポートにはGo issue trackerを利用してください。 227 |

228 | 229 | 230 | -------------------------------------------------------------------------------- /doc/root.html: -------------------------------------------------------------------------------- 1 | 4 | 5 | 8 | 9 |
10 | 11 |
12 | 13 |
Try Go
14 |
15 | 24 |
25 |
26 | 
 27 | Hello, 世界
 28 |
29 |
30 |
31 | Run 32 | 33 | Tour 34 |
35 |
36 | 46 |
47 |
48 | 49 |
50 | 51 |
52 | 53 |
54 | Goはシンプルで、信頼でき、効率的なソフトウェアを構築しやすくするオープンソースのプログラミング言語です。 55 |
56 | 57 |
58 | 59 | 60 | Download Go 61 | 62 | Linux, Mac OS X, Windowsなどで
63 | 利用できます 64 | 65 | 66 | 67 |

68 | 本サイトは golang.org の日本語訳です。利用に当たっては 利用規約を御覧ください。 69 |

70 | 71 |
72 | 73 |
74 | 75 |
76 | 77 |
78 |
Featured video
79 | 80 |
81 | 82 |
83 | 84 |
85 | 86 |
87 |
Featured articles
88 |
Read more
89 |
90 | 91 |
92 | 93 |
94 | 95 | 157 | -------------------------------------------------------------------------------- /doc/tos.html: -------------------------------------------------------------------------------- 1 | 4 | 5 | 8 | 9 |

10 | 本サイトは golang.org の日本語訳です。日本語訳の記述内容により生じたいかなる損害についても 著作権所有者および翻訳者は責任を負いません。 11 | また、本サイトの運用にあたっては、予告なくサイトの運用を停止することがあります。 12 |

13 | 14 |

15 | 全体の活動については The Project を御覧ください。 16 |

17 | -------------------------------------------------------------------------------- /misc/goplay/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2010 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | // goplayはGo言語のコードで実験をするためのWebインタフェースです。 6 | // Go Playgroundと同様のものです：http://golang.org/doc/play/ 7 | // 8 | // goplayの利用方法： 9 | // $ cd $GOROOT/misc/goplay 10 | // $ go run goplay.go 11 | // 続いて、Webブラウザで http://localhost:3999/ をロードします。 12 | // 13 | // Hello Worldプログラムが表示されるはずです。shift-enterキーにより 14 | // コンパイル・実行ができます。チェックボックスをチェックして 15 | // 有効にできる"compile-on-keypress"機能もあります。 16 | // 17 | // 警告！ WARNING! CUIDADO! ACHTUNG! ATTENZIONE! 18 | // セキュリティに関する注意：goplayのWebインタフェースにアクセスすると 19 | // 誰でもあなたのコンピュータ上で任意のコードを実行することができます。 20 | // goplayはサンドボックスではなく、その他のセキュリティの仕組みもありません。 21 | // goplayを信頼の置けない環境にデプロイしないでください。 22 | // デフォルトでは、goplayはlocalhost上のみでリッスンしますが、 23 | // -httpパラメータによりオーバーライドできます。ただし自己責任で行ってください。 24 | // 25 | // 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/misc/goplay/doc.go?r=3633a89bb56d9276a9fe55435b849f931bfa6393 26 | package main 27 | 28 | -------------------------------------------------------------------------------- /refresh.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | ## Refresh golangjp/go documents on godoc.org 4 | 5 | ## Usage: ./refresh.sh 6 | 7 | ## args: path 8 | refresh_godoc_org() { 9 | local path=$1 10 | 11 | echo "refresh $path" 12 | curl -d "path=$path" http://godoc.org/-/refresh 13 | } 14 | 15 | ## 10分以内に更新されたものだけを更新する 16 | updateList=`git log --name-only --pretty=format:"" --since="10 minutes ago"|grep /|sort|uniq` 17 | 18 | for fname in $updateList 19 | do 20 | target=`dirname $fname` 21 | refresh_godoc_org "github.com/gophersjp/go/$target" 22 | done 23 | 24 | ## トップページを更新する 25 | refresh_godoc_org github.com/gophersjp/go 26 | 27 | 28 | ## おしまい。 29 | 30 | -------------------------------------------------------------------------------- /src/cmd/5a/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2009 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | /* 6 | 7 | 5aはPlan 9用のアセンブラです。元のドキュメントについては以下を参照してください。 8 | 9 | http://plan9.bell-labs.com/magic/man2html/1/8a 10 | 11 | ARMアーキテクチャをターゲットとしており、これらのツールにはarmとして参照されます。 12 | 13 | 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/src/cmd/5a/doc.go?r=3633a89bb56d 14 | */ 15 | package main 16 | -------------------------------------------------------------------------------- /src/cmd/5c/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2009 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | /* 6 | 7 | 5cはPlan 9用のCコンパイラです。元のドキュメントについては以下を参照してください。 8 | 9 | http://plan9.bell-labs.com/magic/man2html/1/8c 10 | 11 | ARMアーキテクチャをターゲットとしており、これらのツールにはarmとして参照されます。 12 | 13 | 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/src/cmd/5c/doc.go?r=3633a89bb56d 14 | */ 15 | package main 16 | -------------------------------------------------------------------------------- /src/cmd/5g/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2009 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | /* 6 | 7 | 5gはARM用のgcコンパイラです。 8 | このツールの$GOARCHはarmです。 9 | 10 | これは.goファイルを読み込み、.5ファイルを出力します。このコマンドのフラグについては ../gc/doc.go を参照してください。 11 | 12 | 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/src/cmd/5g/doc.go?r=3633a89bb56d 13 | */ 14 | package main 15 | -------------------------------------------------------------------------------- /src/cmd/5l/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2009 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | /* 6 | 7 | 5lはARM用のリンカです。 8 | このツールの$GOARCHはarmです。 9 | 10 | このコマンドのフラグについては ../ld/doc.go を参照してください。 11 | 12 | 本ドキュメントは以下のドキュメントを翻訳しています:https://code.google.com/p/go/source/browse/src/cmd/5l/doc.go?r=3633a89bb56d 13 | */ 14 | package main 15 | -------------------------------------------------------------------------------- /src/cmd/6a/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2009 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | /* 6 | 7 | 6aはPlan 9用のアセンブラです。元のドキュメントについては以下を参照してください。 8 | 9 | http://plan9.bell-labs.com/magic/man2html/1/8a 10 | 11 | x86-64アーキテクチャをターゲットとしており、これらのツールにはamd64として参照されます。 12 | 13 | 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/src/cmd/6a/doc.go?r=3633a89bb56d 14 | */ 15 | package main 16 | -------------------------------------------------------------------------------- /src/cmd/6c/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2009 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | /* 6 | 7 | 6cはPlan 9用のCコンパイラです。元のドキュメントについては以下を参照してください。 8 | 9 | http://plan9.bell-labs.com/magic/man2html/1/8c 10 | 11 | x86-64アーキテクチャをターゲットとしており、これらのツールにはamd64として参照されます。 12 | 13 | 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/src/cmd/6c/doc.go?r=3633a89bb56d 14 | */ 15 | package main 16 | -------------------------------------------------------------------------------- /src/cmd/6g/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2009 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | /* 6 | 7 | 6gはx86-64用のgcコンパイラです。 8 | このツールの$GOARCHはamd64です。 9 | 10 | これは.goファイルを読み込み、.6ファイルを出力します。このコマンドのフラグについては ../gc/doc.go を参照してください。 11 | 12 | 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/src/cmd/6g/doc.go?r=3633a89bb56d 13 | */ 14 | package main 15 | -------------------------------------------------------------------------------- /src/cmd/6l/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2009 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | /* 6 | 7 | 6lはx86-64用のリンカです。 8 | このツールの$GOARCHはamd64です。 9 | 10 | このコマンドのフラグについては ../ld/doc.go を参照してください。 11 | 12 | 本ドキュメントは以下のドキュメントを翻訳しています:https://code.google.com/p/go/source/browse/src/cmd/6l/doc.go?r=3633a89bb56d 13 | */ 14 | package main 15 | -------------------------------------------------------------------------------- /src/cmd/8a/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2009 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | /* 6 | 7 | 8aはPlan 9用のアセンブラです。元のドキュメントについては以下を参照してください。 8 | 9 | http://plan9.bell-labs.com/magic/man2html/1/8a 10 | 11 | x86アーキテクチャをターゲットとしており、これらのツールには歴史的な理由から386として参照されます。 12 | 13 | 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/src/cmd/8a/doc.go?r=3633a89bb56d 14 | */ 15 | package main 16 | -------------------------------------------------------------------------------- /src/cmd/8c/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2009 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | /* 6 | 7 | 8cはPlan 9用のCコンパイラです。元のドキュメントについては以下を参照してください。 8 | 9 | http://plan9.bell-labs.com/magic/man2html/1/8c 10 | 11 | x86アーキテクチャをターゲットとしており、これらのツールには歴史的な理由から386として参照されます。 12 | 13 | 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/src/cmd/8c/doc.go?r=3633a89bb56d 14 | */ 15 | package main 16 | -------------------------------------------------------------------------------- /src/cmd/8g/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2009 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | /* 6 | 7 | 8gはx86用のgcコンパイラです。 8 | このツールの$GOARCHは386です。 9 | 10 | これは.goファイルを読み込み、.8ファイルを出力します。このコマンドのフラグについては ../gc/doc.go を参照してください。 11 | 12 | 13 | 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/src/cmd/8g/doc.go?r=3633a89bb56d9276a9fe55435b849f931bfa6393 14 | */ 15 | package main 16 | -------------------------------------------------------------------------------- /src/cmd/8l/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2009 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | /* 6 | 7 | 8lは32bit x86用のリンカです。 8 | このツールの$GOARCHは386です。 9 | 10 | このコマンドのフラグについては ../ld/doc.go を参照してください。 11 | 12 | 本ドキュメントは以下のドキュメントを翻訳しています:https://code.google.com/p/go/source/browse/src/cmd/8l/doc.go?r=3633a89bb56d 13 | */ 14 | package main 15 | -------------------------------------------------------------------------------- /src/cmd/fix/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2011 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | /* 6 | fixはGoのプログラムに古いAPIが使われていないかを探し、新しいAPIに書き換えます。 7 | Goのリリースによって、あなたのプログラムに修正の必要が生じたときにfixは役立ちます。 8 | 9 | Usage: 10 | go tool fix [-r name,...] [path ...] 11 | 12 | 明確なパスの入力がなくても、fixは標準入力を読み込み、標準出力に結果を書き出します。 13 | 14 | パスにファイルを指定した場合、fixはそのファイルを書き換えます。 15 | パスにディレクトリを指定した場合、fixはそのディレクトリ・ツリー以下の全ての.goファイルを書き換えます。fixがファイルを書き換える際、標準エラー出力にそのファイル名と修正箇所が出力されます。 16 | 17 | -diffフラグを指定すると、ファイルは書き換えられません。代わりに、fixは上書きされる箇所の差分を表示します。 18 | 19 | -rフラグは指定されたリストの書き換えを禁止します。デフォルト設定では、fixは書き換えが必要な全てについて考慮します。 20 | fixの書き換えは冪等(べきとう)です。そのため-rフラグを使用しなかったとしても、全部もしくは一部の更新されたコードへのfix適用の安全性は保証されます。 21 | 22 | fixはヘルプ出力に適用できる修正の全リストを表示します。 23 | それらを見るには、`go tool fix -?`を実行してください。 24 | 25 | fixは編集するファイルのバックアップを作成しません。 26 | コミットする前にfixによる変更を確認するには、バージョン管理システムの``diff''機能を使ってください。 27 | 28 | 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/src/cmd/fix/doc.go?r=3633a89bb56d 29 | */ 30 | package main 31 | -------------------------------------------------------------------------------- /src/cmd/gc/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2009 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | /* 6 | 7 | gcは、Plan 9(修正済のもの)ツールチェーン(tool chain)の一部として機能するGoコンパイラファミリのための一般的な名称です。 8 | Cコンパイラドキュメントはこちらを参照してください: 9 | 10 | http://plan9.bell-labs.com/sys/doc/comp.pdf (ツールの概要) 11 | http://plan9.bell-labs.com/sys/doc/compiler.pdf (Cコンパイラアーキテクチャ) 12 | 13 | 上記ドキュメントにはツールチェーンの全体の設計が書かれています。 14 | オプティマイザのようないくつかの適用部分を置いておけば、Goコンパイラはまったく新しいプログラムです。 15 | 16 | このコンパイラは、".go"の拡張子のGoファイル群を読み込みます。 17 | これらはすべて、ひとつのパッケージの一部でなければなりません。 18 | 出力は、リンカ(6lなど)へ入力する前段階、コンパイル済みパッケージの"binary assembly"を表す単一の中間ファイルです。 19 | 20 | 生成されたファイルには、パッケージ内でエクスポートしたシンボルについての型情報や、他のパッケージからパッケージ内でインポートしたシンボルで使う型に関する情報が含まれています。 21 | それゆえ、パッケージPの依存のファイルを読み込むために、PのクライアントCをコンパイルしているときには必要ありません。Pのコンパイル済みの出力だけです。 22 | It is therefore not necessary when compiling client C of package P to read the files of P's dependencies, only the compiled output of P. 23 | TODO: 意味確認。 24 | 25 | Command Line 26 | 27 | Usage: 28 | go tool 6g [flags] file... 29 | 指定するファイルはGoのソースコードファイルであり、かつ、すべて同じパッケージの一部である必要があります。 30 | 環境に合わせて適切に6gを8gや5gに変えてください。 31 | 32 | Flags: 33 | -o file 34 | 出力ファイルを指定します。デフォルトでは6gならfile.6です 35 | -e 36 | 全てのエラーを表示します。デフォルトでは10個のエラーを出力するとコンパイラを終了します 37 | -p path 38 | 指定したパスがソースコードの最後のインポートパスだとみなし、 39 | それに依存するパッケージをインポートしようと試みます。 TODO: 意味不明 40 | assume that path is the eventual import path for this code, 41 | and diagnose any attempt to import a package that depends on it. 42 | -D path 43 | パスへの相対として、相対インポートを扱います TODO: 要確認 44 | treat a relative import as relative to path 45 | -L 46 | エラーでファイル名を表示する際に、ファイルパス全体を表示します 47 | -I dir1 -I dir2 48 | dir1とdir2をインポートしたパッケージをチェックするためにパスのリストへ追加します TODO: 要確認 49 | add dir1 and dir2 to the list of paths to check for imported packages 50 | -N 51 | 最適化を無効にします 52 | -S 53 | アセンブリ言語のテキストを標準出力します（コードのみ） 54 | -S -S 55 | アセンブリ言語のテキストを標準出力します（コードとデータ） 56 | -u 57 | safeとされていないパッケージのインポートを拒否します TODO: 要確認 58 | -V 59 | コンパイラのバージョン情報を表示します 60 | -race 61 | レースコンディションの検出器を有効にしてコンパイルします 62 | 63 | 他にも、デバッグ用のフラグがいくつかあります。 64 | このコマンドを引数なしで走らせ、全てのUsageを見てください。 65 | 66 | Compiler Directives 67 | 68 | コンパイラは、行の最初に // のコメントの形式で２つのコンパイラディレクティブを受け入れます。 69 | ディレクティブは、ディレクティブではないコメントと区別するために、スラッシュとディレクティブの名前との間にスペースを必要としません。 70 | コメントですので、ディレクティブを認識しないツールは、 71 | 他のコメントのようにディレクティブをスキップすることができます。 72 | 73 | //line path/to/file:linenumber 74 | 75 | //lineディレクティブは、ソースコードの行を 76 | 指定したファイルパスと行番号から来たものとして記録します。 77 | 連続している行は、指定した行番号を次のディレクティブまでインクリメントして記録します。 78 | コンパイラやデバッガが生成器へ元々の入力で行を表示するので、このディレクティブは、一般的にマシンで生成されたコード中で登場します。 79 | 80 | //go:noescape 81 | 82 | //go:noescapeディレクティブは、 83 | bodyを持たない関数（Goで書かれていない実装があるということ） 84 | でなければならないファイルの次の宣言が 85 | ヒープ、または、関数からの戻り値にエスケープ(escape)する引数として渡るポインタを 86 | なにひとつ許可しないということを記録します。 87 | この情報は、関数を呼び出すGoコードのコンパイラのエスケープ解析中に利用できます。 88 | 89 | 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/src/cmd/gc/doc.go?r=3633a89bb56d9276a9fe55435b849f931bfa6393 90 | */ 91 | package main 92 | -------------------------------------------------------------------------------- /src/cmd/gofmt/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2009 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | /* 6 | gofmtはGoのソースコードをフォーマット（整形）するツールです。 7 | 8 | パスを与えない場合、標準入力の内容を処理します。 9 | ディレクトリを指定した場合は、すべての .go ファイルを再帰的に処理します 10 | （ただし、"."ドットではじまるファイルは無視します）。 11 | 通常、gofmtは標準出力へフォーマットしたコードを表示します。 12 | 13 | Usage: 14 | gofmt [flags] [path ...] 15 | 16 | The flags are: 17 | -d 18 | フォーマットした内容を標準出力へ出力しません。 19 | もしファイルのフォーマットがgofmtに通したものと異なる場合は、 20 | diffを標準出力します。 21 | -e 22 | すべてのエラーを表示します。 23 | -l 24 | フォーマットした内容を標準出力へ出力しません。 25 | もしファイルのフォーマットがgofmtに通したものと異なる場合は、 26 | そのファイル名を標準出力します。 27 | -r rule 28 | 再フォーマット前のソースコードへ置き換えルールを指定します。 29 | (Exampleを参照) 30 | -s 31 | もし該当するコードがあれば、置き換えルールを適用した後にコードの簡素化を試みます。 32 | (The simplify commandを参照) 33 | -w 34 | フォーマットした内容を標準出力へ出力しません。 35 | もしファイルのフォーマットがgofmtに通したものと異なる場合は、 36 | gofmtのもので上書き保存します。 37 | 38 | Formatting control flags: 39 | -comments=true 40 | コメント内容を含めます。falseを指定すると、すべてのコメントが省略されます。 41 | -tabs=true 42 | タブでインデントします。falseを指定すると、スペースが使われます。 43 | -tabwidth=8 44 | スペースでのタブ幅を指定します。 45 | 46 | 47 | 置き換えルールは -r フラグ以下の形式の文字列を次のように指定する必要があります: 48 | 49 | pattern -> replacement 50 | 51 | patternとreplacementの両方は、Goの文法に従っている必要があります。 52 | patternで、小文字の1字はsub-expressionsのワイルドカードとして活用できますので、 53 | replacementで同じ文字へと置換できます。 54 | 55 | gofmtが標準入力から読む場合、Goプログラムの全体か、プログラムの断片のどちらかで受け付けます。 56 | プログラムの断片では、構文的に有効な宣言リスト、ステートメントリスト、式である必要があります。 57 | そのような断片をフォーマットする場合、gofmtは先頭のインデントと末尾のスペースを保持します。 58 | ですので、Goプログラムの個々ののセクションでgofmtを通してフォーマットすることができます。 59 | 60 | Examples 61 | 62 | 余計な括弧のペアが付いているファイルを確認する: 63 | 64 | gofmt -r '(a) -> a' -l *.go 65 | 66 | 余計な括弧のペアを削除する: 67 | 68 | gofmt -r '(a) -> a' -w *.go 69 | 70 | 明示的なスライスサイズの指定から暗黙的なものへパッケージツリー全体を変換する: 71 | 72 | gofmt -r 'α[β:len(α)] -> α[β:]' -w $GOROOT/src/pkg 73 | 74 | The simplify command 75 | 76 | gofmt -sで起動すると、以下のソースコードの変換が可能な場合があります。 77 | 78 | 配列、スライスやマップの複合したもの: 79 | []T{T{}, T{}} 80 | を簡素化すると: 81 | []T{{}, {}} 82 | 83 | スライス: 84 | s[a:len(s)] 85 | を簡素化すると: 86 | s[a:] 87 | 88 | range: 89 | for x, _ = range v {...} 90 | を簡素化すると: 91 | for x = range v {...} 92 | 93 | 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/src/cmd/gofmt/doc.go?r=6152955fc7819180f4fac15eee678407df87da0a 94 | */ 95 | package main 96 | 97 | // BUG(rsc): The implementation of -r is a bit slow. 98 | -------------------------------------------------------------------------------- /src/cmd/pack/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2009 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | /* 6 | 7 | packはPlan 9のar toolの変形です。オリジナルのドキュメントは以下にあります。 8 | 9 | http://plan9.bell-labs.com/magic/man2html/1/ar 10 | 11 | packはアーカイブのファイルからすべてのGoの型情報を収集する__.PKGDEFという 12 | Go言語特有の特別な領域を追加します。その領域はコンパイル時の 13 | パッケージインポートの際、コンパイラが利用します。 14 | 15 | Usage: 16 | go tool pack [uvnbailogS][mrxtdpq][P prefix] archive files ... 17 | 18 | 新たな'g'オプションは、ファイルがアーカイブに追加される際、packに__.PKGDEF領域 19 | を保持させます。 20 | 21 | 新たな'S'オプションは、packに強制的にアーカイブが安全であると指定させます。 22 | 23 | 新たな'P'オプションは、既にアーカイブに格納・追加されているオブジェクトファイルの 24 | 行番号情報にあるファイル名から、プレフィックスをpackに除去させます。 25 | 26 | 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/src/cmd/pack/doc.go?r=3633a89bb56d9276a9fe55435b849f931bfa6393 27 | */ 28 | package main 29 | -------------------------------------------------------------------------------- /src/cmd/prof/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2009 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | 6 | /* 7 | 8 | Profは基本的な機能を備えたリアルタイムプロファイラです。 9 | 10 | 実行コマンド、または既に実行されているコマンドのプロセスID(PID)を与えることで、 11 | プログラムの状態を一定間隔で、振る舞いのレポートをサンプリングします。 12 | オプションを付けずに実行した場合、実行中にサンプリングされたコードの 13 | 位置のヒストグラムが表示されます。 14 | 15 | Profはリアルタイムなプロファイラであるため、従来のプロファイラとは異なり、 16 | たとえスリープ状態やI/Oの待機中といった実行中ではないときでもプログラムの状態をサンプリングします。 17 | 各スレッドは平等に統計処理を行ないます。 18 | 19 | Usage: 20 | go tool prof -p pid [-t total_secs] [-d delta_msec] [6.out args ...] 21 | 22 | The output modes (default -h) are: 23 | 24 | -P file.prof: 25 | プロファイルに関する設定をpprofのフォーマットでfile.profに書き込みます。 26 | 現在のところ、このオプションはLinux amd64バイナリ上のみで動作し、 27 | またELFデバッグ情報を生成するにはバイナリが6l -eを使用して書き出されている必要があります。 28 | 詳細はhttp://code.google.com/p/google-perftoolsを参照してください。 29 | -h: histograms 30 | それぞれのロケーションでサンプルを何回発生させるかを指定します。 31 | -f: dynamic functions 32 | それぞれのサンプル時に、実行中の関数の名前を表示させます。 33 | -l: dynamic file and line numbers 34 | それぞれのサンプル時に、実行した命令の行数やファイル名を表示させます。 35 | -r: dynamic registers 36 | それぞれのサンプル時に変数の値を表示させます。 37 | -s: dynamic function stack traces 38 | それぞれのサンプル時に、シンボリックスタックトレースを表示します。 39 | 40 | -t フラグはサンプリングを行う最大実時間を秒数で設定し、 41 | -d フラグはサンプリング間隔をミリ秒で設定します。 42 | デフォルトではプログラムが完了するまで100ms周期でサンプリングされます。 43 | 44 | profはgo tool profコマンドでインストールされます。また、アーキテクチャ依存です。 45 | 46 | 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/src/cmd/prof/doc.go?r=3633a89bb56d9276a9fe55435b849f931bfa6393 47 | */ 48 | package main 49 | -------------------------------------------------------------------------------- /src/code.google.com/p/go.tools/cmd/godoc/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2009 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | /* 6 | 7 | godocはGoのソースコードからドキュメントを生成します。 8 | 9 | 2つのモデルがあります。 10 | 11 | -httpフラグをつけずに起動すると、コマンドラインモードで実行し、標準出力へテキストの 12 | ドキュメントを表示、終了します。 13 | もしライブラリパッケージとコマンドで同じ名前になっている場合は、ライブラリパッケージ 14 | よりも cmd/ ではじまるコマンドドキュメントを優先します。 15 | -srcフラグが指定されると、godocはGoのソースコード形式でパッケージのエクスポートされた 16 | インターフェースや、個別のエクスポートされたものの実装を表示します: 17 | 18 | godoc fmt # fmtパッケージをドキュメンテーションします 19 | godoc fmt Printf # fmt.Printfをドキュメンテーションします 20 | godoc cmd/go # goコマンドをforce強制的にドキュメンテーションします 21 | godoc -src fmt # Goのソースコード形式で、fmtパッケージを表示します 22 | godoc -src fmt Printf # fmt.Printfの実装を表示します 23 | 24 | -qフラグに検索クエリを指定することで、 25 | ウェブサーバに対して検索結果を問い合わせることができます（コマンドラインモード時）。 26 | サーバアドレスを-serverフラグで指定しなかった場合、godocは最初に localhost:6060 27 | に接続を試み、次に http://golang.org へ接続します。 28 | 29 | godoc -q Reader 30 | godoc -q math.Sin 31 | godoc -server=:6060 -q sin 32 | 33 | -httpフラグをつけて起動すると、ウェブサーバ(localhost:6060)が起動し、ウェブページでドキュメントを読むことができます。 34 | （-httpフラグにはポート番号を以下のように指定します） 35 | 36 | godoc -http=:6060 37 | 38 | Usage: 39 | godoc [flag] package [name ...] 40 | 41 | The flags are: 42 | -v 43 | verbose mode 44 | -q 45 | 引数に検索クエリを指定します。 46 | 有効なクエリの例は、単なる名称（ToLowerといったもの） 47 | や、限定した名称（math.Sinといったもの）です。 48 | -src 49 | ソースコード（エクスポートされたもの）をコマンドラインモードで表示します。 50 | -tabwidth=4 51 | タブ幅をスペースの数で指定します。 52 | -timestamps=true 53 | パッケージディレクトリを表示する際にタイムスタンプを表示します(-http時)。 54 | -index 55 | 全文検索を有効にします 56 | -index_files="" 57 | インデックスファイル名のパターンを指定します。 58 | 設定した場合、インデックスは整列順でファイルを読み込みます。 59 | -index_throttle=0.75 60 | インデックススロットルの値を指定します。 61 | 値を0にすることは、インデクサーへの割り当て時間がない 62 | （インデクサは完了しない）という意味になります。 63 | 値を1.0にすることは、インデックスの生成をフルスロットルで実行する 64 | （他のgoroutineはインデックスのビルドが完了するまでの間は動かない）という意味になります。 65 | -links=true: 66 | 宣言されている箇所へのリンクを生成します。 67 | -write_index=false 68 | インデックスファイルを書き出します。 69 | ファイル名は -index_files で一緒に指定する必要があります。 70 | -maxresults=10000 71 | maximum number of full text search results shown 72 | (no full text index is built if maxresults <= 0) 73 | -notes="BUG" 74 | regular expression matching note markers to show 75 | (e.g., "BUG|TODO", ".*") 76 | -html 77 | コマンドラインモードでHTMLを表示します。 78 | -goroot=$GOROOT 79 | Goのルートディレクトリを指定します。 80 | -http=addr 81 | HTTPサービスのアドレスを指定します (例: '127.0.0.1:6060' または ':6060') 82 | -server=addr 83 | コマンドラインサーチでのサーバアクセス先を指定します。 84 | -templates="" 85 | 代替のテンプレートファイルを含むディレクトリを指定します。 86 | 指定する場合、指定するディレクトリに static/ のファイルの代わりの 87 | テンプレートファイルを用意します。 88 | -url=path 89 | print to standard output the data that would be served by 90 | an HTTP request for path 91 | -zip="" 92 | zipファイルでコンテンツを提供します。未指定で無効です。 93 | 94 | godocは、環境変数 $GOROOT と $GOPATH （設定してあれば）を見てパッケージを検索します。 95 | この動作は、 -gorootフラグで $GOROOT を変えることで変更することができます。 96 | 97 | godocをウェブサーバとして実行する際に -index がセットされると、サーチインデックスを保有します。 98 | インデックスは起動時に生成されます。 99 | 100 | インデックスは、名称とフルテキストのサーチの情報（正規表現で検索できます）を含んでいます。 101 | フルテキストサーチの結果を表示する限度は -maxresultsフラグで指定できます。 102 | もし 0 を指定するとフルテキストサーチの結果は表示されません。 103 | インデックスは名称のみとなり、フルテキストサーチのインデックスは生成されません。 104 | 105 | godocが提供するウェブページのプレゼンテーションモードは、 URLパラメータに"m"でコントロールできます。 106 | これは、コンマ区切りのリストを受け付けます。 107 | 108 | all エクスポートされたものだけではなく、宣言されたすべてのドキュメントを表示します 109 | methods エクスポートしていない匿名フィールドだけでなく、すべての組み込みメソッドを表示します TODO:動作確認 110 | show all embedded methods, not just those of unexported anonymous fields 111 | src ドキュメントではなく、その元のソースコードを表示します 112 | text HTMLではなく、テキストフォーマット（コマンドライン用）で提供します 113 | flat パッケージ表示を階層ではなく、フルパスを用いたフラット（インデントのない）なリストで提供します 114 | 115 | 例えば、 http://golang.org/pkg/math/big/?m=all を開くと、 big パッケージで宣言されたすべて（エクスポートされていないものも）のドキュメントを見ることができます。 116 | コマンドラインでは、 "godoc -src math/big .*" として閲覧することができます。 117 | 118 | 通常、godocは、基盤となっているOSのファイルシステムからファイルを提供します。 119 | 代わりに -zipフラグで .zip ファイルから提供することもできます。 120 | ファイルパスは.zipファイルで保持し、パスセパレータはスラッシュ ('/') を使う必要があり、 121 | それらはアンルート？？？(unroot)されている必要があります。 122 | $GOROOT (または -goroot)は、Goのルートディレクトリを含む.zipファイルへのディレクトリパスを与える必要があります。 123 | コマンドで.zipファイル生成するには、例えば: 124 | 125 | zip go.zip $HOME/go 126 | 127 | のように（訳注1）してファイルを追加し、次のようにgodocを実行できます: 128 | 129 | godoc -http=:6060 -zip=go.zip -goroot=$HOME/go 130 | 131 | godocのドキュメンテーションは go/docパッケージでHTMLやテキストへ変換されます。 132 | フォーマットの詳細は http://golang.org/pkg/go/doc/#ToHTML を御覧ください。 133 | 134 | コメントの良い書き方については、 "Godoc: documenting Go code" 135 | http://golang.org/doc/articles/godoc_documenting_go_code.html を御覧ください。 136 | 137 | 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/cmd/godoc/doc.go?repo=tools&r=0e399fef76b7c34144d51e7b64c6da5b5591ea51 138 | 139 | 訳注1: 140 | zipコマンドの完全な例は: 141 | 142 | zip -r go.zip $HOME/go -i \*.go -i \*.html -i \*.css -i \*.js -i \*.txt -i \*.c -i \*.h -i \*.s -i \*.png -i \*.jpg -i \*.sh -i favicon.ico 143 | 144 | 145 | */ 146 | package main 147 | 148 | import "code.google.com/p/go.tools/cmd/godoc" 149 | -------------------------------------------------------------------------------- /src/code.google.com/p/go.tools/cmd/goimports/doc.go: -------------------------------------------------------------------------------- 1 | /* 2 | 3 | goimportsコマンドは、Goのimport節で不足しているimportを自動で追加したり、参照されていないimport文を削除するgofmt互換のツールです。 4 | インストールは: 5 | 6 | $ go get code.google.com/p/go.tools/cmd/goimports 7 | 8 | です。 9 | 10 | goimportsは、自分のエディタのgofmt-on-saveフックの置き換えができます。 11 | goimportsは、gofmtのコマンドラインインタフェースと同じであり、同じ方法で 12 | コードのフォーマットができるようになっています。 13 | 14 | emacsでは、(Go 1.2+)の go-mode.elを利用します: 15 | https://go.googlecode.com/hg/misc/emacs/go-mode.el 16 | .emacsファイルに以下を追加しましょう: 17 | (setq gofmt-command "goimports") 18 | (add-to-list 'load-path "/home/you/goroot/misc/emacs/") 19 | (require 'go-mode-load) 20 | (add-hook 'before-save-hook 'gofmt-before-save) 21 | 22 | For vim, set "gofmt_command" to "goimports": 23 | https://code.google.com/p/go/source/detail?r=39c724dd7f252 24 | https://code.google.com/p/go/source/browse#hg%2Fmisc%2Fvim 25 | etc 26 | 27 | For GoSublime, follow the steps described here: 28 | http://michaelwhatcott.com/gosublime-goimports/ 29 | 30 | For other editors, you probably know what to do. 31 | 32 | Happy hacking! 33 | 34 | 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/cmd/goimports/doc.go?repo=tools&r=8caf575e6beacc2237f7d78f8bd349c28f1b6b3e 35 | 36 | */ 37 | package main 38 | -------------------------------------------------------------------------------- /src/code.google.com/p/go.tools/cmd/vet/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2010 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | /* 6 | vetコマンドはGoのソースコードをチェックし、Printfの呼び出しで引数が書式文字列(format string)で列んでないような欠陥をレポートします。 7 | vetはヒューリスティック(heuristic)な問題を扱い、すべてのレポートが本当に問題であることを保証しません。しかし、コンパイラで見つけられないエラーを検出することができます。 8 | 9 | コマンドの終了ステータス(exit code)は、コマンドの起動を間違うと"2"、問題がレポートされると"1"、"0"はそれ以外です。 10 | コマンドは起こりうるすべての問題をチェックできず、信頼性の低いヒューリスティックに依存することを覚えておいてください。 11 | ですから、ガイダンスとしてだけ使用すべきで、確固としたプログラムの正当性の指標として利用すべきではありません。 12 | 13 | 通常、すべてのチェックが実行されますが、フラグを付けることで範囲を指定することができます。 14 | 15 | 利用可能なオプション： 16 | 17 | 1. Printf群のチェック (-printf) 18 | 19 | Printf群で関数を呼ぶものをチェックします。 20 | Printf群: 21 | Print Printf Println 22 | Fprint Fprintf Fprintln 23 | Sprint Sprintf Sprintln 24 | Error Errorf 25 | Fatal Fatalf 26 | Panic Panicf Panicln 27 | もし関数が'f'で終わるものであれば、その関数はfmt.Printfの作法での書式化文字をとることを想定します。もしそれ以外をとっていれば、vetは書式化文字列のような引数について一言言ってきます。 28 | 29 | また、Printfの最初の引数のようなWriterを使う場合でもチェックします。 30 | 31 | 2. メソッドのチェック (-methods) 32 | 33 | 以下のよく使われる名前のメソッドで、標準的ではないシグニチャ（関数、引数、戻り値）になっているものをチェックします: 34 | Format GobEncode GobDecode MarshalJSON MarshalXML 35 | Peek ReadByte ReadFrom ReadRune Scan Seek 36 | UnmarshalJSON UnreadByte UnreadRune WriteByte 37 | WriteTo 38 | 39 | 3. 構造体のタグのチェック (-structtags) 40 | 41 | reflect.StructTag.Getで理解できる書式に従っていない構造体のタグをチェックします。 42 | 43 | 4. キーの無い複合的なリテラルのチェック (-composites) 44 | 45 | フィードキーのシンタックスを使っていない複合的な構造体のリテラルをチェックします。 46 | 47 | 48 | Usage: 49 | 50 | go tool vet [flag] [file.go ...] 51 | go tool vet [flag] [directory ...] # ディレクトリ以下の全ての .go ファイルを再帰的にスキャンします 52 | 53 | The other flags are: 54 | -v 55 | Verbose mode 56 | -printfuncs 57 | A comma-separated list of print-like functions to supplement 58 | the standard list. Each entry is in the form Name:N where N 59 | is the zero-based argument position of the first argument 60 | involved in the print: either the format or the first print 61 | argument for non-formatted prints. For example, 62 | if you have Warn and Warnf functions that take an 63 | io.Writer as their first argument, like Fprintf, 64 | -printfuncs=Warn:1,Warnf:1 65 | 66 | 67 | 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/cmd/vet/doc.go?repo=tools&r=81e58ded571716d210ea5358d40cd9e10403b98b 68 | 69 | */ 70 | package main 71 | 72 | import "code.google.com/p/go.tools/cmd/vet" 73 | -------------------------------------------------------------------------------- /src/fmt/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2009 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | /* 6 | fmtパッケージは、C言語のprintfおよびscanfに似た機能を持つ、 7 | フォーマットのためのI/Oを実装します。フォーマットに用いる「動詞」は 8 | C言語から派生されていますが、より簡素なものになっています。 9 | 10 | 11 | プリント 12 | 13 | 動詞： 14 | 15 | 一般： 16 | %v デフォルトフォーマットの値。 17 | 構造体をプリントするときは、プラスフラグ（%+v）にフィールド名を付加します。 18 | %#v 値のGo言語構文表現。 19 | %T 値の型のGo言語構文表現。 20 | %% パーセントリテラル記号で、値を利用しません。 21 | 22 | ブール値： 23 | %t trueもしくはfalseの値 24 | 整数値： 25 | %b 2進数 26 | %c Unicodeのコードポイントに対応する文字 27 | %d 10進数 28 | %o 8進数 29 | %q GO言語構文でエスケープしシングルクオートで囲んだ文字リテラル 30 | %x a-fの小文字を用いた16進数 31 | %X A-Fの大文字を用いた16進数 32 | %U Unicodeフォーマット：U+1234、"U+%04X"と同様 33 | 浮動小数点数値および複素数の構成要素： 34 | %b 2のべき乗を用いた小数を使わない指数表現 35 | 'b'フォーマットを用いたstrconv.FormatFloatと同じ表記となる 36 | 例：-123456p-78 37 | %e 指数表現、例：-1234.456e+78 38 | %E 指数表現、例：-1234.456E+78 39 | %f 指数を用いない小数点表現、例：123.456 40 | %g %e、%fのうち、より簡素な表現 41 | %G %E、%fのうち、より簡素な表現 42 | stringおよびbyte配列のslice： 43 | %s 解釈されないstringのbyte配列もしくはslice 44 | %q Go言語構文で安全にエスケープ処理しダブルクオーテーションで囲ったstring 45 | %x 16進数、小文字、1バイト2文字で表現 46 | %X 16進数、大文字、1バイト2文字で表現 47 | ポインタ： 48 | %p 0xで始まる16進数表現 49 | 50 | 'u'フラグはありません。整数は符号なしの型の場合は符号なしでプリントされます。 51 | 同様に、オペランドのサイズ（int8、int64等）を指定する必要はありません。 52 | 53 | 有効幅と精度はフォーマットを調整しますが、Unicodeコードポイントの単位となります。 54 | （これは単位がバイト数となるC言語のprintfとは異なります。） 55 | どちらか一方もしくは両方のフラグを'*'文字に置き換えることができます。 56 | それらの実際の値は次のオペランドから得られることになりますが、必ずint型である必要があります。 57 | 58 | 数値については、有効幅がフィールドの最小幅、精度が小数点の後の桁数を可能であれば設定します。 59 | ただし、%g/%Gの場合は例外で、精度として総桁数を設定します。例えば、123.45を%6.2fと 60 | フォーマットした場合には123.45、%.4gとフォーマットした場合には123.5とプリントします。 61 | %eおよび%fのデフォルト精度は6、%gのデフォルト精度は値を一意に識別するために 62 | 必要な最小の桁数となります。 63 | 64 | ほとんどの値について、有効幅は表示する際の最小の文字数となり、必要であれば 65 | フォーマットした形式をスペースでパディングします。stringについては、 66 | 精度は表示する際の最大の文字数となり、必要であれば切り詰めを行ないます。 67 | 68 | その他のフラグ： 69 | + 数値に対し常に符号をプリントします。 70 | %g（つまり%+g）についてはASCIIのみでの出力を保証します。 71 | - 左側ではなく、右側にスペースでパディングします（フィールドを左揃えにします）。 72 | # 代替フォーマット。8進数（%#o）の頭に0、16進数（%#ｘ）に0x、 73 | 16進数（%#X）に0Xを付加し、%p (つまり%#p)から0xを除きます。 74 | %gについてはstrconv.CanBackquoteがtrueを返す場合はバッククオートを 75 | を用いた生のstringをプリントします。 76 | characterが%U（つまり%#U）で表示できる場合は、例えばU+0078を'x'と出力します。 77 | ' ' （スペース）数値（たとえば% d）については符号を表示しない場合に符号の分のスペースを残します。 78 | 16進数（たとえば% x、% X）についてはstringやsliceをプリントするbyteの間にスペースを挿入します。 79 | 0 先頭をスペースではなく0でパディングします。 80 | 数値については、符号の後にパディングします。 81 | 82 | 動詞に対し利用できないフラグを指定した場合には無視されます。 83 | たとえば、10進数には代替フォーマットがないため、%#dと%dはまったく同じ動作となります。 84 | 85 | それぞれのPrintf系の関数に対して、フォーマットを持たないPrint関数も存在します。 86 | Print関数はすべてのオペランドに対し%vでプリントさせているのと同等に動作します。 87 | もう一つの類似関数であるPrintlnはオペランドの間に空白を挿入し、最後に改行文字を追加します。 88 | 89 | 動詞にかかわらず、オペランドがインタフェースの値であった場合には、 90 | そのインタフェース自身ではなく内部の具体的な値が利用されます。 91 | つまり、 92 | var i interface{} = 23 93 | fmt.Printf("%v\n", i) 94 | は23をプリントします。 95 | 96 | オペランドがFormatterインタフェースを実装している場合は、 97 | インタフェースでフォーマットを微調整することができます。 98 | 99 | フォーマット（Printlnなどで暗黙的に%vを用いる場合を含む）が 100 | 正しいstring（%s、%q、%v、%x、%X）の場合、下記の2ルールが追加で適用されます。 101 | 102 | 1. オペランドがerrorインタフェースを実装している場合、 103 | Errorメソッドはstringを変換するために用いられ、 104 | 動詞がある場合はそのstringが動詞に従ってフォーマットされます。 105 | 106 | 2. オペランドがメソッドString() stringを実装している場合、 107 | そのメソッドはオブジェクトをstringに変換するために用いられ、 108 | 動詞がある場合はそのstringが動詞に従ってフォーマットされます。 109 | 110 | 以下のような再帰呼び出しを避けるために、 111 | type X string 112 | func (x X) String() string { return Sprintf("<%s>", x) } 113 | 値を変換して下さい。 114 | func (x X) String() string { return Sprintf("<%s>", string(x)) } 115 | 116 | 明示的な引数のインデックス： 117 | 118 | Printf、Sprintf、Fprintfでは、デフォルトでは関数呼び出しの中で 119 | それぞれのフォーマット動詞の次に続く引数をフォーマットするように動作します。 120 | しかし、動詞のすぐ前に[n]表記を挿入すると、代わりにn番目の引数が 121 | フォーマットされるようになります。有効幅および精度については 122 | '*'の前に同じ記法で記述すると、対応する順番の引数で指定することができます。 123 | 一度このカギカッコを用いた[n]記法を記述すると、そのあとは明示的に指定しなければ 124 | 順にn+1、n+2...番目の引数が用いられます。 125 | 126 | 例： 127 | fmt.Sprintf("%[2]d %[1]d\n", 11, 22) 128 | は "22, 11" という結果となります。一方、 129 | fmt.Sprintf("%[2]d %[1]d\n", 11, 22) 130 | は下記と同等で 131 | fmt.Sprintf("%6.2f", 12.0), 132 | " 12.00" という結果となります。明示的なインデックス指定は続く動詞を 133 | 制御できるため、この記法により繰り返す最初の引数のインデックスに 134 | リセットすることで同じ値を複数回表示することが可能です。 135 | fmt.Sprintf("%d %d %#[1]x %#x", 16, 17) 136 | の結果は "16 17 0x10 0x11" となります。 137 | 138 | フォーマットエラー： 139 | 140 | %dにstringを指定するなど、動詞に対し不正な引数が与えられると 141 | 表示されたstringは下記の例のように問題のある表現となります。 142 | 143 | 型の誤りや不明な動詞：%!verb(type=value) 144 | Printf("%d", hi): %!d(string=hi) 145 | 引数が多すぎる：%!(EXTRA type=value) 146 | Printf("hi", "guys"): hi%!(EXTRA string=guys) 147 | 引数が少なすぎる：%!verb(MISSING) 148 | Printf("hi%d"): hi %!d(MISSING) 149 | 有効幅や精度に対してint以外を指定：%!(BADWIDTH) or %!(BADPREC) 150 | Printf("%*s", 4.5, "hi"): %!(BADWIDTH)hi 151 | Printf("%.*s", 4.5, "hi"): %!(BADPREC)hi 152 | 不正な引数のインデックスや引数のインデックスの不正な利用：%!(BADINDEX) 153 | Printf("%*[2]d", 7): %!d(BADINDEX) 154 | Printf("%.[2]d", 7): %!d(BADINDEX) 155 | 156 | すべてのエラーは"%!"の文字列で始まり、その後に1文字（動詞）が入る場合があり、 157 | 最後はカッコ表記で終わります。 158 | 159 | ErrorもしくはStringメソッドがプリント処理で呼び出された時に 160 | panicを引き起こした場合には、fmtパッケージはpanicからの 161 | エラーメッセージをfmtパッケージでの表記に準じて再フォーマットします。 162 | 例えば、Stringメソッドがpanic("bad")を呼び出した場合、 163 | フォーマットしたメッセージは以下のような結果になります。 164 | %!s(PANIC=bad) 165 | 166 | エラーが起きた場合には%!sがprintでの動詞を表すために用いられます。 167 | 168 | スキャン 169 | 170 | 値を取得するためにフォーマットしたテキストをスキャンする一連の類似関数を提供します。 171 | Scan、Scanf、Scanlnはos.Stdinから読み、FScan、Fscanf、Fscanlnは 172 | 指定されたio.Readerから読み、Sscan、Sscanf、Sscanlnは引数に指定した 173 | stringから読みます。Scanln、Fscanln、Sscanlnは改行でスキャンを中止します。 174 | スキャンされる項目は必ず改行を含んでいる必要があります。 175 | Scanf、Fscanf、Sscanfでは入力された改行はフォーマットの改行と一致している 176 | 必要があります。その他の処理では改行はスペースとして扱われます。 177 | 178 | Scanf、Fscanf、SscanfはPrintfと同様にstringで記述されたフォーマットに 179 | したがって引数の内容を分析します。例えば、%xは整数を16進数としてスキャンし、 180 | %vは値に対しデフォルト表現のフォーマットでスキャンします。 181 | 182 | 以下の点を除き、Printfと同様のフォーマットの振る舞いをします。 183 | 184 | %pは実装されていません 185 | %Tは実装されていません 186 | %e %E %f %F %g %Gはすべて同等でどのような浮動小数点数や複素数でも読み込みます 187 | %s、%vはスペースで区切られたトークンをスキャンします 188 | #フラグ、+フラグは実装されていません 189 | 190 | おなじみの基数設定のプレフィックスである0（8進数）、0x（16進数）は 191 | %v動詞を用いるか、全くフォーマットを用いない場合にスキャンすることができます。 192 | 193 | 有効幅は入力されたテキストから解釈できますが（%5sは最大5ルーンの入力を 194 | スキャンすることを意味します）、精度を指定する記法はありません。 195 | （%5.2fは指定できません。%5fのみ指定できます。） 196 | 197 | フォーマットを用いてスキャンする際、連続したスペース（改行を除く）は 198 | フォーマット・入力のいずれにおいても1つのスペースと同等に扱われます。 199 | この条件で、stringで記述されたフォーマットのテキストは入力されたテキストと 200 | 一致しなければなりません。そうでなければ、スキャンできた引数の数を示した 201 | 関数の戻り値を返して、スキャンを中止します。 202 | 203 | これらすべてのスキャン関数において、直後に改行が続くキャリッジリターン 204 | は通常の改行として扱われます。（\r\nは\nと同じ意味です） 205 | 206 | また、これらすべてのスキャン関数において、オペランドがScanメソッドを 207 | 実装している場合（つまり、Scannerインタフェースを実装している場合）、 208 | そのオペランドについては該当のメソッドがテキストを読み込むのに利用されます。 209 | また、スキャンされた引数の数が与えられた引数の数より少なかった場合には 210 | エラーが返されます。 211 | 212 | スキャンされた引数はすべて基本型かScannerインタフェースの実装への 213 | ポインタでなければなりません。 214 | 215 | 注：Fscan等は入力が返された後で1文字（ルーン）を読むことができます。 216 | つまり、スキャン処理を繰り返し呼ぶ場合にはいくつかの入力がスキップされます。 217 | これは通常は入力値の間にスペースがない場合のみに起こる問題です。 218 | Fscanに与えられたreaderがReadRuneを実装している場合、そのメソッドは 219 | 文字を読むために利用されます。readerがさらにUnreadRuneを実装している場合には 220 | そのメソッドは文字情報を保持し、後に続く呼び出しでデータが失われないようにします。 221 | readerにReadRuneメソッドおよびUnreadRuneメソッドを付け実装するのが難しい場合には 222 | bufio.NewReaderを利用して下さい。 223 | 224 | 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/src/pkg/fmt/doc.go?r=09a1cf0d94b2b6cf672f8dcd04c6962e0916bc4e 225 | */ 226 | package fmt 227 | -------------------------------------------------------------------------------- /src/go/build/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2011 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | // buildパッケージはGoのパッケージの情報を収集します。 6 | // 7 | // Go Path 8 | // 9 | // GoのパスはGoのソースコードが入ったディレクトリツリーのリストです。 10 | // 標準のGoのツリー内に見つからなかったインポートはここから探されます。 11 | // デフォルトのパスはGOPATH環境変数の値で、 12 | // OSに応じたパスのリストとして解釈されます(Unixならばコロン区切りの文字列、 13 | // Windowsならばセミコロン区切りの文字列、Plan 9ならばリスト)。 14 | // 15 | // Goのパスにあるそれぞれのディレクトリはあらかじめ決められた構造を持ちます: 16 | // 17 | // src/ディレクトリにはソースコードが入ります。 18 | // 'src'以下のパスがインポートするパスや実行ファイルの名前になります。 19 | // 20 | // pkg/ディレクトリにはインストールされたパッケージオブジェクトが入ります。 21 | // Goのツリーでは、ターゲットとするOSとアーキテクチャのペアごとにサブディレクトリ 22 | // (pkg/GOOS_GOARCH)が作られます。 23 | // 24 | // DIRがGoのパスにあるディレクトリとすると、 25 | // DIR/src/foo/barは"foo/bar"としてインポートされ、 26 | // "DIR/pkg/GOOS_GOARCH/foo/bar.a"としてコンパイルされます。 27 | // (gccgoの場合は"DIR/pkg/gccgo/foo/libbar.a") 28 | // 29 | // bin/ディレクトリにはコンパイル済みのコマンドが入ります。 30 | // 各コマンドはソースディレクトリに基づいて名前が付けられますが、 31 | // パス全体ではなく、最後の要素だけが使われます。 32 | // つまり、DIR/src/foo/quuxはDIR/bin/quuxになるのであって、 33 | // DIR/bin/foo/quuxにはなりません。 34 | // DIR/binをPATHに加えればインストールされたコマンドを使えるようにするために、 35 | // fooは取り除かれます。 36 | // 37 | // 以下はディレクトリレイアウトの例です: 38 | // 39 | // GOPATH=/home/user/gocode 40 | // 41 | // /home/user/gocode/ 42 | // src/ 43 | // foo/ 44 | // bar/ (barパッケージのgoコード) 45 | // x.go 46 | // quux/ (mainパッケージのgoコード) 47 | // y.go 48 | // bin/ 49 | // quux (インストールされたコマンド) 50 | // pkg/ 51 | // linux_amd64/ 52 | // foo/ 53 | // bar.a (インストールされたパッケージオブジェクト) 54 | // 55 | // Build Constraints 56 | // 57 | // ビルド制約はビルドタグとしても知られており、 58 | // 以下に示す文字列で始まる行コメントです。 59 | // 60 | // // +build 61 | // 62 | // この後にそのファイルがパッケージに含められる条件を列挙します。 63 | // 制約はGoに限らずあらゆる種類のソースコードに記載できますが、 64 | // ファイルの先頭付近に存在する必要があり、 65 | // 空行や他の行コメントよりも先に存在する必要があります。 66 | // まとめると、Goのファイルではビルド制約はパッケージ文より前に存在しなければならないということになります。 67 | // 68 | // パッケージドキュメントとビルド制約を識別するために、 69 | // ビルド制約の前に空行を1行入れる必要があります。 70 | // 71 | // ビルド制約は、スペースで区切るとOR条件になり、 72 | // カンマで区切るとAND条件になります。 73 | // それぞれの語は英数字の単語で、先頭に!を付けると否定になります。 74 | // 以下にビルド制約の例を示します: 75 | // 76 | // // +build linux,386 darwin,!cgo 77 | // 78 | // これは以下のような論理式を意味します。 79 | // 80 | // (linux AND 386) OR (darwin AND (NOT cgo)) 81 | // 82 | // ひとつのファイルは複数のビルド制約を持つことができます。 83 | // 全体としての制約は個々の制約をANDで組み合わせたものになります。 84 | // 以下のようなビルド制約があるとします: 85 | // 86 | // // +build linux darwin 87 | // // +build 386 88 | // 89 | // これは以下のような論理式を意味します: 90 | // 91 | // (linux OR darwin) AND 386 92 | // 93 | // 以下の条件は毎回のビルドで満たされます: 94 | // 95 | // - runtime.GOOSで示される対象OS 96 | // - runtime.GOARCHで示される対象アーキテクチャ 97 | // - "gc"あるいは"gccgo"のどちらかの使われているコンパイラ 98 | // - ctxt.CgoEnabledがtrueの場合、"cgo" 99 | // - Goのバージョンが1.1の場合、"go1.1" 100 | // - Goのバージョンが1.2の場合、"go1.2" 101 | // - Goのバージョンが1.3の場合、"go1.3" 102 | // - ctxt.BuildTagsに列挙された追加の条件 103 | // 104 | // ファイル名から拡張子と(あれば)_test接尾詞を除いたものが、 105 | // 以下のパターンのいずれかにマッチする場合: 106 | // *_GOOS 107 | // *_GOARCH 108 | // *_GOOS_GOARCH 109 | // (例: source_windows_amd64.go)または以下のリテラルである場合: 110 | // GOOS 111 | // GOARCH 112 | // (例: windows.go) GOOSとGOARCHはそれぞれ既知のOSとアーキテクチャの値を取り、 113 | // ファイルはそれらの語が示すビルド制約を暗黙的に持つものとして扱われます。 114 | // 115 | // ファイルをビルドしないようにするには以下のようにします: 116 | // 117 | // // +build ignore 118 | // 119 | // (他の条件に関係なく``ignore''は効果を発揮します。) 120 | // 121 | // ファイルをcgoだけを使ってLinuxとOS X上だけでビルドするには以下のようにします: 122 | // 123 | // // +build linux,cgo darwin,cgo 124 | // 125 | // このようなファイルはたいてい他のシステム用のデフォルトの振る舞いを実装したファイルとペアになっており、 126 | // そちらのファイルには以下のような制約が必要になるでしょう: 127 | // 128 | // // +build !linux,!darwin !cgo 129 | // 130 | // dns_windows.goというファイル名を付けると、 131 | // Windows向けにパッケージをビルドしたときだけそのファイルが含まれるようになります。 132 | // 同様に、math_386.sは32ビットのx86向けにパッケージをビルドしたときだけ含まれます。 133 | // 134 | // 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/src/pkg/go/build/doc.go?r=f15ad332ce135a5b23bfb7d521594afe9fd42f8b 135 | // 136 | package build 137 | -------------------------------------------------------------------------------- /src/net/http/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2011 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | /* 6 | httpパッケージはHTTPクライアントとサーバの実装を提供します。 7 | 8 | Get、Head、Post、PostFormはHTTP(またはHTTPS)リクエストを作成します。 9 | 10 | resp, err := http.Get("http://example.com/") 11 | ... 12 | resp, err := http.Post("http://example.com/upload", "image/jpeg", &buf) 13 | ... 14 | resp, err := http.PostForm("http://example.com/form", 15 | url.Values{"key": {"Value"}, "id": {"123"}}) 16 | 17 | クライアントは終了時にレスポンスボディをクローズしなければなりません。 18 | 19 | resp, err := http.Get("http://example.com/") 20 | if err != nil { 21 | // handle error 22 | } 23 | defer resp.Body.Close() 24 | body, err := ioutil.ReadAll(resp.Body) 25 | // ... 26 | 27 | HTTPクライアントヘッダ、リダイレクトポリシーなどの設定を制御するには 28 | Clientを作成してください。 29 | 30 | client := &http.Client{ 31 | CheckRedirect: redirectPolicyFunc, 32 | } 33 | 34 | resp, err := client.Get("http://example.com") 35 | // ... 36 | 37 | req, err := http.NewRequest("GET", "http://example.com", nil) 38 | // ... 39 | req.Header.Add("If-None-Match", `W/"wyzzy"`) 40 | resp, err := client.Do(req) 41 | // ... 42 | 43 | プロキシ、TLS設定、キープアライブ、圧縮などの設定を制御するには 44 | Transportを作成してください。 45 | 46 | tr := &http.Transport{ 47 | TLSClientConfig: &tls.Config{RootCAs: pool}, 48 | DisableCompression: true, 49 | } 50 | client := &http.Client{Transport: tr} 51 | resp, err := client.Get("https://example.com") 52 | 53 | ClientとTransportは複数のゴルーチンからの並行アクセスに対して安全であり、 54 | 効率のために一度だけ作成されて再利用されるべきです。 55 | 56 | ListenAndServeは与えられたアドレスとハンドラを使ってHTTPサーバを開始します。 57 | ハンドラはたいていはnilであり、その場合はDefaultServeMuxが使われます。 58 | HandleとHandleFuncはDefaultServeMuxにハンドラを追加します。 59 | 60 | http.Handle("/foo", fooHandler) 61 | 62 | http.HandleFunc("/bar", func(w http.ResponseWriter, r *http.Request) { 63 | fmt.Fprintf(w, "Hello, %q", html.EscapeString(r.URL.Path)) 64 | }) 65 | 66 | log.Fatal(http.ListenAndServe(":8080", nil)) 67 | 68 | 独自にServerを作成することで、サーバの振る舞いをさらに制御することが可能です。 69 | 70 | s := &http.Server{ 71 | Addr: ":8080", 72 | Handler: myHandler, 73 | ReadTimeout: 10 * time.Second, 74 | WriteTimeout: 10 * time.Second, 75 | MaxHeaderBytes: 1 << 20, 76 | } 77 | log.Fatal(s.ListenAndServe()) 78 | 79 | 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/src/pkg/net/http/doc.go?r=09a1cf0d94b2b6cf672f8dcd04c6962e0916bc4e 80 | */ 81 | package http 82 | -------------------------------------------------------------------------------- /src/os/file.go: -------------------------------------------------------------------------------- 1 | // Copyright 2009 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | // osパッケージはOS機能へのプラットフォーム非依存なインタフェースを提供します。 6 | // 設計はUnixライクですが、エラーの扱いはGoライクになっており、 7 | // 関数呼び出しの失敗時にはエラー番号ではなく、error型の値を返します。 8 | // errorからはより多くの情報が得られることがあります。 9 | // 例えば、ファイル名を受け取る関数呼び出し(OpenやStatなど)が失敗したとき、 10 | // errorをプリントすると失敗したファイル名が得られ、またerrorを*PathError型の値 11 | // として扱うことで、より詳細な情報が得られます。 12 | // 13 | // osパッケージは全てのOSに共通のインタフェースを提供することを目指しています。 14 | // 共通ではない機能はシステム依存なパッケージであるsyscallにあります。 15 | // 16 | // 以下はファイルを開いてそれを読む簡単な例です。 17 | // 18 | // file, err := os.Open("file.go") // For read access. 19 | // if err != nil { 20 | // log.Fatal(err) 21 | // } 22 | // 23 | // ファイルを開くのに失敗すると、errorは以下のようなエラーの内容を示す文字列 24 | // になります。 25 | // 26 | // open file.go: no such file or directory 27 | // 28 | // ファイルのデータはbyteのスライスへ読み込まれます。 29 | // ReadとWriteは引数に渡されたスライスの長さをバイト数として返します。 30 | // 31 | // data := make([]byte, 100) 32 | // count, err := file.Read(data) 33 | // if err != nil { 34 | // log.Fatal(err) 35 | // } 36 | // fmt.Printf("read %d bytes: %q\n", count, data[:count]) 37 | // 38 | // 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/src/pkg/os/file.go?r=5142686ded576fd930ba36b3aeac9b7c3a819d6b 39 | package os 40 | -------------------------------------------------------------------------------- /src/runtime/race/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2013 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | // raceパッケージはデータ競合検知ロジックを実装しています。 6 | // 公開インタフェースは提供されていません。 7 | // データ競合検知についての詳細は http://golang.org/doc/articles/race_detector.html を 8 | // ご覧ください。 9 | // 10 | // 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/src/pkg/runtime/race/doc.go?r=30b1c2ff7d934e0dbbc9253293ba29caf3312507 11 | package race 12 | -------------------------------------------------------------------------------- /src/testing/testing.go: -------------------------------------------------------------------------------- 1 | // Copyright 2009 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | /* 6 | testingパッケージはGoのパッケージの自動テストを支援します。 7 | これは``go test''コマンドとともに使用することで、次のような形式の関数を自動実行します。 8 | func TestXxx(*testing.T) 9 | Xxxはどんな英数字の文字列でもよく(ただし、最初の文字は[a-z]以外でなければなりません)、テストルーチンを識別するために用いられれます。 10 | 11 | これらの関数内では、ErrorやFailといったメソッドを使用することで、失敗を報告することができます。 12 | 13 | 新しいテストスイートを書くには、名前が_test.goで終わり、ここで説明したTestXxx関数を含むファイルを作成してください。 14 | ファイルは、テストされるものと同一のパッケージに配置してください。 15 | このファイルは通常のパッケージビルドからは除外されますが、``go test''コマンドで実行されるときには含まれます。 16 | 詳細については、``go help test''や``go help testflag''を実行してみてください。 17 | 18 | テストとベンチマークは、実行したくない状況では*Tや*BのSkipメソッドを呼び出すことでスキップできます: 19 | 20 | func TestTimeConsuming(t *testing.T) { 21 | if testing.Short() { 22 | t.Skip("skipping test in short mode.") 23 | } 24 | ... 25 | } 26 | 27 | Benchmarks 28 | 29 | 次のような形式の関数 30 | func BenchmarkXxx(*testing.B) 31 | は、ベンチマークとみなされ、"go test"コマンドに-benchフラグが与えられたときに実行されます。 32 | ベンチマークは順次実行されます。 33 | 34 | テストフラグの詳細については、こちらを参照してください: 35 | http://golang-jp.org/pkg/cmd/go/#hdr-Go__________________ 36 | 37 | サンプルのベンチマーク関数は次のようになります: 38 | 39 | func BenchmarkHello(b *testing.B) { 40 | for i := 0; i < b.N; i++ { 41 | fmt.Sprintf("hello") 42 | } 43 | } 44 | 45 | ベンチマーク関数は対象のコードをb.N回実行しなければなりません。 46 | testingパッケージは、ベンチマーク関数が十分な時間継続するようになるまでb.Nを変化させます。 47 | 出力の 48 | BenchmarkHello 10000000 282 ns/op 49 | は、ループが10000000回、一回あたり282ナノ秒で実行されたことを意味します。 50 | 51 | もしベンチマークで処理がはじまる前に時間のかかる初期化が必要なら、タイマーをリセットすることもできます: 52 | 53 | func BenchmarkBigLen(b *testing.B) { 54 | big := NewBig() 55 | b.ResetTimer() 56 | for i := 0; i < b.N; i++ { 57 | big.Len() 58 | } 59 | } 60 | 61 | もしベンチマークで並列処理の性能をテストする必要があれば、RunParallelヘルパー関数を使うこともできます; 62 | このようなベンチマークはgo test -cpuフラグと一緒に使用できます: 63 | 64 | func BenchmarkTemplateParallel(b *testing.B) { 65 | templ := template.Must(template.New("test").Parse("Hello, {{.}}!")) 66 | b.RunParallel(func(pb *testing.PB) { 67 | var buf bytes.Buffer 68 | for pb.Next() { 69 | buf.Reset() 70 | templ.Execute(&buf, "World") 71 | } 72 | }) 73 | } 74 | 75 | Examples 76 | 77 | testingパッケージは用例となるコード(Example関数)を実行し、検証します。 78 | Example関数は結果について"Output:"で始まる一行コメントを含むことができ、テストが実行された際の関数の標準出力と比較されます。 79 | (比較の際、前後の空白は無視されます。) Example関数の例を示します: 80 | 81 | func ExampleHello() { 82 | fmt.Println("hello") 83 | // Output: hello 84 | } 85 | 86 | func ExampleSalutations() { 87 | fmt.Println("hello, and") 88 | fmt.Println("goodbye") 89 | // Output: 90 | // hello, and 91 | // goodbye 92 | } 93 | 94 | Example関数で"Output:"のコメントがないものは、コンパイルはされますが実行はされません。 95 | 96 | Example関数には命名規則があり、そのパッケージ内の関数F、型T、型TのメソッドMの用例を書くには次のようにします: 97 | 98 | func Example() { ... } 99 | func ExampleF() { ... } 100 | func ExampleT() { ... } 101 | func ExampleT_M() { ... } 102 | 103 | 複数のExample関数を一つのパッケージ/型/関数/メソッドについて書くには、固有のサフィックスを名前に追加してください。 104 | サフィックスは、小文字で始まる必要があります。 105 | 106 | func Example_suffix() { ... } 107 | func ExampleF_suffix() { ... } 108 | func ExampleT_suffix() { ... } 109 | func ExampleT_M_suffix() { ... } 110 | 111 | テストファイルが一つのExample関数だけを含む場合、ファイル全体が用例として提示されます。 112 | これは他の関数や型、変数、定数の宣言を少なくとも一つ含み、テスト関数やベンチマーク関数を含まない必要があります。 113 | 114 | Main 115 | 116 | 時には、テストの前後で追加の初期化や終了処理がテストプログラムで必要になることもあります。 117 | また、メインスレッドで実行されるように制御する必要があるテストもあります。 118 | これらをサポートするために、もしテストファイルが次の関数を含んでいた場合には: 119 | 120 | func TestMain(m *testing.M) 121 | 122 | 生成されたテストはテストを直接実行する代わりに、TestMain(m)を呼び出します。 123 | TestMainはメインのゴルーチンで実行されるため、m.Runの呼び出しの前後で必要な初期化や終了処理を挟むことができます。 124 | ここではm.Runの結果をもとにos.Exitを呼び出すべきです。 125 | 126 | TestMainの最小実装は: 127 | 128 | func TestMain(m *testing.M) { os.Exit(m.Run()) } 129 | 130 | 実際のところ、この実装はTestMainが明示的に定義されなかった場合に使用されます。 131 | 132 | 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/src/testing/testing.go?r=804cc55d6b47e49e4bf46baa4ca9ec44b9684bed 133 | */ 134 | package testing 135 | -------------------------------------------------------------------------------- /src/text/template/doc.go: -------------------------------------------------------------------------------- 1 | // Copyright 2011 The Go Authors. All rights reserved. 2 | // Use of this source code is governed by a BSD-style 3 | // license that can be found in the LICENSE file. 4 | 5 | /* 6 | templateパッケージはテキストの出力を生成するデータ駆動テンプレートを実装します。 7 | 8 | HTMLの出力を生成するには、html/templateパッケージを参照してください。 9 | html/templateパッケージはこのパッケージと同じインタフェースを備えていますが、 10 | HTML出力を既知の攻撃から自動的に守ります。 11 | 12 | テンプレートはデータ構造へ適用することで実行されます。 13 | テンプレート中のアノテーションはデータ構造内の要素(典型的には構造体のフィールド、またはマップのキー)を参照し、実行の制御や値の表示を行います。 14 | テンプレートの実行はデータ構造内を移動し、実行の進捗を示すために、データ構造内の現在地を示す値にカーソルをセットします。 15 | カーソルは1つのピリオド'.'で表され、「ドット」と呼ばれます。 16 | 17 | テンプレートへの入力テキストはフォーマットなしのUTF-8でエンコードされたテキストです。 18 | データ評価または制御構造である「アクション」は"{{"と"}}"で区切られます。 19 | アクションの外側のテキストは全てそのまま出力となります。 20 | アクションは改行はできませんが、コメントは可能です。 21 | 22 | 一度パースされると、テンプレートは安全に並行して実行できるようになります。 23 | 24 | 以下は"17 items are made of wool"と表示する簡単な例です。 25 | 26 | type Inventory struct { 27 | Material string 28 | Count uint 29 | } 30 | sweaters := Inventory{"wool", 17} 31 | tmpl, err := template.New("test").Parse("{{.Count}} items are made of {{.Material}}") 32 | if err != nil { panic(err) } 33 | err = tmpl.Execute(os.Stdout, sweaters) 34 | if err != nil { panic(err) } 35 | 36 | この先にはより複雑な例があります。 37 | 38 | Actions 39 | 40 | 以下はアクションのリストです。 41 | データの評価を行う「引数」と「パイプライン」についてはその後で詳細な説明をします。 42 | 43 | */ 44 | // {{/* a comment */}} 45 | // コメント: 破棄されます。改行を含むことができます。 46 | // コメントはネストできず、ここで示している区切り文字で開始・終了する必要があります。 47 | /* 48 | 49 | {{pipeline}} 50 | pipelineの値に対するデフォルトのテキスト表現が出力されます。 51 | 52 | {{if pipeline}} T1 {{end}} 53 | pipelineの値が空の場合、何も出力されません。 54 | そうでない場合、T1が実行されます。 55 | 空の値とは、false、0、nilポインタまたはインタフェース値、 56 | 長さがゼロの配列、スライス、マップ、文字列です。 57 | ドットは影響を受けません。 58 | 59 | {{if pipeline}} T1 {{else}} T0 {{end}} 60 | pipelineの値が空の場合、T0が実行されます。 61 | そうでない場合、T1が実行されます。 62 | ドットは影響を受けません。 63 | 64 | {{if pipeline}} T1 {{else if pipeline}} T0 {{end}} 65 | if-elseの連鎖が起きないように、elseアクションは他のifを直接含めることができます。 66 | この例は次の文とまったく同じ意味になります。 67 | {{if pipeline}} T1 {{else}}{{if pipeline}} T0 {{end}}{{end}} 68 | 69 | {{range pipeline}} T1 {{end}} 70 | pipelineの値は配列、スライス、マップ、チャネルのどれかである必要があります。 71 | pipelineの値の長さがゼロの場合、何も出力されません。 72 | そうでない場合、配列、スライス、マップ中の次の要素にドットがセットされ、T1が実行されます。 73 | 値がマップで、キーが整列可能である(「比較可能」である)基本型の値である場合、 74 | 要素はキーがソートされた順にアクセスされます。 75 | 76 | {{range pipeline}} T1 {{else}} T0 {{end}} 77 | pipelineの値は配列、スライス、マップ、チャネルのどれかである必要があります。 78 | pipelineの値の長さがゼロの場合、ドットは影響を受けず、T0が実行されます。 79 | そうでない場合、配列、スライス、マップ中の次の要素にドットがセットされ、T1が実行されます。 80 | 81 | {{template "name"}} 82 | 指定された名前のテンプレートがnilデータに対して実行されます。 83 | 84 | {{template "name" pipeline}} 85 | ドットがpipelineの値にセットされ、指定された名前のテンプレートが実行されます。 86 | 87 | {{with pipeline}} T1 {{end}} 88 | pipelineの値が空の場合、出力は何も生成されません。 89 | そうでない場合、ドットがpipelineの値にセットされ、T1が実行されます。 90 | 91 | {{with pipeline}} T1 {{else}} T0 {{end}} 92 | pipelineの値が空の場合、ドットは影響を受けず、T0が実行されます。 93 | そうでない場合、ドットがpipelineの値にセットされ、T1が実行されます。 94 | 95 | Arguments 96 | 97 | 引数は以下に示されるような単純な値です。 98 | 99 | - Goの文法における真偽値、文字列、文字、数値、浮動小数点数、虚数、複素数の定数。 100 | これらはGoの型指定なしの定数と同じように振る舞いますが、未加工文字列中の改行は無視されます。 101 | - nil値。Goの型指定なしのnilと同じです。 102 | - ピリオド文字'.': 103 | . 104 | 結果はドットの値です。 105 | - 変数名。ドルマークに続く英数字の文字列(なくてもよい)です。例えば以下のようなものです。 106 | $piOver2 107 | あるいは以下のようなものです。 108 | $ 109 | 結果は変数の値です。 110 | 変数については後で説明します。 111 | - 構造体のフィールドの名前。以下のように、前にピリオドを付けます。 112 | .Field 113 | 結果はフィールドの値です。フィールドは連鎖させることができます: 114 | .Field1.Field2 115 | フィールドは変数から連鎖させて評価させることもできます: 116 | .$x.Field1.Field2 117 | - マップのキーの名前。以下のように、前にピリオドを付けます。 118 | .Key 119 | 結果はマップ中のそのキーに対応した要素の値です。 120 | キーはフィールドと組み合わせて何段も連鎖させることができます: 121 | .Field1.Key1.Field2.Key2 122 | キーは英数字の名前でなくてはなりませんが、フィールド名のように大文字で始まる必要がありません。 123 | キーは変数から連鎖させて評価させることもできます: 124 | $x.key1.key2 125 | - 引数なしのメソッド。以下のように、前にピリオドを付けます。 126 | .Method 127 | 結果はドットをレシーバとしてドット.Method()を実行した結果になります。 128 | このようなメソッドは任意の型の戻り値1つか、第2戻り値としてerrorを加えた2つの戻り値を返す必要があります。 129 | 戻り値が2つでerrorが非nilであれば、実行結果はエラーとなります。 130 | メソッドの呼び出しはフィールドやキーと組み合わせて何段も連鎖させることができます: 131 | .Field1.Key1.Method1.Field2.Key2.Method2 132 | メソッドは変数から連鎖させて評価させることもできます" 133 | $x.Method1.Field 134 | - 引数なしの関数。以下のようなものです。 135 | fun 136 | 結果は関数fun()を実行した結果になります。 137 | 返される型と値はメソッドの場合と同じ振る舞いです。 138 | 関数と関数名は後で説明します。 139 | - ここまでに説明したものは丸括弧で囲むとグループになります。 140 | 結果はフィールドまたはマップのキー呼び出しによってアクセスできます。 141 | print (.F1 arg1) (.F2 arg2) 142 | (.StructValuedMethod "arg").Field 143 | 144 | 引数は任意の型になります。引数がポインタであれば、必要に応じて値型になります。 145 | 構造体の関数型フィールドのように、評価によって関数値が生成される場合、その関数は自動的には実行されませんが、ifアクションなどにとってはtrueとして扱われます。 146 | 関数を実行する方法は、以降で示しています。 147 | 148 | パイプラインは可能な限り「コマンド」のシーケンスをつないだものになります。 149 | コマンドは単なる値(引数)か、可能な限り複数の引数をとるようにした関数またはメソッドです。 150 | 151 | Argument 152 | 結果は引数の評価値です。 153 | .Method [Argument...] 154 | メソッドは単独か連鎖の最後の要素ですが、連鎖の中間にあるメソッドと違い、引数をとることができます。 155 | 結果は引数を与えてメソッドを実行した結果になります: 156 | dot.Method(Argument1, etc.) 157 | functionName [Argument...] 158 | 結果はその名前に紐付いている関数を実行した値になります: 159 | function(Argument1, etc.) 160 | 関数と関数名については以降で示します。 161 | 162 | Pipelines 163 | 164 | パイプラインはパイプライン文字'|'で区切ってコマンドをつなげることによって「連鎖」させることができます。 165 | 連鎖されたパイプラインでは、各コマンドの結果は次のコマンドへ最後の引数として渡されます。 166 | パイプラインにおける最後のコマンドの出力がそのパイプラインの値になります。 167 | 168 | コマンドの出力が1つか2つの場合、2番目の出力はerror型になります。 169 | もし2つめの値が存在し、評価結果がnilでなければ、実行は終了し、呼び出し元へはエラーが返されます。 170 | 171 | Variables 172 | 173 | アクション内のパイプラインは変数を初期化し結果を受け取ることができます。 174 | 初期化の構文は次の通りです。 175 | 176 | $variable := pipeline 177 | 178 | $variableは変数の名前です。 179 | 変数を宣言するアクションは何も出力しません。 180 | 181 | "range"アクションが変数を初期化する場合、変数にはイテレーションで毎回生成される値がセットされます。 182 | "range"がカンマで区切った2つの変数を宣言する場合: 183 | 184 | range $index, $element := pipeline 185 | 186 | この場合、$indexと$elementは、毎回生成される、配列・スライスのインデックスあるいはマップのキーと値がそれぞれセットされます。 187 | 1つだけ変数がある場合は、値がセットされることに注意してください。これはGoのrange式と同様になっています。 188 | 189 | 変数のスコープはそれが宣言された制御構造("if", "with", "range")における"end"アクションまで続きます。 190 | 制御構造がない場合はテンプレートの終わりまで続きます。 191 | テンプレートは実行された箇所から変数を受け継ぐことはありません。 192 | 193 | 実行が始まった時、$は実行に渡されたデータ引数にセットされます。 194 | つまり最初の値はドットであるということです。 195 | 196 | Examples 197 | 198 | 以下はパイプラインと変数をデモする1行テンプレートの例です。 199 | これら全てがダブルクオートで囲まれた"output"という語を出力します。 200 | 201 | {{"\"output\""}} 202 | 文字列定数です。 203 | {{`"output"`}} 204 | 未加工文字列定数です。 205 | {{printf "%q" "output"}} 206 | 関数呼び出しです。 207 | {{"output" | printf "%q"}} 208 | 関数呼び出しですが、最後の引数は前のコマンドから受け取っています。 209 | {{printf "%q" (print "out" "put")}} 210 | カッコで囲まれた引数です。 211 | {{"put" | printf "%s%s" "out" | printf "%q"}} 212 | より複雑な関数呼び出しです。 213 | {{"output" | printf "%s" | printf "%q"}} 214 | 少し長い連鎖です。 215 | {{with "output"}}{{printf "%q" .}}{{end}} 216 | ドットを使ったアクションの例です。 217 | {{with $x := "output" | printf "%q"}}{{$x}}{{end}} 218 | 変数を生成して使用するアクションの例です。 219 | {{with $x := "output"}}{{printf "%q" $x}}{{end}} 220 | 別のアクションで変数を利用する例です。 221 | {{with $x := "output"}}{{$x | printf "%q"}}{{end}} 222 | 同様の例ですが、パイプラインを使っています。 223 | 224 | Functions 225 | 226 | 実行の間、関数は次の2つの関数マップから探されます: 227 | 1つめはテンプレート中にあるもので、その場合はグローバルな関数マップになります。 228 | デフォルトではテンプレート内で関数は定義されていませんが、Funcsメソッドによって関数を追加することができます。 229 | 230 | あらかじめ定義されたグローバル関数は次のようになっています。 231 | 232 | and 233 | 引数のAND値を返します。最初の空の引数または最後の引数を返します。 234 | つまり、"and x y"は「xが真のときy、そうでなければx」となります。 235 | 全ての引数は評価されます。 236 | call 237 | 最初の引数の関数に残りの引数をパラメータとして与えて実行した結果を返します。 238 | 例えば"call .X.Y 1 2"はGoで書くと dot.X.Y(1, 2) となります。Yは関数型のフィールドやマップのエントリ等です。 239 | 最初の引数は関数型の値(printのような組み込み関数ではないもの)を生成する評価結果でなくてはなりません。 240 | 関数は1つまたは2つの値を返す必要があり、2番目はerror型になります。 241 | 引数が関数型でない、あるいは戻り値のerror値がnilでなかった場合、実行は停止します。 242 | html 243 | 引数のテキスト表現をエスケープされたHTMLに変換したものを返します。 244 | index 245 | 最初の引数を続く引数でインデックスした結果を返します。 246 | 例えば"index x 1 2 3"はGoの文法では x[1][2][3]となります。 247 | インデックスされる値はマップ、スライス、配列である必要があります。 248 | js 249 | 引数のテキスト表現をエスケープされたJavaScriptに変換したものを返します。 250 | len 251 | 引数の長さを表す整数を返します。 252 | not 253 | 引数を1つ受け取り、その論理否定値を返します。 254 | or 255 | 引数のOR値を返します。最初の空の引数または最後の引数を返します。 256 | つまり、"or x y"は「xが真のときx、そうでなければy」となります。 257 | 全ての引数は評価されます。 258 | print 259 | fmt.Sprintへのエイリアスです。 260 | printf 261 | fmt.Sprintfへのエイリアスです。 262 | println 263 | fmt.Sprintlnへのエイリアスです。 264 | urlquery 265 | 引数のテキスト表現を、URLのクエリとして埋め込み可能な形式に変換して返します。 266 | 267 | 真偽値の関数はゼロ値を受け取るとfalseを、非ゼロ値を受け取るとtrueを返します。 268 | 269 | 以下のような二項比較演算子の関数もあります: 270 | 271 | eq 272 | arg1 == arg2ならば真を返します。 273 | ne 274 | arg1 != arg2ならば真を返します。 275 | lt 276 | arg1 < arg2ならば真を返します。 277 | le 278 | arg1 <= arg2ならば真を返します。 279 | gt 280 | arg1 > arg2ならば真を返します。 281 | ge 282 | arg1 >= arg2ならば真を返します。 283 | 284 | 単純な複数比較のテストでは、eq(だけ)は2つ以上の引数を取り、2番目やそれ以降の引数を最初の引数と比較します。 285 | 要するに以下のような結果を返します。 286 | 287 | arg1==arg2 || arg1==arg3 || arg1==arg4 ... 288 | 289 | (Goの||と異なり、eqは関数呼び出しであり、全ての引数は評価されます。) 290 | 291 | 比較関数は基本型(または"type Celsius float32"のように名前を付けた基本型)にのみ有効です。 292 | これらはGoにおける値の比較を実装していますが、値のサイズと厳密な型は無視されます。 293 | よってあらゆる整数値同士や符号なし整数値同士などを比較することができます。 294 | しかしやはり、intとfloat32との比較のようなことはできません。 295 | 296 | Associated templates 297 | 298 | 各テンプレートは生成されるときに指定された文字列の名前が付きます。 299 | また、各テンプレートは名前によって自分が起動した0個以上の他のテンプレートへ関連付けられます。 300 | このような関連付けは推移的であり、テンプレートの名前空間を形成します。 301 | 302 | テンプレートは他の関連付けられたテンプレートを起動することによってインスタンス化することができます。 303 | 前述の"template"アクションの説明を見てください。 304 | 名前は起動を行うテンプレートと関連付けられたテンプレートのものである必要があります。 305 | 306 | Nested template definitions 307 | 308 | テンプレートをパースするとき、他のテンプレートを定義し、パース中のテンプレートと関連付けることができます。 309 | テンプレートの定義はGoのプログラムにおけるグローバル変数のようにテンプレートのトップレベルに存在しなければなりません。 310 | 311 | このような定義の文法は、それぞれのテンプレートの宣言を"define"と"end"で囲みます。 312 | 313 | defineアクションは生成されるテンプレートに文字列定数を使って名前付けをします。 314 | 以下は簡単な例です: 315 | 316 | `{{define "T1"}}ONE{{end}} 317 | {{define "T2"}}TWO{{end}} 318 | {{define "T3"}}{{template "T1"}} {{template "T2"}}{{end}} 319 | {{template "T3"}}` 320 | 321 | これはT1とT2の2つのテンプレートを定義します。 322 | そして3つめのT3は他の2つを実行するものです。 323 | 最後にT3を起動します。 324 | 実行するとこのテンプレートは以下のテキストを生成します。 325 | 326 | ONE TWO 327 | 328 | 組み立てられたテンプレートは1つだけ関連付けに属することができます。 329 | 複数の関連付けから辿れるようにする必要がある場合、テンプレートの定義は個々の*Template型の値を生成するために複数回パースされる必要があります。 330 | あるいは、CloneかAddParseTreeメソッドを使ってコピーされる必要があります。 331 | 332 | パースは関連付けられた個々のテンプレートを組み立てるために複数回実行されます。 333 | ParseFilesとParseGlob関数およびメソッドを参照してください。 334 | これらはファイルに保存された関連するテンプレートをパースするためのシンプルな方法を提供します。 335 | 336 | テンプレートは直接か、名前を指定して関連付けられたテンプレートを実行するExecuteTemplate関数を通して実行されます。 337 | 前述の例を起動するには、以下のように書きます。 338 | 339 | err := tmpl.Execute(os.Stdout, "no data needed") 340 | if err != nil { 341 | log.Fatalf("execution failed: %s", err) 342 | } 343 | 344 | または名前を明示して部分テンプレートを実行します。 345 | 346 | err := tmpl.ExecuteTemplate(os.Stdout, "T2", "no data needed") 347 | if err != nil { 348 | log.Fatalf("execution failed: %s", err) 349 | } 350 | 351 | 本ドキュメントは以下のドキュメントを翻訳しています: https://code.google.com/p/go/source/browse/src/pkg/text/template/doc.go?r=ae48c492cd8d2f2d5c3b728345882a31a085dfcd 352 | */ 353 | package template 354 | --------------------------------------------------------------------------------