2019-02-04

natbib on arxiv...

ご無沙汰しています。

すっっっっっっっっっっっっごく久しぶりに論文を投稿したのですが、例によってarXivでのコンパイルエラーで苦しみました。

というか、bibの部分。

Error: Bibliography not compatible with author-year citations.

これ。生成されたbblファイルが、arXivの期待するnatbibスタイルになってない。

My FIx: [numbers]{natbib}

main.textがあったとして、.bibファイルはmain.bibにしておく。
\bibliograph{main}はいじらなくてよろしい
\usepackage{natbib} --> \usepackge[numbers]{natbib}
main.bblファイルも同梱すればいけた。

2018-08-20

dockerの使い方

これも恥ずかしいけど、基本的なところから

イメージを作成する

Dockerfileのあるディレクトリで？

docker build -t [image name] [path to save image?]

ログインしないで、取得したイメージでコンテナを起動、則コマンドを実行する

docker run [image name] [command]

e.g. docker run my_image:latest echo "hello world"

echo "hello world"がコマンド。

取得したイメージでコンテナを起動、bashシェルでログイン

docker run -i -t [image name] /bin/bash

zzshでログインするなら/bin/zsh

コンテナとホストの間でファイルのコピー

docker conainer ps でコンテナのID番号を調べて

docker cp {container ID}:{file path on container} {dir(file?} path on host}

docker cp {file path on host} {container ID}:{dir(file?) path on container}

コンテナにホストのファイルシステムをマウント

Docker imageなどの管理系

作成したdocker imageをprivateなレジストリに置くためにタグをつける

docker tag {作ったdocker imageの名前} {docker-hostのドメイン}/{リポジトリ名}:{tag}

今のイメージが新しい名前で登録される。

作ったイメージをレポジトリとかにpush

dockerpush {docker-hostのドメイン}/{リポジトリ名}:{tag}

使っていない/止まっているコンテナ、イメージなどの整理

docker system prune

2018-08-17

git(hub)の使い方　自分用メモ（随時修正）

恥ずかしい気もするけど間違えるよりはずっといい。

これもメモしていかないと・・・

レポジトリやブランチをもらってくる系の操作

レポジトリをコピー(clone)してくる

git clone <.git アドレス>

特定のブランチをコピー(clone)してくる

git clone -b <branch name> <.gitアドレス>

ローカルに新しいブランチを作る

現在のブランチのファイル内容そのままで名前だけ変わる

git branch <new branch name>

ローカルで指定のブランチに移る

git checkout <branch name>

ローカルの指定のブランチをremote/originに一致(pull)させる

git checkout <branch name>

git pull origin <branch name>

git pullは実際にはfetchしてmergeするのに似ている。

あえてfetch, mergeと分けたほうがいいこともある。

特に、upstreamなど、origin以外のリモートレポジトリを参照するとき。

あるレポジトリを参照するリモートブランチに追加。upstreamという名前にする

git remote add upstream <repository .git to refer>

自分のmasterを、公式レポのmasterに追従するときとかに使える。（でも、ものとしては公式とは分離しておく、危ないから）

git checkout master # これはローカルのmaster

git fetch upstream master # upstreamの最新masterをダウンロード

git merge upstream/master # upstreamのmasterブランチを、自分のローカルブランチに統合(merge)

リモートレポはいくらでも作れる。

消す系の操作

ローカルの特定ファイルの修正をなかったことにする

git checkout <file name>

ローカルのすべてのファイルの修正をなかったことにする

git checkout .

ローカルで特定のブランチを消す

git branch -D <branch name to be deleted>

HEADとかの操作系

ローカルで開発しているうちにmasterが進んでいたので、masterの先頭から延びたようにする

git checkout master

git pull origin master

git checkout <developing branch>

git rebase origin/master

Headとは、ツリーとは。。。

勉強して自分の理解を記録していく

rebaseしたらコンフリクトしたので修正してrebase続行

git add <fixed file>

git rebase --continue

git rebaseよくわからない！取りやめ！

git rebase --abort

Pull Request

送るとき

rebaseをきれいに実施して、commit logをきれいにしておくといい

受けたとき

てもとで動作させるために、ローカルにリクエストを持ってくる

$ git checkout <pull request URL>

これでやってみて、動くようならいいし、動かないようなら修正してもらう

PRを間違ってmergeしてしまったとき

tweeeety.hateblo.jp

2018-08-09

git submoduleの自分用メモ書き

git submoduleはほかのレポジトリの「特定コミット」を自分の内部の構成要素にする仕組みで、大きいものを作るときや、各要素が複雑enoughな時に役立つっぽい。

基本の理解

submodule内のレポと本体のレポは別物
本体としてはsubmoduleのコミット番号のみを記憶している
submoduleを直接修正pushしてらsubmoduleのレポだけが更新されるが、本体は何の更新も見えない
submodule更新してから、submoduleのディレクトリの外でgit submodule updateすると、本体レポの記憶しているコミット番号が更新される

