introは非表示にしないほうがいいよ。
一台だけvimのdeopleteが動かない環境があって、設定か、site-packageか、とか、いろいろ試してみた結果、そもそもvimのバージョンが違ってた。
既にあるテキストを開いてコピペが主な作業なので、introとか邪魔だと思って全環境で非表示にしてました。
最初に疑うべきをバージョンを確認せず、最初に確認すべき:messagesを確認せず、他のところから見ていくという現場猫系手順で、無駄に小一時間費してしまった…。
filezillaのエディター設定をコンソールのvimを呼び出すラッパースクリプトにする。
ここまではググって楽勝。
#!/usr/bin/zsh tilix -e "vim $1"
これでやると制御文字がナマで中出しされるので、こうしないとだめっぽい。
#!/usr/bin/zsh tilix -e "tmux new-window vim $1"
あれやこれや入れ子にしまくると、いつも制御文字系に引っかかる。便利は不便w
Electron and xfce4-notifyd or other notify daemon don’t get along.
Chromium stops short time, when we viewing pornHub and other some cool sites.
How to fix this.
sudo mv /usr/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service /usr/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications_service
Rename file and reboot.
add your i3config this.
exec --no-startup-id dunst
notice: dunstrc on ubuntu
/usr/share/doc/dunst/dunstrc.gz
Have fun!
1000枚程度の画像ファイルをconvertで適当な処理をやる工程をpython3のsubprocessで
単純にforで回して
for file in files: subprocess.Popen([convertへのコマンド], cwd=dir)
みたいな感じをOSXでやると、メモリいっぱいまで食いつぶして気持ちいい爆速処理ができます。仮想8コア100%。CPU稼動率はっぴゃくぱーせんと！ なんだか楽しくなってきます。
そんなに入らないぃぃぃ状態まで食わせるので、当然他の操作は出来ません。ファンがめったにない高速回転になるのが気持ちいい。回転数が下がったら処理が終わりみたいな感じ。
投げっぱなしなので、適当な手段で次の逐次処理に追い越されないようにしないといけませんが、OSXでは処理前ファイルと処理後ファイルの数を比較して、合わなかったら寝てろで止められます。書き出し中のファイルはカウントしないようです。
これをLinuxでやると予定通り、oom_killerに殺されてシステム自体が動作不能になります。
どこでも動く制限付きのマルチスレッドに変更せねば…。
ということで、
「フォルダ1」にtiffファイルが入っていて、処理済みのファイルを「フォルダ2」に書き出す処理。
def hage(x):
subprocess.check_output(['convert'---x[n]を適当に当てはめてコマンドを形成--], cwd='./'--カレントディレクトリで走らせる決め打ち)
def main():
todo_list = []
for file in files:
todo_list.append(フォーループで回すのに使うはずだった変数一覧）
# ここで読み込みファイルのフルパスと書き出しファイル名のリストを作るので順不同に処理されても問題なし
p = Pool(いい塩梅なプロセス制限の数値）
p.map(hage, todo_list)
check_outputのsubprocessがPool()個づつ回ります。
ここで、またPopenを使ってしまうと、戻りがないので、ひたすらぶっこまれて最初に戻るになります。
6.2MBのTiffファイルを200枚の処理で、単純にcheck_outputに投げると、1ファイルずつの処理になるので約280秒。Pool(8)ちゃんに回してもらうと、約60秒。
単純にPopenに投げたときより少しだけ速かったので、ちょっとびっくり。
食いつぶされても死なないようにOSXがなんかしてるオーバーヘッド的な何かがなくなり、論理コア数分（うちのは4コア。論理8コア）のプロセスしか使わないのでお気楽になるのだと思われます。
st(suckless terminal or simple terminal)はひどい。
もちろん、いい意味で。
sucklessをgoogle翻訳すると「ひどい」と出る。ホントの意味はわからない。
.strcみたいな設定ファイルはなくて、なんというか、こう、コンパイル時に設定オプションを書き換えてリコンパイルしろという恐ろしい仕様。
起動オプションでも変更できる設定があるけど、せっかくなので設定用のファイルを書き換えたほうがstっぽい感じ。設定ファイルがわけわからん状態になっても大丈夫。オリジナルをコピーし忘れてもデフォルト設定ファイルがオマケで入っている親切設計。
もちろん、そんな鬼仕様なのでコンパイルは瞬殺で終わる。
起動が超速い。どのくらい速いかと言うとcairo-dockのエフェクトが終わらないうちに起動する。設定がハードコーディングされるので読み込むものがない。一人で使うものはこうでなくちゃ。どうせ決まった設定なんて滅多に変えないし、コンパイルは爆速なのでmake clean install Return!!!の!あたりで終わってる。
fcitxでインライン変換が出来ない。左右metaに割り当てたon/off切替が効かないのでcontrol+spaceを使わないといけない。何かに食われているらしいけど読むのはCのソースコードなのでまたの機会にw。キー設定も書かれているので読めばわかるだろ系。
安心のtrue color対応。ubuntuの旧型LTSでも使えます。
