helm-recentf-directoriesの修正

(2017-10-04更新) migemoに対応した

(2017-06-14更新) helmのupgradeに伴って(？)不具合が発生したのでcodeを修正。actionの定義が問題を起こしていたので関連部分を削除

helm-recentf-directoriesは、recentf listの中からdirectoriesを抽出し表示するfunction。

http://d.hatena.ne.jp/syohex/20120911/1347378503で紹介されていたcodeを便利に使わせて貰っているのだが、helmの更新で上手く動かない状態になっていた。

helm-imenu.elをベースに、きちんとした方法でsourceを作製する方法へ修正してみた。


(defun helm-recentf-directories-candidates ()
  "Make candidate list of recentf directories."
  (loop for file in recentf-list
when (file-directory-p file)
collect file))

(defclass helm-recentf-directories-source (helm-source-sync)
  ((candidates :initform 'helm-recentf-directories-candidates)
   (keymap :initform helm-find-files-map)
   (migemo :initform t)
   (action :initform 'helm-find-files-actions)))

(defvar helm-source-recentf-directories
  (helm-make-source "Recent Directories"
    'helm-recentf-directories-source))

(defun helm-recentf-directories ()
  "Alternative for helm-recentf that displays only directories."
  (interactive)
  (helm :sources 'helm-source-recentf-directories
:buffer "*helm recentf directories*"))


やっていることは:

* recentf-listからdirectoryな要素を取り出すfunctionを定義
* 以上のfunctionを候補とし、keymapとactionはfind-filesのものを流用したclassを作製
* helm-make-sourceに引き渡しsourceを作製
* sourceを使うfunctionを定義

Emacsのdiff-modeでdiff-hunk-prev/next等の挙動が変更された

diff-hunk-prevやdiff-hunk-nextといった、変更箇所間を移動するfunctionsにおいて、「header直下にあるhunkをskipする」よう挙動が変更された (@ commit 2c8a7e50d24daf19ea7d86f1cfeaa98a41c56085)。

例:

diff-modeで次のような表示があったとする (※1〜※3は場所の明示のためのマーク)

※1 diff --git a/path/to/changed/file b/path/to/changed/file
--- a/path/to/changed/file
+++ b/path/to/changed/file
※2 @@ -343,5 +343,10 @@
...HUNK 1...
※3 @@ -451,1 +451,3 @@
...HUNK 2...


最初のcursor positionが※1の時、従来はdiff-hunk-next ("n")で※2 → ※3と移動していた。しかし、今回の変更により※2は最初のhunkなのでskipされ、いきなり※3に飛んでしまう。

diff-hunk-prevも同じで、header直下のhunkはskipされるのがdefaultの挙動となっている。

何が問題か？

diff-modeで、具体的にどこが変更されたのかをわかりやすくする為に、diff-auto-refine-modeを設定している。これは、wdiffのように文字単位での変更を色付けしてくれるのだが、処理速度の問題からdiff-hunk-prevやdiff-hunk-nextでそのhunkをvisitした際に色付けされる仕組みである。

従って、今回の挙動変更によりheader直下の@@部分へのjumpがskipされると、diff-refine-hunkが適用されずに困る。

解決法

diff-hunk-next, diff-hunk-prevなどのoptional argumentsの一つであるskip-hunk-startにnilを渡して呼び出せば従来の挙動に戻る。

1. lambdaを使う

(with-eval-after-load "diff-mode"
  ;; diff-hunk-next
  (define-key diff-mode-shared-map "n"
    (lambda (&optional count)
      (interactive)
      (diff-hunk-next count nil)))
  ;; diff-hunk-prev
  (define-key diff-mode-shared-map "p"
    (lambda (&optional count)
      (interactive)
      (diff-hunk-prev count nil))))

2. オレオレfunctionを定義しkeybindする

(with-eval-after-load "diff-mode"

  (defun my-diff-hunk-next (&optional count)

    (interactive)

    (diff-hunk-next count nil))

  (defun my-diff-hunk-prev (&optional count)

    (interactive)

    (diff-hunk-prev count nil))

  ;; key bindings

  (define-key diff-mode-shared-map "n" 'my-diff-hunk-next)

  (define-key diff-mode-shared-map "p" 'my-diff-hunk-prev))

3. 気に入らない挙動を修正する

• adviceを使う？
• noflet, dfletあたりを使う？

Debian unstableのgcc-6 6.2.0-7以降でLinux kernelなどのbuildができない件への対処 (2016-12-03更新)

Debian unstableのgcc-6は、6.2.0-7から--enable-default-pieというflag付きでbuildされており、これがあちこちで問題を引き起こしている。

cf. https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=gcc-6

影響を受けているのはLinux kernelやSeaBIOSなど。

今の所backoutされる予定はなさそうなので、upstream (kernel側)で対応する迄は以下のworkaroundで我慢するか、自前でgcc-6 (6.2.0-6)をbuildするしかない。

Linux kernelのbuild

(2016-12-03追記)

Linux kernel 4.8.11でDebianのGCCで行われた変更に対応した。よって、それ以降のversionを利用する場合以下のworkaroundは不要。

stack protectorをenableにしていると:

> -fstack-protector not supported by compiler

と出てbuildが止まったり、そうでなくても:

> error: code model kernel does not support PIC mode

と出てbuildが止まったりする。

何れも、KCPPFLAGS=-fno-picをmake-kpkgあたりに渡してbuildするというworkaroundが紹介されている (cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841533)。

著者の環境ではworkaroundによりmake-kpkgでkernelがbuildできた。

ccache userへ

FirefoxやEmacsのbuildにも影響が出た。

一旦、ccache -C -zでcacheを破棄してrebuildすると良い。

ZoL (ZFS on Linux)

(2016-10-28追記)

ZoLはkernel modulesとしてbuildする関係から、もろにこの変更の影響を受ける。しかも、KCPPFLAGS=-fno-picを渡しても./configure scriptが途中でコケる。

(2016-12-03追記)

SPLもZFSも正常にbuildできるようになった。

それがGCC側の変更なのか、kernel sourceのupgradeの結果なのかは切り分けられなかった。

PulseAudio w/o systemd

以前、ffmpegでsound cardからのrecordingを取り扱ったが、systemdを排除した場合に変化が生じたのでメモ。

無論、以下のcommand lineで示すのは著者の環境に固有のものである。

以前:

% XDG_RUNTIME_DIR=/run/user/1000 ffmpeg -f pulse -ac 2 -ar 44100 -i alsa_input.pci-0000_00_1f.3.analog-stereo -acodec libvorbis -q 3 output.ogg

以降:

% ffmpeg -f pulse -ac 2 -ar 44100 -i alsa_input.pci-0000_00_1f.3.analog-stereo -acodec libvorbis -q 3 output.ogg

systemdを排除した場合、XDG_RUNTIME_DIRを設定しているpam_systemdも排除されるので、この指定が不要になる。というか/run/userが作られないのでerrorになる。

ZoLでZFSのdiskをmountする

zpool createでpoolを作製すると自動でmountされるが、これをexplicitに行う方法。

• zfs importでimport可能なpoolを検出
• zfs import <pool>で実際にimportを行う。このcommandが完了するとmountも行われる

PostgreSQL 9.5→9.6へupgradeに伴うMediaWikiへの影響と対策

Debian Sidで、PostgreSQLが9.5→9.6にupgradeされた。MediaWikiをPostgreSQL +textsearch_jaで使っている人は、clusterのupgradeをする前にtextsearch_jaのinstallが必要。

Upgrade手順の概要

• database clusterのbackupを取る
• (aptitudeとかで) PostgreSQLをupgrade (今回は9.5→9.6)
• PostgreSQLやweb serverなどを停止
• textsearch_jaを9.6のdevelopment filesでrebuild & install
• pg_upgradeclusterでclusterをupgrade
• textsearch_ja.sqlを修正し、対象databseに適用
• web serverなどをstart
• MediaWikiの動作確認
• 古い (9.5の)clusterをdrop

実際にいろいろとやってみた結果、上記の手順なら不具合が出ないか少なくて済むと思う。

なお、以下の個別の詳細手順については↑とは一致しない。というのも、aptitudeでupgradeすると、9.6がinstallされた時点でserverが9.6の空cluster＋port 5433でstartしてしまっているから。

PostgreSQLのupgrade

PostgreSQLそのもののupgradeに関しては/usr/share/doc/postgresql-9.6/README.Debian.gzを参照のこと。

ざっくりまとめると、install scriptによって新しいversion (9.6)の空っぽのclusterが自動で作られるので、それをdropしてから古いversion (9.5)のclusterを9.6にupgradeしてね、ということ。

pg_dropcluster 9.6 main
pg_upgradecluster 9.5 main

なお、不要になった古いversionのclusterは、変換したclusterが正常であることを確認した後に削除して良い。

portの修正

この時点で9.5のserverがport 5432を使っていたため、9.6のserverはport 5433を使ってしまった。/etc/postgresql/9.6/main/postgresql.confにportの設定があるので、これを5432に修正しておく。

portが変更されたままだとphp-fpmとかがPostgreSQLを見付けられなくなる。

MediaWiki関連のupgrade

textsearch_jaの更新

MediaWikiで全文検索できるようにするため、PostgreSQLで日本語の全文検索を行うためのtextsearch_jaをinstallする。SourceからbuildするのにPostgreSQLのdeveloment packageが必要なのでpostgresql-server-devをinstallしておく。

textsearch_jaのdirectoryにて:

make PGXS_USE=1
sudo make PGXS_USE=1 install

これで/usr/share/postgresql/9.6/contrib/あたりに関連filesがinstallされる。

※この手順が終わるより前にpg_upgradeclusterを実行すると、functionが見付からないとかでMediaWiki関連のdatabaseでerrorが大量に出る。

textsearch_jaの適用

MediaWikiが使用しているdatabaseにtextsearch_jaをinstallする。しかし、その前にPostgreSQLの仕様変更に伴う修正をtextsearch_ja.sqlに行う必要がある。

具体的には"LANGUAGE 'C'" → "LANGUAGE c"に全て変更する。

cf. http://stackoverflow.com/questions/12514664/postgresql-procedural-language-c-not-found

修正後、

psql -f /usr/share/postgresql/9.6/contrib/textsearch_ja.sql <database>

既にfunctionがあるとかでerrorが出る場合は、一旦

psql -f /usr/share/postgresql/9.6/contrib/uninstall_textsearch_ja.sql <database>

を実行してから、あらためてやりなおす。

GCC 5.x → GCC 6.xへ完全移行 @Debian Sid

Debian GNU/Linux Sidではしばらく前にdefaultのGCCが5→6になったのだが、Firefoxのbuildに不具合がありGCC 5.xを残してあった。

今日、Firefox 49 (release)をbuildしてみた所、mach packageがうまくいかない不具合が解消されていたので、晴れてGCC 5 seriesをuninstallした。