Google Chrome のマウス ジェスチャー拡張として AutoControl を使い始めた。
 |
| AutoControl |
家族が使っているノート PC の HDD を SSD に換装したので、HDD を廃棄するためにデータを消去する手順を確認した。
いまどきの HDD と Windows であれば、Windows 標準の format コマンドだけで十分なデータ消去ができるようだ。
ただし、不良セクターの代替処理がおこなわれている場合やハードウェア障害によりエラーが発生している場合には関連するセクターのデータ消去はできない恐れがある。
/P スイッチを使ってゼロ埋めと追加の上書きを指示する。
PS C:\WINDOWS\system32> format /?
（略）
/P:count Zero every sector on the volume. After that, the volume
will be overwritten "count" times using a different
random number each time. If "count" is zero, no additional
overwrites are made after zeroing every sector. This switch
is ignored when /Q is specified.
（略）
以下、私による訳
ボリュームの各セクターをゼロ埋めする。その後、毎回異なる乱数を使用して指定回数上書きする。0回を指定すると、ゼロ埋め後に追加の上書きはおこなわれない。このスイッチは /Q （クイック フォーマット）時には無視される。
データの完全消去 - Wikipedia によると 1回で良い。以下引用
アメリカ国立標準技術研究所（NIST）が2006年に発表したSpecial Publication 800-88の7ページでは、次のように述べられている。『2001年以降の（15GBytes以上の）集積度の高いATAハードディスクにおいては、データの完全消去はディスク全域に1回のみ上書きすれば事足りる』[4][7]。 また、Center for Magnetic Recording Researchは、次のように述べている『データの完全消去はディスクに対する1回の上書きのことである。アメリカ国家安全保障局も推奨要綱にて、同相信号除去比（CMRR）試験をした結果、複数回の上書きは何ら安全性の向上に優位な差をもたらさず、1回の上書きで十分であることを認めている』[8]。
実際には処分する HDD をまっさらにしてから単一のボリューム（パーティション） を作成し、そのボリュームに対して format コマンドを実行した。
PS C:\WINDOWS\system32> diskpart
Microsoft DiskPart version 10.0.19041.1
Copyright (C) Microsoft Corporation.
On computer: CXAXUKLUTH
DISKPART> list disk
Disk ### Status Size Free Dyn Gpt
-------- ------------- ------- ------- --- ---
Disk 0 Online 476 GB 5120 KB *
Disk 1 Online 298 GB 7168 KB *
DISKPART> select disk 1
Disk 1 is now the selected disk.
DISKPART> clean
DiskPart succeeded in cleaning the disk.
DISKPART> create partition primary
DiskPart succeeded in creating the specified partition.
DISKPART> assign LETTER=x
DiskPart successfully assigned the drive letter or mount point.
DISKPART> exit
Leaving DiskPart...
PS C:\WINDOWS\system32> format x: /P:1
The type of the file system is RAW.
The new file system is NTFS.
WARNING, ALL DATA ON NON-REMOVABLE DISK
DRIVE X: WILL BE LOST!
Proceed with Format (Y/N)? y
Formatting 298.1 GB
Volume label (32 characters, ENTER for none)?
Creating file system structures.
Format complete.
298.1 GB total disk space.
298.0 GB are available.
最近は再利用するかもしれないことを考えて convert gpt している。以下のファイルとコマンドラインで手間を省いている。環境ごとに diskpart スクリプトを作ってけばディスクを誤選択することもなく安全だと思う。
select disk 1 clean convert gpt create partition primary format fs=ntfs label="cleantarget" quick assign letter=x exit
cmd /c diskpart /s diskpart_clean_disk.txt && timeout /t 15 && echo cleantarget | format x: /P:1 /V:CLEAN /Y
Emacs 23 になってから、これまで Windows の Emacs では create-fontset-from-ascii-font で作ったフォントセットを使ってきた。default-fontset をいじる設定も試したことがあったが納得いかなかった。上記の EmacsWiki を見て standard-fontset をいじって使ってみたところ、これは良さそうだ。
…と言っても毎度代わり映えしない設定なわけですが。
基本的なアルファベットのところは Consolas を使い、日本語は(表示できればいいや、で) MS Gothic、残りはフォントリンク、default-fontset のフォールバック、Arial Unicode MS によしなにしてもらう設定です。
Emacs 23.2.92 での view-hello-file
この設定ではギリシャ文字やキリル文字の見た目の文字幅(プロポーショナルで幅 1 っぽい)と、Emacs が扱う char-width の文字幅 2 が異なる状態になるので、これが問題になるようなら、本当に文字幅を 1 にするなり、latin-jisx0201, cyrillic-iso8859-5, greek-iso8859-7 を MS Gothic で表示してちゃんと文字幅 2 で見えるようにする必要があると思います。
半角カナは Arial Unicode MS での表示。MS Gothic より少しは綺麗。
まぁ少々ぴこぴこするけど。まず使わないし
十分十分。どうせ読めないし
いずれも古いので参考にしないほうが良いと思います…。
これは SKK Advent Calendar 2010 の六日目 2010/12/13 の記事です。
五日目は tomoya さんによる、
です。 (setq skk-kakutei-when-unique-candidate t) は便利そうですね。実は単語登録したいとき困るのじゃないかと思っていたら、続けて skk-undo-kakutei すれば辞書登録モードになるという新発見もありました。
さて、SKK の特徴的な機能の一つには再帰的な辞書登録モードがあり、たとえ世界中のどの辞書にも載っていない単語だとしても、超簡単に単語を登録してあっというまに個人辞書を充実させていくことができます。
ぼくは普段 Windows のデスクトップで生活していて、Emacs では Daredevil SKK (ddskk) を使い、他のアプリケーションでは skkime を使って日本語を入力しています。ところが ddskk と skkime はそれぞれ別の個人辞書を使うので、どちらかで単語を登録してももう一方ではすぐにその単語が出てきません。これはちょっと悲しい。そこで今日は個人辞書育成を少しだけ楽しくする TIPS を紹介したいと思います。
まずは skkime から ddskk の個人辞書を参照できるように設定します。
skkime のプロパティを表示して、辞書設定のタブから、ファイル辞書として ddskk で使っている個人辞書のファイルを指定します。辞書ファイルのパスはお使いの環境に合わせてください。
ddskk の個人辞書はソートされていませんので、「この辞書はソートされている」のチェックは入れないようにしてください。
これで skkime の個人辞書にない単語を変換したときに、ddskk の個人辞書を参照して変換できるようになりました。
しかし、これだけでは、ddskk で単語登録した直後にはその単語を skkime で使うことができません。単語登録をしても、ディスク上の個人辞書ファイルがすぐに更新されるわけではないためです。
ですから、ddskk の設定にも少し手を入れます。以下のように .skk ファイルへ追記します。
(defvar my-skk-jisyo-updated
nil
"個人辞書の更新直後に保存するかどうかを示すフラグ")
(defadvice skk-henkan-in-minibuff (after my-skk-raise-jisyo-update-flag last
activate compile)
"単語登録された場合 my-skk-jisyo-updated をセットする"
(if ad-return-value
(setq my-skk-jisyo-updated t)))
(defadvice skk-update-jisyo (after my-skk-sync-private-jisyo last
(word &optional purge)
activate compile)
"新たに単語が登録されたか削除された時、個人辞書を保存する"
(if (or my-skk-jisyo-updated purge)
(progn
(skk-save-jisyo 'quiet)
(setq my-skk-jisyo-updated nil))))
これで便利になりました！
ddskk で単語を登録して、すぐに skkime からもその単語を変換できるようになっていることを確認してみてください。
さて、続いてこんどは逆に ddskk から skkime の個人辞書を参照できるようにしましょう。
2010/12/17 以降の CVS 版 ddskk をお使いの場合は、上記の代わりに以下のように書くだけで良くなりました。※コメント参照
(setq skk-save-jisyo-instantly t)
ddskk 開発者の北本さんが、同等の機能を ddskk 本体に取り込んでくださいました。
ありがとうございます！
実はこれから紹介する方法はあまりスマートではありません。
と言うのも、前項のように辞書を更新する適切なトリガーが無い(あるいは、ぼくが知らない)ので、手動で更新するような形になってしまうのです。
まず、いくつかのツールが必要になるので、以下からダウンロードするなどして用意してください。
それぞれの実行可能ファイルを PATH の通ったディレクトリに置いて、以下のように .skk ファイルへ追記します。
(setq skk-extra-jisyo-file-list
(list '("c:/Users/yu-ji/home/.skkime-jisyo_euc_sort" . euc-jp)))
(defun my-skk-update-skkime-jisyo ()
"skkime の個人辞書を保存し、文字エンコーディングを変換し、ソートする
既に読み込まれていれば辞書バッファーを削除する"
(interactive)
(let* ((extra-jisyo-dir "c:/Users/yu-ji/home/")
(extra-jisyo-name ".skkime-jisyo_euc_sort")
(skkime-jisyo-dir "c:/Users/yu-ji/home/")
(skkime-jisyo-name ".skkime-jisyo")
(sync-command "syncskkiserv")
(nkf-command "nkf -W16L -e -Lu -d")
(buf (get-buffer (concat " *" extra-jisyo-name "*")))
(command-line (concat sync-command
" && " nkf-command
" < " skkime-jisyo-dir skkime-jisyo-name
" | " "skkdic-sort"
" > " extra-jisyo-dir extra-jisyo-name)))
(shell-command command-line)
(if (buffer-live-p buf)
(kill-buffer buf))))
辞書ファイルのパスはお使いの環境に合わせてください。既定では、
などになっていると思います。
このとき nkf に渡すオプションでは、skkime 用の辞書の文字エンコーディングが UTF-16-LE、ddskk 用の辞書は EUC-JP を想定しています。実際のところ様々なエンコーディングを使えるのですが、skkdic-sort のフィルターを通す前に EUC-JP へ変換する必要があります。
これで M-x my-skk-update-skkime-jisyo とすると、skkime 用の個人辞書を変換して ddskk で使えるようにしたファイルが用意され、このファイルを ddskk から参照して変換できるようになります。
理想的には、skkime で単語を登録したタイミングで個人辞書を保存したり、ddskk 側で(個人辞書以外にも)ソートされていない辞書ファイルを扱えれば良いのかなぁと考えています。
(add-hook 'skk-mode-hook
(lambda () (my-skk-update-skkime-jisyo)))
いまのところはこのように C-x C-j したタイミングで更新するようにして使っています。
後半はかなり弱気になってしまいましたが、どうでしょうか。Advent Calendar 初参加の @yunh がお送りいたしました。
もしほかの上手い方法をご存知のかたがいらしたらぜひ教えてください。
そして可能ならブログしてその記事を SKK Advent Calendar 2010 で！
七日目となる明日は tyru さん Humanity が書いてくださいます。
よろしくお願いします！
MinGW / MSYS の環境を作り直して、久しぶりに Emacs の emacs-23 ブランチをビルドしてみたら、make all や make bootstrap で emacs.exe を作るときに windres がコケるようになってた。
$ make bootstrap (的なコマンドライン) (略) windres -O coff --include-dir ../nt -o oo-spd/i386/emacs.res ../nt/emacs.rc rm oo-spd/i386/temacs0.a rm: cannot lstat `oo-spd/i386/temacs0.a': No such file or directory make[2]: [oo-spd/i386/temacs0.a] Error 1 (ignored) ar -rsc oo-spd/i386/temacs0.a oo-spd/i386/emacs.o windres: can't open icon file `icons\emacs.ico': No such file or directory make[2]: *** [oo-spd/i386/emacs.res] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory `/c/Users/yu-ji/home/src/wc/emacs/emacs-23/src' make[1]: *** [bootstrap-temacs] Error 2 make[1]: Leaving directory `/c/Users/yu-ji/home/src/wc/emacs/emacs-23/src' make: *** [bootstrap-gmake] Error 2
(並列に走ってる部分なので余計なメッセージも混ざってますが…)
使ったのは binutils-2.20.51-1-mingw32-bin.tar.lzma で、以前の環境で正常だったはずの binutils-2.20-1-mingw32-bin.tar.gz の windres に戻しても同様にコケる。
=== modified file 'nt/emacs.rc' --- nt/emacs.rc 2010-05-08 04:46:44 +0000 +++ nt/emacs.rc 2010-07-17 07:33:02 +0000 @@ -1,5 +1,5 @@ -Emacs ICON icons\emacs.ico -32649 CURSOR icons\hand.cur +Emacs ICON icons/emacs.ico +32649 CURSOR icons/hand.cur 1 24 "emacs.manifest" #ifndef VS_VERSION_INFO
emacsclient.rc のほうは直さなくてもいいみたい。なんでしょうね…。MinGW / MSYS の環境作りでなにか忘れてるのかなぁ。
※以前 "MSYS gcc 4.5.0" と書いていましたが "MinGW gcc 4.5.0" の間違いです。
MinGW gcc 4.5.0 の -march=native オプションを Core i7 860 で使うと適用されるオプションがおかしい。
のシェルスクリプトを拝借して…、
(一部手動改行)
## 参考に Cygwin で。 $ cat /proc/cpuinfo | grep '^model ' | sort | uniq model name : Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz $ uname -a CYGWIN_NT-6.1-WOW64 devildoll 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin $ gcc --version gcc (GCC) 4.3.4 20090804 (release) 1 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ ~/work/gcc_native.sh -march=core2 -mcx16 -msahf --param l1-cache-size=32 --param l1-cache-line-size=64 -mtune=core2 ## MinGW / MSYS で。 $ uname -a MINGW32_NT-6.1 DEVILDOLL 1.0.14(0.47/3/2) 2010-03-17 23:02 i686 Msys $ gcc --version gcc.exe (GCC) 4.5.0 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ ./work/gcc_native.sh -march=atom -mcx16 -msahf -mpopcnt -msse4.2 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=core2
(ノ∀`) ｱﾁｬｰ atom て
こないだ zlib はオフィシャルから配布されてた DLL を使いましたが、新バージョン公開後すぐにバイナリーが上がるわけではないみたい。なので自分で make してみた。
win32/DLL_FAQ.txt によればオフィシャルの DLL を使うよう推奨しているのにね…。
## Cygwin で $ cd ~/src $ wget http://zlib.net/zlib-1.2.5.tar.bz2 $ tar xjf zlib-1.2.5.tar.bz2 ## MinGW で $ cd zlib-1.2.5 $ cp contrib/asm686/match.S ./match.S $ make LOC=-DASMV OBJA=match.o -fwin32/Makefile.gcc gcc -DASMV -O3 -Wall -DNO_VIZ -c -o adler32.o adler32.c gcc -DASMV -O3 -Wall -DNO_VIZ -c -o compress.o compress.c gcc -DASMV -O3 -Wall -DNO_VIZ -c -o crc32.o crc32.c gcc -DASMV -O3 -Wall -DNO_VIZ -c -o deflate.o deflate.c gcc -DASMV -O3 -Wall -DNO_VIZ -c -o gzclose.o gzclose.c gcc -DASMV -O3 -Wall -DNO_VIZ -c -o gzlib.o gzlib.c gcc -DASMV -O3 -Wall -DNO_VIZ -c -o gzread.o gzread.c gcc -DASMV -O3 -Wall -DNO_VIZ -c -o gzwrite.o gzwrite.c gcc -DASMV -O3 -Wall -DNO_VIZ -c -o infback.o infback.c gcc -DASMV -O3 -Wall -DNO_VIZ -c -o inffast.o inffast.c gcc -DASMV -O3 -Wall -DNO_VIZ -c -o inflate.o inflate.c gcc -DASMV -O3 -Wall -DNO_VIZ -c -o inftrees.o inftrees.c gcc -DASMV -O3 -Wall -DNO_VIZ -c -o trees.o trees.c gcc -DASMV -O3 -Wall -DNO_VIZ -c -o uncompr.o uncompr.c gcc -DASMV -O3 -Wall -DNO_VIZ -c -o zutil.o zutil.c gcc -DASMV -Wall -c -o match.o match.S ar rcs libz.a adler32.o compress.o crc32.o deflate.o gzclose.o gzlib.o gzread.o gzwrite.o infback.o inffast.o inflate.o inftrees.o trees.o uncompr.o zutil.o match.o windres --define GCC_WINDRES -o zlibrc.o win32/zlib1.rc gcc -shared -Wl,--out-implib,libzdll.a -DASMV \ -o zlib1.dll win32/zlib.def adler32.o compress.o crc32.o deflate.o gzclose.o gzlib.o gzread.o gzwrite.o infback.o inffast.o inflate.o inftrees.o trees.o uncompr.o zutil.o match.o zlibrc.o Creating library file: libzdll.a strip zlib1.dll gcc -DASMV -O3 -Wall -DNO_VIZ -c -o example.o example.c gcc -DASMV -o example.exe example.o libz.a strip example.exe gcc -DASMV -O3 -Wall -DNO_VIZ -c -o minigzip.o minigzip.c gcc -DASMV -o minigzip.exe minigzip.o libz.a strip minigzip.exe gcc -DASMV -o example_d.exe example.o libzdll.a strip example_d.exe gcc -DASMV -o minigzip_d.exe minigzip.o libzdll.a strip minigzip_d.exe $ make test testdll -fwin32/Makefile.gcc ./example zlib version 1.2.5 = 0x1250, compile flags = 0x255 uncompress(): hello, hello! gzread(): hello, hello! gzgets() after gzseek: hello! inflate(): hello, hello! large_inflate(): OK after inflateSync(): hello, hello! inflate with dictionary: hello, hello! echo hello world | ./minigzip | ./minigzip -d hello world ./example_d zlib version 1.2.5 = 0x1250, compile flags = 0x255 uncompress(): hello, hello! gzread(): hello, hello! gzgets() after gzseek: hello! inflate(): hello, hello! large_inflate(): OK after inflateSync(): hello, hello! inflate with dictionary: hello, hello! echo hello world | ./minigzip_d | ./minigzip_d -d hello world ## Cygwin で $ tar cvzf zlib-1.2.5-win32-x86-unofficial-uch.tar.gz \ > ./zlib-1.2.5/*.{exe,dll} ./zlib-1.2.5/example.exe ./zlib-1.2.5/example_d.exe ./zlib-1.2.5/minigzip.exe ./zlib-1.2.5/minigzip_d.exe ./zlib-1.2.5/zlib1.dll
いちおう置いてみます。オフィシャルの DLL が出たのに気づいたら消します。ダウンロード前に http://www.zlib.net/ をチェックしてみてください。
オフィシャルの DLL がでています。
Windows の Emacs (NTEmacs) のイメージサポートに必要な DLL を作る。
現実逃避メモ。
#
# XPM
#
$ cd ~/src/
$ wget http://alpha.gnu.org/gnu/emacs/pretest/windows/libxpm-3.5.7-w32-src.zip
$ unzip libxpm-3.5.7-w32-src.zip
$ cd libXpm-3.5.7/src
# MinGW で
$ make
$ cp -pf libXpm.dll /c/emacs/23/bin
# 後始末
$ rm -f *.{dll,o}
または、
$ wget http://ftp.gnu.org/pub/gnu/emacs/windows/libxpm-3.5.8-w32-src.zip
$ mkdir libXpm-3.5.8
$ cd libXpm-3.5.8
$ unzip ../libxpm-3.5.8-w32-src.zip
$ cd src
$ rm -f *.{dll,o}
# MinGW で
$ make
# 後始末
$ rm -f *.{dll,o}
この libxpm-3.5.8-w32-src.zip はたまたま置いてあるだけかも。バイナリもはいってるし。
# # JPEG # # Independent JPEG Group # http://www.ijg.org/ # $ wget http://www.ijg.org/files/jpegsrc.v8a.tar.gz $ tar xzf jpegsrc.v8a.tar.gz $ cd jpeg-8a/ # MinGW で $ ./configure CFLAGS="-O2 -mno-cygwin -march=native" $ make $ cp -pf .libs/libjpeg-8.dll /c/emacs/23/bin/libjpeg.dll # 後始末 $ make distclean
オフィシャルバイナリありがたや。
# # zlib # # zlib Home Site # http://www.zlib.net/ # $ wget http://zlib.net/zlib124-dll.zip $ unzip zlib124-dll.zip $ cp -pf zlib-1.2.4/zlib1.dll /cygdrive/c/emacs/23/bin
追記@Fri May 14 02:13:19 2010
その後やっぱり自分で作ってみた。
# #PNG # # libpng Home Page # http://www.libpng.org/pub/png/libpng.html # $ wget ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng-1.4.1.tar.gz $ tar xzf libpng-1.4.1.tar.gz $ cd libpng-1.4.1 $ mkdir include $ cp png.h pngconf.h include/ # MinGW で $ cp scripts/makefile.mingw Makefile $ make CFLAGS="-Ic:/Users/yu-ji/home/src/zlib-1.2.4" $ cp -pf libpng14.dll /c/emacs/23/bin/libpng.dll # 後始末 $ make clean
息抜きに…じゃ済まなさそうなので、またいずれ。
# # TIFF # # LibTIFF - TIFF Library and Utilities # http://www.remotesensing.org/libtiff/ $ wget http://download.osgeo.org/libtiff/tiff-3.9.2.tar.gz $ tar xzf tiff-3.9.2.tar.gz $ cd tiff-3.9.2 # MinGW で $ ./configure CFLAGS="-O2 -mno-cygwin -march=native" \ --with-zlib-include-dir=c:/Users/yu-ji/home/src/zlib-1.2.4 \ --with-zlib-lib-dir=c:/Users/yu-ji/home/src/zlib-1.2.4 \ --with-jpeg-include-dir=c:/Users/yu-ji/home/src/jpeg-8a \ --with-jpeg-lib-dir=c:/Users/yu-ji/home/src/jpeg-8a $ make # 途中でこけるけど $ cp -pf libtiff/.libs/libtiff-3.dll /c/emacs/23/bin/libtiff.dll # やっぱダメ
DLL できたけど、なんか変。なのでまたこんど。
emacs/nt/configure.bat
configure.bat --with-gcc --no-cygwin --no-debug --prefix=C:/emacs/23 \ --cflags -Ic:/Users/yu-ji/home/src/libXpm-3.5.8/include \ --cflags -Ic:/Users/yu-ji/home/src/libXpm-3.5.8/src \ --cflags -Ic:/Users/yu-ji/home/src/jpeg-8a \ --cflags -Ic:/Users/yu-ji/home/src/zlib-1.2.4 \ --cflags -Ic:/Users/yu-ji/home/src/libpng-1.4.1/include \ --without-gif --without-tiff
後先ですが…、セキュリティ絡みの修正がでても更新されない gnuwin32 の DLL を卒業したいと思った。
さっと息抜きに済ませるはずが、giflib が手強くって、gnuwin32 からソース落として patch を眺めたところで諦めた。libtiff も時間のあるときに延期。
gnuwin32 が更新されたら何も心配しないで済むんですが…。
右に Windows キーのあるキーボードを使うようになったので、右の Win キーを Super モディファイアに、App キーを Hyper モディファイアに使えるよう NTEmacs を設定してみた。
;; 右 Win キーを Super モディファイアキーに (setq w32-pass-rwindow-to-system nil) (setq w32-rwindow-modifier 'super) ;; 左 Win キーを Super モディファイアキーに ;;(setq w32-pass-lwindow-to-system nil) ;;(setq w32-lwindow-modifier 'super) ;; Super + Shift + s で「先生！お願いしますっ！」 (define-key global-map [(s S s)] 'doctor) ;; App キーを Hyper モディファイアキーに (setq w32-apps-modifier 'hyper) ;; Hyper + なんちゃらでフレーム操作 (define-key global-map [(H f)] '(lambda (arg) (interactive "p") (other-frame (- arg)))) (define-key global-map [(H b)] '(lambda (arg) (interactive "p") (other-frame arg))) (define-key global-map [(H o)] 'other-frame) (define-key global-map (kbd "H-2") 'make-frame-command) (define-key global-map (kbd "H-0") 'delete-frame)
Win キーとの組み合わせは Windows シェルの explorer でホットキーに使われているキーがけっこうあって、いまいち使いづらい感じです。Windows のホットキーはアプリケーションにキーが渡る前に処理されるので、NTEmacs 側ではどうにもならないんですね。
他のモディファイアキーと組み合わせたり、prefix キーにすればあるいは…でも、そこまでして使いたいバインディングがあるわけじゃなく…。ちょっと活用が思いつかないなぁ。
App キーはふつうに便利に使えそう。
金曜日に 23.1.93 の pretest がはじまりました。
が、23.1.93 は Windows では壊れていることが発覚したので、tarball から入れる人はスキップした方が良さそうです。
メンテナーによると近いうちにもう一度つぎの pretest を出す予定とか。
23.2 branch とどっちが先かな…。
GNU Aspell と Firefox と TortoiseSVN のスペルチェック用ユーザ辞書をマージする Perl スクリプト。
ついでに NTEmacs の ddskk と skkime のユーザ辞書から abbrev モードで使う単語も抜き出してくっつけます。
Windows の ActivePerl 5.10.1 と Cygwin の Perl 5.10.1 で動くようにしてあります。
こんなの需要があるか分かりませんが、あのムカつく赤波アンダーラインが嫌いな人向けです。ファイルのバックアップとかしませんので必要なら手動でどぞ…。
予定どおりに 23.1.92 が出たようです。
bzr を使って追っかけするのにもだいぶ慣れてきました。
が、やっぱ、なにをするにも遅いんだよなぁ。
Cygwin 1.7 の bzr は 2.0.0 なんですけど、これが遅いんですかね？なんだろうな。
公式で git を使えるようになったらすぐに乗り換えると思います。
一応、有志による git ミラーは以下にあります。
さて、こないだから MinGW + MSYS でビルドするようになったので、そこらへんを少しだけ。
うちでは Windows 7 Enterprise x64, MinGW 5.1.6, MSYS 1.0.13-2, gcc 4.4.0 でビルドしています。
$ msysinfo msysinfo-1.3: Send this to the MSYS support list: MSYS 1.0.13(0.47/3/2) 2010-01-27 23:29 i686 unknown; targ=MINGW32 GNU bash, version 3.1.17(1)-release (i686-pc-msys); ENV=.profile GNU Make 3.81This program built for i686-pc-msys; MAKE_MODE=unix gcc.exe (GCC) 4.4.0; targ=MINGW32 GNU ld (GNU Binutils) 2.20 00 2010-01-28 13:31:10.000000000 +0900 /bin/msys-1.0.dll 92 2009-07-11 15:34:34.000000000 +0900 /bin/msys-bz2-1.dll 74 2010-01-06 19:46:31.000000000 +0900 /bin/msys-lzma-1.dll 52 2009-11-08 10:09:15.000000000 +0900 /bin/make.exe 2009-06-23 11:46:39.000000000 +0900 /c/MinGW/bin/gcc.exe 8 2009-10-24 09:13:00.000000000 +0900 /c/MinGW/bin/ld.exe HOME=/c/Users/yu-ji/home Sysname=MINGW32_NT-6.1 OSTYPE=msys TERM=cygwin PATH=.:/usr/local/bin:/mingw/bin:/bin:/usr/bin:/c/MinGW/bin:/c/Windows/system32:/c/Windows
普段使いの環境は Cygwin 1.7 に合わせてあるので、msys.bat で MinGW + MSYS 用の環境を調整しています。Emacs をビルドするときには、cmd でも bash でも大丈夫ですが、なんとなく bash からやってます。
$ diff msys.bat~ msys.bat 1a2,3 > set Path=C:\msys\1.0\bin;C:\MinGW\bin;%SystemRoot%\system32;%SystemRoot% > set LANG=C
間違って Cygwin 環境でやっちゃうとややこしいことになるので、configure と make はそれぞれシェルスクリプトをかませてやっています。
emacs.config.sh とかファイル名つけて…、
#!/bin/sh
if [[ $MSYSTEM != "MINGW32" ]]; then
echo emacs.config.sh must run under the MSYS shell;
exit;
fi
export LANG=C
time $COMSPEC /c \
'configure.bat --with-gcc --no-cygwin --no-debug --prefix=C:/emacs/23' \
2>&1 | tee config.log.yu-ji;
引数とか忘れますしね。
以下は emacs.make.sh とかファイル名つけて…、
#!/bin/sh
if [[ $MSYSTEM != "MINGW32" ]]; then
echo emacs.make.sh must run under the MSYS shell;
exit;
fi
export LANG=C
time make \
--jobs=4 XMFLAGS="--jobs=3" \
ARCH_CFLAGS="-c -mno-cygwin -march=native -O3 -fno-tree-vectorize -mfpmath=sse -mthreads -pipe" \
$1 $2 $3 $4 $5 \
2>&1 | tee make.log.yu-ji;
うちの CPU は一昨年くらいの Core 2 Duo です。-O3 だけだと temacs をダンプするとき(だったと思う)にこけるので optimization 関係のオプションを調整した結果 -O3 -fno-tree-vectorize になりました。これが何を意味するかは知りませんし、他のマシンにバイナリを持っていくことも考えてません…。
※追記参照のこと
普段追っかけるときには、以下のようにやってます。ローカルのリポジトリの持ち方によって違う気がします。ワーキングコピーに merge してから diff して commit するほうが通信量も少ない気がします。
$ cd ~/src/wc/emacs/trunk/ (emacs のワーキングコピーに移動) $ bzr merge --preview | lv (変更点を眺めてみる) $ bzr merge --pull (変更点を取り込む) $ cd nt $ ../../../emacs.make.sh all (上に載せたシェルスクリプトです) $ ../../../emacs.make.sh recompile EMACS=../src/oo-spd/i386/emacs.exe (lisp/ 以下に変更があったときにはこれやらないと .elc が古いままです) $ ../../../emacs.make.sh install (いんすこ)
なにかおかしくなったら、ワーキングコピーを綺麗にして bootstrap からやりなおします。
$ ../../../emacs.make.sh realclean $ ../../../emacs.make.sh distclean $ ../../../emacs.config.sh $ ../../../emacs.make.sh bootstrap
こんな感じで。
MinGW-w64 で x64 Emacs はビルドできるんですかねえ。画像用の DLL 作るあたりが鬼門そうだ…。
@dnerkxさんが -O3 -fno-tree-vectorize の件を調べてくれました。thx!
作業中のデスクトップを残したままロックしてキーボードを掃除していたところ、気がついたらいつのまにか Windows がシャットダウンしていました…。
怒らないぞ泣かないぞ。(つД｀)
ということで、懐かしの Ctrl + Alt + Del に戻ってきてもらう方法。
netplwiz.exe (Advanced User Accounts Control Panel) を実行して、
"Require users to press Ctrl+Alt+Delete" にチェックを入れる。
ログオンやロック解除時に Ctrl + Alt + Del の入力を要求されるようになります。(Ease of Access は動いちゃうけど)
これなら気軽にキーボードを掃除できますね。ちゃんと掃除するときは USB から抜いて外してやるけどね。
大晦日に 23.1.91 が出ました。
Emacs のリポジトリが、VCS を CVS から Bazaar(bzr) に乗り換えたので、emacs-devel はまだ混乱中のようです。
ぼくもとりあえず local の branch を作っただけで、他の使い方は知りません…。CVS と同期した git の使い勝手が良かったので、Bazaar のリポジトリでも git から使えるようになると良いのですが。
Cygwin を 1.5 系から 1.7 系に乗り換えたので(完全移行したので)、Cygwin + MinGW + gcc-3 で -mno-cygwin のバイナリが作れなくなりました。
なので、今回から MinGW + MSYS + gcc 4.4 の環境でビルドしてみました。
英語版の Windows 7 で emacs -Q して F1 h (view-hello-file) するとこんな感じです。すぐ表示できないのは、ビルマ語(Burmese)とオリヤー語(Oriya)、あとなぜか日本語の半角カナだけ。Windows も Emacs もすごいなー。
もちろんフォント入れればぜんぶ表示できるはず。
参考: u-ch: NTEmacs 23 で (view-hello-file) ぜんぶ表示してみた
年末にメインの PC を Windows 7 へ載せ替えたので使い方をちょっとだけ試行錯誤してみた。
けっきょくスタートメニュー(のようなもの)は捨てられず…。こんな具合に旧来のフォルダメニューを出すようにした。
もともと良く使うショートカットを Win 1キー 1キー の 3ストロークちょっとで使えるように集めていたので、mklink を使ってそのフォルダをほぼそのまま %USERPROFILE% 以下に symlink した。Win TAB Enter Enter 1キーとキーストロークは増えたものの、まぁ、悪くない感じです。search box や taskbar に pin したやつを Win + 数字キーで使うのも便利だし。でもさっき power button を誤爆して logoff しかけたので lock に変えるかも…。
元の My Documents 的なディスクボリュームを %USERPROFILE%\home の junction にマウントし、%USERPROFILE% 以下の各 junction はターゲットを振り替えて使っています。
Windows Explorer の使い勝手が良いので(悪くなったところもあるけど！)普段使いでは気にすることはないが、%USERPROFILE% のあたりはほんっと使い辛いというか分かりづらい。これだけぐちゃぐちゃにしてまで互換性を保ったのは偉い、でも、頭がどうかしてるとしか思えん。あとどうせ変えるなら "My なんたら" って表記するのばっさりやめれば良かったのにね。
Emacs 23.2 リリースに向けた pretest が始まりました。
相変わらず、以前書いた上記のメモと同じ手順で作ってます。メインの PC を Windows 7 にしたら、Cygwin 1.7 に移行して、それが落ち着いたら MinGW でのビルド環境作ろうかと。年末、お正月か、来年か…。orz
ちなみに 23.2 では Windows 7 のタスクバーでうまいこと動くよう runemacs や emacsclient に改良が加えられています。
etc/NEWS を眺めて個人的に気になったのは以下の項目。
forward-word とかが長音符 "ー" に引っ掛らなくなったのが地味に嬉しい。
Emacs は、FTP で接続した先にあるファイルを、ローカルにあるファイルと同じ感覚で編集できます。
古くは ange-ftp、現在では tramp という仕組みを使います。(実際のところ tramp で FTP を扱うときは、裏で ange-ftp が動いているみたいです)
Linux など UNIX 系 OS の Emacs では、OS のディストリビューションに含まれている /usr/bin/ftp など BSD 由来(たぶん？)の ftp が使われます。
Windows にも C:\WINDOWS\system32\ftp.exe がありますけれど、これは Emacs から使うことはできません。
そこで Emacs のお膝元で配布している BSD 由来の Windows 用 ftp を使います。
(※追記参照のこと)
これの Release\ftp.exe を適当なディレクトリに置いて使います。ぼくは横着なので Emacs と同じディレクトリに置いてます。
ange-ftp にこの ftp.exe を使うように指示するには以下のようにします。
(setq ange-ftp-ftp-program-name "C:\\emacs\\23\\bin\\ftp.exe")
M-x customize-group RET ange-ftp で Ange Ftp Ftp Program Name を編集しても良いです。個人的には customize を使った方法が好みです(どうでもいい)。
これで、あとはいつも通り C-x C-f /ftp:user@ftpserver:/path/to/file こんな感じでファイルを開けるようになります。
/ftp:user@ftpserver: TAB とすれば補完も効きます。パスワードは一回入れたらあとは聞かれないです。保存するのはもちろん C-x C-s です。
だいたいのファイル操作を透過的に扱えるようになるのが tramp / ange-ftp の利点です。
FTP ではなくて SFTP とか SSH を使いたい人は tramp の info を読んでみてください。その場合、Windows では PuTTY の plink + pageant を使うのが楽です。
すごく雑な駆け足の説明ですが。(・∀・；)
上で紹介した ftp.exe を NIS2010 のファイルインサイトにかけたら「100人未満」とか言われちゃって…。
いくら FTP が使われなくなりつつあると言っても、まったく使わないわけでもないし、Emacs から直接ファイル編集できたら便利ですし、知られていなかったらもったいないので紹介してみました。
ftp.exe 使うよりもいい方法があるよ！って場合はぜひ教えてください。
ftp-for-win32.zip に含まれる ftp.exe は Passive mode (PASV) がデフォルトになっているため、active mode でも ftp を使いたい場合にはデフォルトを変更する必要があります。ange-ftp の PASV 関連の設定を有効に使うためにもこちらを使うのが良さそうです。
$ diff -pu main.c~ main.c
--- main.c~ 1999-07-19 17:06:00.000000000 +0900
+++ main.c 2009-12-15 07:07:18.739744200 +0900
@@ -215,7 +215,7 @@ int main(int argc, char *argv[])
verbose++;
cpend = 0; /* no pending replies */
proxy = 0; /* proxy not active */
- passivemode = 1; /* passive mode *is* active */
+ passivemode = 0; /* passive mode is *not* active */
crflag = 1; /* strip c.r. on ascii gets */
/*
* Set up the home directory in case we're globbing.
が、白井秀行さんが他のバグも含めて直してコンパイルしてくださったファイルがあるので、それを使うのがお手軽なようです。
ftp-for-win32.new.tar.gz の Release\ftp.exe で置き換えてそのまま使えます。
passive も使えるけど active じゃないとダメという環境がありまして、自分とこで VS2008 を使ってバイナリを作ってみたけど warning だらけの上にまともに動きませんでした。
ともあれ先達に感謝。
Windows のデフラグツールの新バージョン、Diskeeper 2010 (DK14) の新機能 IntelliWrite がすごいので簡易なベンチマークを取ってレビューします。
IntelliWrite はディスクの断片化(フラグメントの発生)を事前に防止する機能です。日本では 19日に発売となった Diskeeper 2010 に初めて搭載されました。
その昔フラグメントが起こりにくいとされていたくせに、実はめちゃくちゃフラグメントしまくる NTFS の、まさに弱点を補うような機能です。(FAT については追記参照)
IntelliWrite はファイルシステムのフィルタドライバとして実装されています。
ベンチマークのテストプログラムは、無駄に並列に、無駄に細切れに、無駄にフラグメントを起こすような形で、ディスクへの書き込みを行なうものにしました。
では、早速、ベンチマークの結果を。
| IntelliWrite | OS | 試行回 | 所要秒数 | 超過断片数 |
| 無効 | Windows XP | 1 | 83 | 18,810 |
| 2 | 76 | 18,810 | ||
| 3 | 72 | 18,810 | ||
| 4 | 73 | 18,810 | ||
| 5 | 70 | 18,810 | ||
| 有効 | Windows XP | 1 | 38 | 30 |
| 2 | 43 | 30 | ||
| 3 | 36 | 30 | ||
| 4 | 31 | 30 | ||
| 5 | 37 | 30 | ||
| IntelliWrite | OS | 試行回 | 所要秒数 | 超過断片数 |
| 無効 | Windows 7 | 1 | 119 | 18,810 |
| 2 | 132 | 18,386 | ||
| 3 | 136 | 18,158 | ||
| 4 | 146 | 18,544 | ||
| 5 | 139 | 18,810 | ||
| 有効 | Windows 7 | 1 | 51 | 84 |
| 2 | 53 | 84 | ||
| 3 | 55 | 87 | ||
| 4 | 60 | 84 | ||
| 5 | 55 | 85 | ||
| IntelliWrite | OS | 試行回 | 所要秒数 | 超過断片数 |
テストプログラムの実行によって発生した超過断片の数と、その所要時間です。Windows XP と Windows 7 の二台は別のマシンで、CPU もディスクもコントローラも性能が異なります。「自動デフラグ」はオフにしてあります。断片数の値にあまりぶれがないのは、かなり地ならしした後の計測だからです。
解説は…いらないかな。IntelliWrite の有効 / 無効のあいだで、所要秒数と超過断片数の違いを見てください。
断片数は桁が三つ違いますから放っておいて、所要秒数の平均値をグラフで見易くすると以下のようになります。(繰り返しますが Windows 7 と Windows XP ではマシンの性能が異なります。Windows 7 と Windows XP の比較ではありません)
Netbook や Note PC でバッテリが気になる使い方をしていれば、この違いが強烈に効いてくると分かってもらえると思います。
IntelliWrite を使うと、
です。
これまでのデフラグソフトは「パフォーマンスを低下させない」あるいは「低下したパフォーマンスを元に戻す」ものでした。しかし Diskeeper 2010 の IntelliWrite はパフォーマンスを向上させます。
この記事、別に回し者じゃないけどべた褒めする気で書いてます。(・∀・；)
もっとも、断片化が発生しないディスク I/O の場合にはそもそも違いはでませんけどね。
ベンチマークの結果は、もう、なんつーか、びっくりでしょう？ぼくもびっくりしました。
これだけ断片化しまくる NTFS も酷いけどｗ、対してそれをほとんど阻止する IntelliWrite がすごい。
Diskeeper 2010 のダッシュボードでは、その日に発生した断片化のうち、IntelliWrite がどれだけ防止したのかが表示されます。このベンチマークのような極端な場合には 99% 表示となりますが、通常の使用では 60% ～ 80% 程度になるようです。公称は最大約 85% と言われています。もちろんディスクの使われ方によりますけど。
これまで Diskeeper を使ったことがない人にもぜひ試して欲しいので、どのエディションを買ったら良いのか、選び方を書いてみます。この blog の他の記事を見てもらえれば分かりますが、普段はさすがにここまで書かないです…。
安いです。とりあえずあらゆる Windows PC に入れとけ的なエディションです。
それでも、IntelliWrite と InvisiTasking が使えるので、Windows 標準のデフラグや他の似たような製品とは違うのがすぐに体感できると思います。Netbook や Note PC にちょうど良くて、かつ、コストパフォーマンスが抜群だと思います。
いまどきの子ならお小遣いで十分買えるんじゃないかな。
このエディションを最もお勧めします。
ミッドレンジ～ハイエンドのノート PC とデスクトップ PC には ProPremier 一択です。
Diskeeper の特徴的な機能はすべて使えます。サイズ 60GB 以上の HDD ボリュームでは、TVE という特別なデフラグエンジンを利用できます。元はハイエンドサーバ向けのデフラグエンジンでしたが、下位のエディションに降りてきました。いまどき一般的な 250GB 以上とかの HDD 容量があるなら違いが顕著です。500GB ～最近のテラバイト級の HDD を使っているなら下位のエディションとはデフラグ速度の性能差が 4倍～ 5倍くらいは出ると言われています。
母親の PC にこれをインストールしてあげたら 10歳は若返ったと喜んでます。(本人の感想であり効果効能をあらわすものではありませｎ)
4年前は十ン万円してたエンジンがいまなら一万以下。やりくり上手なあなたならきっと買えますよ。
業務用です。機能は ProPremier 相当です。
IntelliWrite は本来サーバでこそ待ち望まれた機能だと思います。一般的な web サーバ、ファイルサーバ、その他なんでも Windows Server ならこれで(Home Server は除く)。
SQL Server 使ってますか？効きますよ。お父さんなら決済通せるよね。
企業のネットワークで効率的に Diskeeper を展開・管理する場合、Administrator Edition の使用を検討してください。プッシュインストール便利です。
/ アップグレード版
学校・企業で導入の場合、また、クライアント版で 10本以上、サーバー版で 2本以上を導入する場合には、ボリュームライセンスが利用できます。
エンタープライズ用、あるいは廃人用です。
/ アップグレード版
現在最高性能のデフラグエンジン Titan Defrag Engine を積んでます。数年未来を先取りしたい人、デフラグがどうしても好きな人、これで勝てます。2TB のディスクいっぱい繋いじゃってボリューム組んでるとか(棒読み)、痛なんとか Itanium の人もこれです。
うふふ。
Diskeeper の各エディションが動作可能な Windows の SKU は購入前に必ず確認してください。トライアル版で試用してみるのが安心です。
Home エディションは Windows のビジネス向け SKU (Vista Business, Vista/7 Enterprise) にはインストールできません。但し、7 Professional にはインストールできます。
今回紹介した IntelliWrite は Diskeeper 2010 の Administrator を除く全エディションに搭載されています。テストプログラムの実行環境では ProPremier を使いました。
以前のバージョンにあったエディションごとの最大ボリュームサイズの制限は、Diskeeper 2010 から無制限になったようです。
SSD も使う場合は "with HyperFast" 版か "HyperFast 追加パック" で。
以下は開発元 Diskeeper Corporation のサイト。ぜんぶ英語です。
ベンチマークに使ったテストプログラムは以下の Perl スクリプトです。
先週、PDK 8.1 が出ました。
Windows 用の Graphical Debugger はデフォルトではインストールされなくなり、今後は Komodo IDE 使えばいいよってことのようです。Komode ねぇ…。Graphical Debugger がもし今後ディスコンされるようなら PDK の価値が実質減ることになりますかねえ。IDE が欲しいんじゃなくて、困ったときだけ頼れるデバッガがあれば良いんですけども。
Acer Aspire One D250 (AOD250) のメモリカードスロット(all in one カードリーダ)を一度も使ったことが無いのに気づいたので、SDHC カードを買って ReadyBoost をやってみた。
CrystalDiskMark でベンチ取ってみたら、速度はいまいちな感じ。ReadyBoost にギリギリ使えるという程度。Class 6 ではそんなもんなのかなぁ。カードリーダが腐ってるのかなぁ。
random アクセスとかなんでこんなに遅いんでしょうね。
ぼく自身の認識の問題だけども、ほんと、SSD のときもそうだったけど、フラッシュメモリが速いなんていう幻想は捨てなきゃいけないな。…というか妄想幻想で期待し過ぎなんですけども。ま、値段も値段ですしね。
Windows 7 の ReadyBoost では、Vista のときあったような容量やデバイス数の制限は取っ払われたそうだ。
フォーマットは FAT32, exFAT, NTFS が使えて、どれが良いという結論は無いっぽい。少しぐぐってみたところ、「ReadyBoost として使えたならどれでも良し」という感じのようだ。 Vista の時の情報では Microsoft は NTFS で ReadyBoost をテストしていないなんて情報もあった。
動けばおｋなら、ぼくとしてはわざわざ FAT 系を選ぶ理由も無いから NTFS にした。
割り当てる容量は物理メモリの 2倍あれば良し、3倍あれば尚良しという感じらしい。
そもそも ReadyBoost.sfcache がどんな用途に使われるのか、どの資料を読んでも明確には判然としない。Superfetch の結果がキャッシュされるとか、page file がキャッシュされるとか、あらゆる HDD へのアクセスがキャッシュされるとか、まぁとにかくそんな感じらしい。
ぼくはこの SDHC カードを他で使う予定もないので ReadyBoost 専用に設定してみたところ、実効容量 7.46GB 中 7.39GB の ReadyBoost.sfcache が出来上がって、5.28MB が余った。なんか微妙な余り具合…。
さて、肝心の効果の程は…はっきりいってイマイチ分からない。
昨日設定したばかりだし。そもそもこんなおもちゃ Netbook でごりごり作業なんてしないし…。物理メモリを 2GB に増設してみたけど、出荷時の 1GB だったときでも、そんなに困っていたわけでもない。(・∀・；)
そんなわけで、なにか目に見えて効果があったりしたらまた書くかも知れない。書かないかも知れない。
そういえば不満が一つあったので追記。
メディアを ReadyBoost 専用として使う場合でも drive letter を割り当てなければいけないようだ。割り当て無しと junction point に mount した場合を試してみたけど ReadyBoost のタブが出てこなかった。ユーザアプリケーションじゃないんだから、drive letter なんかいらんだろうに。ぶつぶつ…。
