Bag of ML Words

ML = Machine Learning, Music Love, and Miscellaneous things in daily Livings

Dockerfileでsourceを使う。というかbashを使う for installing chainer-cv

Dockerfileの中だとsourceコマンドが使えないというのは良く知られた話のようで、それはDockerfileの中ではシェルがbashではなくてshだから。

 

で、chianer-cvのインストール

Installation Guide — ChainerCV 0.11.0 documentation

のところを見ると、sourceがあるので。

 

結局、以下のようにしたらOKになった。

RUN ["/bin/bash", "-c", "source activate chainercv"]

のところ。

 

RUN git clone git://github.com/pyenv/pyenv.git ./.pyenv
RUN mkdir -p ./.pyenv/versions ./.pyenv/shims
ENV PYENV_ROOT $HOME/.pyenv
ENV PATH $PATH:$HOME/.pyenv/shims:$HOME/.pyenv/bin
RUN chmod 777 $HOME/.pyenv -R

ARG python_version="anaconda3-5.1.0"
RUN pyenv install ${python_version}
RUN pyenv global ${python_version}

# --- Install modules ---
WORKDIR $HOME/
RUN pip install --upgrade pip
RUN pip install numpy scipy
RUN pip install matplotlib
RUN pip install pandas
RUN pip install chainer
RUN pip install tqdm
RUN pip install joblib
RUN git clone https://github.com/chainer/chainer
RUN pip install cupy-cuda92
RUN pip install optuna

# Chainer CV
RUN git clone https://github.com/chainer/chainercv
WORKDIR chainercv
RUN conda env create -f environment.yml
RUN ["/bin/bash", "-c", "source activate chainercv"]
RUN pip install -e .

 

natbib on arxiv...

ご無沙汰しています。

 

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

というか、bibの部分。

 

Error: Bibliography not compatible with author-year citations.

 

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

 

My FIx: [numbers]{natbib}

 

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

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

 

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

 

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については特定のコミットを落としてくることができる。

zsh on Ubuntu on Windows Subsystem for Linux

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

随時修正ってことで。

 

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

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

 

  1. まず、WSL上のUbuntuにapt-getでdockerを入れます。これはクライアント(?)になります。
  2. 次に、windows上でdockerアプリをインストールします。多分、これはPowerShellとかでそのまま使うことを想定している。

    docs.docker.com

  3. Docker for windowsが起動すると、タスクトレイに白いクジラさんが出てくるので、右クリックしてsetting --> General --> Expose daemon in tcp://localhost:2375 without TLSをonにする。
  4. 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があるんですけど、そのためにはUbuntusshd サービスを起動していないといけません。

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

 

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