オタク日記
(Mac と Linux, 2017Q1)
目次
2017-03-11 (Sat): Apple さん、お願いしますよ2017-02-25 (Sat): ReST より Markdown (その 2)
2017-02-11 (Sat): ReST より Markdown (その 1)
2017-01-28 (Sat): Matplotlib よ、お前もかっ!
2017-01-21 (Sat): Jupyter Notebook (その 5) ——宅外サーバで Jupyter
2017-01-07 (Sat): Jupyter Notebook (その 4) ——PyVenv on Ubuntu
古い日記:
2016Q4
2016Q3
2016Q2
2016Q1
2015Q4
2015Q3
2015Q2
2015Q1
2014Q4
2014Q3
2014Q2
2014Q1
2013Q4
2013Q3
2013Q2
2013Q1
2012 年
2011 年
2010 年
2009 年
2008 年
2007 年
2006 年
2005 年
2004 年
2003 年
2002 年
2001 年
2017-03-11 (Sat): Apple さん、お願いしますよ
Mac + Wireshark は使えるツールになった
またぞろ WiFi のパケット解析を初めた。三年前に MacOS で動かせ初めた頃は、XQuartz に依存していた事もあり、とにかく不安定で、 しかも、なかなか 802.11 レベルのフレームキャプチャができなかった。 本格的に使い始めた二年前は、主目的が WiFi リンクの解析という事もあって、802.11 フレームをキャプチャする事が必須だったが、意外にも Mac の AirPort (要は Mac 内蔵の WiFi モジュール) が Monitor mode をサポートしている事が分り、なんとか仕事の格好をつける事ができた。 (一番悩んだのは、Wireshark から、AirPort を Monitor mode にするあたりだった :-)なので、今回また Wireshark のお世話になる羽目になって、相当身構えたが、 今やそのあたりも様変りで、
- Wireshark が、2.x.x になり XQuartz に依存しなくなって、 起動やその後の動作がキビキビしている。 (かつては、起動にあんまり時間がかかるので、「使えねぇ」と諦めた事があったが。)
- また、かつては測定チャネル (?) を、Monitor mode にするのに悩まされたものだが、 今や何と、アプリを起動した最初の画面で、チャネルを選ぶ際に、Monitor mode のチェックボックスが出てくる。 最初これに気がつかなくて、小一時間ウロウロした。 「あまりに大きくて目に入らなかった」らしい :-)
- おまけに、なんと、その Monitor mode (sniff mode?) の時の使用チャネルまで GUI で指定できる……
Mac-mini の WiFi が不調
その結果、現在のプラットフォーム (Falcon: Mac-mini) は、メモリが 16 GB も載っている事もあり、大変快適に使えていたが、ある頃から、 キャプチャしたパケットの FCS (Frame Check Sequence) に失敗する確率が上がってきた。 酷い時には、QoS データフレームは全滅ということさえ。 最初は被試験機のどちらかだろうと疑ったが、しかし、 それらが FCS の生成やチェックに失敗しているなら、 「対話」は成り立たない筈なので、これはやはり sniff している Falcon に問題が有るのだろう。そのうち、自宅の AP にさえ接続できなくなり、「これはおかしい」となって、 よく調べてみると、Falcon の WiFi モジュールの受信機のノイズレベルが、 -73 〜 -75 dBm などという情け無い値になっている。しかも、これは 2.4 G帯のみで、 5 G バンドは、-92 dBm という素晴しい値を安定して出している。
これはもう、WiFi モジュールの劣化に違いない。
アップルさんお願いしますよ……一回目
Apple のサポートセンターに電話してみると、意外にあっさり継がって、 元気の良い女性の声が応えてくれた。幸先良さそう…… が、なかなか話が通じない。くいつきが良いだろうと思って、「2.4 G だけ、AP に接続できないんです」で始めたのがまずかったみたいで、 2.4 G 帯が継がりにくくなるケースについて延々とレクチャーしてくれ、 私が「いや、そうではなくて、感度が……」と説明しても、 一向に聞いてくれない。そのうち、「動作を確認するから、 そちらのマックに接続させて欲しい」と言い出した。ちょっと迷ったが、 この際だし、Apple Support がどのような「検査」をするのか興味が有ったので、合意。 でも、まあ、やる事は、私がとっくにやった事ばかり……中断を挟んで延々 2 時間も付き合わされたあげく、 結局 2.4G 側だけどうもおかしいというこちらのクレームに納得して頂いた。 ただ、「Noise Level が……」という私のクレームはあっさりスルーされて、 「何度やっても、我が家の AP の 2.4G 側には接続できない」 という事を目の前でやってみせる事で漸く納得して頂けたよう。 徒労感は有ったが、とりあえず、 修理してくださるようなので、引き取り修理に合意した。
翌日(土曜日)、ヤマト運輸の人が引き取りに来てくれた。(ケーブル他を全部外して、 本体をホイ、と渡すだけ。二度目だけどちょっと感心。)
しかも、何と、月曜日の午前中には戻ってきた! さすが、アップル・ヤマトの連携プレイ、機敏だ……と感動しかけたのだが、 開梱して修理レポートを読んでみると、「クレームは再現できず、 他にどのような異常み見付からなかった。ただ Fusion Drive に不具合が見付かったので、再フォーマットしときました」だと。 前半はともかく、後半には目を剥いた……つまり、 電話の御嬢さんに縷々説明した事はあっさり無視されて、通り一遍の AP への接続を試して問題なかった、だけど、HDD は全部消しときました、って事。
アップルさんお願いしますよ……2 回目
なんともむかっ腹が立つが、自分の所にしかバックアップは無い訣で、 泣く泣くでも、復旧しないと仕方がない。Time Machine は使い始めた頃、「HDD が一杯になったので古いのを消します」 と言ったきり、ウンともスンとも言わなくなった事があり、不信感が拭えない。 だから、リカバリーを始めたものの、やってる間中宣戦恐々、しかも、 サポセンのお兄さんがデータを消してしまった事を呪いながら、 なので中々他の事が手につかずに困った。
それでも、開始してから 3 時間過ぎる頃には、Progress Bar の残りが、1-2 mm になり、 「あと 33 分」との表示になって、 「おお、なんとか無事終りそうだな」と安心しかけた所で、異変が……。 Progress Bar は後退はしないものの、「残り時間 (remianing time)」 がどんどん増え始めたのだった。30 分くらい様子を見ているうちに、 残り時間が、10 時間を超えた。
少々怖くなって、またアップルさんに電話。 「先週金曜日に対応してくれた○○さんをお願いします」から始めたのだけど、 別の部署なのでそれはできない……などから始まって、 また延々とやりとりが有ったのだけど、結局
- リカバリーの際の Progress Bar も ETA (remaining time) もアテにならないので、それらは無視してとにかく待ってみて欲しい。
- 再度修理を受け付けるが、その際、サポセンから「とにかく WiFi モジュールを交換する」事を修理の担当に「強制」する。
- 「その際、HDD の再フォーマット(初期化)はやらないで欲しい」 は交渉はしたものの、修理担当からは「保証しかねる」との回答だった。
肝心のリカバリーの方は、電話が終る頃には、残り 30 時間になっていた :-(. その後 6 日間まで伸びた Y^_^; ところで、運を天に任せて放置しおいたところ、 約 2 時間後には、起動音が鳴って、リカバリーが完了していた。ホッ。
途中、「あなたの修理要求はキャンセルされました」 とのメールが来るという御愛嬌 (ホントはもう怒り心頭 :-) もあったりしたが、二日後に約束通りヤマト運輸さんが受け取りに来て、 さらに二日後、戻って来た。
すったもんだの結果……
ようやく修理もなって?帰ってきた愛機を怖々、Turn On。 どうやら、初期化は免れたようで、プロンプトが出てきた。はてさて、WiFi モジュールはどうなったかいな……と、ここで、MAC Address を控えておくのを忘れた事に気付いた。 ともあれ、上で触れたツールで評価してみる。
問題の Noise は -78 dBm。修理前が、-74±1 dB だったから、約 4 dB の改善……。修理前や別の Mac (MacBook Air, late 2010) と比較してみる概略次の表のとおり。
性能項目 | Mac-mini 修理前 | Mac-mini 修理後 | MacBook Air |
---|---|---|---|
Network Name | Kohei-AP | Kohei-AP | Kohei-AP |
Active PHY mode | 802.11n | 802.11n | 802.11n |
RSSI | -54 dBm | -56 dBm | -50 dBm |
Noise | -74±1 dBm | -78±1 dBm | -86±1 dBm |
Channel | 6 | 6 | 6 |
Channel Width | 20 MHz | 20 MHz | 20 MHz |
うーむ、修理前はもとより、修理後でも (7 年近くも型落ちの) MBA に遥かに及ばない。一方で、5 GHz バンドの 11n で比較すると、Mac-mini (-93 dBm) は、MBA (-89 dBm) を凌いでいるんだけどなぁ。 どう考えても、周波数が高くて、バンド幅が広い 5G の方が厳しい筈なんだが…… Mac-mini が 11ac 対応になって、2.4G バンドは「目じゃなく」なったのだろうか?
2017-02-25 (Sat): ReST より Markdown (その 2)
新しくおつきあいを始めた会社が.md
ファイルでも技術資料を提出して下さるようになったので、EmacsMac.app
の markdown-mode
と Marked2.app を日常的に使うようになった。
……となると「何だかなぁ」も見えてくるのが世の習い……
MathJax による数式表示
AMS-LaTeX の デリミタ ("delimiter") の、 しかもそのエスケープの問題なので、 まあ些細というか Otacky な問題と言えば言えるのだが、 たまたま最初にぶち当った上に、なかなか解消しないので……
事はどうやらデリミタ修飾子 (?)
(left, right, bigl, bigr,
etc.) の後につけるデリミタのエスケープの扱いの問題らしい。
なので、下のような「ソース」を作って比較してみる。
$$ \iint_{\Omega} \left( \frac{\partial u}{\partial x} \frac{\partial v}{\partial x} + \frac{\partial u}{\partial y} \frac{\partial v}{\partial y} \right) dxdy = 0 $$ $$ \iint_{\Omega} \left\( \frac{\partial u}{\partial x} \frac{\partial v}{\partial x} + \frac{\partial u}{\partial y} \frac{\partial v}{\partial y} \right\) dxdy = 0 $$ $$ \iint_{\Omega} \left\{ \frac{\partial u}{\partial x} \frac{\partial v}{\partial x} + \frac{\partial u}{\partial y} \frac{\partial v}{\partial y} \right\} dxdy = 0 $$ $$ \iint_{\Omega} \left\\{ \frac{\partial u}{\partial x} \frac{\partial v}{\partial x} + \frac{\partial u}{\partial y} \frac{\partial v}{\partial y} \right\\} dxdy = 0 $$もちろん
\left(
や \left\{
が正解、
つまり 1 行目と 3 行目 が正しい。
これを MathJax は以下のように「正しく」レンダリングする。
ところが、Marked 2 によると以下のように、第 1 行目を除いて、 正誤が反転してしまう。
ちなみに、Multimarkdown でも、同様の結果となる。 (Emacs のmarkdown-mode
から Firefox に表示させる。)
但し、この場合はソースに以下のように HTML header:
ディレクティブ?を付けた。
HTML header: <script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS_HTML"> </script> $$ \iint_{\Omega} \left( \frac{\partial u}{\partial x} \frac{\partial v}{\partial x} + \frac{\partial u}{\partial y} \frac{\partial v}{\partial y} \right) dxdy = 0 $$ .....これらの結果から想像するに、Marked 2 も Multimarkdown も、html に変換する際に「デリミタの後の
'/'
を一つ取る」という (間違った) 操作をしているに違いない。
これは困ったなあ…… .md をファイルを書くに当っては、
数式のチェックって最も頻繁にやるもんだし。
当面は「エスケープの必要ない括弧 ('('
)
だけを使う」で凌げるだろうけど、これ以外にバグが有ったら嫌だな。
Newline Code でも躓く
上の問題も気にはなるけど、当面の仕事 (数式はあまり出てこない) には然程の差し支えがないので、Marked 2 を使い続けていた。 しかし、頂いた資料を読んでいる内は気がつかなかったが、 いざ自分で書く段になるといきなり大問題が……newline
code
が hard linebreak として解釈される——つまり"fill paragraph"
してくれない……。最初に問題に気付いたのが日本語の入ったソースだった事や、
Emacs の file-coding-system
の自動補正の機能もからんで、殆んど「わけわか」になっていたが、どうやら各
OS の
newline
('\n' (utf-8-unix), '\r\n' (utf-8-dos), '\r' (utf-8-mac)
)
のうち '\r\n'
だけが soft linebreak
と解釈される、という事らしい。
かつて coding system については、散々悩んだあげく、何でも
(.html
でも、.py
でも……)UTF-8 に統一し、
かつ、newline
は '\n'
に統一する事で、
これまで一応の収束を見てきたのに、
今頃になってこんなアプリに付き当るとは……
今さら、Marked 2 に食わす時だけ utf-8-dos
にする、
なんてのも情け無いし、その上、日本語が入っていると「行の間隔がばらつく」
という問題まで見つかり、すっかり嫌気がさしてきた。
Multimarkdown
一方で、Multimarkdown の方はそんな問題は皆無である上、 上述のように、HTML Headers:
に必要なスクリプトを指定する事で、MathJax
によるレンダリングも自動でできるようになった。
(markdown-preview-mode
がうまく行かないと悩んでいたが、そんなものは使わずに、
「ソースの先頭にディレクティブを書く」が正解だった訣。)
なので、当面 Multimarkdown を使っていく事にする。
2017-02-11 (Sat): ReST より Markdown (その 1)
reStructuredText (ReST) に嵌った、というか嵌りそうになった事がある。 文法?なども結構真面目に勉強したが、使ってみる段になると、処理系である Sphinx がなかなかすっきり動いてくれない。 (そもそも、MacPorts で sphinx がうまくインストールできない、という事さえあった。) それでも、Markdown は何だか安直な気がして、何とか ReST でと頑張っていた (ウソです、「それにかこつけて手をこまねいていた」がより近い :-)Jupyter Notebook の Markdown
しかし、Jupyter を使うようになると、これはもう選択の余地がなく、 Markdown になる。最初は抵抗感が有ったが、 しばらく使っていると、なんだかこっち (Markdown) が「あたり前」になってきた。 何より AMS-LaTeX が事もなげに解釈されるのに感動した。こうなると EmacsMac でも使えるようにして、 ジャーナルから日記まで、何でもかんでも Markdown にしてしまいたい、というオタク心が……
Emacs で Markdown
等と力むまでもなく、markdown パッケージ (markdown-mode) はとうの昔にインストールしてあった——package package のおかげで、やたらインストールしっぱなしの package が増える :-) なので、 私の場合はむしろ余計なもの (markdown-preview-mode とか、markdown-preview-eww, flymd, markdown-mode+ 等) をアンインストールするところから始めた :-)- Multimarkdown をインストール
$$$ fukuda@falcon:~% sudo port install multimarkdown fukuda@falcon:~% sudo port installed multimarkdown The following ports are currently installed: multimarkdown @4.5_0 (active)
- EmacsMac 上で package-mode を使って、markdown-mode をインストール。
-
init.el
に(setq markdown-command "multimarkdown") #1) (setq markdown-open-command "marked2") #2)
- #1) markdown-mode から、Multimarkdown アプリを呼ぶための設定
- #2) OSX 上のアプリの Marked 2 で、preview するための設定。 (以下で詳述する。)
init.el
に加えた lisp-code を eval-region すると、markdown-mode
が使えるようになる。
つまり、M-x markdown-mode
とするか、.md
もしくは .markdown
の拡張子を持ったファイルを読み込むと、
markdown-mode に入る。
このモード内で、以下のようなコマンドを入力すると、様々な出力が得られる。
- 'C-c C-c m' ('markdown-other-window'): 別の (Emacs の) バッファに HTML file が出力され、それが別のウィンドウに表示される。
- 'C-c C-c p' ('markdown-preview'): ディフォルトファイルに、HTML ファイルが出力され、それが (ディフォルトの) ブラウザに表示される。
- 'C-c C-c l' ('markdown-live-preview-mode'): (Emacs の) eww-mode ウィンドウに変換結果が表示される。
- 'C-c C-c o' ('markdown-open'):
上記の設定で、markdown-open-command
で定義されたコマンド (アプリケイション) で、表示される。
.md
ファイルを改変してセーブする毎に、表示が改訂されるので大変便利。
Markdown-preview-mode から Marked 2 へ
以上で一応機能は揃っているが、Web ページの見栄えをコントロールしたり、 数式を表示するには、.html
に <script>
や
<style>
を入れる必要があるが、それには
markdown-preview-mode が必要なように見える。
しかし、何故かこれがうまく動いてくれない。
特に、markdown-preview-javascript
の設定がエラーで弾かれてしまい、
そのためか肝心の AMS-LaTeX のレンダリングをやってくれない。
(正確には、一旦は、数式が見えるのだが、
それが直ぐに消えてしまう。) これでは、お話にならない。
少々がっかりしていたが、
markdown-mode の Info に、markdown-output-command
の候補として、
Marked 2
が挙げられていたので、同サイトの "Free Trial"
版をダウンロードして、試してみた。
PATH の通ったディレクトリに、
#!/bin/bash # marked2 if [ "$1" ]; then open -a "Marked 2" "$1"; else open -a "Marked 2"; fi等としておいて
その結果は素晴しい!の一言。上記の markdown-output-command
の設定しておけば、
.md
ファイルを開いたバッファの中で、'C-c C-c o' とやるだけで
2017-01-28 (Sat): Matplotlib、お前もかっ!
理工系のグラフはかくあるべし
高専・大学で教わった事のうち今でも憶えていて、 かつ今でも「成程」と思える事は多くはないが、 その中の一つに「グラフの描き方」が有る。要するに、原則として- プロットする範囲は実線で囲む。
- tick はその実線の枠の内側に、tick value (目盛値) は tick に対応する箇所に書く。
- X/Y 軸の両端にも tick value をつける。
- y 軸のラベルは、横書を 90 度回転したもの。
- 理論値、計算値は太い実線で、
- データポイントは、(中抜きの)○ で、
- データポイントに線を追加する場合は、 (データポイントを結ぶ「折れ線」ではなく)「スムージングした曲線」を示す。
- 複数のデータをプロットする場合は、色分けではなく、 マーカーの形や、line style を変える事で識別する。
とはいえ、これらは 40 年前に教わった事「そのまま」ではなく、その後色々な折に「強化」 されてきた記憶かも知れない。というのは、 主立った論文誌(今最新号を確認できるのは Proceeding of the IEEE のみだが) に載っているグラフの殆んどがこれに沿っているから。 つまり、「これらの原則によれば、データや計算結果の傾向が把握し易く、 解釈に曖昧さの少ないグラフが最小限の手間で作れる」という事でもあるのだろう。 (また、個人的には rOtring と (本当の) template や雲形定規 で描くのに適していた、 という事でもあるように思う——実は私この作業が好きで得意でした。:-)
段々乱れてきたのは MS Excel のせい?
ところが、この「良い習慣」が大分乱れてきている。最初は 8. の「マルチカラー禁止」だった。ただ、そもそもこの「きまり」は、 論文誌に多色刷りのページが全く無いか、 有ってもほんの一部という条件から来ているので、 論文誌の多色刷りがあたり前になり、また PDF で発表・配布される例が増え始めると、 これが忘れられ、無視されるのは不思議ではないのかも。 (そもそも、上の例が二色使ってるし :-)
しかし、最近は、1. 〜 7. も怪しくなってきた。 自分ではオーソドックスだと思ってきた Proceeding of the IEEE でさえ、 これらが無視されたグラフが増えてきたように思う。 普段プレゼンテーション等で御目にかかるグラフに至っては、 この良き伝統は絶滅の危機にある……。
これは MS Excel の「グラフ機能」 のせいではないかと私は邪推している。 何しろ、下図の典型例はこれらの全部をあっさり無視している。 (まあ、全部無視しているのを敢えて選んだ、という憾みはあるが…… :-)
Gnuplot から matplotlib へ
今読み返してみて、ちょっと驚いたのだが、5 年も前から matplotlib 対 Gnuplot なんて悩んでいたらしい。尤も、悩みの中心は、 「どちらがうまく(簡単に)インストールできるか」だったようだが。 ともあれ、そのどちらとも上記の 1. 〜 4. は満足しているが、5. の「circle でプロット」については Gnuplot では難しい——Terminal を eps に設定すれば可能だが、それではリアルタイムで確認できない。勿論、matplotlib へ完全移行したのは、Django の views からグラフをプロットするにはそれが必須だったからだが、 この点 (circle でのプロット) も重要な要素だったと思う。
Jupyter から使う場合でも、matplotlib はお約束で、
のようなグラフを (然程のオプション付加無しで) 描いてくれる。matplotlib-2.0 になったら……
なんだかとっても幸せな気分だったが、 そういう気分は長くは続かないもののようだ。 PyVenv で常に pip-compile/pip-sync とやって、module を最新に保っているので、或る日 matplotlib が 2.0 になった時も迷わず上げた。いつものとおり、 コンパイルやインストールに何の問題も無かった……が、それによるグラフは問題大有りで、tick の向き、tick label の取り方等、1.5.3 のそれに遠く及ばない……
何だかがっかり。とりわけ旧版の matplotlib が描くヒストグラムは、ちょっと感動モノだったので、 -2.0 でボーダーを無くしたのはトンデモ!と思ってしまう。
それでも、パラメータの設定で何とかなるのではないか、
と四苦八苦してみたが、ここであんまり頑張るようでは、
ささっと全体の傾向を把握するためのプロット、という主旨に反するし、
その内、plt.show()
で以前のプロットが紛れ込む、
なんていう致命的な不具合が見付かったので、matplotlib
に関しては、-1.5.3 に戻る事にした。
こういう時にも PyVenv は便利で、requirements.in
に、
..... numpy matplotlib==1.5.3 scipy .....という具合に、保持したいバージョン番号を付け加えれば良い。 こうしておいて、pip-compile/pip-sync とやれば、 他のモジュールへの依存性も含めて、きちんと元へ戻してくれるし、 以降も matplotlib だけ 1.5.3 に固定してくれる。
2017-01-21 (Sat): Jupyter Notebook (その 5) ——宅外サーバで Jupyter
数値計算はすぐ重くなる
Python shell でも、iPython でも、込み入った事をやり始めると、 最初にぶつかるのが Regression Test の問題。 長い一連のプロセスを構築していて、途中のプロセスを改変すると、 当然の事ながら、その前のステップから再試行して検証をしなければならないが、 これがすぐにワケワカになる。少々の手間や不便を忍んでも Jupyter に拘るのは、この事が実に簡単にやれるから。 「初めから全部の Cell の処理を走らせる」とか「特定の Cell からそれ以降全部」などというコマンドがあるので、その Notebook にある一連のプロセスの整合性を保つのがコマンド一発で済む訳。 これは感動モノであるが、しかし怠け者の「要求」にはキリがない ……「全部の Cell を……」に 2 分、3 分とかかるようになると、 だんだん不満になってきて、なんとかもうちょっと手っ取り早くならないかなあ、 となる。
で、宅外サーバは、Mac mini より速かったし、殆んどいつも CPU パワーが余っているから……という事で、Jupyter Notebook をそちらで走らせる事にした。
宅外サーバに Jupyter Notebook をインストール
digoc02 の PyVenv, pve35 には、既に numpy, scipy, matplotlib, ipython 等がインストールされているから、新たに requirements.in に、jupyter と pandoc を加えるだけで良い。(pve35) fukuda@digoc02:~/pve35% nano requirements.in (pve35) fukuda@digoc02:~/pve35% pip-compile (pve35) fukuda@digoc02:~/pve35% pip-syncで、ipykernel, jupyter-core, jupyter-client, etc. etc. 等が大量にインストールされる。
ここから、サーバとして使うための設定: ( IP[y] に倣いました。)
- Login password のハッシュ値を算出
(pve35) fukuda@digoc02:~/pve35% ipython Python 3.5.2 (default, Sep 10 2016, 08:21:44) Type "copyright", "credits" or "license" for more information. .... IPython 5.1.0 -a- An enhanced Interactive Python. .... In [1]: from IPython.lib import passwd In [3]: passwd() Enter password: Verify password: Out[3]: 'sha1:389cae953dd6:ce793...'
このハッシュ値 (sha1) を使って - config file (
~/.jupyter/jupyter_notebook_config.py
) を作成する。(pve35) fukuda@digoc02:~/pve35% jupyter notebook --generate-config
- できた config file を編集して次の行を uncomment もしくは変更:
c.IPKernelApp.pylab = 'inline' c.NotebookApp.ip = '*' c.NotebookApp.open_browser = False c.NotebookApp.port = 8888 c.NotebookApp.password = u'sha1:389cae953dd6:ce793...'
最後の行の sha1 は、先程作ったハッシュ値。 - (もしまだならば) .pystartup を編集し、
お約束のモジュールを import するように設定、かつ ufw
でテスト用の port を開く
(pve35) fukuda@digoc02:~/pve35% cat ~/.pystartup import numpy as np import scipy as sp import matplotlib.pyplot as plt (pve35) fukuda@digoc02:~/pve35% sudo ufw allow 8888/tcp (pve35) fukuda@digoc02:~/pve35% sudo ufw status [sudo] password for fukuda: Status: active To Action From -- ------ ---- Apache Full ALLOW Anywhere Postfix ALLOW Anywhere Postfix Submission ALLOW Anywhere OpenSSH LIMIT Anywhere Dovecot Secure IMAP ALLOW Anywhere 8888/tcp ALLOW Anywhere
- ここまでやってから、
(pve35) fukuda@digoc02:~/pve35% jupyter notebook &!
として jupyter notebook を起動し、 - 手許の browser から、宅外サーバの <http://otacky.jp:8888> 動作を確認する。
Jupyter Notebook を daemon に
我が宅外サーバ (digoc02.otacky.jp) は、Ubuntu-16.04LTS なので、systemd のサービスにする。
まず以下のような jupyter.service
という init script
を書く。
# jupyter.service [Unit] Description=Jupyter Notebook [Service] Type=simple PIDFile=/run/jupyter.pid ExecStart=/home/fukuda/pve35/bin/jupyter-notebook --config=/home/fukuda/.jupyter/jupyter_notebook_config.py User=fukuda Group=fukuda WorkingDirectory=/home/fukuda/pve35/Notebooks/ Restart=always RestartSec=10 #KillMode=mixed [Install] WantedBy=multi-user.targetこれを、
/lib/systemd/system
の下に置いて、
(pve35) fukuda@digoc02:~% sudo systemctl enable jupyter.service (pve35) fukuda@digoc02:~% sudo systemctl start jupyter.service (pve35) fukuda@digoc02:~% sudo systemctl status jupyter.service ● jupyter.service - Jupyter Notebook Loaded: loaded (/lib/systemd/system/jupyter.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2017-01-22 10:36:21 JST; 42min ago Main PID: 23181 (jupyter-noteboo) CGroup: /system.slice/jupyter.service ├─23181 /home/fukuda/pve35/bin/python3.5 /home/fukuda/pve35/bin/jupyter-noteb ook --config=/home/fukuda/.jupyter/jupyter_notebook_config.py └─23235 /home/fukuda/pve35/bin/python3.5 -m ipykernel -f /home/fukuda/.local/ share/jupyter/runtime/kernel-6514f171-5f9a-4489-9063-36702a33f634.json Jan 22 10:38:16 digoc02 jupyter-notebook[23181]: [I 10:38:16.793 NotebookApp] 302 GET /t ree? (116.58.186.101) 1.71ms .....のようにしてスタートさせる。 以降はリブートしたら自動で立ち上がるようになる。
スピードテスト
この何ヶ月かごそごそ弄っている Notebook が [Cell] → [Run All] をやるのに 3 分近くもかかるようになった、というのが、 この四苦八苦のきっかけになったので、 それを使ってスピードテストをやってみた。 普段使っている Falcon (Mac-mini) と Hawk (MacBook Air) とのSystem | OS | 所要時間 (分:秒) | fft2 *1) (ms) |
---|---|---|---|
digoc02 (Xeon, E5-2630L) | Ubuntu-16.04LTS | 06:02 | 87.6 |
Falcon (Mac-mini) | OSX 10.10.5 | 02:44 | 69.4 |
Hawk (MacBook Air) | OSX 10.9.5 | 10:03 | 222 |
ここに、
-
*1) 演算速度の目安として Numpy の 二次元 fft (fft2) を使った
(pve35) fukuda@digoc02:~/pve35% ipython Python 3.5.2 (default, Nov 17 2016, 17:05:23) ..... In [1]: A = np.random.rand(1024, 1024) In [2]: %timeit C = np.fft.fft2(A) 10 loops, best of 3: 87.6 ms per loop
まとめ
余っている宅外サーバの CPU パワーを活用しようと始めた企みだったが、 残念ながら常用している Falcon (Mac-mini) の半分以下のスピードしか出ない事が判明—— Numpy の fft2 では、20% くらいしか違わないのに……。常用する気にはなれないので、「自作ノートブックの公開用」にでも使うか。
2017-01-07 (Sat): Jupyter Notebook (その 4) ——PyVenv on Ubuntu
PyVenv は素晴しい!
最近は iPython とその上の Jupyter、また Django の上の各アプリも PyVenv (Python Virtual Environment) の上で走らせる事にしている。 最初はかなり戸惑ったが、一旦要領が解ってしまうと、 しみじみ「これは素晴しい仕組」だと思う。お陰で、OSX 10.10.5, OSX 10.9.5, Ubuntu-16.04 LTS の上で、Django や Jupyter が compatibility の心配なく動いてくれる上に、piptools (pip-compile/pip-sync) で手間暇かけずに環境を構築・更新・維持できる……いい事ずくめ、なのだが、宅外サーバでは Django で公開しているアプリケーションがあるので、(過去のトラブルの経験からして) PyPI のアップグレードをいつもいきなり行うのはちょっと危い気がする。 そこで、VMware Fusion 上の Ubuntu-16.04LTS に同じ環境を作って、 そこで事前に確認、なんてことをやっている。 これまでは、その事前確認で問題は出なかったが、 その試験用サーバに iPython をインストールしようとしたら、 いきなり躓いてしまった。 iPython が要求するモジュールを pip-sync がビルドしている間に、 ImportError となる。 一方で、宅外サーバには同じ事をやっても何ら問題がない……。
PyVenv on Ubuntu-16.04LTS
実稼働している宅外サーバで問題が無いのだから、 「実害」はないにしても、同じ Ubuntu-16.04 で動作が違うってのが、 どうも嫌な感じがしたので、ちょっと真面目に調べてみる事にした。 まずは新たな環境 (pvetmp) を作って、問題を再現させてみる。fukuda@xenail:~% pyvenv-3.5 pvetmp fukuda@xenail:~% cd pvetmp fukuda@xenail:~/pvetmp% . bin/activate (pvetmp) fukuda@xenail:~/pvetmp% pip install pip-tools (pvetmp) fukuda@xenail:~/pvetmp% pip list click (6.7) first (2.0.1) pip (8.1.1) pip-tools (1.8.0) pkg-resources (0.0.0) setuptools (20.7.0) # Note! six (1.10.0)ここで、ipython だけインストールする
requiments.in
を作り
(pvetmp) fukuda@xenail:~/pvetmp% cat requirements.in ipython (pvetmp) fukuda@xenail:~/pvetmp% pip-compile # # This file is autogenerated by pip-compile # To update, run: # # pip-compile --output-file requirements.txt requirements.in # decorator==4.0.10 # via ipython, traitlets ipython-genutils==0.1.0 # via traitlets ipython==5.1.0 pexpect==4.2.1 # via ipython pickleshare==0.7.4 # via ipython prompt-toolkit==1.0.9 # via ipython ptyprocess==0.5.1 # via pexpect pygments==2.1.3 # via ipython simplegeneric==0.8.1 # via ipython six==1.10.0 # via prompt-toolkit, traitlets traitlets==4.3.1 # via ipython wcwidth==0.1.7 # via prompt-toolkit # The following packages are considered to be unsafe in a requirements file: # setuptools # via ipython #1) (pvetmp) fukuda@xenail:~/pvetmp% pip-sync Collecting simplegeneric==0.8.1 Using cached simplegeneric-0.8.1.zip Could not import setuptools which is required to install from a source distribution. Traceback (most recent call last): ..... ImportError: No module named 'pkg_resources' Traceback (most recent call last): ..... (pvetmp) fukuda@xenail:~/pvetmp% pip install setuptools --upgrade Collecting setuptools Using cached setuptools-32.3.1-py2.py3-none-any.whl Installing collected packages: setuptools Found existing installation: setuptools 20.7.0 Uninstalling setuptools-20.7.0: Successfully uninstalled setuptools-20.7.0 Successfully installed setuptools-32.3.1 (pvetmp) fukuda@xenail:~/pvetmp% pip-sync Collecting decorator==4.0.10 Using cached decorator-4.0.10-py2.py3-none-any.whl ..... Successfully installed decorator-4.0.10 ipython-5.1.0 ipython-genutils-0.1.0 \ pexpect-4.2.1 pickleshare-0.7.4 prompt-toolkit-1.0.9 ptyprocess-0.5.1 \ pygments-2.1.3 simplegeneric-0.8.1 traitlets-4.3.1 wcwidth-0.1.7要は、
- setuptools (20.7.0) では、simplegeneric-0.8.1 の build に失敗する。
- それより古いバージョン (20.6.7) でも、最新バージョン (32.2.1) でも OK
- pip のみを最新バージョンにしてもダメ。この場合は、pip-compile の時点で問題が出る
- pyvenv-3.5 がインストールする setuptools が、
どこかの時点で、20.6.7 から 20.7.0 に変わった。
これが、
digos02.otacky.jp
で問題ないのに、xenial.otacky.us
(Fusion 上の「試験用サーバ」) ではエラーになる原因。 - また、pip-compile は、管理するモジュール群 (つまり
requirements.in
のエントリ) に、iPython が入ると、setuptools を pip-compile/sync による自動アップグレードから外す (上記リストの #1))。 このせいで、iPython をインストールした時点から、setuptools のバージョンが固定される
fukuda@xenial:~% pyvenv-3.5 pvetmp fukuda@xenial:~% cd pvetmp fukuda@xenial:~/pvetmp% . bin/activate (pvetmp) fukuda@xenial:~/pvetmp% ls bin/ include/ lib/ lib64@ pyvenv.cfg share/ (pvetmp) fukuda@xenial:~/pvetmp% pip install pip --upgrade (pvetmp) fukuda@xenial:~/pvetmp% pip install pip-tools (pvetmp) fukuda@xenial:~/pvetmp% pip install setuptools --upgradeのように、通常の PyVenv の構築の後に setuptools をバージョンアップしてから、 pip-tools による環境構築を始めれば良い。 (既存の PyVenv が有るなら、それに iPython をインストールする前に、setuptools をアップグレードする。)
それにしても、simplegeneric のパッケージングのせいかのか、 それとも、それに対する pip-compile の弥縫策が不味かったのか、 はたまた、Ubuntu のパッケージングミスのせいなのかよく分らないけど、 ちょっと残念な経緯だった。Ubuntu のユーザが「Jupyter Notebook を試してみたけど、このせいで失敗、ギブアップ!」なんて事が多くないといいのだが。
26/1,792,081 Taka Fukuda Last modified: 2017-12-19 (Tue) 17:04:24 JST