TeXlive 2012から2013へアップデート(年をまたいで更新)する on Windows 7 (1:調査編)

お久しぶりでございます。今回は技術的な文章です。

現状

さて、TeXの環境としてWindowsではTeXliveを用いていますが、導入したのは昨年の話。つまり、2012年版なわけです。
最近友人とファイルのやりとりをしていて気がついたのですが、～.logに記述されているTeXのバージョンが違う。もちろん導入時期が違うせいですが、私のほうが古いので、更新をすることにしました。

C:\> tlmgr update --self --all
tlmgr.pl: The TeX Live versions supported by the repository
  (2013--2013)
do not include the version of the local installation
  (2012).
## 訳１：リポジトリのサポートしているTeXのバージョンは(2013--2013)です。
## 訳２：ローカルにインストールされているバージョン(2012)はサポートに含まれていません。

はぁ。左様でございますか。

tlmgrでどうにもできないようなので、検索しました。

調査

上手い検索ワードが見つからないせいなのか、なかなかこのアップデートの記事が出てきません。
とりあえず見つけたのが次のページです。

TeX Live 2013 のインストール
http://www.fugenji.org/~thomas/texlive-guide/install.html

Debianでの記事ですが、Windowsにも共通していそうな部分を要約するとこうです。

• 年をまたいだ更新は、殆ど「新規インストール」と同じ。
• 2012年のパッケージは、texlive関連ディレクトリの2012フォルダ内に全て収まっている。
• 2013年のものをインストールすると同様に収まる。
• つまり2012ディレクトリ内を弄らずに、2013をインストールできる。
• 万が一2013が動かなくても、環境変数PATHを書き換えることで対処できる。

なるほど。ちなみに環境変数については、

set | grep 2012
set path # grepがないとき

で確認できます。Windowsはgrepじゃなかったはずですけど。

とにかく、

• texlive2013の新規インストール
• (必要なら)環境変数の編集

やることはこれだけみたいです。

これは推測ですが、texmf-localは共用です。つまり自分であとから追加したパッケージ等は2013でそのまま使えるはずです。ちゃんとTeXliveの流儀に従っていればということですけど。

次回予告？

次回はちゃんとインストールを実行します。

texwikiのWindowsの項目にどうやらCUIインストールの解説がなくなったようなので、そのあたり補完できればと思っています。むしろGUIでやったことがないだけですけどね。

Gistの貼り付けテスト

……どうやら、文字色が悲惨なことになっているようですね。仕方ありません。

覚え書き。

いくつかソースをクローズドに管理する方法を見つけたのでそれを書き留めておく。
でも基本はGit。

GitLab

自分でサーバーを立てて、そこにGitHub立てるイメージみたい。GitHubのオープンソースクローンらしいね。そういうのもありなのかもしれない。

DropBox + Git

基本は単純にGitするだけ。違いはGitで管理するディレクトリを置く場所。DropBoxに同期されるディレクトリを選んで、そこにリポジトリを作る。
これ、GitHubが提供しているWindows向けのGUIソフトで管理できないかな？　このソフトの使い方がいまいちよくわかってないのが悪いんだけど。

手動管理

明らかに手間。だけど誰でもできるよ。失敗率が高すぎておすすめする気はないよ。
手法はきっといくらでもあるけど、それを敢えて選ぶ理由がないと思うの。

課題(というか、宿題)

これももしかしてgit管理できるのでは？　とか考えたけど、でも普通に使えばいいね。はい。
大規模とかで使いそうだったら、DropBoxに入るためのUbuntuでも作ろうかな？

おなじの。

プログラミングにおいて、ソースコードの綺麗さと保守性・可読性を保つための表記手段として、「適切な字下げ」と「適切なスペーシング」があるわけ。

まず、字下げ。主にブロックを表すのに使う。
例。

#include <stdio.h>

int main(void) {
　　int n;
　　scanf("%d", &n);
　　if (n == 0) {
　　　　printf("nはゼロです。\n");
　　} else {
　　　　printf("nは%dです。\n", n);
　　}

　　return 0;
}

ブロックを表すというのはどういうことか。1段目付近を見ていけば分かるだろう。
・まず、#にぶつかる。　とくに1行で終わるので、なにもない。
・次にint～にぶつかる。行末に始まり括弧がある。
　・この次の行から一段下がっている。ここからが１ブロックだ。
　・対応する終わり括弧を探すのは簡単。だって1段目だけを追っていけばいいから。
こんなふうに、対応が取れるのです。わかるかな？

ところで、この字下げスタイルはK&Rのものに似ているけれどちょっと違う。
K&Rでは、関数の始まりは

