2018年12月14日金曜日

Astrolux S42 (w/ Nichia 219C)のfirst impression

Astrolux S42 (以下、S42)というLED flashlightを購入したのでfirst impressionなど。


図1 S42全形

図2 ヘッド部分にあるスイッチ (breathingしている)



S42は2種類のconfigurationがあるが、個人的にneutral white 〜 warm whiteが好きなのでNichia (日亜化学) 219Cを搭載したmodelを選択した (もう片方はCree XP-G3)。

図3 ヘッド部分の拡大

4つのLEDに個別のTIR (total internal reflector)を装着してあり (図3)、照射パターンは非常にフラット。手元などの至近距離を照らすような室内での使用に向いている。


図4 FENIX LD10 (上)、S42 (中)、18650 (下)

本体チューブの長さを変更して18350 (CR123Aと同サイズ)か18650を使用できるが、今回は18650タイプのチューブが装着されているものを選んだ。それでもAA×1のFENIX LD10とさほど大きさが変わらないコンパクトさには驚く (図4)。

今回購入した際にはSAMSUNGのINR 18650が付属していた。負極側に絶縁用のテープが張ってあるのに気付かず不良品かと思ったのは良い思い出。


操作体系


S42は操作体系が複雑である (とは言ってもNovatacのflashlightのようにprogrammableではないだけましだが)。

Modesが多いので2つのmode groupsに分割してあり、初期状態 (電池を入れた直後)ではGroup 1である。普段遣いならば4 modesに限定されたGroup 2で事足りるだろう。しかし、本機の売りであるはずのMAX 1600 lmが出せないのが玉に瑕。

図5 操作体系のDAG

なお、図5の太線は短い間隔で二度押し、点線は長押し、普通の線は一度押しである。


軽く使ってみての評価


pros


* 非常にコンパクト (1AAタイプと比較しても対して違いを感じない)
* 20 sec限定ではあるが1600 lm (w/ Nichia 219C)出せる ※high drain対応のIMRもしくはINRが必要
* 普段遣いに向いたシンプルな操作体系 (mode group)が用意されている

cons


主にコンパクトさを目指した結果として:

* 操作体系が複雑。しかもそれをスイッチ1つで行う必要がある
* Turbo (1600 lm)が20 secしか持たない。仮にこの制限がなくても、小さいので放熱が追い付かず常用できなかっただろう
* IPX8の競合製品が溢れる中、当機はIP65である。防塵性能が具体的に表記されている (そして最大である)点は良いが、防水は5 (いかなる方向からの水の直接噴流を受けても有害な影響を受けない)に留まる


こんな人におすすめ


* コンパクトかつ強力なライトが欲しい
* 手元など近距離を照らす用途が主、あるいは屋内での使用
* 広い範囲をフラットに照らしたい、いわゆるfloodな配光が好み
* 水に沈める使い方はしないがある程度の防水性能は欲しい
* 18650に手を出したいが専用充電器を持っていない (要USB出力のある電源+USBケーブル)

2018年12月13日木曜日

[NieR:Automata] 個人的にお気に入りのYoRHa部隊員達

NieR:Automataの全世界累計販売数350万本突破と、"NieR:Automata Game of the YoRHa edition"発表を記念して。

******

作中に登場する個性的なYoRHa部隊員達の中でも、特に気になった機体を紹介したい。なお、以下で用いる名称は一部を除いて勿論仮称である (「ヨルハ部隊員」となっていて、本編中では固有の識別符号が確認できないので)。

ちなみに、以下の画像で2Bさんが黒髪なのはDLCで手に入るヘアカラーを使っているため。黒髪だと月の涙の花飾りがとても映えるのでお気に入り。


……SOULCALIBUR VIコラボの通称”2P”を本編に追加するDLC希望。


オアシスちゃん


砂漠地帯のオアシスにいる子 (図1)。

図1 オアシスちゃん (仮称)

やってきた鳥の群れについて穏やかな口調で語る所がとても可愛い  (図2)。

図2 鳥の群れについて語るオアシスちゃん

彼女は物語が進み[検閲済み]が[検閲済み]した後もここに居るYoRHaの一人である。


箱入り娘ちゃん (戦闘タイプ)


バンカーの指令室にいる子 (図3)。


図3 箱入り娘ちゃん (仮称)とオペレータさん (心配性)

本人は人類の勝利に貢献する気満々なのだが、専属のオペレータさんが過保護で心配性なため、いつまで経っても出撃させてもらえずにいるちょっと不憫な戦闘タイプ。

図4

図5 出撃への思いを語る箱入り娘ちゃん

察するに、彼女が出撃すると一人で戦争を終わらせてしまうほどの力を秘めた最終兵器なので、ホワイト司令官が密かに裏から手を回して出撃できないようにしているんだろう。きっと。


ノービスちゃん


続いてバンカーの指令室にいる子 (図6)。

図6 ノービスちゃん (仮称)
 製造から日が浅いためか任務の前に緊張している初々しさが素敵 (図8)。

図7

図8 任務への意気込みは十分だ

なぜか[検閲済み]の調整が間違っていて、担当オペレータさんの[検閲済み]が[検閲済み]として認識されていたといううっかりさん (本人というよりは調整の担当者が)。


8B (たぶん)と担当オペレータさん (たぶん)


バンカーの8Bの部屋にいる二人。

地球に降りていろいろと見て回りたいというオペレータさんと、できることなら連れて行きたいという8Bの関係が実に良い。


図9 語り合う8B (?)とオペレータさん

地上で会うことになる8Bとは見た目が違っている。

2018年12月12日水曜日

Kali LinuxをVirtualBoxにinstallしてみた

Hardware requirementsは確認しよう


最初、HDDの領域として最大8 GiBを割り当てたのだがinstallが途中で止まってしまった。

host machineのdmesgにもdirect I/Oがどうのでdiskの内容がcorruptしたかも、みたいな赤文字のerror messageが出た。何事かと思ったら、原因は8 GiBでは足りないことにあった。

Kali Linuxのofficial websiteにあるinstallation prerequisitesによれば:

  • A minimum of 20 GB disk space for the Kali Linux install.
  • RAM for i386 and amd64 architectures, minimum: 1GB, recommended: 2GB or more.
  • CD-DVD Drive / USB boot support

