2020年7月20日月曜日

Debian SidのMercurialがPython 3へ移行したためinfo.pyに異常が出た (workaroundあり)

Debian SidのMercurialが5.4.1→5.4.2にupgradeされた。このversionでは(Mercurialが依存する) Pythonが2.7→3へ変更された。

この影響で、Mercurialのextensionとして導入しているinfo.pyの実行に不具合が発生した:

> % hg st .
> *** failed to import extension info from ~/.hg.d/info.py: unicode 'info' found in cmdtable
> *** (use b'' to make it byte string)
> ...

info.pyを読み込む際にerrorが発生してimportに失敗している。`bytes`を想定している`cmdtable`内にUnicodeとして認識されたstringが混入したため。

Workaroundとして、「`b''`を使って (explicit type conversionして)ね!」というerror messageに従い、info.pyにて:

> - @command('info')
> + @command(b'info')

の変更を行い解決した。


Python 3.xでのstrとbytesについて


Python 3では`str`がUnicodeへ変更された (Unicodeが`str`になった)一方で、Mercurial (のAPI)は`bytes`を想定している。Python 3は (Python 2 seriesのような)`str` (Unicode)と`bytes`のimplicit type conversionを行わないので、このような事例はerrorとして検出される。

以下、Python 3.8.4のdocumentationより引用:

Note
 
For Python 2.x users: In the Python 2.x series, a variety of implicit conversions between 8-bit strings (the closest thing 2.x offers to a built-in binary data type) and Unicode strings were permitted. This was a backwards compatibility workaround to account for the fact that Python originally only supported 8-bit text, and Unicode text was a later addition. In Python 3.x, those implicit conversions are gone - conversions between 8-bit binary data and Unicode text must be explicit, and bytes and string objects will always compare unequal.

cf. [Built-in Types — Python 3.8.4 documentation](https://docs.python.org/3/library/stdtypes.html#bytes)

(要約)

Python 2.xまでは色々な過去の経緯もあってUnicode文字列と8bit文字列の暗黙的な変換が横行していた。Python 3.xからは一切暗黙的に変換しないのでプログラマは明示的に変換する必要がある。`str`と`bytes`の比較は常に等しくない。


2020年7月15日水曜日

SwissMicros DM15LのfirmwareをV29にrevert (downgrade)

具体的にいつごろrevertが推奨されたのか把握していないが、少なくとも2020-07-09には以下の文言がfirmwareのupdate historyに追加されていた:

!!! V30 firmware was removed after confirmation of excessive consumption in OFF mode
!!! Everybody should revert to V29 firmware.

cf. <https://www.swissmicros.com/voyager/firmware/history.txt>

(私訳) V30ファームウェアは、OFFモードにおける過大な電力消費が確認されたので削除された。全ての人はV29ファームウェアに差し戻すべき。

V30 firmwareの不具合が影響したのかは不明だが、最近DM15Lの電池 (CR2032 ×1)を交換した記憶がある。もっとも、リチウムを使用しているため長期保存に向く (〜10年)とされるCR2032とは言え、古い物であることが影響していた可能性はある。

なお、firmwareの差し戻し (revert)の手順は、upgradeの手順と全く同じ。例えば、lpc2lispを使ってLinux boxからUSB cableで行う場合は指定するfirmware fileが異なるだけである。