GNU Emacs for Windows における最近の IMEパッチ問題

自分は GNU Emacs 使いなのですが、Windows版の Emacs を使用する場合、IMEパッチの問題がありました。

ざっくり言うと、FSFの正規のリリースバイナリだと日本語変換のIMEに切り替えた時、インラインで候補文字が表示されないという問題です。そのために有志の方々が IMEパッチを提供してくれておりまして（感謝）、それがあてられた 日本語Windows 向け Emacs を使うというのが上等手段となっています（なっていました）。

最近、Windows上の Emacs を更新しようかと思って、IMEパッチがあたった Emacs を探していたのですが、どうも最近は FSF がリリースする正規の Emacs バイナリが対応している「ダイナミックモジュール」という機能を使って、IMEパッチに相当する DLL をロードして、その対応をする方向で進んでいるみたいです。

その名称は

Emulator of GNU Emacs IME patch for Windows (tr-ime)

みたいで、GitHub上で公開されています。

https://github.com/trueroad/tr-emacs-ime-module

 詳細な説明も記載されてまして、その通りに対応することで、自分も無事、正規リリースの

GNU Emacs 28.2 (build 2, x86_64-w64-mingw32)

 of 2022-09-14

で問題なく IME を使用できるようになりました。

それこそ、Mule/Meadow の時代から日本語Emacsを使っている身からすると、その日本語対応・多国語対応への進展は感慨深いです。

あと今回の導入において、Emacs-Lisp のパッケージ管理システムやリポジトリ：

MELPA (Milkypostman’s Emacs Lisp Package Archive)

も初めて知りました。これも便利そうですね。なお MELPA については以下の記事の内容が参考になりました（GNU標準リポジトリ GNU ELPA との違いなど）。

Emacsのpackage.elのリポジトリにMELPAを追加する

色々と進化していますね。

MSYS2/pacman のパッケージアップデートでのファイルダウンロード速度エラー

Windows上でのUnix環境ととして MSYS2/MinGW64 を常用しています。

今日、過負荷状態であるPC上で MSYS2/MinGW64 のパッケージアップデート:

pacman -Syu

を行っていた所、以下のメッセージが出て、アップデートが終了しました：

エラー: ファイル 'libxml2-2.10.4-1-x86_64.pkg.tar.zst.sig' を mirror.archlinux.tw から取得するのに失敗しました : 

Operation too slow. Less than 1 bytes/sec transferred the last 10 seconds

このエラーに初めて遭遇したので、「ほう」という感じでした。

確かに超過負荷状態でしたが、「10秒間に10バイト未満しか取得できなかった」というのは「エラー」という程の状態なのですかね。。。

まだ「100秒間に100バイト未満しか取得できなかった」とか「300秒（5分）間に300バイト未満しか取得できなかった」という方が、なんとなくしっくりくる時間窓枠なのですが。。。

因みに実行していたのは「ディスクのクリーンアップ」での「Windows Updateのクリーンアップ」です。この処理はCPU利用率というよりはディスクアクセスが100%になるという状況でして、CPU利用率はさほど高くないですがIOアクセスが一杯で通信 and/or ディスクへのファイル保存ができない状態かと思います。

過去の経験上、Windows Update のクリーンアップが5分で終了するのは難しいかもしれませんが、pacman の方も、エラーで停止するよりは、「ダウンロードに時間かかっているけど継続する？」と確認メッセージを出して、一時停止してもらう方が状況的にもユーザインタラクション的にも合ってそうな気がするのですが。

ダウンロードに時間がかかるのが「エラー」と言われると、少し「うん？」と思いますし、「エラーの発生」に対してこちらのリアクションを思うと、もう少しフレンドリな扱いでも良さそうな気はします。

もちろん、そんなアップデートを行うのは一般にはシステム管理者（の位置づけの人）なので、

そういう過負荷状態でアップデートを敢行しようとは普通のシステム管理者はしないだろうから、その様な状況は想定外であり、エラー表示が適切