cf. [Kali Linux Hard Disk Install – Kali Linux](https://docs.kali.org/installation/kali-linux-hard-disk-install)

とある。実際、install後にdfで見てみると10 GiB近く (9.6 GiBぐらい)使っていた。これはinstallation processだって止まる。

現在のversionのVirtualBoxはGUI (Virtual Media Manager)から簡単にdisk領域の拡張ができるので8 GiB → 32 GiBに拡張して解決した。

Swap partitionの削除に際しての注意


Partitionの分割を間違ってswapを有効にしてしまったので、fdiskで消してext4 (root partition)に割り当て直してresize2fsで拡張したまでは良かったが、その後bootにやたら時間が掛かるようになってしまった。

systemd-analyzeで見てみたりもしたのだが、いまいち原因が分からず。というのも、systemd-analyzeから詳細が見えるのはsystemdによるboot processであって、systemdが呼び出される前については分からないからだ (systemd-analyze plotで出力できるchartにおける"kernel"の部分)。

GRUB menuからrescue modeで立ち上げてみると、/etc/initramfs-tools/がどうのというmessageが出ており、ここで30 secほど待たされていた。調べてみると、/etc/initramfs-tools/conf.d/resumeというfileに指定されているswap partitionを待っているのが原因と分かった (cf. [#860533 - initramfs-tools: boot delayed by 30sec. due to /scripts/local-block loop - Debian Bug report logs](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860533))。

RESUME=none

と変更して解決した (cf. [Linux Manpages Online - man.cx manual pages](https://man.cx/initramfs.conf(5%29))。

Metasploit Frameworkに関する注意


Metasploit FrameworkはDBMS backendとしてPostgreSQLを利用している。

起動時にPostgreSQLへ接続するのだが、折しもPostgreSQL 10 → PostgreSQL 11へのupgradeを先に行ってclusterの移行をせずにそのまま削除したため、port 5432に接続できずerrorとなった。

/etc/postgres/11/main/postgresql.confにて:

port = 5433

となっていた箇所を

port = 5432

に変更して解決した。

PostgreSQL 10のclusterと11のclusterが同時に立ち上げられると、default port 5432が10のclusterで使用され、11のclusterは自動的に5433を使う。この名残りが今回のerrorの原因である。

2018年12月11日火曜日

VirtualBox 5.2のGUI (Qt5)でVirtual Media ManagerからMachine Toolsに戻れない時はtoolbarを出そう

*** 2019-01-24 追記 ***

最近、VirtualBox 6.0 (virtualbox-6.0.2)がDebian experimentalに入った。GUIの見た目が変化しており、この記事の内容は当て嵌らない点がある。

*** 追記ここまで ***


VirtualBoxの管理画面 (GUI)の設定をいじったことをすっかり忘れていて、Virtual Media Managerに遷移したあと (元の) Machine Toolsに戻れない状態になっていた。

調べてみると同じ現象で困っていた人がいて、適当な場所で右クリックしてToolbarを出せば直ると分かった (cf. [virtualbox.org • View topic - \[Resolved\] Manager GUI: How do I switch back from media manager to machines list ?](https://forums.virtualbox.org/viewtopic.php?f=1&t=90242))。

なお、VirtualBoxはDebian sidのrepositoryから導入しており、versionは5.2.22-dfsg-2。


キャプチャ画像で見る復旧までの手順


1. VirtualBoxを起動した時の画面 (Machine Tools)。Defaultの設定からはいじってあるのでToolbarが表示されていない



2. File → Virtual Media Manager を選択すると……



3. Virtual Media Managerに遷移した



4. が……Machine Toolsに戻れない



既に触れた通り、Machine Toolsに戻るにはToolbarを表示させる必要があるので復活させる。

5. Menubar (File Helpなどが並んでいる部分。赤く色を付けた領域)にカーソルを合わせて右クリック



6. Context menuが表示されるので、Show Toolbarを選択する



7. Toolbar (赤く色を付けた領域)が復活した



8. Toolbarの中にあるMachine Toolsボタン (赤く色を付けた部分)をクリック



9. Machine Toolsに戻れた


おつかれさまでした。


おまけ


Machine Toolsにて、Detailsの部分で右クリックすると表示する情報を変更できる。


2018年12月10日月曜日

mpvのkey割り当てを変更する

LinuxなどUnix-like OSでは特にお世話になるmultimedia playerであるmpv。

実はkey (に限らずmouseも含めたinput一般)に対する機能の割り当てを~/.config/mpv/input.confで設定できる。mpvのsource treeの中にあるetc/input.confをcpしてそれを編集するのが良いだろう。

最初はleft/rightのarrow keysにそれぞれseek -1/+1 secを割り当てようかと考えていたのだが、これはShiftを押しながらでできるとfileを眺めていて気付いた。

cf. [change seek / jump time span when using keys arrow-right / left · Issue #4396 · mpv-player/mpv · GitHub](https://github.com/mpv-player/mpv/issues/4396)

2018年12月9日日曜日

Linux boxでラジオ番組を自動録音する returns

以前、同じ目的の記事を書いた:

cf. [Linux boxでラジオ番組を自動録音する](https://typeinf-memo.blogspot.com/2016/01/linux-box.html)

今回、再び同じtitleで記事を書いたのは、録音に使っているLinux box (Debian sid)のinit systemを遂にsystemd化した (ずっとsysvinitで粘っていたが限界が訪れた)のが原因で録音に失敗したためである。

症状


* ffmpegを使って指定したpulseaudioのsourceから録音できない (cronからのみ)

logを取ってみるとこんな感じだった:

ffmpeg version N-92645-gc782e7aa9e Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 8 (Debian 8.2.0-10)
  configuration: --enable-gpl --enable-version3 --enable-nonfree --enable-libass --enable-libfdk-aac --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libpulse --enable-gnutls --enable-ladspa --enable-libbluray --enable-libflite --enable-libmodplug --enable-libaom --enable-opencl --enable-vaapi --enable-vdpau --enable-pic --enable-shared --extra-cflags='-fPIC -Ofast'
  libavutil      56. 24.101 / 56. 24.101
  libavcodec     58. 41.102 / 58. 41.102
  libavformat    58. 23.102 / 58. 23.102
  libavdevice    58.  6.101 / 58.  6.101
  libavfilter     7. 46.101 /  7. 46.101
  libswscale      5.  4.100 /  5.  4.100
  libswresample   3.  4.100 /  3.  4.100
  libpostproc    55.  4.100 / 55.  4.100
alsa_input.pci-0000_00_1f.3.analog-stereo: Input/output error

これは多分前回の記事と同じerrorで、XDG_RUNTIME_DIRを指定すれば解決するはず。

なお、以前に記事を書いた時とpulseaudioのsourceが少し違っているが、以前systemd→sysvinitに戻した際変化した (cf. [PulseAudio w/o systemd](https://typeinf-memo.blogspot.com/2016/10/pulseaudio-wo-systemd.html))。

その時の変更をまた戻すことになった訳である。

対策


* XDG_RUNTIME_DIRを指定してffmpegを実行する

ついでに、backgroundでinvokeしたffmpegのPIDを取得しておき録音時間sleepさせた後kill -TERMで殺す、という方法ではなく、ffmpegの-t optionでduration指定する方法に改めた。

XDG_RUNTIME_DIR=/usr/user/1000 "${FFMPEG}" -f pulse -ac 2 -ar 44100 -i "${SOURCE}" -acodec libvorbis -q 3 -t ${DURATION} "${FILEPATH}" >${LOGFILE} 2>&1 &
なお、${FFMPEG}のような大文字の定数はscript内で
FFMPEG=/usr/local/bin/ffmpeg
といった具合に定義してある。


今後の展望


headless運用をしていて普段loginしない (maintenanceのためにたまにsshでloginするくらいの) Linux boxで自動録音をするなら、PulseAudioをsystem-wideなdaemonとして立ち上げておく方法が考えられる。

loginしていない時にはPulseAudioのper-user daemonが立ち上がっていないのでsourceも存在せずerrorを吐くと思うので。

ちなみにPulseAudioのdeveloperはPulseAudioのsystem-wide modeを推奨していない:

cf. [SystemWide](https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/SystemWide/)


HiKey 620 (HiKey LeMaker)へのDebian stretch (stable) installで嵌った

*** 更新履歴 ***

* 2019-01-28 画像にミスがあったので差し替え (WiFi/BT chipの名称を修正)

*** 更新履歴ここまで ***


※この記事で紹介しているHiKey 620 (HiKey LeMaker)は古い (2015年頃の)SBCなので、これから購入するのなら後継機であるHiKey 960やHiKey 970或いはDragonBoard 410cなどが推奨される

図1 HiKey 620とmicroSD card
図2 表面のIC配置
図3 インタフェースの配置


結論: 公式websiteのdocumentに従おう

これからHiKey 620 (HiKey LeMaker)にDebianをinstallしたい人が参照すべきdocuments


cf. [Documentation for HiKey - 96Boards](https://www.96boards.org/documentation/consumer/hikey/hikey620/)

英語だが難しくないので、downloadするfilesや手順を確認しつつ従っていけばできるはず。

重要な点としては、

* 最初にrecovery.binをhisi-idt.pyで書き込むこと
* この時にPython 2.7を使うこと


簡単な経緯


* HiKey 620 (LeMaker version)、以下HiKeyにDebian stretchを導入しようと考えた
* 以前eMMCにinstallしていたDebian jessie (oldstable) → stretch (stable)にupgradeする最中に止まってunbootableになった
* eMMCにUEFIを導入するために色々試してみたがことごく失敗 (switch scienceやDebian Wikiの手順など)
* Linaroの公式websiteのdocumentをよく見ると、他で紹介されている手順とは異なっていることに気付く (hisi-idt.pyでrecovery.binを書き込むなど)
* Linaroの公式documentのやり方に従ったらDebian stretchの導入に成功

Debian Wikiやswitch scienceで紹介されている(古い)手順から変更されていることに気付くのが遅れて、随分遠回りをする羽目になった。もう一度改めて書くが、

上で紹介したLinaro公式websiteのdocumentに従うこと

を強く推奨する。


おまけ


microSD cardからのboot


Setting jumper の1-2をclose、3-4と5-6はopenにしておく。


root partitionの拡張


SD cardにDebianをinstallした場合、SD cardの一部の領域 (たぶん1.8GiBぐらい)しか利用されていない。Raspberry Pi seriesにinstallするRaspbianの場合はinstallerが拡張してくれるoptionがあるが、こちらはfdisk等を使って手動で行う必要がある。

* fdisk /dev/mmcblk1
* partition tableの表示 (p)
* partition 1がboot partition、partition 2がDebianのroot (ext4)
* ここで一旦partition 2を消す (d)
* 以前partition 2だった部分を含めたpartitionを改めて作製する (n) → 新生partition 2
* ext4のsignatureが残っているけどどうするかを聞かれたら「残す」を選択
* 一応書き込んでおく (w) ※著者の環境では失敗しfdiskから抜けた

動いているLinux kernelは変更前のpartition tableの情報を持ったままなので、更新するためにHiKeyをrebootする。無事に立ち上がったらsudo resize2fs /dev/mmcblk1p2を発行。ext4の場合、filesystemをonlineで拡張できる。

最後に確認すると、こんな感じになるはず:

linaro@linaro-developer:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            912M     0  912M   0% /dev
tmpfs           196M  5.4M  191M   3% /run
/dev/mmcblk1p2   29G  1.6G   26G   6% / ← root filesystem
tmpfs           979M     0  979M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           979M     0  979M   0% /sys/fs/cgroup
/dev/mmcblk1p1   64M  848K   64M   2% /boot/efi
tmpfs           196M     0  196M   0% /run/user/0
tmpfs           196M     0  196M   0% /run/user/1000

今回は32GB (=29.8GiB)のmicro SD card (Toshiba)を使ったので、root partitionが29Gである。

2018年11月24日土曜日

Debian packageのinstall/uninstall processが失敗した時に手動でどうにかする方法

Debian packageのinstall/uninstall processの実体は、packageに含まれている幾つかのshell scriptである。

これらは/var/lib/dpkg/info/以下に展開されており、例としてx11-utils packageについてのfilesは、

x11-utils.conffiles
x11-utils.list
x11-utils.md5sums
x11-utils.postinst
x11-utils.postrm

がある。このうち、scriptが.postinstと.postrmの2つで、名前の通りそれぞれinstall後及びuninstall後に実行される内容が記述されている。

何かしらの要因でinstall scriptに不具合が発生してinstall processが失敗する時 (unstableでは時々ある)は、ここを直接修正すれば中途半端な状態を解消できる可能性がある。

最近では、iptables packageのpostinst scriptにinstall (upgrade)が失敗する不具合があった (2018-11-24現在修正済み)。この場合は、/var/lib/dpkg/info/iptables.postinstを手動で修正してaptitudeなどからupgradeをやり直した。

cf. [#913811 - iptables fails to upgrade from 1.8.1-2 to 1.8.2-1 - Debian Bug report logs](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913811)

2018年10月21日日曜日

Debian sidでnfsdが立ち上がらなくなったのでscriptを修正 (sysvinit)

*** 注意 ***

Debianはinit daemonとしてsystemdを採用している。

個人的な趣味から今回の問題が起きたPCではsystemdを入れていない (sysvinitで運用)。おそらく、maintenanceされていないsysvinit用のscriptが原因でこのような問題が発生したと考える。

よって、普通にsystemdを使っているuserにはaffectしない。

*** 注意ここまで ***


大容量HDDを搭載したPCでnfsdを立ち上げて、LAN内にあるPCからNFSv4でmountできるようにしてあるのだが、kernelのupgrade後にmountできなくなった。

Debianでは、NFSの機能がnfs-commonとnfs-kernel-serverに分割されている。このうちnfs-commonの方は問題なかった。

一方、nfsdが立ち上がっていないし、以下のようなmessageも出るので、nfs-kerrnel-server側のscript内でerrorが発生しているとわかった。

% sudo service nfs-kernel-server restart
[ ok ] Stopping NFS kernel daemon: mountd nfsd.
[ ok ] Unexporting directories for NFS kernel daemon....
[ ok ] Exporting directories for NFS kernel daemon....
[....] Starting NFS kernel daemon: nfsd
[warn] Not starting: portmapper is not running ... (warning).

script (/etc/init.d/nfs-kernel-server)を眺めてみると、92-99行にportmapperがどうのというwarningを出力する箇所で、rpcinfoというcommandへのpathが$PREFIX/sbin/rpcinfoとなっている:

        # See if rpcbind is running
        $PREFIX/bin/rpcinfo -p >/dev/null 2>&1
        RET=$?
        if [ $RET != 0 ]; then
            echo
            log_warning_msg "Not starting: portmapper is not running"
            exit 0
        fi

rpcinfoのreturn valueがnon zeroなのでifに引っ掛かってexit 0している訳だ。

rpcinfoがどういう出力なのか確かめてみようと打ってみる:

% sudo /usr/sbin/rpcinfo -p
sudo: /usr/sbin/rpcinfo: command not found

/usr/sbin/rpcinfoが存在しない。では、rpcinfoがどのpackageに含まれているのか (あるいは存在しないのか)調べてみる:

% dpkg -S rpcinfo
rpcbind: /usr/bin/rpcinfo
nmap-common: /usr/share/nmap/scripts/rpcinfo.nse
rpcbind: /usr/share/man/man8/rpcinfo.8.gz

sbinじゃなくてbinになっている。移動したようだ。では改めて:

% /usr/bin/rpcinfo -p                                         
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  57281  status
    100024    1   tcp  59599  status
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    3   tcp   2049
    100003    3   udp   2049  nfs
    100227    3   udp   2049
    100021    1   udp  49265  nlockmgr
    100021    3   udp  49265  nlockmgr
    100021    4   udp  49265  nlockmgr
    100021    1   tcp  33993  nlockmgr
    100021    3   tcp  33993  nlockmgr
    100021    4   tcp  33993  nlockmgr
    100005    1   udp  49349  mountd
    100005    1   tcp  53921  mountd
    100005    2   udp  60977  mountd
    100005    2   tcp  32831  mountd
    100005    3   udp  52847  mountd
    100005    3   tcp  49695  mountd

scriptではrpcinfoの実行結果 (というか出力は/dev/nullに棄てて、return valueだけを見て)からportmapperがsupportされているかどうかを確認していた。この出力を見る限り、portmapperはsupportされていると分かる。

scriptの当該箇所を修正 ($PREFIX/sbin/rpcinfo → $PREFIX/bin/rpcinfo) して、改めて試してみる:

% sudo service nfs-kernel-server restart
[ ok ] Stopping NFS kernel daemon: mountd nfsd.
[ ok ] Unexporting directories for NFS kernel daemon....
[ ok ] Exporting directories for NFS kernel daemon....
[....] Starting NFS kernel daemon: nfsd mountdrpc.mountd: svc_tli_create: could not open connection for udp6
rpc.mountd: svc_tli_create: could not open connection for tcp6
rpc.mountd: svc_tli_create: could not open connection for udp6
rpc.mountd: svc_tli_create: could not open connection for tcp6
rpc.mountd: svc_tli_create: could not open connection for udp6
rpc.mountd: svc_tli_create: could not open connection for tcp6
. ok 

ここでtcp6やudp6に関するerror或いはwarningが出ているのは、IPv6を使ってないのでkernel levelでsupportを切っているため。明示的に使っていなくても切らない方がいいのかも知れない。或いは、/etc/netconfigのtcp6とudp6の行をcomment outする手もある。

何れにしてもnfsdが立ち上がるようになり、NFS clientからもmountできるようになった。

今回このような問題が発生したのは、Debianではinit daemonがsystemdに変更されたため、sysvinitに由来するscriptが既にmaintenanceされていないからと考えられる。


2018年10月19日金曜日

DDSKKで変換をcancelする時にC-gを二度押す必要があるのはannotationのせいだった

DDSKKでannotationの表示を有効にしていると、変換を取り消してかなに戻す時C-gを二度押す必要がある (時がある)。

具体的には、変換後間も無くC-gでcancelしようとすると二度押さないと戻らない。少し時間を置くと一回で戻る。

(setq skk-annotation nil)でannotationを無効にすると、一度でかなに戻る。

現在の所、これを回避するにはannotationを使わないしか方法がない。


Debian packageのdependencyをごまかして (強制的に) installする方法

*** 更新情報 ***

2018-10-22現在、Debian sidにおけるcalibreの最新版はqtbase-abi-5-11-2へ対応したversionへ更新されたので、以下の不整合は発生しない。

*** 更新情報ここまで ***


calibreというebook readerがある。

読むだけではなく、formatの変換なども行える (swiss army knife的に)多機能なsoftwareで、個人的に使えないと非常に困るのだが、先にupdateされるQt libraryへのdependencyで不整合を起こしuninstallされ (かけ)ることがままある。

最近も、Qt relatedなpackagesが更新されて、これらが提供するvirtual packageであるqtbase-abi-5-11-0がqtbase-abi-5-11-2へ上がった。calibreの実体programを提供するpackageであるcalibre-bin 3.32.0_dfsg-1+b1はqtbase-abi-5-11-0にdependしているため不整合を起こしてuninstallされかけた。

calibreを新しいQtとlinkしてbuildした上でcontrolを修正するのが最も真っ当な方法だが、たかが5.11.0 → 5.11.2の変化ならどうにかなるだろう、という根拠のない推測からdependencyをごまかしてuninstallされないようにした。実際、calibreは無事立ち上がり、特に問題なく動作しているので、ひとまずこの状態で使ってみる。

無論、ABIのversionが変わっている以上互換性は保証されず、強制的にinstallしても動作しなかったり、意図しない動作になったりする可能性があるので注意。

やり方の概要


以前にも同じようなことをした記憶があったので検索してみた所、

cf. https://typeinf-memo.blogspot.com/2015/08/debian-unstable-sidexperimental.html

に似たような記事を書いていた。

前回はcontrolから不要なdependencyを削除していたが、今回もやることは余り変わらない (今回はversionを書き換えるだけ)。

* binary packageをdownloadして展開
* control.tar.xzを展開してcontrolを書き換える
* 改編したcontrolを含むcontrol.tar.xzを生成
* 変更したcontrol.tar.xzを含むbinary packageを生成
* installして動作確認

具体的な手順


* calibre-binのbinary packageをdownload

% apt-get download calibre-bin

* arでbinary packageを展開

% ar x calibre-bin_3.32.0_dfsg-1+b1_amd64.deb

control.tar.xz、data.tar.xz、debian-binaryが生成される。

* control.tar.xzを展開

% tar xJf control.tar.xz

control、md5sumsが生成される

* 適当なtext editor (vimなど)でcontrolを書き換える。今回の場合"qtbase-abi-5-11-0"を"qtbase-abi-5-11-2"へ書き換えて保存する

* 書き換えたcontrolを含むcontrol.tar.xzを作る

% tar --create --file control.tar.xz --xz md5sums control

* 作り直したcontrol.tar.xzを含むbinary packageを生成する

% ar rcs calibre-bin_3.32.0_dfsg-1+b1_amd64.deb debian-binary control.tar.xz data.tar.xz

* dpkg -iでinstallし動作確認

% sudo dpkg -i calibre-bin_3.32.0_dfsg-1+b1_amd64.deb

* aptitudeなどを使っている場合はupdateによる書き換えを防ぐためにcalibre-binをholdしておくとよい

おつかれさまでした。

2018年10月15日月曜日

SwissMicros DM42のfirmwareがv3.11へ更新され、USB接続時のfreezeが解消された

SwissMicros DM42のfirmware updateに伴って、USB cableを接続するとfreezeするというtroubleが発生していた (cf. https://typeinf-memo.blogspot.com/2018/09/swissmicros-dm42usbtrouble.html)が、DMCP v3.11のreleaseに伴い遂に解決された。

DMCP v3.11: 2018-10-11
Fix for "Bug when connecting to USB cable"



Firmwareをupdateするには:

* DM42のinternal FAT diskにfirmwareを転送しmenuからupgradeする
* PCに接続してdfu-utilなどでupgradeする

以上2つの方法があるが、USB cableを接続してfreezeする場合はどちらも使えない。

但し、裏蓋を外してRESETとPGM buttonsを露出させれば、freeze bugに関係なくbootloader modeを強制でき、dfu-utilでfirmwareをupdateできる。

具体的な方法については過去記事を参照のこと:

Shuttle SZ170R8のBIOS update (v2.10→v2.11)

2018-10-08にreleaseされたBIOS v2.11にupdateした。

cf. BIOS v.210 cf. [Shuttle Global - SZ170R8](http://global.shuttle.com/main/productsDownload?productId=1995)

更新内容はCPUのmicrocodeのupdate。

Update手順については過去記事を参照のこと (cf. https://typeinf-memo.blogspot.com/2018/04/shuttle-sz170r8bios-uefi.html)。

2018年10月8日月曜日

Raspbianのawkがsegfaultを吐いた

atで登録しているcommandが失敗していたので何が起こったのかと調べてみた所、awkがsegmentation faultを起こしていると分かった。

試してに実行してみると:

% awk --version
awk: fatal error: internal error: segfault
zsh: abort      awk --version

以前、sudoがsegvったことを思い出し (cf. https://typeinf-memo.blogspot.com/2018/06/watchdograspiansudofork-bombreboot.html)、取り敢えずrebootをかけてみたら直った。

2018年10月5日金曜日

SwissMicros DM42のfirmware v3.10がreleaseされた (2018-10-15更新)

*** 更新情報 ***

v3.11でUSB cableを繋いだ際に発生するfreezeは解消された cf. https://typeinf-memo.blogspot.com/2018/10/swissmicros-dm42firmwarev311usbfreeze.html

*** 更新情報は以上 ***


DM42のDMCP v3.10がreleaseされていたのでupdateした。

なお、v3.9.1 → v3.10へupdate後も、所持している個体ではUSB cableを繋ぐとerror messageが出てfreezeする症状は発現する。

2018年9月18日火曜日

Raspbianのlatest firmware (4.14.70-v7+ #1143)がshutdown時にkernel panic

*** このページの不具合は修正済み (2018-09-22更新) ***

shutdown / reboot時にkernel panicする不具合は4.14.70-v7+ #1144で著者の環境では再現せず、修正された模様。

なお、2018-09-22現在の最新版は4.14.71-v7+ #1145である。

*** 以上 ***


Raspberry Pi 3 model B (RasPi3B)をRaspbianで運用しているが、rpi-updateでupdateした最近のfirmware (4.14.69あたりから? 2018-09-18現在最新の4.14.70-v7+でも)だと、shutdown時にkernel panicを起こしてrestartしない。

普段RasPi3Bをheadless (displayに繋がずに)運用しているため、なぜrebootしないのか原因が分からなかったが、試しにHDMIにLCDを繋いでみたところ判明した。

Raspberry Pi Forumsによると、

* Bluetoothのon/offによる → BTがoffだとkernel panicする
* USBからのbootだとこのbugがaffectする?

などの書き込みがある。

workaroundとしては、8月中旬ごろのfirmwareにdowngradeする手がある。

cf.

* [Is this a stable kernel? - Raspberry Pi Forums](https://www.raspberrypi.org/forums/viewtopic.php?t=222448)
* [After last updates RPI 3+ hangs on shurdown/reboot if bluetooth off - Page 2 - Raspberry Pi Forums](https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=222475&start=25)

2018年9月15日土曜日

SwissMicros DM42のUSB関連のtrouble (2018-10-15更新, v3.11で解消)

(更新記録)

* 2018-10-15 firmware v3.11で当問題が解決されたのでupdateを推奨 cf. https://typeinf-memo.blogspot.com/2018/10/swissmicros-dm42firmwarev311usbfreeze.html
* 2018-09-18 画像を追加

(更新記録は以上)

Firmware v3.7あたりにupgradeしてから、DM42にUSB cableを接続すると次のようなerrorが出てfreezeするようになった:

ErrSrc/main.c:867
Err:main.c:867
Err:SetFreq 2
ERROR: 0777
Desc:SetFreq 2

このため、firmwareのupgradeができない、FAT diskへのaccessができない状態。

SwissMicrosのforumには既に報告されている cf. [Bug when connecting the USB cable - www.SwissMicros.com](https://forum.swissmicros.com/viewtopic.php?t=1922)が、まだ完全に解決された訳ではないようだ。なお、全てのDM42で発現する訳ではなく、稀らしい……。

この状態でもPGMとRESETの2つのhardware buttonsを使ってbootloader modeにした後、USB cableを接続したPCからdfu-utilを実行してfirmwareをupgradeできる:

Bootloader mode can be activated from main Setup menu: System > Bootloader or by resetting the calculator using RESET button while PGM button is pressed too.

To be more precise, the sequence of entering bootloader mode using RESET and PGM button is: - press and hold PGM button - press and release the RESET button - release the PGM button
cf. [DM42 User Manual](https://www.swissmicros.com/dm42/doc/dm42_user_manual/#bootloader_mode_activation)

手順


* 2本のネジ (図1の緑色の矢印)を取って裏蓋を外す → 下部にツメがあるので、USB connector等がある上の方 (LCDがある方)から外す。隙間にテレカのような薄いプラスチックを挟んで開けるのがお勧め
* PCB上にRESET buttonとPGM buttonがある → 裏蓋をつけたままだとRESETのみaccessible (図1の赤色の矢印)


図1 DM42背面
図2 裏蓋を外した様子 (左側が本体、右側がカバー)

図3 PCB拡大 (赤矢印=RESET, 黄矢印=PGM, 水色矢印=電池, 紫矢印=圧電ブザー)

* PGM (図3の黄色の矢印)を押しながらRESET (図3の赤色の矢印)を押すと強制的にbootloader modeになる → この時画面に変化がないのでmodeに入ったかどうかわかりにくいが、入力を受け付けず画面にも変化がないので判別できる
* USB cableを接続するとPCがDM42を認識するので、予めdownloadしておいたfirmwareをdfu-utilで書き込む cf. https://typeinf-memo.blogspot.com/2017/12/swissmicros-dm42firmware-update.html (過去記事)
* 終了したらRESET buttonを押す
* 表示される"About"でfirmwareのversionを確認する
* 裏蓋を戻してネジをしめる

結果とworkaround


この方法で無事v3.9.1 (2018-09-15現在の最新版)にupgradeできたが、USB cableを接続すると依然errorが表示されfreezeする。

workaroundとしては、

* USBへ接続せずに普通に使い続ける
* v3.5にdowngradeする

の2つがある。

v3.11へのupdateを行うと解決する。

SwissMicros DM15Lのfirmware upgrade (v27)

DM15Lのfirmare v27が公開されていたのでupgradeした。

Upgradeの手順については過去記事 (https://typeinf-memo.blogspot.com/2016/07/swissmicros-dm-15lfirmware-upgrade.html)を参照されたい。

2018年7月16日月曜日

repositoryのprotocol指定が間違っているとhg pullが失敗する

当たり前と言えば当たり前のtitleなのだが。これまでhttpでokだった場合でも、httpsへの移行が進んでいるのだなと。


Mozilla FirefoxなどのsoftwareはMercurialで管理されている。

Firefoxの最新版 (mozilla-central)を取得しようとした所、失敗した:

% hg pull -u
pulling from http://hg.mozilla.org/mozilla-central/
abort: error: Connection reset by peer

もしかしたらrepositoryの場所が移動したり、serverが死んだりしているのかと確認してみたが、普通に生きている。


ふと、protocolがhttpでなくhttpsであると気付きこれを修正してみた。

% vim .hg/hgrc
# example repository config (see 'hg help config' for more info)
[paths]
default = https://hg.mozilla.org/mozilla-central/

正常にpullできるようになった。


2018年7月14日土曜日

VirtualBoxのkernel moduleをdkmsでrebuildする

*** VERR_LDRELF_RELOCATION_NOT_SUPPORTED への対応 ***

2018-07-14現在の情報: Debian unstableでVirtualBox (OSE)を利用している場合、最新版5.2.14-dfsg-4ではerrorが再発してVMを実行できない。5.2.14-dsfg-3か、testing或いはstable版を利用されたい。

以前のunstableのpackageはsnapshot.debian.orgなどから取得可能。

cf. [#902897 - virtualbox: fails to start vm (VERR_LDRELF_RELOCATION_NOT_SUPPORTED) - Debian Bug report logs](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902897)

2018-07-16 update: 5.2.14-dfsg-5で修正された模様。

2018-07-17 update: 5.2.14-dfsg-7で(ようやく)修正された模様。


dkmsを手動で


自前でbuildしたkernelをinstallした後、VirtualBoxのkernel object (kernel module)がerrorを吐いてloadできなくなったので、手動でkernel moduleをrebuildした。通常はdkmsでkernel moduleをinstallしていれば、packageやkernelのupgradeに伴い自動でrebuildしてくれるので必要ないのだが。

手順


dkms commandを実行する際にmodule nameとかversion numberとかが必要なので、status subcommandで確認しておく。

% sudo dkms status
virtualbox, 5.2.14, 4.17.6, x86_64: installed

man dkmsを見てみるとautoinstallとかそれっぽいsubcommandがあるのだが、実行してみてもrebuildされなかったので、一旦moduleを削除してやり直してみる:

% sudo dkms remove virtualbox/5.2.14 -k 4.17.6

改めてaddし直す:

% sudo dkms add virtualbox/5.2.14 -k 4.17.6

この時点でmoduleは登録されているが、実際のbuildは行われていない。autoinstall subcommandを発行してrebuildさせてみる:

% sudo dkms autoinstall -k 4.17.6

moduleのbuildが終わるとVirtualBoxのkernel moduleがloadされるはずだが、一応serviceでrestartをかける:

% sudo service virtualbox restart


2018年6月16日土曜日

Windows 10 version 1709 → version 1803へupgrade

遂にupdateが降ってきたので適用した。ちなみにWindows 10 Home。

1709のend of service (EOS)自体は2019-04-09まで (cf. https://support.microsoft.com/ja-jp/help/13853/windows-lifecycle-fact-sheet)なのでそれまでにupdateしておけば問題ないと思うが、security関連のpatchが降ってくるかどうかはよく分からない。

例によってあちらこちらで不具合の報告がなされているので不安だったし、Windows PCが使えなくなる時間がそれなりにあるし、一通り設定を見直したり動作確認したりする必要があるしで面倒なことこの上ない。個人的にはWindows PCはゲームをするためにしか使わないのでまだ良いが、これで仕事用とかだと恐しくなる。

取り敢えずやったことをざっと挙げていくと:

* Edgeが犯人かは分からないがlogin後に不要なshortcuts (yahooとか)が作られたので削除
* 「設定」の中にあるものを全部見て不要な物を片っ端から切る (カメラとかマイクのアクセスとか、Timelineの収集とか)
* Spybot Anti-Beaconを入れてtelemetryを全部切る
* 不要なAppsの削除 (特にメニューから消せないやつ) → PowerShellを使って消す
* MS-IMEの「A」とか「あ」とか表示されるが目障りなので消す → メニューから、及びレジストリをいじって消す
* 気休め程度にディスクの最適化 (C:)
* RDPWrapper libraryは入れ直したら動いた (v1.6.2から1803に対応しているらしい)

このあたりのwebsitesが参考になると思う:

* [How to turn off the Timeline and your activity history, in Windows 10 | Digital Citizen](https://www.digitalcitizen.life/how-disable-timeline-activity-history-windows)
* [Windows10標準アプリを削除、再インストールする方法 | Windows10 FAQ](http://windowsfaq.net/settings/delete-application/)
* [Windows10 で画面中央に「あ」「A」と表示されるものを消したい - すなばいじり](http://psn.hatenablog.jp/entry/2017/04/18/090001)

あとは様子見。10日以内であれば1709に戻せるという話だったはず。

SwissMicros DM42のfirmware update (v3.5 → v3.7)

*** 更新履歴 ***

firmware v3.7〜v3.10ではUSB cableを接続した際に一部の個体でfreezeするbugがあったがv3.11で解消された。それ以降のfirmwareへの更新を推奨する。

cf. https://typeinf-memo.blogspot.com/2018/10/swissmicros-dm42firmwarev311usbfreeze.html ※v3.11へのupgradeについて

USB cableを接続した場合freezeするbugに遭遇している場合は、裏蓋を開けてPGM buttonを露出すればbootloader modeに入れるので、そこからv3.11以上のfirmwareにupgradeされたい。

cf. https://typeinf-memo.blogspot.com/2018/09/swissmicros-dm42usbtrouble.html ※裏蓋を開いてPGM buttonでbootloader modeにする手順

2018-09-15現在、v3.7以上のfirmwareにupgradeした場合、稀にDM42にUSB cableを接続するとerror messageが出てfreezeする個体がある。最新版であるv3.9.1でも解決されていないので、不幸にもaffectした場合は裏蓋を開けてRESET+PGMのbuttonsを押してbootloader modeに入り、dfu-utilからv3.5に戻すなどの対処をする必要がある。

cf. https://typeinf-memo.blogspot.com/2018/09/swissmicros-dm42usbtrouble.html

*** 更新履歴ここまで ***


SwissMicros DM42のfirmwareがupdateされていた (v3.5 → v3.7)のでupgradeしてみた。

なお、documentにもhistory.htmlにも、v3.7から2つに分割されたfirmwareの正しいupdateの方法が書かれていない。もしかするとまだbetaとかの扱いなのかも知れないので注意。
※公式documentは更新済み。


準備


用意するもの


* Linux PC (WindowsやMacでも可)
* SwissMicros DM42
* USB A-microUSB B cable
* 細いピン

firmware filesの準備


DM42のfirmwareが置かれているpageから2つのfilesをdownloadする (2018-06-15現在):

* DMCP_flash_3.7.bin
* DM42-3.7.1.pgm


updateの手順


Linux hostからDM42のfirmwareをupdateするにはdfu-utilを使う方法と、DM42に内蔵されているFAT disk (USB memory)からupdateする方法がある。今回はDM42のFAT diskをPCからUSB memoryとしてmountしfirmware filesを書き込んだ後、DM42単独でfirmware updateする。

DM42のinternal FAT diskにfilesを転送


* ON
* [ ] + [0] (SETUP)
* 3. Activate USB Disk -> [ENTER]
* USB cableでDM42とPCを接続
* DM42のFAT diskをmount eg. sudo mount -o rw,noatime,uid=1000,gid=1000 /dev/sdb /mnt/dm42
* Downloadしておいたfiles 2つを転送 eg. cp -i DMCP_flash_3.7.bin DM42-3.7.1.pgm /mnt/dm42
* umount
* cableを外す
* EXIT

Internal FAT diskからfirmware update


DMCP_flash_3.7.bin


* [ ] + [0] (SETUP)
* 4. System ->
* 2. Enter System Menu
* 1. Flash firmware from FAT
* 電池の消耗を防ぐため (&途中で電源が落ちないように) USB cableを繋ぐよう表示される
* cableを接続するとflashが開始される
* しばらく待つとRESETするよう指示が出るので、裏側のRESET buttonを押す
* EXIT

ここまででDMCP_flash_3.7.binの書き込み終了。

DM42-3.7.1.pgm


* まだFree42が起動する状態ではないので何かしらmessageが表示される
* 3.か4.あたりのprogram infoだったかrun programだったかを選択 (空覚え)
* DM42-3.7.1.pgmを選択
* 書き込みが始まるのでしばらく待つ
* RESETするよう指示が出るので、裏側のRESET buttonを押す
* EXIT

DM42-3.7.1.pgmの書き込み終了。以上で計算機が使えるようになっているはず。

Firmwareのversion check


* [ ] + [0] (SETUP)
* 5. About ->
* DM42の値がv3.5あたりからv3.7.1あたりになっているのを確認する
* EXIT

おつかれさまでした。

2018年6月15日金曜日

watchdogを導入したRaspbianでsudoが使えなくなったのでfork bombでrebootさせた話

Raspberry Pi 3 model BにRaspbian (armv7l)を入れて有線routerとして利用しているが、sudoがsegmentation faultを吐いて使えなくなる状況に陥った。

どうやらsudoのpermissionがおかしくなったことが要因らしいが、理由はどうあれRaspbianでsudoが使えないのは致命的である。普通にinstallして特に設定しない場合、Raspbianではrootとしてloginできない。一般userが必要に応じてsudoする運用が前提だからだ。

こうなると、aptでsystem updateも、rpi-updateでfirmware upgradeも、shutdownもできない。最終手段として強制的に電源を切る (=microUSBのcableを引っこ抜く)ぐらいしか思い付かないが、NAND flashのstorageではあまりやりたくない (HDDでも嫌だが)。

そこで、watchdogをinstallしていることを思い出し、fork bombでsystemをdownさせてrebootさせようと思い付いた。つまり:

* fork bombを発動
* watchdogが発動 → reboot
* boot processでfsckが実行される → filesystemが修復されpermissionが回復
* sudoが使えるようになる (はず)

fork bombにはshell scriptで実行する方法と、Cあたりでprogramを書いて実行する方法がある。今回はshell scriptより速く効きそうなCでprogramを書いて実行した。

#include <unistd.h>

int main(void){
  while(1){
    fork();
  }
}
これをforkbomb.cとして保存し、gcc -o forkbomb forkbomb.cでcompile。実行前に気休めとして一応syncを発行しておく。

./forkbombを実行。systemがfreeze → watchdogによりrebootがかかるのを待つ。

無事rebootし、fsckが実行されたのか、sudoは何事もなく使えるようになった。


2018年6月12日火曜日

ZoLのsplがzfsのrepositoryにmergeされた

ZFSはlicenseの問題でmainline kernelに含まれずout-of-treeなので、Linuxで使いたい場合は大きく2つの選択肢がある:

* ZFS on Linux (ZoL)
* ZFS-FUSE

ZoLがkernel moduleとしてのimplementationで、ZFS-FUSEはuserland (FUSE)でのimplementation。

OSがLinuxでなくて良いならillumos (OpenSolaris)やFreeBSD (TrueOS)などを使う手もある (出所的あるいはlicense的にはこっちの方が素直か?)。

さて、この度、ZoLをsource (git)からbuildする手順が簡単になった。これまではzfsをbuildするにはspl (Solaris porting layer)というSolarisとLinuxの違いを吸収するlayerが必要で、それを別途build & installしなければならかった。

それが先日、splのgit repositoryからautogen.shが削除されていたのでどうしたのかと思いgit logを見てみたら、zfsのrepositoryにmergeされたとあった。今後はsplをgit cloneしてautogen.sh→configure→make→make installという手順が不要になった。

2018年5月28日月曜日

helm-default-display-bufferの変更で手元のhelm-swoopが使用不能になったので修正

2018-05-28現在の最新のhelmにupdateした所、helm-swoopが
Symbol's value as variable is void: helm-swoop-pattern
なるerrorを吐くようになったので原因を調べてみた。

順当にhelm-swoopのgithubのpageを見てみる


今年(2018)の1/22に:

cf. [Symbol's value as variable is void: helm-swoop-pattern · Issue #123 · ShingoFukuyama/helm-swoop](https://github.com/ShingoFukuyama/helm-swoop/issues/123)

そのものずばりのtitleのissueがfileされている。この中で触れられているように、helmのcoreの方でhelm-default-display-bufferに修正が入って、それが影響しているとのこと。その後のdiffなどを見ている限り、vanillaのまま使っているなら対応済みのようだ。

原因と対策


個人的には、helm-swoop実行時にfull widthで表示させるために、問題になっているhelm-swoop-split-window-functionを自前で設定していたのが原因でerrorが出ていた。helm-default-display-bufferの変更に合わせて適当にargumentを追加しておく:

*** before ***

-  (setq helm-swoop-split-window-function
- '(lambda (buffer)
-    (helm-default-display-buffer buffer)))

*** after ***

+  (setq helm-swoop-split-window-function
+ '(lambda (buffer &optional resume)
+    (helm-default-display-buffer buffer)))

もしかしたら&optional resumeじゃなくて&rest resumeにしておいた方が、今後またargumentsに変更があった時に対応しやすいかもしれない。

おまけ1. 原因の特定の仕方


*scratch* bufferで:

(setq debug-on-error t)
(setq helm-swoop-pattern "")

などとお膳立てした後に徐にhelm-swoopを起動するとbacktraceが見られる。

自前の設定が問題だというのはこれで分かった。

おまけ2. helm-occur


helm-swoopはとても便利に使っているが、そのalternativeとなるものも存在している。その一つがhelm-occurで、helm-occurを実行する他に、isearchからもhelm-occur-from-isearchを使えば呼び出せる。

helm-swoopはメンテの頻度が低いとか (だからと言って本家にも取り込まれなさそうだ)、実行速度に問題があるとしてhelm-occurを勧める向きもある。機能の全てではないにしろ、候補の選択に伴ってcursor positionも移動するような設定も可能みたいなので一応紹介はしておく。

ちなみに設定すればmigemoも使える。


2018年5月26日土曜日

hg infoをMercurial 4.6に対応させる

Mercurial 4.6に更新されたために色々な部分が変更された (cf. [WhatsNew - Mercurial](https://www.mercurial-scm.org/wiki/WhatsNew))。

現在のMercurial repositoryに関する情報を表示するhg info (cf. [InfoExtension - Mercurial](https://www.mercurial-scm.org/wiki/InfoExtension))というextensionを導入しているのだが、4.6へのupgradeに伴ってerrorを吐くようになったので修正。

原因は2つある:

1. cmdutil.commandが削除された
2. changectx()の仕様変更

cmdutilの仕様変更への対処


changeset:   37957:fb0de0bcd297
user:        Matt Harbison <matt_harbison@yahoo.com>
date:        Thu May 10 21:53:48 2018 -0400
summary:     cmdutil: drop deprecated precursor of registrar.command (API)
diff -r f1f8b655da32 -r fb0de0bcd297 mercurial/cmdutil.py
--- a/mercurial/cmdutil.py      Fri May 11 00:53:29 2018 -0400
+++ b/mercurial/cmdutil.py      Thu May 10 21:53:48 2018 -0400
@@ -37,7 +37,6 @@
     patch,
     pathutil,
     pycompat,
-    registrar,
     revlog,
     rewriteutil,
     scmutil,
@@ -3151,12 +3150,6 @@
         if f in copied:
             repo.dirstate.copy(copied[f], f)

-class command(registrar.command):
-    """deprecated: used registrar.command instead"""
-    def _doregister(self, func, name, *args, **kwargs):
-        func._deprecatedregistrar = True  # flag for deprecwarn in extensions.p
y
-        return super(command, self)._doregister(func, name, *args, **kwargs)
-
 # a list of (ui, repo, otherpeer, opts, missing) functions called by
 # commands.outgoing.  "missing" is "missing" of the result of
 # "findcommonoutgoing()"
diff -r f1f8b655da32 -r fb0de0bcd297 mercurial/extensions.py
--- a/mercurial/extensions.py   Fri May 11 00:53:29 2018 -0400
+++ b/mercurial/extensions.py   Thu May 10 21:53:48 2018 -0400
@@ -145,9 +145,6 @@
     """Check if extension commands have required attributes"""
     for c, e in cmdtable.iteritems():
         f = e[0]
-        if getattr(f, '_deprecatedregistrar', False):
-            ui.deprecwarn("cmdutil.command is deprecated, use "
-                          "registrar.command to register '%s'" % c, '4.6')
         missing = [a for a in _cmdfuncattrs if not util.safehasattr(f, a)]
         if not missing:
             continue
diff -r f1f8b655da32 -r fb0de0bcd297 tests/test-extension.t
--- a/tests/test-extension.t    Fri May 11 00:53:29 2018 -0400
+++ b/tests/test-extension.t    Thu May 10 21:53:48 2018 -0400
@@ -1697,10 +1697,6 @@
   >     pass
   > EOF

-  $ hg --config extensions.nonregistrar=`pwd`/nonregistrar.py version > /dev/nu
ll
-  devel-warn: cmdutil.command is deprecated, use registrar.command to register
'foo'
-  (compatibility will be dropped after Mercurial-4.6, update your code.) * (glo
b)
-
 Prohibit the use of unicode strings as the default value of options

   $ hg init $TESTTMP/opt-unicode-default

代わりにregistrar.commandを使えとあるので書き換えた。

- from mercurial import cmdutil
+ from mercurial import registrar

- command = cmdutil.command(cmdtable)
+ command = registrar.command(cmdtable)

changectx()の仕様変更への対処


changeset:   37852:8b86acc7aa64
user:        Martin von Zweigbergk <martinvonz@google.com>
date:        Sat Apr 28 23:16:41 2018 -0700
summary:     context: drop support for looking up context by ambiguous changeid
(API)
... 
-def changectxdeprecwarn(repo):
-    # changectx's constructor will soon lose support for these forms of
-    # changeids:
-    #  * stringinfied ints
-    #  * bookmarks, tags, branches, and other namespace identifiers
-    #  * hex nodeid prefixes
-    #
-    # Depending on your use case, replace repo[x] by one of these:
-    #  * If you want to support general revsets, use scmutil.revsingle(x)
-    #  * If you know that "x" is a stringified int, use repo[int(x)]
-    #  * If you know that "x" is a bookmark, use repo._bookmarks.changectx(x)
-    #  * If you know that "x" is a tag, use repo[repo.tags()[x]]
-    #  * If you know that "x" is a branch or in some other namespace,
-    #    use the appropriate mechanism for that namespace
-    #  * If you know that "x" is a hex nodeid prefix, use
-    #    repo[scmutil.resolvehexnodeidprefix(repo, x)]
-    #  * If "x" is a string that can be any of the above, but you don't want
-    #    to allow general revsets (perhaps because "x" may come from a remote
-    #    user and the revset may be too costly), use scmutil.revsymbol(repo, x)
-    #  * If "x" can be a mix of the above, you'll have to figure it out
-    #    yourself
-    repo.ui.deprecwarn("changectx.__init__ is getting more limited, see "
-                       "context.changectxdeprecwarn() for details", "4.6",
-                       stacklevel=4)

それぞれ以下のように対応した:

-    ui.write(_("Base Hash: %s [hg id -r0]\n") % (hex(repo.changectx(0).node()),))
+    ui.write(_("Base Hash: %s [hg id -r0]\n") % (hex(repo.changelog.node(0)),))

changectx().node()が削除されたので、changelog.node()に変更。

-    ui.write(_("Files: %s [hg manifest | wc -l]\n") % (len(repo.changectx(numrev-1).manifest()),))
+    ui.write(_("Files: %s [hg manifest | wc -l]\n") % (len(repo[numrev-1].manifest()),))

changectx().manifest()が削除されたので、repo[].manifest()に変更。


まとめ


--- info.py.orig 2018-05-26 15:23:14.524041991 +0900
+++ info.py 2018-05-26 15:23:25.523203385 +0900
@@ -7,9 +7,15 @@
 # This software may be used and distributed according to the terms
 # of the GNU General Public License, incorporated herein by reference.

+from mercurial import registrar
 from mercurial.i18n import _
 from mercurial.node import short, hex

+cmdtable = {}
+command = registrar.command(cmdtable)
+
+@command('info')
+
 def info(ui, repo):
     """Print information about the repository"""
     try:
@@ -18,17 +24,11 @@
         numrev = len(repo)

     ui.write(_("Repository: %s [hg root]\n") % (repo.root,))
-    ui.write(_("Base Hash: %s [hg id -r0]\n") % (hex(repo.changectx(0).node()),))
+    ui.write(_("Base Hash: %s [hg id -r0]\n") % (hex(repo.changelog.node(0)),))
     ui.write(_('Revisions: %s [hg tip --template "{rev}"]\n') % (numrev,))
-    ui.write(_("Files: %s [hg manifest | wc -l]\n") % (len(repo.changectx(numrev-1).manifest()),))
+    ui.write(_("Files: %s [hg manifest | wc -l]\n") % (len(repo[numrev-1].manifest()),))
     ui.write(_("Cloned From: %s [hg paths default]\n") % (ui.config('paths','default'),))
     default_push = ui.config('paths','default-push')
     if default_push:
         ui.write(_("Push To: %s [hg paths default-push]\n") % (default_push,))

-
-cmdtable = {
-    # "command-name": (function-call, options-list, help-string)
-    "info": (info, [], _("hg info"))
-}
-

Links


* [MercurialApi - Mercurial](https://www.mercurial-scm.org/wiki/MercurialApi)

2018年4月29日日曜日

Linux kernel 4.16.5でRealtekのUSB SD/MMC card readerを使う

以前は普通に使えていた気がするのだが、いつの間にやらSD cardを挿入しても認識しなくなっていた (`/dev/mmcblk0p1`のようなdevice fileが作られない)ので、原因を調べてみた。

結論から言うと、必要なdevice driversが組み込まれていなかったのが原因だった。

環境


* ASUS X200LA
* Debian GNU/Linux (amd64, sid)
* Linux kernel 4.16.5
* Realtek RTS5129 card reader controller


実際の手順


何を探せばいい?


`lsusb`を使うと実際に使えるかどうかは別として接続されている (認識している?)devicesを表示してくれるので、それを元にしてkernelに組み込むべきdevice driver(s)を探せばいい。

今回の場合は:

% lsusb
...
Realtek Semiconductor Corp. RTS5129 Card Reader Controller
...

RealtekのRTS5129というdeviceに対するdriverを探す。

対応しているdriverやmoduleは?


kernelを自前でbuildしているので、取り敢えず`make menuconfig`を使い、それっぽいoptionがないかを探してみる。"realtek"で検索してみたところ、それっぽいoptionが見付かった:

`MMC_REALTEK_USB` ("Device Drivers" → "MMC/SD/SDIO card support" → "Realtek USB SD/MMC Card Interface Driver") = `rtsx_usb_sdmmc`

そのまんまな名前だ。helpにもそれっぽいことが書かれているので試してみる価値はあると思ったのだが、なぜかmenuに表示されておらず、故にy/mで選択もできない。その原因は依存関係が満たされていないためだった:

`MISC_RTSX_USB` ("Device Drivers" → "Misc devices" → "Realtek USB card reader") = `rtsx_usb`

このoptionをy/m何れかに設定すると、`MMC_REALTEK_USB`を選択する項目が表示されこちらもy/m何れか選択できるようになる。

動作確認


Kernelをrebuildしてinstall、rebootした後に、SD cardを差し込んで認識されることを確認。`lsmod`でも見てみる:

% lsmod | rg mmc
mmc_block
rtsx_usb_sdmmc
mmc_core
rtsx_usb

2018年4月21日土曜日

fontconfigの設定が腐っていたので修正

最近、何かにつけて

Fontconfig error: failed reading config file

というerror messageが目に付いたので、何が原因なのかを探って解決するまで。

概要


症状


* 様々なapplication softawreを立ち上げ時に"Fontconfig error: failed reading config file"というerror messageが複数回 (4回)出る


推測


* fontconfigに関する設定の間違い
* これまで出ていた記憶がない(最近になって見掛けるようになった)ので、updateによる書式やoptionの変更があった?

原因


* fontconfigの設定directory `/etc/fonts/conf.avail/`にある一部のfilesがおかしなことになっていた
* 具体的には`65-0-fonts-beng-extra.conf`など、設定filesと同じdirectoriesが複数存在しており、そのdirectoriesの中にそれぞれ更に同名のfileが存在していた
* `/etc/fonts/conf.d/`以下から貼られているsymlinksは当然切れている → 読み込めないerrorの原因
* なぜ`65-0-fonts-beng-extra.conf`などと言ったdirectoriesが作られたのかは分からないが、過去のinstallerのbugとか野良packagesの仕業とか何かのworkaroundで忘れていたものかも知れない?

対処


* 当該directoriesを削除し、.dpkg-new suffixのついたfilesをmv


2018年4月13日金曜日

Shuttle SZ170R8のBIOS (UEFI) v2.10がreleaseされていたのでupdate

3/27にShuttle SZ170R8のBIOS (UEFI)のv2.10がreleaseされていたのでupdateした。

Intel CPUのspeculative executionに関するvulnerabilities (いわゆる"Meltdown"と"Spectre")に対応したmicrocodeを含む。

BIOS v2.10 cf. [Shuttle Global - SZ170R8](http://global.shuttle.com/main/productsDownload?productId=1995)

update手順の概要


Boot mediaの準備


Rufus (cf. [Rufus - Create bootable USB drives the easy way](https://rufus.akeo.ie/))でbootable USB memoryを作り、そこにdownloadしてきたzip archiveの中身を展開して書き込む。

* Rufusで、vfat (FreeDOS)なbootable USB memoryを作製
* BIOS (UEFI)のzip archiveをdownloadして展開
* DOS/の中にあるflash.batとBIOS/をflash memoryのtop directoryにcp

SZ170R8の準備


* 何度も電源が切れたり入ったりを繰り返すので、予めHDDとか周辺機器は外しておく

Update process


* USB memoryからbootしてcommand promptが出たらflash.batを実行
* 画面に進捗状況が表示されるので暫く待つ
* 更新が終わるまで何度かrebootを繰り返す

BIOS設定の確認


* DEL keyを何度か押すとBIOS画面に入るので、設定を戻すなり確認するなりして保存
* 適当にmenu画面か何かで止めておいてスイッチで電源断
* この辺りでHDDや周辺機器を戻す

Bootの確認


* 電源を投入し正常にOSがbootすることを確かめる


2018年3月26日月曜日

SwissMicros DM42 及び DM15Lのfirmwareがupdateされた

SwissMicros DM42とDM15Lのfirmwareがそれぞれupdateされた。

DM42はv3.5が、DM15Lはv26がそれぞれ最新のfirmware。詳しくはlink先を参照のこと:

cf. [SwissMicros | Firmware](https://www.swissmicros.com/firmware.php)

また、firmware updateの方法については以前書いているので参照されたい:

https://typeinf-memo.blogspot.com/2017/12/swissmicros-dm42firmware-update.html ※DM42のfirmware updateについて
https://typeinf-memo.blogspot.com/2016/07/swissmicros-dm-15lfirmware-upgrade.html ※DM15Lのfirmware updateについて

2018年3月17日土曜日

Raspberry Pi 3 Model B+が発表された

先日、Raspberry Pi財団よりRaspberry Pi 3 Model B+ (3B+)が発表された。

cf. [Raspberry Pi 3 Model B+ on sale now at $35 - Raspberry Pi](https://www.raspberrypi.org/blog/raspberry-pi-3-model-bplus-sale-now-35/)

Raspberry Pi 3 Model Bからの主な改良点は:

* SoCがBCM2837B0へupgrade (1.4GHz)
* SoCが金属ヒートシンクに覆われた → 放熱性up
* GbEへの対応 (3までは100BASE-Tだった) ※USB2.0 (up to 480MB/s)での接続
* PoEへの対応 ※HATによる対応
* Wi-Fiのupgrade (802.11ac対応、特に5GHz帯の改善)
* 電源の強化

など、Network関連の強化 (connectivity)に主眼が置かれている。

なお、価格は据え置かれて$35のまま。例として、RSコンポーネンツでは「発売開始時期未定」となっているが、日本では電源を除いて4500円ぐらいで購入できるだろう (2018-03-17現在入手可能な3Bは税込み4320円)。

2018年3月16日金曜日

SwissMicros DM42のfirmware 3.4aが公開された (3/7)

DM42のfirmware 3.4aが3/7に公開されていたのでupgrade。

3.4ではoccasionally lockupなどの不具合に対する修正が行われているので、所有者はfirmware updateを検討されたい。

cf. [Firmware History](https://www.swissmicros.com/dm42/firmware/history.html)


2018年3月12日月曜日

SwissMicros DM42で簡単なprogramを組んでみる

SwissMicros DM42 (HP-42Sの互換機)で、有名な「ユークリッドの互除法」(Euclidean algorithm)を実装してみる。


ユークリッドの互除法について


ユークリッドの互除法は2つの自然数xとyがあった時に、その最大公約数 (xとyに共通する最も大きな約数、割り切る数)を求める手順だ。面倒なので、最大公約数を以後GCD (greatest common divisor)と書く。

古代ギリシアの数学者ユークリッド (Euclid)によって記された『原論』(Elements)の中に書かれており、紀元前300年ごろには存在していたというから凄い。

このアルゴリズムでは、以下のように計算を進める:

1. xをyで割った余りをrとする
2. rが0でなければ、x←y、y←rとして1.に戻る
3. rが0ならば、その時のyが元々のxおよびyのGCDである


電卓を叩いて確かめてみる


例として、DM42を使い手動で1785と374のGCDを求めてみる。

使うDM42の機能について:

* MOD → y÷xの余りを計算してxに積む
* LASTX → 直前までxに入っていた内容を保持するL-registerの内容をxに積む
* x≶y → X-registerとY-registerの内容を交換する


1. 1785
2. ENTER
3. 374
4. MOD ⇒ 289 ※余りは0ではない
5. LASTX ⇒ 374 ※直前のxの内容を呼び出した
6. x≶y ⇒ 289 ※xとyの内容を交換
7. MOD ⇒ 85 ※余りは0ではない
8. LASTX ⇒ 289
9. x≶y ⇒ 85
10. MOD ⇒ 34 ※余りは0ではない
11. LASTX ⇒ 85
12. x≶y ⇒ 34
13. MOD ⇒ 17 ※余りは0ではない
14. LASTX ⇒ 34
15. x≶y ⇒ 17
16. MOD ⇒ 0 ※余りが0になった!
17. LASTX ⇒ 17 ※これが1785と374のGCD

MODの結果が0になるまで、ひたすらLASTXしてx≶yしてMODする、を繰り返すだけでGCDが計算できるとわかる。このような単純作業はもちろん機械にやらせるべきだ。


DM42でprogramming


DM42 (HP-42S)に限らず、RPN方式の関数電卓では基本的にキー入力の羅列がそのままprogramになる。ただし、practicalなprogramを記述するには、LBLや条件分岐やjump命令などが必要になる。

DM42のprogramの構造は:

LBL "LABEL"
...
END (或いはRTN)

のようになっている。LBL (label)はprogram (或いはsubroutine)の名前で、様々な手順が続き、最後はRTN (return)或いはENDである。


PRGM (□+R/S)でprogram modeに入る。

先頭の行番号はDM42が勝手につけてくれるので無視すると、こんな感じに書ける:

LBL "GCD"
LBL 02
MOD
X=0?
GTO 01
LASTX
X<>Y
GTO 02
LBL 01
LASTX
RTN

EXITでprogram modeを抜ける。

programを実行するにはXEQを押す。すると、software menuにprogramで指定したlabel (LBL)が表示されるので、GCDを選ぶ。ただし、今回のprogramはとにかく手順をそのまま書いただけなので、予めY-registerに大きい方の自然数を、X-registerに小さい方の自然数をそれぞれ積んでおく必要がある。

1. 1785 [ENTER]
2. 374
3. XEQ → GCD ⇒ 17

X-registerには17が残っているはずだ。


そして最小公倍数へ


ちなみに、GCDとくればLCM (least common multiple)——最小公倍数も忘れてはならない。2つの正の整数について:

GCD(x,y) LCM(x,y) = xy

という関係が成り立つと知られているので、GCDが分かっていればLCMも計算できる。

LCM(x,y) = xy / GCD(x,y)

1785と374の場合は39270である。


2018年3月11日日曜日

Seagateの12TB (≒10.91TiB) HDDを導入した

メインマシン兼NASとして使っているPCのデータストレージとして、これまではWestern DigitalのNAS向け製品であるWD RedシリーズのWD80EFZX (8TB ≒ 7.28TiB)を使っていた。これを新たにSeagateのNAS向け製品であるIronWolfシリーズのST12000VN0007 (12TB ≒ 10.91TiB)へ換装した。ここ数年はWestern DigitalのHDDばかり購入してきた (Redの6TB、8TB)ので、SeagateのHDDを購入するのは久し振りだ。

換装した一番の理由は、WD80EFZXの残り容量がほぼ無くなったこと。丁度決算期で普段より値引きが期待できる時期なのと、前回HDDを導入してから2年ほど経っているので頃合いなこともあった。

LUKS+Btrfsで運用している。RMAの兼ね合いもあるので、2年くらい持てばいいのだが。


S.M.A.R.T.の情報を見てみる


Linuxなので、smartctlを使ってみた:

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   079   068   044    Pre-fail  Always       -       74220560
  3 Spin_Up_Time            0x0003   097   097   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       2
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   068   060   045    Pre-fail  Always       -       5995223
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       15
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       2
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   064   062   040    Old_age   Always       -       36 (Min/Max 25/38)
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       2
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       2
194 Temperature_Celsius     0x0022   036   040   000    Old_age   Always       -       36 (0 25 0 0 0)
195 Hardware_ECC_Recovered  0x001a   040   036   000    Old_age   Always       -       74220560
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0023   100   100   001    Pre-fail  Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       15 (143 172 0)
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       13528061790
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       455020

WDのHDDと違い、SeagateのHDDでは1 Raw_Read_Error_Rateや7 Seek_Error_Rate、195 Hardware_ECC_Recoveredといった値が物凄い勢いで増加しているので、最初diskの故障を疑った。

しかし、これらのraw valueをそのまま解釈するのは無意味であり、本当に気にするべきなのは5 Reallocated_Sector_Ctや197 Current_Pending_Sector、198 Offline_Uncorrectableの値であるとの情報があった。

* [Just got a Seagate Ironwolf... are these SMART readings normal? : DataHoarder](https://www.reddit.com/r/DataHoarder/comments/61pmsb/just_got_a_seagate_ironwolf_are_these_smart/)
* [Seagate製HDDが故障する直前のsmart値 – UbuntuによるEco Linuxサーバ構築記](http://eco.senritu.net/seagate%E8%A3%BDhdd%E3%81%8C%E6%95%85%E9%9A%9C%E3%81%99%E3%82%8B%E7%9B%B4%E5%89%8D%E3%81%AEsmart%E5%80%A4/)


RAIDでもNAS専用機でもなくsingle disk換装を選んだ理由


Single disk換装を行ったのは、費用や運用の面で最も適していると考えたからだ。

他にはNASを組む (或いはNASキットを買う)、RAIDを組むなどの方法もあるが:

* 初期コストが高い (diskが複数本必要、それを格納できるケースやマザーボード或いはNAS本体、etc)
* 運用の複雑さが増す
* 電気代が増す
* 総容量が大きくなるとバックアップを取るのが難しくなる

といった問題がある。Single disk運用は、そのdiskが故障すると終わりという問題があるものの、これまで使っていたdisks (8TBと6TB)に定期的にbackupを取ることで影響をある程度緩和する方針を取る。

raidzを使い、信頼性のあるきちんとしたfile serverを構築する場合には、以下のpageが参考になるだろう:

Windows 10 + AMD RX480な環境でFinal Fantasy XV Playable Demoが落ちることがある

Final Fantasy XVのPlayable Demoが配信されていたのでやってみた。取り敢えずFullHD程度ならRX480でもさほどストレスなく遊べる印象 (後でベンチマークソフトを走らせてみたら「やや快適」だった)。

男ばっかり4人のチームで、ホストが旅するゲームとか言われていたりしたけど、実際にやってみると結構面白いと感じている。

ただ、3度も同じような場所で止まったので、おそらくdriver側 (Adlenarinの最新版)に問題ありな雰囲気。

また、数日後には別の場所で画面がピンク色になって入力を受け付けなくなり、Windowsごと落ちてrebootした。

1年くらい前、『NieR:Automata』 (Steam版)でもdriverが安定するまでに時間がかかったのを思い出した。ただ、Automataとは違ってFFXVはオートセーブなのには結構救われた印象がある。

最新のEmacsにてset-default-font (obsoleted)が削除された

commit f1c48b0ec521744826ed43ae27eed0e152c472bfにて、22.1の頃にobsolete扱いになっていたfunctionsが削除された。

set-default-fontもその中の一つで、これで指定していたdefault fontが適用されなくなった。代わりにset-frame-fontを使えとあるので、そのまま書き換える。

eg. Default fontとしてRictyの12ptを使う

× (set-default-font "Ricty-12")



○ (set-frame-font "Ricty-12")

2018年3月3日土曜日

Firefox (やその系列の) web browserでJavaScriptによるcontext menuの禁止を解除する

一部のwebsiteではJavaScriptの機能を応用 (悪用?)してcontext menuを出せないようにしている。今時のwebsiteをまともに閲覧するにはJavaScriptを丸ごとdisableするのも難しい (一応、No Scriptのようなextensionsを入れるという手はある)。

そこで、JavaScriptの機能のうち、context menuを変更するための機能のみをdisableしてみる。

* URL barに"about:config"と入力
* dom.event.contextmenu.enabledを"false"にする

これでJavaScriptによるcontext menuの変更 (禁止含む)を解除できる。

以前はPreferenceの画面にJavaScriptの機能を細かく制御できるoptionがあった気がするが、最近のversionだと無くなっている。


gitでuntrackedなfilesをまとめてrmする

gitで最新版を追い掛けるだけの使い方をしていると、何らかの理由で手元のworking directoryにuntrackedなfilesが残ってしまうことがある。

1つや2つならまだ良いが、それ以上となると1つ1つに対して個別のpathを指定してrmを発行するのは面倒過ぎるし、そもそもprogramを嗜む者の端くれとしてあるべき姿ではない。

 % git status -s | awk '{print $2}' | xargs rm -f

で片付けられる。一応rm -fを実行する前にどんなことになっているのかlsにpipeするなどして確認しておくと安全。


mesalibをbuildする際にdefault以外のversionのLLVMを使う

configure scriptに対応するoptionがあるので使う。

--with-llvm-prefixがこれで、例えば2018-02-20現在のrelease版のLLVMは5.0.1だが、Debian unstableに入っているLLVM 7を使いたい場合:

% ./configure --with-llvm-prefix=`llvm-config-7 --prefix`

のように指定する。


2018年2月20日火曜日

SwissMicros DM42のOFF Imageとして『NieR:Automata』の2Bさんを表示する

SwissMicros DM42 (HP-42SのemulatorであるFree42で動くRPN calculator)は、originalのHP-42Sよりも表示領域が拡張されていて、電源をoffにすると画像が表示されるようになっている。

好きな画像を適当に加工すれば表示できるので試してみた。


図1 2Bさん@DM42

図2 並べてみた

DM42へのOFF image (OFFの時に表示される画像)の書き込み方


cf. https://www.swissmicros.com/dm42/doc/dm42_user_manual/#off_images

DM42をUSB cableでPCに接続し、□SETUP → 1. File → 3. Activate  USB Diskを選択するとDM42の記憶領域をUSB mass storage (USBメモリ)として読み書きできる。領域のfilesystemはいわゆるVFAT (FAT32)なので、Linuxでmountする時には:

% sudo mount -t vfat -o rw,uid=1000,gid=1000 /dev/sdb /mnt/dm42

のようにする。ちなみに、-t vfatでfilesystemにVFATを指定、-o以降に渡してあるのは:

* rw → 読み書きモード
* uid=1000 → fileの所有者を1000 (たぶん一番最初に作った一般ユーザアカウントのid)にする
* gid=1000 → fileの所有groupを1000 (同上)にする

※VFATにはfileの所有者/所有groupの概念がなく、uidやgidを明示的に指定しないと所有者がrootになる。mvやcpを発行するのに一々sudoをつけるのが面倒なので指定

以上の設定で/dev/sdb (著者の環境ではこれがDM42の記憶領域)を/mnt/dm42にmountする。

この時、/mnt/dm42/以下に見えるOFFIMG directoryに適切なimage file (大きさ400×240, 色深度1bit, BMP)を放り込むと、電源off時ランダムで表示されるようになる。

書き込み終わったらPC側でumount後、/sys/block/sdb/device/deleteに1を与えて安全に取り外せる。

% sudo umount /mnt/dm42
% echo 1 | sudo tee -a /sys/block/sdb/device/delete


大きさ400×240で色深度1bitなBMP画像の作り方


cf. [白黒(1ビット)画像の作り方](http://yay.cla.kobe-u.ac.jp/~jm/edu/2015/media/errorta/)

GIMPを使った。InkscapeやPhotoshopでも勿論できるが、ここでは解説しない。

* 画像を取り込むか描く
* Image → Mode → Grayscaleを選択してGrayscaleにする
* Colors → Brightness-Contrast...を選択し明るさとコントラストを調整する
* Image → Scale Image...で大きさを調整する
* Image → Canvas Size...で横400×縦240に設定
* Move toolで表示する部分を調整する
* Image → Mode → Indexed... → Colormap → Use black and white (1-bit) paletteを選択
* Dithering → 適切なcolor ditheringを選び Convert


最後に


2018-02-12にDM42のfirmware v.3.3がreleaseされた。詳細については以下linkを参照されたい。

cf. [Index of /dm42/firmware](https://www.swissmicros.com/dm42/firmware/)


人類に栄光あれ。