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 -RARG 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}
- main.textがあったとして、.bibファイルはmain.bibにしておく。
- \bibliograph{main}はいじらなくてよろしい
- \usepackage{natbib} --> \usepackge[numbers]{natbib}
- 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
使っていない/止まっているコンテナ、イメージなどの整理
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してしまったとき
git submoduleの自分用メモ書き
git submoduleはほかのレポジトリの「特定コミット」を自分の内部の構成要素にする仕組みで、大きいものを作るときや、各要素が複雑enoughな時に役立つっぽい。
基本の理解
- submodule内のレポと本体のレポは別物
- 本体としてはsubmoduleのコミット番号のみを記憶している
- submoduleを直接修正pushしてらsubmoduleのレポだけが更新されるが、本体は何の更新も見えない
- submodule更新してから、submoduleのディレクトリの外でgit submodule updateすると、本体レポの記憶しているコミット番号が更新される
これ良かったね
基本コマンド
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を入れた後は、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をインストール、常駐してもらったうえで、それと通信するような感じに使う必要があります
どうやってやるか
もうずいぶんまえのことで忘れてしまったけども。
に書いてあるようなやりかたでできます。
- まず、WSL上のUbuntuにapt-getでdockerを入れます。これはクライアント(?)になります。
- 次に、windows上でdockerアプリをインストールします。多分、これはPowerShellとかでそのまま使うことを想定している。
- 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)