タイトルの通りです。やることは少ない。そして適当。
一時利用
一時利用するだけなら、以下のコマンドで動きます。
# Cygwinのインストールされた場所のバイナリにパスを通す。 C:\> set PATH=c:\cygwin\bin;%PATH% # 日本語メッセージを表示させる。 C:\> set LANG=ja_JP.UTF-8
タイトルの通りです。やることは少ない。そして適当。
一時利用するだけなら、以下のコマンドで動きます。
# Cygwinのインストールされた場所のバイナリにパスを通す。 C:\> set PATH=c:\cygwin\bin;%PATH% # 日本語メッセージを表示させる。 C:\> set LANG=ja_JP.UTF-8
お久しぶりでございます。今回は技術的な文章です。
さて、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). ## 訳1:リポジトリのサポートしているTeXのバージョンは(2013--2013)です。 ## 訳2:ローカルにインストールされているバージョン(2012)はサポートに含まれていません。
はぁ。左様でございますか。
tlmgrでどうにもできないようなので、検索しました。
上手い検索ワードが見つからないせいなのか、なかなかこのアップデートの記事が出てきません。
とりあえず見つけたのが次のページです。
TeX Live 2013 のインストール
http://www.fugenji.org/~thomas/texlive-guide/install.html
Debianでの記事ですが、Windowsにも共通していそうな部分を要約するとこうです。
なるほど。ちなみに環境変数については、
set | grep 2012 set path # grepがないとき
で確認できます。Windowsはgrepじゃなかったはずですけど。
とにかく、
やることはこれだけみたいです。
これは推測ですが、texmf-localは共用です。つまり自分であとから追加したパッケージ等は2013でそのまま使えるはずです。ちゃんとTeXliveの流儀に従っていればということですけど。
……どうやら、文字色が悲惨なことになっているようですね。仕方ありません。
いくつかソースをクローズドに管理する方法を見つけたのでそれを書き留めておく。
でも基本はGit。
自分でサーバーを立てて、そこにGitHub立てるイメージみたい。GitHubのオープンソースクローンらしいね。そういうのもありなのかもしれない。
基本は単純にGitするだけ。違いはGitで管理するディレクトリを置く場所。DropBoxに同期されるディレクトリを選んで、そこにリポジトリを作る。
これ、GitHubが提供しているWindows向けのGUIソフトで管理できないかな? このソフトの使い方がいまいちよくわかってないのが悪いんだけど。
明らかに手間。だけど誰でもできるよ。失敗率が高すぎておすすめする気はないよ。
手法はきっといくらでもあるけど、それを敢えて選ぶ理由がないと思うの。
プログラミングにおいて、ソースコードの綺麗さと保守性・可読性を保つための表記手段として、「適切な字下げ」と「適切なスペーシング」があるわけ。
まず、字下げ。主にブロックを表すのに使う。
例。
#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ブロックだ。
・対応する終わり括弧を探すのは簡単。だって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++のテンプレートクラスにグローバルスコープ演算子入れた時に、三つ組みで詰んだ人とか。
スペースが少ないコードは、横に詰まって見える。汚いからやめてほしい。
ちなみに、コードをコピペすると、スペーシングでばれてしまうよ。一度本で、一部分だけスペーシングが違うのを見つけてしまって、ああ、コピペしたんだなってすぐ分かったから。
まとめ。綺麗に書くって、すばらしい。