Just another Ruby porter,

〜2013年11月中旬〜


<Prev(,) | Next(.)> | Recent(/)>> | RDF

2013-11-11 (Mon)

adb devicesでno permissionsになる理由

なんか2台目がなりやすいなと思ったら、
それ/lib/udev/rules/51-android.rulesに登録してないよ。
追加したらsudoしなくてもいけるようになった。
なんと、それが原因だったんかい。
ということは/lib/udev/rulesに何も書かなくても、
sudo adb start-serverすればいけるんだな。

% adb kill-server
% sudo mv /lib/udev/rules.d/51-android.rules
% sudo adb start-server * daemon not running. starting it now on port 5037 * * daemon started successfully * % adb devices List of devices attached 015d256851181c0e device m:~/1311 % adb shell date Mon Nov 11 21:25:31 JST 2013

問題 $ echo "私は'zarigani'です。" | ruby -pe

deleteとかgsubを使わない方法。

% echo "私は'zarigani'です。" | ruby -pe '$_=$F*""' -aF\'
私はzariganiです。

1.8ならjoinしなくても$_=$Fでいい。


2013-11-12 (Tue)

advpngはなぜかgrayscaleが未対応

これは困る。スキャンした画像はほとんどがグレーなので。
どうして?

% advpng -z -4 001.png 
      391388      391388 100% 001.png (Unsupported bit depth/color type, 8/0)
      391388      391388 100%

というわけで、zopflipngを使うわけなんだけどこっちはこっちですごく遅い。
スキャンした原画像を残すためにも少しでも小さくしたいわけだけど、
数が多いしねえ。

カラーでスキャンしたUbuntu Magazineをやってみた結果。

% du -sh *
158M	C120-UM-NO07
154M	C120-UM-NO07-advdef
146M	C120-UM-NO07-advpng
146M	C120-UM-NO07-zopflipng

C120-UM-NO07が元画像。pngで134枚。
advpngは20分ぐらいでzopfilipngは90分。この差はでかい。
advdefはpng画像だけでなく、.gzもzopfliと同じ方法で再圧縮してくれるすぐれもの。
あとadvzipってのもある。そのうちrubyのソースで試してみよう。


2013-11-13 (Wed)

advdefとadvzipで再圧縮と7zの実力

Rubyのソースでやってみた。

% cp ruby-2.1.0-preview1.tar.gz ruby-2.1.0-preview1.tar.advdef4.gz
% time advdef -z -4 ruby-2.1.0-preview1.tar.advdef4.gz
    14449544    12933217  89% ruby-2.1.0-preview1.tar.advdef4.gz
    14449544    12933217  89%
advdef -z -4 ruby-2.1.0-preview1.tar.advdef4.gz  416.71s user 3.49s system 99% cpu 7:01.89 total

7分とか結構時間がかかるが、1割ぐらいは小さくなる。
1度だけだし普通のgzipで伸長可能なので転送量を減らすためにもやっといたほうがいいかもしれない。
zipはadvzipで。

% cp ruby-2.1.0-preview1.zip ruby-2.1.0-preview1.advzip4.zip
% time advzip -z -4 ruby-2.1.0-preview1.advzip4.zip
    16124069    14290333  88% ruby-2.1.0-preview1.advzip4.zip
    16124069    14290333  88%
advzip -z -4 ruby-2.1.0-preview1.advzip4.zip  554.12s user 7.10s system 99% cpu 9:23.66 total

こちらもおなじような感じ。時間は余計にかかっているがunzipで展開可能。

-3でも試してみる。

% cp ruby-2.1.0-preview1.tar.gz ruby-2.1.0-preview1.tar.advdef3.gz
% time advdef -z -3 ruby-2.1.0-preview1.tar.advdef3.gz
    14449544    12927303  89% ruby-2.1.0-preview1.tar.advdef3.gz
    14449544    12927303  89%
advdef -z -3 ruby-2.1.0-preview1.tar.advdef3.gz  124.88s user 0.07s system 99% cpu 2:05.46 total

あれ、意外にも勝ってしまった。時間もかからないし。7zも優秀だったのか。
だったらzipも最初から7zで作るほういいか。

% unzip -q ruby-2.1.0-preview1.zip
% time 7z a -tzip -mx=9 ruby-2.1.0-preview1.7z.zip ruby-2.1.0-preview1 >/dev/null
7z a -tzip -mx=9 ruby-2.1.0-preview1.7z.zip ruby-2.1.0-preview1 > /dev/null  92.19s user 0.39s system 359% cpu 25.752 total
% ls -o ruby-2.1.0-preview1.7z.zip
-rw-r--r-- 1 eban 14349935 2013-11-14 02:11:22 ruby-2.1.0-preview1.7z.zip

すばらしい。zopfliを使わなくても7zで十分だったか。

全部並べてみる。

% ls -oS ruby-2.1.0-preview1*.gz
-rw-r--r-- 1 eban 14449544 2013-09-23 00:29:26 ruby-2.1.0-preview1.tar.gz
-rw-r--r-- 1 eban 12933217 2013-11-14 01:48:59 ruby-2.1.0-preview1.tar.advdef4.gz
-rw-r--r-- 1 eban 12927303 2013-11-14 02:06:54 ruby-2.1.0-preview1.tar.advdef3.gz
% ls -oS ruby-2.1.0-preview1*.zip
-rw-r--r-- 1 eban 16124069 2013-09-23 00:29:26 ruby-2.1.0-preview1.zip
-rw-r--r-- 1 eban 14349935 2013-11-14 02:11:22 ruby-2.1.0-preview1.7z.zip
-rw-r--r-- 1 eban 14290333 2013-11-14 02:01:43 ruby-2.1.0-preview1.advzip.zip

