2022-06-02

RISC-VなClockwork DevTermがやってきた

Clockworkが発売してるDevTermにRISC-V64なボードが追加されてたので買ったところ届きました。

中のパーツは組み立てる必要がある。電源はUSB-C経由だが、18650バッテリー搭載可能。

なお、このボードは阿里巴巴のXuanTie C906コアなAllwinner D1使っているのでこんな感じ。

cpi@devterm-R01:~$ uname -a
Linux devterm-R01 5.4.61 #12 PREEMPT Wed Mar 30 14:44:22 CST 2022 riscv64 riscv64 riscv64 GNU/Linux

cpi@devterm-R01:~$ cat /proc/cpuinfo
processor	: 0
hart		: 0
isa		: rv64imafdcvu
mmu		: sv39

だそうです。Vecter Extension!

同梱のSDカードにUbuntu 22.04ベースの起動イメージが入っているのだが、これはhttp://dl.clockworkpi.com/からダウンロード可能。なお、スクラッチから作る方法も公開されている

なお、参考にUnix Bench

========================================================================
   BYTE UNIX Benchmarks (Version 5.1.3)

   System: devterm-R01: GNU/Linux
   OS: GNU/Linux -- 5.4.61 -- #12 PREEMPT Wed Mar 30 14:44:22 CST 2022
   Machine: riscv64 (riscv64)
   Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
   16:18:46 up 3 min,  2 users,  load average: 0.92, 1.11, 0.53; runlevel 2022-06-02

------------------------------------------------------------------------
Benchmark Run: Fri Jun 03 2022 16:18:46 - 16:46:57
1 CPU in system; running 1 parallel copy of tests

Dhrystone 2 using register variables        2958013.9 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     1045.0 MWIPS (9.9 s, 7 samples)
Execl Throughput                                254.0 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks         44255.0 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           12537.2 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        116663.8 KBps  (30.0 s, 2 samples)
Pipe Throughput                              163270.2 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  26226.4 lps   (10.0 s, 7 samples)
Process Creation                                696.3 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                    567.4 lpm   (60.1 s, 2 samples)
Shell Scripts (8 concurrent)                     73.9 lpm   (60.5 s, 2 samples)
System Call Overhead                         383377.8 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0    2958013.9    253.5
Double-Precision Whetstone                       55.0       1045.0    190.0
Execl Throughput                                 43.0        254.0     59.1
File Copy 1024 bufsize 2000 maxblocks          3960.0      44255.0    111.8
File Copy 256 bufsize 500 maxblocks            1655.0      12537.2     75.8
File Copy 4096 bufsize 8000 maxblocks          5800.0     116663.8    201.1
Pipe Throughput                               12440.0     163270.2    131.2
Pipe-based Context Switching                   4000.0      26226.4     65.6
Process Creation                                126.0        696.3     55.3
Shell Scripts (1 concurrent)                     42.4        567.4    133.8
Shell Scripts (8 concurrent)                      6.0         73.9    123.1
System Call Overhead                          15000.0     383377.8    255.6
                                                                   ========
System Benchmarks Index Score                                         120.8

2022-05-24

Intl.MessageFormat

hi18n (i18nライブラリ) の紹介 (1) 設計思想と基本方針というのを見た。このブログ記事を見るとこれは文字列翻訳のメッセージフォーマットを行うライブラリの話らしい。翻訳というのは、Localizaiton (L10N) と呼ぶもので、Internationalization (i18n) とは違う。i18nというのは、文字翻訳じゃなくて、多言語を扱う、表示するということを基本指す。例えば日本語が表示できるとか入力ができるとか。まずwantedly社は正しい言葉を使うようにしてほしい。

さて、本題。

こういうメッセージフォーマットというのは、どうもいろいろ各社持っているらしく、車輪の再発明を各社でやっている状況らしい。そんな状態は労働力の無駄でしかないので、ECMA-402でIntl.MessageFormatというのを作ることになった。元のベースはFirefoxで使っているFluentと呼んでいるライブラリで、そもそもそれはFirefox OSのときに作られた仕組み (今は某社で働いてるZibiがFirefox OSのころからやってて、これをFirefox本体へ持ち込むときにECMA-402のいろんな仕様も追加してた)。