これ良かったね

Git submodule の基礎 - Qiita

基本コマンド

git submodule update --recursive

これでトラックするsubmoduleのコミット状況を更新かな？

git submodule foreach git pull origin master

foreachコマンドはその名の通り、同じ処理を繰り返し順番にやってくれる。

これでやれるのは各submoduleにおいてpull origin masterをするってこと

git pull origin [specific-commit identifier]

各submoduleのディレクトリにおりて、そこで上記の通常pullを行うと、そのsubmoduleについては特定のコミットを落としてくることができる。

2018-08-08

zsh on Ubuntu on Windows Subsystem for Linux

WSLのデフォルトシェルはバッシュなんですけど、やっぱzsh使いたいよねぇとか、あとWSLならではの設定とかいろいろここ１か月苦労していたので、メモを残しておきましょう。

随時修正ってことで。

zshでしょ

まあ、これは普通にzsh入れればいいんですが、普通にやると、bash on windows起動 --> zsh起動になってうれしくない。

今の私の環境は、Ubuntuのアイコン（ショートカット）がデスクトップとアイコンバーにあって、それをクリックするとzshのターミナルが開く状態です。

どうやるか

普通に考えると.bashrcでまずzsh開くようにすればよい。

if [ -t 1 ]; then
exec zsh
fi

私の場合は、chshを使って/etc/passwdの中身を書き換えています。

参考：

Zsh on Ubuntu on Windows

zshを入れた後は、preztoとかauto-completionとかいれて、

あとはコンソールの見た目を手でいじります。時間入れたりとか。

参考:

prezto:

GitHub - sorin-ionescu/prezto: The configuration framework for Zsh

auto-completion:

GitHub - zsh-users/zsh-autosuggestions: Fish-like autosuggestions for zsh

fzf(超便利):

GitHub - junegunn/fzf: A command-line fuzzy finder

zsh-syntax-hilighting(多分上記をインストールするとenableされてる):

GitHub - zsh-users/zsh-syntax-highlighting: Fish shell like syntax highlighting for Zsh.

Dockerが動かない・・・？

結論から言うと、Ubuntu上でaptとかしてdocker入れても動きません。Windowsネイティブのdocker for windoesをインストール、常駐してもらったうえで、それと通信するような感じに使う必要があります

どうやってやるか

もうずいぶんまえのことで忘れてしまったけども。

qiita.com

に書いてあるようなやりかたでできます。

まず、WSL上のUbuntuにapt-getでdockerを入れます。これはクライアント（？）になります。
次に、windows上でdockerアプリをインストールします。多分、これはPowerShellとかでそのまま使うことを想定している。
docs.docker.com
Docker for windowsが起動すると、タスクトレイに白いクジラさんが出てくるので、右クリックしてsetting --> General --> Expose daemon in tcp://localhost:2375 without TLSをonにする。
ubuntuのdockerがこのポートと通信するように設定する。.bashrcや.zshrcに

export DOCKER_HOST='tcp://0.0.0.0:2375'

を書き足せばOK

SSHが毎回主導でサービス起動しないといけない

Ubuntu上でpython環境とかをpyenvで作っているので、windowsネイティブのエディタ(pycharmとかVS Codeとか)もそのpythonを参照してデバッグとかコンパイルしたいです。pycharmはそのための仕組みとしてremote interpreterがあるんですけど、そのためにはUbuntuがsshd サービスを起動していないといけません。

普通のUbuntuなら何も考えずにサービス起動しっぱなしなんですが、WSLだと普通にやると起動のたびにsshdサービスが止まります。のでめんどい。これを、windowsが起動した瞬間からsshが欲しい。

どうやってやるか(now working)

2018-01-16

Lapack for Torch

ちょっとSVDが必要だったのでtorch.svdをしたら"LAPACKがないよ"と怒られました。

torchの線形代数ライブラリはLapackをラッパしているだけなので、そもそもコンパイル時にLapackがないとだめ。

ということでOpenBLASをインストールする。

git clone https://github.com/xianyi/OpenBLAS.git

cd OpenBLAS

make NO_AFFINITY=1 USE_OPENMP=1

sudo make install

これで/opt/OpenBLASにBLASが入ります。

あとはpathを通す。

export CMAKE_LIBRARY_PATH=/opt/OpenBLAS/include:/opt/OpenBLAS/lib:$CMAKE_LIBRARY_PATH

このパスが正しく通っていればTorchの再コンパイルでLapackが使えるようになっているはず。

2018-01-09

2つのファイルの共通業を抽出するワンライナー

たびたび使うので。

grep -x -i -f file1 file2

以下のQiita記事に書いてありました！