まとめるとgzipしてからadvdef -z -3がサイズ的時間的にもお得。
zipよりは7zのzip互換モードを使うほうがお得。


2013-11-14 (Thu)

何か変だと思ったら

Google Chromeを先日新しいの入れたんだけど、妙に軽かったりと不思議に思い、
ふとfileで見てみたら32ビット版だった。

% file /opt/google/chrome/chrome
/opt/google/chrome/chrome: ELF 32-bit LSB shared object, Intel 80386, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xd3fff1d61e19a0c0c1b89af18c4741111dbc787b, stripped

まあいいか。ひょっとしてOnTabも32ビットにしたからいけたとか?


2013-11-15 (Fri)

1回クリックで3回分

なんか最近文字列の選択がしづらい。
なぜか途中でキャンセルされて何度もやりなおさないといけない。
あとhototのリンクをクリックするとブラウザに2個3個と同じ内容のタブがでてきて、
ああそうか、だからキャンセル扱いなんだなと納得した。
どうしたもんかと基本の電源OFFしてONしたらなおった。
こんなことがないとOFFにしないしなあ。って裏にそんなスイッチがあるなんて気づかなかったよ。
OFFにする必要ないもんなあ。


2013-11-16 (Sat)

xargs -P0 advdefしてみたらOSごとハングした

調子に乗って400個ぐらいあるディレクトリで

% ls *.png | xargs -rP0 -n1 advdef -z -4

したら何も受けつけなくなった。強制的にリセットしたら全ファイル一度にやろうとしていた。
可能な限りってのはコアの数とか何も考えずにってことらしい。
というわけで/proc/cpuinfoとか見ることにした。と思ったらnprocなんてコマンドが。

% nproc
4

やっぱそういうコマンドも必要だよな。


2013-11-17 (Sun)

GNU Parallel

卜部さんに教えてもらったので、parallelを使ってみる。
今回はconvertで。convertだとファイル名は途中に書かないといけないので-iオプション必須。
{}がファイル名に置き換わる。実際に実行すると

% parallel -i convert '{}' -resize x754 -type grayscale -depth 4 -verbose ../outdir/'{}' -- *.png
004.png=>../outdir/004.png PNG 1090x1600=>514x754 514x754+0+0 8-bit PseudoClass 5c 0.450u 0:01.030
002.png=>../outdir/002.png PNG 1090x1600=>514x754 514x754+0+0 8-bit PseudoClass 3c 0.450u 0:01.019
001.png=>../outdir/001.png PNG 1090x1600=>514x754 514x754+0+0 8-bit PseudoClass 16c 4.1KB 0.450u 0:01.039
003.png=>../outdir/003.png PNG 1090x1600=>514x754 514x754+0+0 8-bit PseudoClass 16c 8.19KB 0.460u 0:01.199
006.png=>../outdir/006.png PNG 1090x1600=>514x754 514x754+0+0 8-bit PseudoClass 4c 0.440u 0:00.959
005.png=>../outdir/005.png PNG 1090x1600=>514x754 514x754+0+0 8-bit PseudoClass 16c 0.440u 0:01.099
007.png=>../outdir/007.png PNG 1090x1600=>514x754 514x754+0+0 8-bit PseudoClass 16c 0.440u 0:01.049
008.png=>../outdir/008.png PNG 1090x1600=>514x754 514x754+0+0 8-bit PseudoClass 6c 0.450u 0:00.920
009.png=>../outdir/009.png PNG 1090x1600=>514x754 514x754+0+0 8-bit PseudoClass 16c 41KB 0.500u 0:00.440

という感じになる。parallelはコアの数をちゃんと考慮に入れてくれるので、
この場合は最大4プロセスで処理される。
xargsの-0相当がないのでfindとの組み合わせは注意。
convert '*.png'はメモリをやたらと喰うのでforで回していたが、やっぱ並列で処理したほうが速いよな。


2013-11-18 (Mon)

convertで処理した情報をファイルに保存せずに表示する

convertでノンブルをcropしてtrimして目的の大きさへリサイズするなんてよくやるが、
そのときに縮小率を揃えるために何個かサンプル取るよね。
そこでどのくらいの大きさになったのか知りたくなる。
今までは

% identify 100.png                                 
100.png PNG 1090x1600 1090x1600+0+0 8-bit PseudoClass 16c 136KB 0.000u 0:00.000
% convert -crop +0+100 -fuzz 80% -trim 100.png x.png
% identify x.png  
x.png PNG 880x1349 1090x1600+105+125 8-bit PseudoClass 16c 109KB 0.000u 0:00.000

てなことをしていたが、info:で得られるようだ。

% convert -crop +0+100 -fuzz 80% -trim 100.png info:
100.png PNG 880x1349 1090x1600+105+125 8-bit PseudoClass 16c 0.020u 0:00.080

というか不思議なことにpngって元画像の情報も残ってるんだな。

高さとそのオフセットが知りたければformatで指定できる。

% convert -crop +0+100 -fuzz 80% -trim 100.png -format "%h %Y" info:
1349 +125

2013-11-19 (Tue)

マウスのバッテリーが切れた

丁度半年だが、今回はなぜこんなに早いのか。
ひょっとしてちょっと前に 変な挙動してたが、
あれって結構電力消費してたりして?
まあ、半年も保てば全然問題ないんだけどね。


<Prev(,) | Next(.)> | Recent(/)>> | RDF


WWW を検索 jarp.does.notwork.org を検索

わたなべひろふみ
Key fingerprint = C456 1350 085F A320 C6C8 8A36 0F15 9B2E EB12 3885
Valid HTML 4.01!