と言われるとそれまでなのですが笑、MSYS2/MinGW64であり、頻繁にパッケージアップデートがあることを考えると、もう少し軽い感じでも良さそうな気はします。

特に、一番最後の

警告: 複数のファイルの取得に失敗しました

エラー: 処理を完了できませんでした (予期しないエラー)

エラーが発生したため、パッケージは更新されませんでした。

という部分で、俺はそのぐらいの転送速度にはなるかもな、と予期はしていましたし笑

誰が予期してなかったのでしょうね。

TeXLive 2023のリリースと 64bit化

MSYS2 / MinGW64 の pacman アップデートで texlive の大量アップデートが発生したので「TeXLive 2023 がリリースされたんだろうなぁ」と思い、ネットで情報を検索してみたら、どうやらこのリリースから、

Windowsのtexアプリが 64bit化！

したみたいですね。

僕は LuaLaTeX 使いで、フォント使用時のメモリ利用量の問題があり、デフォルトが 64bit アプリである MSYS2/MinGW64 の 64bit 版 LuaLaTeX を使っていましたが、これからは TeXLive のデフォルトインストーラで提供されるものも 64bit 化されている様ですね。

今後、どっちを使おうかなぁ。。。

悩ましい所ですね。

LuaLaTeX には MSYS2 MinGW 64-bit がお勧め

自分は文書作成環境として LuaLaTeX を使うことが多いです。

理由は、

• LaTeXの様々なパッケージを使うことで効率的に文書を仕上げることが可能
• 文書の最終フォーマットはpdfで良いことが多く、LuaLaTeXにより直接pdfを出力可能であり、また pdf の機能を直接操作可能なパッケージも存在していること
• 日本語の入力やフォントをうまく扱うことが出来ること（utf-8入力という制約がありますが、逆に自分としては、新規に起こす文書は utf-8 なので問題ありません）

です。

ただ1つだけ難点がありました。

それは

Windows向けの texlive で普通にインストールすると、32bit実行形式の LuaLaTeX がインストールされ、デフォルト以外の日本語フォントを使用すると、メモリエラーでLuaLaTeXが落ちる

です。

「64-bit実行形式の LuaLaTeXなら、メモリエラーの問題は回避可能」というのは知っていまして、対策として「別途 64bit版のLuaLaTeXを差分インストールする」という手もあるのですが、インストールの手間は増やしたくないですし、なんか良い手はないかと思っていました。

因みに 64bit LuaLaTeX でデフォルト以外の日本語フォントを使用した場合のメモリ使用量の増減は、以下のようになっています：

縦軸の一目盛がだいたい1.5GBでして、LuaLaTeXのフォント処理時はトータルで二目盛ぐらいのメモリが必要となり、 3GB 程度、メモリを使用している模様です。64bitアプリということで、幾分かメモリ使用量が増加する所はあるかもしれませんが、32bit LuaLaTeX で扱うのは厳しいか、という印象ですね。

それとは別に、Windows上で C/C++ のコンパイル環境として

「MSYS2 MinGW 64-bit」

https://www.msys2.org/

を使っていたのですが、ふと、

MSYS2（64-bit）に texlive は入ってないのかな？

と思い、確認した所、ありました！

mingw-w64-x86_64-texlive-full

https://packages.msys2.org/groups/mingw-w64-x86_64-texlive-full

です。

MSYS2のパッケージインストーラ pacman を使い、

$ pacman -S mingw-w64-x86_64-texlive-full

とすれば普通に 64-bit版 LuaLaTeX が使えるようになりますし、メモリエラーは発生しません。

自分としては「Eclipse + texlipse」の環境で使うことが多いのですが、任意の日本語フォントを使用しても途中でメモリエラーで止まることがなくなり、大変重宝しています。

Eclipse の TeXLipse プラグインが2年ぶりに更新されていた話

文書作成には主に LaTeX (LuaLaTeX) を使ってまして，執筆用の環境としては Eclipse 上の TeXLipse を使っています．