Intl.MessageFormatはただのAPIだけど、メッセージフォーマットの仕様はThe MessageFormat 2.0 Specificationに現時点のドラフトがある。ICU4Xで使えればWASMでも使えるので、自社で同じような機能の車輪の再発明を行っているのであれば、ここでいろいろ意見を言えば取り込まれると思うよ

2021-12-31

2021年に買ったもの

Google Pixel 4a

XPERIA XZ2 Compactを使っていたのだが、3度目の修理になったタイミングでメイン端末の代わりとして購入。XPERIA XZシリーズはほんと出来が悪かったし、ドコモ経由で買ってたので、修理代が非常に安く、あれでは元を取れてないのではと思うものだった。

Googleはこのくらいのミッドレンジの端末が一番コスパいいと思うので続けてほしいと思う。そもそも昔のNexusのときと違ってAOSPそのままではなくなってるし、どれがリファレンスなんだかわからなくなってはいるが。

HiFive Unmatched

2020年にオーダーしたものだったけど、5月くらいに到着。Mini-ITXなケースと電源、AMDのPCIeなGPUを用意すると、普通にLinuxが実用速度でボートするRISC-Vボードなので、いろんなコードを試しにポートしてみた。今年くらいにリリースされるようなSoCだと今度はSIMDとかCrypto Extensionとか実装されてそうし、新しいSoCが入ったボードが出たら買うだろうな。

TP-Link 5ポート 2.5Gbps ハブ アンマネージ スイッチングハブ TL-SG105-M2

コスパはいいTP-Linkが最安クラスの2.5Gbpsハブを発売したので、早速購入。結構熱は持つけど、速度としては安定してる。そういえば、自分が100Mbpsなハブを買ったのもこのくらいの値段になったころだったなぁと思い出した。

SwitchBotスマート加湿器

部屋が乾燥してて朝起きると喉の調子がわるいので、購入。加湿器を買うんだったらくだらないものを買おうと思い、SwitchBotにした。はっきりいうと加湿器なんてずっとつけっぱなしだし、タンクの水がなくなっているという情報をスマホで見ても、だから?って感じなので、スマホとかからコントロールするような機能は改めていらないなと。

ネスカフェ ドルチェグスト MINI ME

家でコーヒーの飲む時は一杯毎ドリップして飲んでいたのだけど、面倒になって、コストコでMINI MEを購入。自分のような面倒くさがりな人にとってはこういうカプセルのものが理にかなってた。

山善 エアフライヤー YAF-C120

普通の電気フライヤーは持ってはいるのだけど、油の処理がもったいない気がしてて、エアフライヤーで代替できないかと思って購入。はっきりいうと中途半端過ぎて、代替にならなかった。200℃だと微妙に温度が足りない感。たしかにフライドポテトとかは簡単にできるのだけど、その程度かなぁ。今後も使い続けるかは微妙。

2021-11-30

Web Speech APIのSpeechSynthesisEvent.elapsedTimeは秒を返すのだけど

バグレポートを受け取って気づいたのだけど、SpeechSynthesisEvent.elapsedTimeは秒を返すのが正しい。ただほとんどのブラウザがこの値を秒で返していなかった (例外はFirefox for Linuxくらいかも)。なので、Safariも最近直っていたので、Firefox側も直した

ここまでは普通の話なのだが、バグ報告をした人がChromeでも同じ問題が起きるとしてバグを報告したのだが、このバグが滑稽。Chromeはバグを受け付けるとQAが出てくるのだけど、そのQAがまずWeb APIの仕様を理解してないし、理解しようともしない。その人を乗り越えないと、Bug Triageさえちゃんとやってくれないようで、バグを認識させるためにはそのQAが投げ出すまで付き合ってあげないといけなくて、非常に無駄なコストがかかる。google.comじゃなくてchromium.orgのメアドを使っているからどこかのベンダーなんだと予想してるのだけど、そうだったらもっとまともな会社使おうよと、Google。

そもそもWeb Platform test (wpt) でTest failure発生させられる話だったら、そういうテストケースを書いておいて、さくっとwptに入れちゃうのだけど、このissueに関してはwptを書きようがないので、まぁChromeチームはずっと放置すると読んでる。

なお、Bug Triageに関してはMozillaは詳しい人かチームマネージャがやるので、大概ちゃんとした人が見ることになることが多い。こんな感じでBug Triageをちゃんとやらない製品はバグ修正とかにコストかけない (または評価システム上、評価されない) だろうなぁと勝手に思ってる。

2021-10-08

