2018年5月16日水曜日

タマラ・ド・レンピッカ

Googleのいわゆる生誕の日シリーズでたまたま見たが,
なんだかよくわからないが絵が響いた. それだけ.

2018年5月14日月曜日

現状のvimプラグイン管理方法

基本はgithubを中心とした管理になるが, その方法である.
.vimrc, .gvimrc, .vimディレクトリの3つをどう管理するか, ということである.
.vimrc, .gvimrcについては, gitの通常管理でなんら問題ない. 一方, .vimディレクトリについては, 配下にプラグインディレクトリが存在し, それら自体も, 先人たちが作成したgitリポジトリからのクローンである.
一つの方法としては, パッケージ管理プラグインを導入する方法である. こちらは, パッケージプラグインさえ確実に配置すれば, あとはVim上でupdateや, インストール, アンインストールができる.
しかし, このパッケージ管理プラグインもまた, gitリポジトリからのものなので, 更新がかかるかもしれないし, 個人の作成なので, いつ管理が止まるかわからない. しかも, こういったプラグインを使う場合, 新たなプラグインを導入する際, vimrcに書いたり, 削除する際は消したり, と, vimrcへの依存性が大きくなる. vimrcは, vimの設定であるべきで, その他さまざまなプラグインの設定を書きこむのは美しくない.
そこで, もう一つの案, .vimディレクトリ配下のプラグインたちを, サブモジュールとして, 全体のリポジトリに抱かせてしまうやり方である. ようは, updateやバージョン管理を, gitに統一するということである. VIM上からupdateできないデメリットがあるものの, vimrcに何か書いたりする必要がなくなり, 分離性がよくなる.
この方法の場合, gitに管理負荷がいく分, gitの使いこなしが重要になるが, 個人作成のプラグインよりはいいであろう.

結局, .vimの配下を, サブモジュールとして管理する. 全体のリポジトリをクローンしてきて, .vimrc, .gvimrc, .vimを, ユーザーホームにシンボリックリンクすることで, 現状の運用としている.

SourceTreeは, 既存の配下リポジトリを自動でサブモジュール処理してくれない

既存のフォルダを, SourceTreeでローカルリポジトリ化した際, フォルダ内に, すでに別モジュールとして, リポジトリが存在していた場合,
あたかもちゃんと認識したかのごとく, SourceTree上では, サブモジュールに表示される. 
しかし, サブモジュールとしてただしく処理されるためには, .gitmodulesというファイルが生成されている必要があり, この段階では作成されていないし, ここからファイルを自動で作成する方法もなさそうだ. 
これをそのままコミット, githubなどにpushしても, サブモジュールとして正しく管理されない. 
こういった場合は, 手動で.gitmodulesを作成してやる必要がある. 

[サブモジュール名]
      path = (相対パス)
      url = (リモートリポジトリアドレス)

というフォーマットで書きこんでいく. そうすると, ただしくサブモジュールとして認識される. 
また, サブモジュールを含むリポジトリをクローンする場合は, 詳細オプションにおいて, 
サブモジュールを再帰にチェックを入れると, クローン時に, すべてのサブモジュールを自動でupdateしてくれる. 
もし, これをしなかった場合は, 最初は, ローカルリポジトリが空っぽになる. このときは, SourceTree上で, サブモジュールを開く(ダブルクリック or 右クリックから開く)ことで, リポジトリがupdateされる. 

2018年5月13日日曜日

WindowsのVimはなんだか動きがおかしい

MacVim用に作成したvimrcが, Windows用のVimでうまく動作しない.
カラースキームの指定は, vimrcで動くはずだが, Windows版では, gvimrcに記載しないと反映されない.
また, Windowsの, gvimではなくvimに対し, molokaiを適用すると, 背景が真っ青になり, 太字や, 色の設定がめちゃくちゃになる.
一方で, プラグインの設定は, gvimに書いてしまうと, 起動時に反映されない.
したがって,
MacVim用に一通りの設定を書いたvimrcを用意しつつ,
Windowsで使えるように, molokai設定だけ書いたgvimrcを用意したうえで,
Windowsではgvimを使う, という運用しか今のところなさそうだ.

EclipseのプロジェクトウィザードですべてのToolChainを表示する

Windows環境において, C/C++の開発環境を, Eclipseで準備したとき, 困ったのでメモとして残す.
筆者は, プライベートではMACユーザであるが, 仕事場ではWindowsである. 仕事でのプログラミングで, 家での思いつきを使いたい時もあれば, その逆もある.
そんなとき, ソースの断片だけを共有し, それぞれの開発環境に埋め込むのはめんどくさい.
そこで, Win, Mac, Linuxなど多くの環境に対応した, Eclipseを開発環境として選ぶことが多いのだが, WindowsでのEclipse導入でしばらくはまっていた.
ネットをたたけば, 導入ガイドがいくらでも出てくる, Eclipse + CDT + MinGW.
CDT導入, MinGW導入, パスを通すまではあっさりといく.
しかし, いざEclipseでプロジェクトを起こそうとすると, プロジェクト生成ウィザードにおいて, ToolChainの一覧に, CrossGCCしか出てこない.
Pleadesなどを導入すると最初からMinGWGCCなどが表示されているようだが, 筆者がよく使うプラグインが, Pleadesの日本語プラグインと相性が悪いようで, Pleadesは使っておらず, 筆者はどうしてもそれが出てこなかった.

たまたま, Eclipseをいじっていた際に, 解決策を見つけた.
(Windowsの場合)
Window > Preference > C/C++ > New C/C++ Project Wizard
において, Show only supported toolchains, by default のチェックを外す.
これにより, Wizardにおいて, 大量のツールチェインが出てくる. この中にMinGWGCCもあり, 無事, ビルド, デバッグなどが実行できた.

なお, 筆者の環境は,
Windows7 32bit Professional
Eclipse Oxygen 3
MinGW_w64