最新の日記
ScalaからJavaFXを利用する
ScalaからJavaFxを利用したい。ScalaならScalaFxを利用するべきなのでは？と思うかもしれないが、そこは一旦気にしないで欲しい。 プロジェクトの依存関係にJavaFXを追加し、assemblyでjarアーカイブをビルドした。 このjarを実行すると、JavaFXコンポーネントが足りないと言われて終了してしまう。 このjarファイルはJavaFXを参照してはいるが、JavaFX本体は埋め込まれていないと推察できる。 一方で、だったら問題なく実行できることから、JavaFXの本体はこのマシンのどこかに存在していて、sbtはその場所を知っているはずである。 しかもaptでOpenJFXパッケージをインストールする前から動作したので、sbtがJFXをどこからかフェッチしてきて実行しているということである。 さらに、sbtがどこからパッケージをダウンロードしているのかも謎だ。 マニュアルにはレジストリの指定方法とか書いてあったかな？ Scalaとは無関係にJavaのパッケージにも中央集権的なレジストリがあるのかも。 しばらく調べていると、StackOverflowに以下のような質問を見つけた。 どうやらJavaFXはちゃんと埋め込まれているが、バージョン11特有の不具合で、エントリポイントになるクラスがを継承していると問題が起こるようだった。 適当にMain関数のラッパーを書いて、build.sbtにエントリポイントを記述すると、無事実行することができた。 JavaFXのMediaPlayerが作成できないエラーに遭遇した。これまではopenjfx11を使っていたが、現在の開発環境にインストールされている新しいバージョンのコーデックと互換性がない。特にJavaFX11に固執する理由もなかったので、最新のLTS版であるバージョン20を使うことにした。 sbt の対話型環境から複数回すると、最初の実行のみ期待通りに動作し、2回目以降はモジュールのロードに失敗していまう。これは解決していないが、毎回jarにバンドルすれば一応実行はできるので、後回しにすることにした。 また、jarアーカイブを作成する際に、大量のファイルが衝突した。どうやらjarアーカイブの中には1つしか存在できない特別なファイルがあり、複数のjarをまとめて一つのjarを作るときには、それらをうまくマージして一つにしないといけないようだった。
mozcをコンテナでビルドする
mozcにユーザー辞書を入れたい mozcはgoogle日本語入力のオープンソース版 しかし辞書は入っていないので、最小限の辞書のみを入れている 知らないことはたくさんある。 そもそも、キーボードの入力の列からローマ字やひらがなに変換し、それをいくつかの節に分割して、候補となる変換先を列挙するというタスクの内、IMEが担当するのはどの部分なのか？ インプットメソッドとは？ 前後の文脈を判断して変換候補に反映させたりできるのか？ 辞書はどのように作られているのか？ 辞書はどのように導入できるのか？ 複数の辞書を導入しても衝突しないか？ 複数のIMEに共通する規格はあるのか？ そもそも辞書とはどのような構造なのか？読み→漢字のペア以外にどんな追加のデータを含んでいるのか？ さすがに今日はユーザー辞書について調べた ut辞書のビルドはできた sh ではなくbashでスクリプトを実行しないと生成できない 問題は、生成した辞書をmozcに組み込むところだ。 mozcではユーザー辞書を使って変換候補を拡張することができるのだが、実はut辞書はmozcのユーザー辞書の形式になっておらず、インポートすることができない。 ではどうやって利用するのかというと、mozcのビルド時に既存の辞書に結合して使う。 なぜ素直にインポート可能な形式にしないのかと疑問に思ったが、単に後から単語を追加するだけだと変換精度が悪くなるケースがあるようだ。 そもそもユーザー辞書では単なる(読み,書き)以上の情報を与えることができない。 そうなると、mozcを自力でビルドしなければならないということになる。 ビルドそのものは簡単に見える。公式でDockerfileが配布されていて、それを使ったビルド方法の説明が載っているからだ。 しかし実際はうまくいかなかった。 ビルド時のエラーメッセージを読んでみると、それがbazelによって自動生成されたファイルに由来している事が分かった。 bazelはgoogleのプロジェクトで使われているビルドシステムで、非常に活発に開発が行われ、高頻度のリリースが行われているようだった。 それ以外にbazelについて知っていることは全く無いため、別ののタグにチェックアウトしてビルドできないかどうか試した。 しかし、バージョン毎に異なるエラーに見舞われるだけだった。 不思議なのは、同じような症状を訴えるissueが全く無いことだった。 このリポジトリはCIを運用していて、少なくともビルドが通らなければタグを付けるはずがない。 そう考えてDockerfileを眺めていると、原因らしきものが見つかった。 このビルドに使用するコンテナイメージはubuntuをベースとしており、依存パッケージはaptでインストールする。 ほとんどのパッケージがdebianレジストリからインストールされる一方で、bazelなgoogleの管理するレジストリからインストールされていた。 そのため、bazelだけはバージョンを明示しなければならないが、件のDockerfileではbazelのバージョンを指定していなかった。 そのため、自分がビルドしようとしているmozcのバージョンがプッシュされたときのビルド環境と自分の手元の環境が異なるものになっていた。 原因がわかったので、明日はbazelのバージョンを変えて試してみたい。 mozcのビルドができた。しかしテストを実行できない。GitHub Actionの実行環境のubuntuには予め多くのパッケージがインストールされているが、ubuntuの公式Dockerイメージには最小限のソフトウェアしかインストールされていない。 を参考に、bazelのバージョンを合わせ、jdkをインストールし、JAVA_HOMEを設定するようにした。 しかし、Githubの環境と同じようにbazelのバージョンを6にすると何故かビルドできないので、bazelのバージョンを5.3.1にしてビルドした。 すると、今度は/varパーティションが小さすぎて、テストのビルドが最後まで終わらない。新たにパーティションを切り直すのは大変なので諦めようかと思ったが、試す価値のありそうな方法がまだ残っていた。Dockerの代わりにpodmanを使うというものである。podmanはコンテナをユーザー毎に管理するらしく、共用のディレクトリである/varを圧迫しないだろうと考えた。 mozcのビルドが途中でストップするのは、bazelのバージョンの不整合のせいではなかった。 現バージョンのmozcではbazelの最新バージョンを使用してビルドする際に、 pkgconfigにまつわる不具合が起こっていた。 そのワークアラウンドとして、リポジトリにqt6のpkgconfigを置いておき、そのパスを環境変数で渡すようになっている。 オリジナルのDockerfileでは、イメージのビルド時にmozcのリポジトリ全体をフェッチしてくるようになっていたが、ビルドコンテキストからソースファイルをコピーするようにしていた。 srcディレクトリのみをコピーしていたのでコンテナ内にはpkgconfigは存在せず、ビルドが失敗していた。