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が異なるだけである。


2020年6月10日水曜日

[Minecraft] 快適な建築のための環境設定

2020-06-10現在の最新安定版であるJava Edition (JE) v1.15.2向け。

まとめ


Create New World (新しいワールドの作成時)


* Game Mode: Creative
* Generate Structure: Off
* World Type: Superflat

Play Selected World (作成したワールドを遊ぶ時に一度だけ設定)


* /gamerule doMobSpawn false
* /gamerule doWeatherCycle false
* /gamerule doTileDrops false


蛇足


ブロックを積んでちょっとした「建築」を楽しみたい時には、Creative modeでなおかつSuperflatなworld typeが良い。

Creative inventoryが使える上に飛行でき、どんなブロックも1回で破壊できるので試行錯誤にはぴったりだ。また、Superflatな世界なら地形を平らにならす「整地」が必要なくなる。村やダンジョンなどの生成を禁止するのも良い。

ただし、これだけでは:

* 夜間や暗い場所にゾンビやコウモリが湧く
* エンダーマンにブロックを持って行かれる
* クリーパーが出て爆発する
* 天気が悪化して視界不良になる

と言った妨害を受ける。

敵対的なmobs (ゾンビ、クリーパー、エンダーマン、etc)については、/difficulty peacefulへの設定で即座に存在を消せる。しかし、夜間や暗所に湧くコウモリは中間的mobsのためこれだけでは不十分である。そもそも建築に集中するのにmobsは邪魔なため、/gamerule doMobSpawn falseですっきりする。

特にコウモリが湧かなくなるといわゆる「湧き潰し」のため至る所で明るさを確保する必要がなくなり手間が省ける。

天候の悪化 (雨)も視界不良の原因となるので、/gamerule doWeatherCycle falseで切る。個人的に夜の雰囲気は好きなので昼夜の変化は切っていないが、必要なら/gamerule doDailyLightCycle falseで切れる。

細かいことだが、ドアなどを破壊した際にitem化しても邪魔なだけなので/gamerule doTileDrops falseで止める。そもそも建築時にはcreative inventoryが使えるのでitemを回収する必要がない。

cf. [Commands/gamerule – Official Minecraft Wiki](https://minecraft.gamepedia.com/Commands/gamerule)


残る課題


* creative modeで空を飛んでいる時の挙動が嫌 → 所謂「慣性」 (inertia, momentum)が残るのが操作しにくい原因。キーを押している時だけ動いて、話したら即止まって欲しい
* ↑一応そういう感じのmodがあるようなので導入を検討したい

2020年4月18日土曜日

Windows 10 version 1909へのupdate

Windows 10 version 1809のEOLが約1ヶ月後の2020-05-21に迫っていることもありversion 1909へupdateした。

Downloadやinstallationなどで2〜3時間掛かったが正常にupdateは終了した。2020-04-18現在、使っていて特に問題はない。

なお、version 1909のEOLは2021-05-11の予定。

cf. [Windows ライフサイクルのファクト シート - Windows Help](https://support.microsoft.com/ja-jp/help/13853/windows-lifecycle-fact-sheet)

SwissMicros DM1X series向けのfirmware V30がreleaseされていた (2020-01-17)

(注意)

2020-07-15現在、V30 firmwareには「OFFモード中の過大な電力消費」という不具合が公式に確認されている。V29の方はそのままで、V30にupdateした方はV29へのrevertが推奨される。

(注意ここまで)


SwissMicros DM1X向けのlatest firmwareであるV30が2020-01-17にreleaseされていた。

気付いたのが2020-02-24で、その日のうちにupdateを実行した。

変更点を引用:
V30: 17.01.2020
ALL: Added 'bootloader' serial console command
ALL: Abandoned support for 32kB firmwares
ALL: Improvements to Nut emulation layer
DM41: Stopwatch now generates 'TIMER ALARM' when SW is hidden as well when calculator is turned off.
cf. [Firmware History](https://www.swissmicros.com/voyager/firmware/history.txt)

Firmware updateはいつも通り、Linux boxからlpc2lispを使って実行。具体的な手順については以前の記事 (cf. https://typeinf-memo.blogspot.com/2016/07/swissmicros-dm-15lfirmware-upgrade.html)を参照されたい。


SwissMicros DM42のfirmware update (DMCP 3.18 + DM42 3.15)

SwissMicros DM42のfirmware (DMCP 3.18 + DM42 3.15)が2020-03-30にreleaseされていた (cf. [Index of /dm42/firmware](https://www.swissmicros.com/dm42/firmware/))。

今回はDMCP OS (OSのcore)+DM42 program (HP42 emulator)をまとめてdfu-utilでupdateした。具体的な手順については以前の記事 (https://typeinf-memo.blogspot.com/2017/12/swissmicros-dm42firmware-update.html)を参照されたい。

なお、一つ前のversionは2020-02にupdateされており、それも適用していたのだが記事にし忘れていた。



2020年1月21日火曜日

Chromium 79.0.3945.79-1 (Debian sid)がSEGVる (1/21: version upで解決済み)

*** update ***

2020-01-21、Sidにてchromiumがupdateされていて (79.0.3945.79-1 → 79.0.3945.130-2)、こちらのversionでは特に問題なく使用できている。

*** updateここまで ***


Web browserのchromiumを79.0.3945.79-1 (12/19現在の最新版)にupgradeしてからSEGVるようになった。起動しないとか、起動してすぐとかではなく、しばらくするといつの間にか落ちている感じ。

Debian Bug Tracking System (BTS)を見てみると既に複数の報告がなされている:

cf. [#945920 - Chromium randomly crashes in the latest version. - Debian Bug report logs](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945920)

現状でできる対策は前のversion (78.0.3904.108-1とか)に戻すことだが、もしかしたらsecurity flawとかがあるかも知れない。