int main(void)
{

のように表記する。中括弧を「落とす」。これは歴史的な経緯が関係あるけれど、その辺は割愛。
ではなぜ、これを使わないのか。理由は一つ。「行数削減」だ。
両方の括弧を落としてしまうと、意味のない行が2行できる。対して、始まりを乗せると、今度はこれが1行になる。たかが1行だけれど、それでも50%だ。

また、字下げは一つの疑問を生むことになる。
「長く書く部分なのに、字下げされているとタブの入力が面倒じゃないか」
そのとおりですね。手入力なんてやってられません。
いや、だからといって取り除いてしまうのは良くない。だから、エディタに任せるのだ。最近のエディタは偉いから、Cぐらいなら難なくスマートインデントしてくれるよ。

それと、字下げ幅は趣味がある。2とか4とか8が主流だけれど、中には奇数幅の人だって居るかもしれない。
だから、これもエディタに任せちゃう。tab文字を使うんだ。大体のエディタはtab文字幅を調節できるから、読む人が任意に設定すればいい。

字下げ幅に悩む箇所は、いくつかある。
1. 関数の引数が多く、2行以上になってしまった時、関数本体は何処に書いたらいいのか。
そのまま一段下げにすれば、普段と同じ高さ。でも、すぐ上の引数リストと同じ高さになってしまう。自分は、引数リストの閉じ括弧と本体の始まり括弧を次の行に持ってきてしまう。
2. プリプロセッサ命令。
これらは処理レベルが違う。だから、そういうことを明示するために、あえて字下げなしで書くことが多い。
3. switch文。
caseラベルと実行文は、一段ずらして書くのはおきまりみたいだけれど、caseラベルをどの階層に置くかは好みとエディタ次第かもしれない。
switch（）がある階層と同じにするのも悪くない。一段下げて、結果実行文が二段下がるのも悪くない。

全然スペースが余ってるし、スペーシングの話もしようか。
適切なスペーシングが必要な理由は、言語仕様にも書いてある。以下の一文があったとしよう。

n=x+++++y;

これは、コンパイルエラー。なぜなら：
　・まずトークンが区切られる。左寄せで区切るので、「n = x ++ ++ + y ;」となる。
　・演算子の優先順位に従って、「x++」が処理される。
　・つぎに、その隣の「++」が処理対象になるが、被演算数は「x++」の演算結果、つまりは定数なのでインクリメントできない。よってコンパイルエラー。
さて、ここで以下のようにスペーシングする。

n = x++ + ++y;

これならコンパイルエラーにならない。説明がめんどくさいから、言語仕様を読んで欲しい。

さて、だいじさはわかっただろうか。ここでは一例を紹介する。
関数定義の時、関数名と引数括弧はくっつける。関数本体の中括弧は離す。
カンマの前はつける、後は離す。
制御構文と条件括弧は離す。関数呼び出しでないことを明示するため。
括弧の外側は離す、内側はつける。ただし、キャストの括弧はつける。
間接参照演算子は、変数の前につける。
その他単項演算子は基本的につける。
二項以上の演算子は、演算子と対象を離す。

自分はスペースの量はそこそこだと思うので、好きな人はとにかく離すかもしれない。
あとC++のテンプレートクラスにグローバルスコープ演算子入れた時に、三つ組みで詰んだ人とか。
スペースが少ないコードは、横に詰まって見える。汚いからやめてほしい。

ちなみに、コードをコピペすると、スペーシングでばれてしまうよ。一度本で、一部分だけスペーシングが違うのを見つけてしまって、ああ、コピペしたんだなってすぐ分かったから。

まとめ。綺麗に書くって、すばらしい。

メモ的に。

他人の作ったスタイルファイルをそのまま使ってるのに言うことじゃないんだけれども、まぁ。

二行アキさせると改段、一行アキだと小空白。そんな使い方の方がいいのかも？

ただ改行させるだけだと、どこが段落頭かわからない気もする。これめんどくさいとおもっちゃうんだけれど、仕方ないのかな？

行間は広めでいいね。ちょっと広すぎるぐらい？ 全然問題ない。行間が広い分、原文での一行アキがあまり目立たないのがちょっとだけ。

コード枠と文章との間は結構いいと思う。

test.
#枠内が少し、上下余白が広いかもしれない。

どう？ 問題ないでしょ？

タイトルと見出し(全レベル)の区別が付かない。論文臭く、そこそこに見出し付けしたかったが、やめた。

普通にみやすいと思うし、カラーリングも好きなんだけれど、やっぱり理想100%とは行かないんだよね。世の中だもん。