Main Menu
いらっしゃいませ入口 (Home) 出口 (リンク集) われも工房（同）サイト内全文検索サイト・プロフィール New! RSS 購読 Twilog
オタク系オヤジへの道オタク日記 New! 倉庫 19(Q1, Q2, Q3), 24Q2 倉庫 18(Q1, Q2, Q3, Q4) 倉庫 17(Q1, Q2, Q3, Q4) 倉庫 16(Q1, Q2, Q3, Q4) Mac でハック (1), (2) 自宅サーバを立てる Python Corner
つれづれなるままにわれもかう通信倉庫 13(Q2 Q3) 14Q1 San Diego 通信極私的批評空間倉庫 2002-2010 Lund 通信（遠島日記）
Site Management Access Count Server Status

オタク日記
(Mac と Linux, 2017Q1)

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 を控えておくのを忘れた事に気付いた。ともあれ、上で触れたツールで評価してみる。

Wireless Diagnostics による WiFi 性能評価

問題の Noise は -78 dBm。修理前が、-74±1 dB だったから、約 4 dB の改善……。修理前や別の Mac (MacBook Air, late 2010) と比較してみる概略次の表のとおり。

WiFi モジュールの感度 (Noise Level)
性能項目	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 は以下のように「正しく」レンダリングする。

$$ \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 $$

ところが、Marked 2 によると以下のように、第 1 行目を除いて、正誤が反転してしまう。

Marked 2 によるレンダリング
(Emacs から C-c C-c o)

ちなみに、Multimarkdown でも、同様の結果となる。 (Emacs のmarkdown-mode から Firefox に表示させる。)

Multimarkdown によるレンダリング (Emacs で C-c C-c p)

但し、この場合はソースに以下のように 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. #1) markdown-mode から、Multimarkdown アプリを呼ぶための設定
2. #2) OSX 上のアプリの Marked 2 で、preview するための設定。 (以下で詳述する。)

以上で、基本的な設定は終り。EmacsMac を再起動するか、上の 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' とやるだけで

EmacsMac 上の Markdown ソース

以下のような preview が得られる。

Marked 2 でレンダリングされた Markdown ドキュメント

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 の「グラフ機能」のせいではないかと私は邪推している。何しろ、下図の典型例はこれらの全部をあっさり無視している。（まあ、全部無視しているのを敢えて選んだ、という憾みはあるが…… :-)

MS Excel の典型的なグラフ

Gnuplot から matplotlib へ

今読み返してみて、ちょっと驚いたのだが、5 年も前から matplotlib 対 Gnuplot なんて悩んでいたらしい。尤も、悩みの中心は、「どちらがうまく（簡単に）インストールできるか」だったようだが。ともあれ、そのどちらとも上記の 1. 〜 4. は満足しているが、5. の「circle でプロット」については Gnuplot では難しい——Terminal を eps に設定すれば可能だが、それではリアルタイムで確認できない。

勿論、matplotlib へ完全移行したのは、Django の views からグラフをプロットするにはそれが必須だったからだが、この点 (circle でのプロット) も重要な要素だったと思う。

Jupyter から使う場合でも、matplotlib はお約束で、

Jupyter + matplotlib-1.5.3 によるグラフ

Jupyter + matplotlib-1.5.3 によるヒストグラム

のようなグラフを (然程のオプション付加無しで) 描いてくれる。

matplotlib-2.0 になったら……

なんだかとっても幸せな気分だったが、そういう気分は長くは続かないもののようだ。 PyVenv で常に pip-compile/pip-sync とやって、module を最新に保っているので、或る日 matplotlib が 2.0 になった時も迷わず上げた。いつものとおり、コンパイルやインストールに何の問題も無かった……

が、それによるグラフは問題大有りで、tick の向き、tick label の取り方等、1.5.3 のそれに遠く及ばない……

Jupyter + matplotlib-2.0 によるグラフ

Jupyter + matplotlib-2.0 によるヒストグラム

何だかがっかり。とりわけ旧版の 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] に倣いました。)

(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 Engine にアクセス

どうやらうまくインストールできたようなので、reboot 時に自動で立ち上がるようにしておく。

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) との

Jupyter の処理速度比較
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 のバージョンが固定される

という事のようだ。 (pyvenv-3.5 を含む) python3.5 （現在 3.5.2-2ubuntu0~16.04.1) のバージョンが上がれば、この問題は出なくなると思われるが、それまでは、

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 を試してみたけど、このせいで失敗、ギブアップ！」なんて事が多くないといいのだが。

240/1,788,170

Taka Fukuda

Last modified: 2017-12-19 (Tue) 17:04:24 JST

オタク日記 (Mac と Linux, 2017Q1)

目次