最近，かなりアグレッシブにドキュメントを書くことが増えてきてまして，だんだんと TeXLipse の小さな問題が気になってきました．現在使っている 2020-06/2020-09 との相性の部分もあるかとは思いますが，特に

• bib ファイルの編集をしようとして BibTeX Editor で開いても何も表示されず，通常のテキストエディタで編集せざるえない
• なお両エディタ共に Eclipse 上のものです．BibTeX Editor は TeXLipse をインストールすると Preferences で表示されますし，Project Explorer 上でファイルを選択し Open with で開こうとすると出てきますので何かしら機能はあると思いますが，見たことがありません
• tex ⇔ bib との連携がうまく行かないことがあり，文献参照が適切に表示されない
• usepackageのbiblatexでbiberを指定することが多いですが，途中まではうまくいっていたのに，ある時から citation が見つからないというエラーが出て，参考文献リストも文章中の参照も適切に表示されない（citation名が表示される）

でつまることが増えて，ちょっと困ってました．

Eclipse 上で「Check for Updates」を実行してもなんら表示されないので，最新版は出てないままかと思っていましたが，上記問題への解決策がないかとプロジェクトのホームページを開いてみると，実はこの10月13日にバージョン 2.0.3 の最新版がリリースされていることが分かりました．前の 2.0.2 が 2018年7月27日だったため，2年ぶりの更新となります．

どうやってインストールするのかと調べてみた所，このページの Release に記載されているページ:

http://download.eclipse.org/texlipse/2.0.3/

を Eclipse の Install New Software のリポジトリに登録(Add)して，インストールすれば良いみたいですね．

実行した結果，無事に BibTeX Editor も動作するようになりました．

なお Eclipse 上のメニュー 「LaTeX」から「Force build」というのが選べて，前からこれを実行すると Eclipse がハングアップするという状況が発生してたのですが，それについては，変わってないみたいですね．．．

Ubuntu Server 20.04/Tomcat9でJenkinsインストール

Ubuntu Server 20.04 および Tomcat9 も動作し、GitBucket もインストールが完了したので、次のサーブレットとして Jenkins をインストールしようと思います。

Jenkins は Wikipedia の記載では、

Jenkins（ジェンキンス）はフリーでオープンソースの自動化サーバー

です。

イメージとしては、GitBucket に対してコミットしたファイル群から、様々な自動化処理を行ってくれるためのフレームワークといった所です。

Jenkinsのホームページから war ファイルがダウンロード可能で、同ファイルをデプロイすることで使用が可能です。

Jenkinsのインストール手順が書かれたページによると、

Jenkins can also be run as a servlet in different Java servlet containers such as Apache Tomcat or GlassFish. However, instructions for setting up these types of installations are beyond the scope of this chapter.

とのことで、一瞬、「ん？」と思えますが、手順は簡単なため、以下に手順として記載しておきます。

Jenkinsのサイトから war ファイルをダウンロード

これはそのまんまです。Jenkinsのダウンロードサイトからwarファイルをダウンロードします。なお Jenkins も LTS と最新の2種類が存在していますが、今回は LTS を使用することとします。現時点での最新版は Jenkins 2.249.3 LTS  みたいです。

なおどれが war ファイルのダウンロードなのか、少し分かりにくいです。ぱっと見た時、Ubuntu/Debian と書かれた所に目がいってしまいますが、左側の表の一番上の、少しごちゃごちゃと記載されているのが war ファイルとなります。なお左側がLTSを示しています。

tomcatサービスの停止

デプロイを安全に行うために一度tomcatを停止します。稼働させたままデプロイできるやもしれませんが、心配なので一旦停止します。

$ sudo systemctl stop tomcat9

tomcatのwebappにコピー

tomcatが停止したことを確認した後、tomcatのwebappフォルダにダウンロードしたwarファイルをコピーします。停止の確認は以下で可能です。ステータスが inactive であれば大丈夫です。

$ sudo systemctl status tomcat9

なおwebappフォルダは以下です。システム構成によっては違うかもしれませんが。

/var/lib/tomcat9/webapps