いまさらながらAndroidのAutofill Frameworkの困った話

AndroidのAutofillというのは、カスタムコントロールを使わないアプリにとっては実装は難しくはないのだが、カスタムビューを実装しているアプリでは、自分でいろいろな情報を提供しないといけない。実際には、自動入力用にアプリを最適化するに書かれているように、システムがAutofill用の情報を要求してきたら提供する、フォーカスの状態をシステムに通知するなどを追加実装する必要がある。

全部のアプリケーションでそのような実装しているとは限らないので、実装していないような昔のアプリケーション用にAndroidはおせっかいな機能を追加している。互換モードだ。これはアクセシビリティの実装を用いたautofillのエミュレーションを提供するもので、カスタムビューがアクセシビリティ機能の実装をしている場合は、それを利用してAutofill情報を設定する。そもそもアクセシビリティの実装しててAutofillの実装しないアプリがあるのかと問い詰めたいところではあるが。

この互換モードというのは自動的に切り替わるわけではなくて、Autofillサービス側で事前に設定をする。だから例えばアプリがAutofillの実装を入れたとしても、アプリ側からこの互換モードを無効にする方法は残念ながらない。この互換モードが動作してしまうと、アクセシビリティノードの走査が走ってしまうため、当然ながらパフォーマンス問題を引き起こす。アクセシビリティノードの走査はandroid.view.Viewの実装内で行われているから、該当コードを実行しないようにすれば、アクセシビリティノードの走査が実行されなくなるので、ある程度は回避可能ではある。残念ながらある程度ね。

この互換モードで実行しているかどうかは、こんな感じで調べられると思う。

public boolean isCompatibilityMode(Context context) {
  try {
    final AccessibilityManager manager =
      (AccessibilityManager) context.getSystemService(
                               Context.ACCESSIBILITY_SERVICE);
    if (manager == null) {
      return false;
    }
    final List<AccessibilityServiceInfo> serviceInfoList =
      manager.getEnabledAccessibilityServiceList(0);
    if (serviceInfoList == null) {
      return false;
    }
    for (final AccessibilityServiceInfo info : serviceInfoList) {
      if (info.getId().equals(
        "android/com.android.server.autofill.AutofillCompatAccessibilityService"
      )) {
        return true;
      }
    }
  } catch (final Exception e) {
  }
  return false;
}

アクセシビリティノードを走査させないようにしたとしても、互換モードは引き続きおせっかいなコードを実行する。この互換モードが動作する際には、CompatibilityBridgeと呼ばれるものがアクセシビリティイベントをウォッチするようになる (これについては無効にする方法はない)。そのためアクセシビリティイベントを発火させるとそれに応じて勝手にAutofillの互換コードが実行されてしまう。例えばAccessibilityEvent.TYPE_VIEW_FOCUSEDのイベントを受け取ると、AutofillManager.notifyViewEnteredを呼び指したりする。そのため内部でAutofillフォーカスがアクセシビリティノード上に移動する。たとえアプリケーションがAutofill情報を提供してたとしてもだ。AndroidのAutofillはフォーカスが移った際にAutofill用のリクエストをAutofillサービスに渡すので、互換モードでかつ、もしアプリがAutofillの実装をしてた場合、2度リクエストが飛ぶという困ったことになってる。

今どきのWebブラウザというにはOSのAPIはUI Processで実行される。Webコンテンツ内のアクセシビリティ情報をコンテンツのロード時にContent Processで集められ、集まった後UI Processへ送られる。アクセシビリティ情報の収集というのは非常に重い処理なので、UI Processへ送られるのは、ブラウザにとっては相当後になる。なので下手をするとAutofillフォーカスが予期もしてないアクセシビリティノードに奪われた状態でAutofillサービスがAutofillのUIを出したりしようとするので、ブラウザにとっては予期しない動作になりがちになる。例えば、Bug 1693152とかBug 1715549とか。

このように残念な互換モードを使っているAutofillサービスで有名なのはBitwarden。昔Bitwardenの開発者になんで互換モードに設定しているの?って聞いたけどよくわからない答えを返してきたので、今度こそどうにか止めさせるつもり。このような問題に引っかかるのはたぶん自分だけだと思いたいし、Androidはこの互換モードをアプリ側から止める方法を提供してほしかった。

なお、Bitwardenを使ってて、たまにChromeとかでもAutofillが動かないという話があれば、おそらくこのパターンの話。