tomcatサービスの起動

warファイルをコピー後、tomcatを再稼働させます。これはstopと逆の操作です。

$ sudo systemctl start tomcat9

jenkinsへ1stアクセス

これで Jenkins のインストールが開始されます。無事に動作したかどうかは tomcat の manager 画面から確認出来ると思います。URLとしては、

http://localhost:8080/manager/html

とかになるかと思います（localhostの場合）。

ここでエラーなく Jenkins が稼働（Running が true）しているのを確認したら Jenkins のページにアクセスします。

http://localhost:8080/jenkins

ですね。

そうすると以下のUnlock画面が表示されます。

このページの意味は書かれている内容の通りですが、画面上に表示されている指定のファイルからパスワード文字列をコピーして入力欄に貼り付けて Continue です。

その後、無事に動作し、プラグインのインストール画面が表示されます。

水色で示されている Install suggested plugins をクリックします。

このように提案された各種プラグインのインストールが開始されます。

無事にインストールが終わるとFirst Admin User の登録画面が表示されます。

これで Save and Continue として進めると無事にJenkinsが開始されます。

webアプリケーションによるとは思いますが、いつもながら Jenkins のデプロイは楽ですね。開発者またユーザの皆様に感謝です。

実務側ではソフトウェアリポジトリへコミットされたソース群を Nightly で検証することをさせていますが、家のサーバですし、少し便利な使い方を考えてみたいと思います。

もしかしたら「それ、cronで出来るやん」という使い方だけで終わるかもしれませんが。。。

HomeServer / 気がつくと Gnome Desktop が...

 最近稼働中の HomeServer ですが、元々 Ubuntu Server 20.04 として GUI なし CUI ベースで導入していたのですが、今しがたリモートログインして top を見てみると、Xサーバが稼働していることに気づきました...

うーんです...

前に本サーバからメインの開発PCにリモートで色々とXアプリケーションをとばして表示させようとしていたのですが、その時、うっかりと導入してしまった模様です。

gnome-shellも動いてますね。

基本サーバマシンであり低消費電力で連続動作させたいってのがありますので、このデスクトップ環境は停めたいなと思いますね。

また、まだサーバの方、電力制御の設定を行っていないので、低電力化の設定としてまとめて次は行いたいと思います。

それを進めるには CPU のモードや BIOS 機能など、色々とハード側の確認が必要な気がしますので、そちらについては本ブログの兄弟であるハードウェア関係のブログ記事に書いていこうかと思います。

Ubuntu Server 20.04/Tomcat9/GitBucketでMySQL

前回の記事で Ubuntu Server 20.04/tomcat9上でGitBucketが動作する所までは対応しました。

GitBucketはデフォルトで H2 Database を使用しています。

開発元が公式に

「H2はデータの保全性に問題がありますので業務等の重要な用途にGitBucketを使われるのであればなるべくPostgreSQLもしくはMySQLを利用することが望ましいです（パフォーマンス面でもメリットがあります）」

と説明されていますので、今回、MySQLに変更することにしました。

なお前の Ubuntu 18.04 の時も MySQL を使用していました。基本的な内容は同じです。細かな部分については前の記事の方が詳しいので、そちらを参考にしてください。大枠としては 20.04/Tomcat9 での動作確認の意味でこちらの記事を参照してください。

• GitBucket の設定 / データベース (1)
• GitBucket の設定 / データベース (2)

MySQL を Ubuntu Server 20.04 の標準リポジトリからインストールすると、本記事作成時点では、バージョン 8.0.22 がインストールされます:

$ mysql --version
mysql  Ver 8.0.22-0ubuntu0.20.04.2 for Linux on x86_64 ((Ubuntu))

これを使うことにします。

GitBucket 側の設定方法は公式Wikiの External database configuration に説明が記載されています。

ほぼその通りにすれば出来るのですが、注意点としては、

• mysqlのバージョンが8以上なので、上記ページ記載の MySQL8 以上への対応が必要
• 説明されている grant all privileges on ... のコマンド一文が MySQL8 ではエラーとなるため、ユーザ作成と grant を別コマンドで実行

があるかなと思います。

無事に稼働すると、以下のように外部データベースで無事に接続出来ていることが確認出来ます。

色々とスムーズに導入できるので、開発者の方やこれまでの多くのユーザさんに感謝です。

これで信頼性を確保し導入が容易なGitリポジトリが実現出来ました。

あと気になる所はデータバックアップですね。

次はデータバックアップの設定を行いたいと思います。

ただバックアップからの復帰確認は、するかしないか、少し悩んでいます。

ちょっとした手間＋リスクですしね。

そもそも自分ローカルのネットワーク内でどこでも作業可能とし、色々な開発リソースの置き場を一元化することを主目的に導入したものであるため、とりあえずバックアップが取れて、そこに必要なデータが入っていることが確認出来たら、それ以上は確認しないかもしれません。

Ubuntu Server 20.04/Tomcat9でGitBucketインストール

現在、Ubuntu 20.04 Server のサーバマシン上で Tomcat9 を動かしています。

なおJavaは OpenJDK 14 を使用しています。

サーバマシンのハードウェア詳細については、別のブログに記載しています（書きかけのため公開していない記事も多いので、色々と前後していますが）。 

同サーバ上で稼働させるサーバとしてはGitサーバとCMSサーバを予定しています。

両者共にJavaサーブレットとしての実現を考えており、まずはGitサーバとして以前から愛用している GitBucket を導入しました。

インストールの方、ざっくりとは同じやり方で問題ないかとは思いますが、ちょっとだけ Tomcat9 へのデプロイ時にエラーでごたごたしましたので、記録としてメモしておきます。

なお基本的なデプロイの方法についてはGitBucketのインストールページの「Deployment to JEE and Servlet containers」に紹介されていますが、Tomcat9 の所は ToDo となっています。

インストール時のごたごた、具体的にはデプロイに失敗する（falseとなる）はインストール手順どうこうというよりは、こちらのTomcat9 側の基本設定に依存する内容かな、と思いますので、参考までに情報を列挙する形で上げておきます。

• Tomcat が使用する Java環境としては Ubuntu 20.04 Server の通常リポジトリから OpenJDK14 をインストール
• Ubuntu 20.04 Server の通常リポジトリから Tomcat9 をインストール
• インストールによりユーザ tomcat が自動生成されるが、ホームディレクトリが設定されていないため設定
• /home/tomcat をmkdirし、/etc/passwdのtomcatユーザの設定箇所に /home/tomcat を追加
• chown tomcat:tomcat /home/tomcat によりオーナを tomcat に
• GitBucket のサイトから gitbucket.war をダウンロードし、Tomcat の管理画面 (TomcatのURL/manager/html ）の「サーバ上のWARファイル又はディレクトリの配備」の[WARファイル又はディレクトリのURL:] でファイル位置を指定してデプロイ (配置)

です。

僕がミスしていた所は上記で chown を忘れ root アクセス権のままで、gitbucket をデプロイする際に同ディレクトリ下にファイル等を生成出来ないためでした。

これで無事に起動しました。tomcatの管理画面上ではこのようになっています。

また GitBucket 側の管理画面上ではこのようになっています。

上述のような素の設定下では GITBUCKET_HOME は自動的に /home/tomcat/.gitbucket となる模様です。

なおいつもデプロイ直後に「どうだったっけ？」と悩む管理者の初期情報ですが、GitBucketのページの Installation に記載されている以下の情報ですね。

• Download the latest gitbucket.war from the releases page and run it by java -jar gitbucket.war.
• Go to http://[hostname]:8080/ and log in with ID: root / Pass: root.

これで無事Gitサーバは起動しました。

次は上記の管理画面に記載されているデータベースの変更を行おうと思います。

Google Noto Fonts

家で仕事をする中でドキュメントを書くことが多いのですが、色々とフォントのことが気になります。

ちょっと Unicode 全般について勉強する必要も出てきてて、出来るだけ多くの文字が、豆腐文字になることなく表示できるフォントを探してます。

そのまさに「NO more TOfu」となるフォントがGoogle Noto Fontsの様です。

この Google Noto Fonts をメインマシン(Ubuntu 18.04)に入れてみようと思います。

Google Noto Fonts の入手

Google Noto Fonts は以下のサイトから入手可能です。

Google Noto Fonts/Beautiful and free fonts for all languages

ページ上の [DOWNLOAD ALL FONTS] ボタンをクリックするとダウンロードが始まります。

ダウンロードボタンの下に書いてある通り1.1GBもあるフォントセットです。

Google Noto Fonts のインストール

インストールは上記ページの[Install]の所の説明の通りです。

How to install fonts

Windows/macOS/Linuxでのインストール方法の説明がのっています。

僕は Ubuntu18.04 なので Linux インストールなのですが、「for a single user」か「for all users」かの選択肢があります。

どちらにしようか悩みましたが「for all users」にしておこうかと思います。

その手順は以下の様です。

# for all users
sudo mkdir -p /usr/share/fonts/opentype/noto
sudo cp *otf *otc /usr/share/fonts/opentype/noto
sudo fc-cache -f -v # optional

ちょっと2つ目のコマンドが正常動作しないので、以下としました。

sudo cp *.otf  /usr/share/fonts/opentype/noto

そして fc-cache をして終了です。

notoフォントとして 137フォント が取り込まれてますね。

/usr/share/fonts/opentype/noto: caching, new cache contents: 137 fonts, 0 dirs

TeX Live 2020 での LuaLatex エンジン

前の記事 で、TeX Live 2020 は 2019 から対して変わってないのでは、みたいなことを書きましたが、 ちょっと使ってみて、それなりに大きな違いが発生していることに気が付きました。

僕はpdfの直接的な生成を考えて LuaLatex を、Eclipse上のTeXLipseで使っています。

TeXLipse上での実行時にコンソールに表示される最初のメッセージは、これまで、

running: /usr/local/texlive/2019/bin/x86_64-linux/lualatex -synctex=1 -interaction=nonstopmode document.tex 
lualatex> This is LuaTeX, Version 1.10.0 (TeX Live 2019) 

だったのですが、TeX Live 2020 に変えると、

running: /usr/local/texlive/2020/bin/x86_64-linux/lualatex -synctex=1 -interaction=nonstopmode document.tex 
lualatex> This is LuaHBTeX, Version 1.12.0 (TeX Live 2020) 

となっていることに気が付きました。

これまではLuaTeXベースだったのが TeX Live 2020 からは LuaHBTeXベースになったのですね。

LuaHBTeXは前にLuaTeXについて調べた時に存在は知っていたのですが、HarfBuzzライブラリを組み込んだLuaTeXのことみたいです。

HarfBuzzライブラリとは、フリーのOpenTypeテキストシェーピングエンジン(フォントレンダリングエンジン)みたいです。

ここが開発元で Android, Chrome, ChromeOS, Firefox, OpenJDK, Qt 等にも使われているみたいです。

TeX Live 2020 から変更されたことの情報源を探していたのですが、 LATEX News/Issue 31, February 2020 に記載がありました。

Concerning this release . . . (LuaLATEX engine) The new LuaHBTEX engine is LuaTEX with an embedded HarfBuzz library. HarfBuzz can be used by setting a suitable renderer in the font declaration. A basic interface for that is provided by fontspec. This additional font renderer will greatly improve the shaping of various scripts when using LuaLATEX, many of which are currently handled correctly only by X TEEX, which always uses HarfBuzz. To simplify testing of the new engine, binaries have already been added to MiKTEX and TEX Live 2019 and both distributions have already now changed the LuaLATEX-dev format to use it. Going forward, LuaLATEX (and LuaLATEX-dev) will both use the LuaHBTEX engine. The timing of the switch to the LuaHBTEX engine depends on the distribution you use (for TEX Live this will be with TEX Live 2020).

とのことです。