この記事は Haskell Advent Calendar 2023 の6日目の記事です。
私はここ数年、HaskellコンパイラーであるGHCに貢献しています。この記事では、今年(2023年)に私が行った貢献を紹介します。
GHCの開発は独自ホストされたGitLab上で行われています。
続きを読むこの記事は Haskell Advent Calendar 2023 の6日目の記事です。
私はここ数年、HaskellコンパイラーであるGHCに貢献しています。この記事では、今年(2023年)に私が行った貢献を紹介します。
GHCの開発は独自ホストされたGitLab上で行われています。
続きを読むEvernoteがまた改悪するらしい。
この前に値上げのニュースがあって、Personalプランが年額5200円から9300円に値上がりする。流石にこの値上げ幅はきつい。私の次回更新は数日後なので、PersonalをやめてFreeプランにするつもりだった。Freeプランでは同期できる台数にきつい制限があるので、どのみちEvernoteは常用をやめるつもりだ。過去のノートの参照には使うかもしれない。
私がEvernoteを使い始めたのは2010年だったらしい。13年間の長い付き合いだった。
Evernoteのデスクトップアプリを使うとノートをエクスポートできる。Freeプランは今回の改悪後も参照はできるようだが、念の為、HTMLにエクスポートした。
ノートテイキングアプリは何が便利だったか。私が求めるのは
あたりだろうか。Evernoteにはノートブックという分類の仕組みがあるが、最近はあまり活用していない。ユーザーに分類させるのはユーザーの時間を消費するので、分類はAIがやるか、検索機能を強力にする等で対応するべきだと思う。
今後何を使うか。最近流行りなのはNotionというやつだろうか。しかし、いまいち新しいサービスを試す気力が湧かない。
登山計画書など、他人と共有する必要のある文書は最近はGoogleドキュメントで書いている。個人用のメモもGoogleドキュメントで良いのではないか。しばらくGoogleドキュメントを常用してみて、「気軽さ」「検索性」を確かめてみたい。
Appleのメモアプリというのもある。iPhoneの購入により手持ちの端末が大体Apple製になったのでこれもアリだ。しかしいざという時のエクスポートの容易性はよくわからない。
いわゆるトンデモに関して私が思うことを何点か書いておく。
続きを読む今年の秋は安達太良山(福島県)や八溝山(茨城県・福島県)に登ったが、いまいち満足できなかった。シーズンが終わる前にもう一個くらいガッツリした山に登りたい。
ということで、前から気になっていた皇海山(栃木と群馬の県境、渡良瀬川源流、足尾の主)に行くことにした。皇海山は日本百名山だが、コースタイムがかなり長い(最寄りの山小屋から山頂まで往復10時間)上に山頂の展望はない、マニアックな山という印象である。
数年前までは群馬側の林道を使って日帰りでも行けたようだが、その林道は通行不可になり、今は(バリエーションルートを除けば)事実上栃木側からの「クラシックルート」一択である。それも登山地図には一部が破線で表示されている。
皇海山は栃木県の山のグレーディングでは最難関(D;グレーディングの技術的難易度としてはAからEまでがある)とされている。地図に登山道が載らない錫ヶ岳よりも高難易度とはどういうことなのか……。
日本百名山全体を見ても皇海山は割と(体力的に)難易度の高い方なのではないかと思う。コースタイムが10時間以上なのは他に平ヶ岳(コースタイムが12時間で、山中に宿泊できない)が思いつく。
続きを読むLaTeX処理自動化ツールClutTeXの今後の計画について。
まず、いくつかバグ修正や機能追加が溜まっているのでバージョン0.6をリリースしたいです。
それで、TeX LiveのContributing package
を久しぶりに読んだら「manページを書いた方が良い」「tarball中にバージョンがわかるファイルがあると良い」みたいな文言があった(以前読んだ時に読み飛ばしたのか最近新しく追加されたのかは未確認)ので、manページを書こうとしています。
manページは他のフォーマットから(pandocなどで)変換することもできるようです(llmkを見たらronnというツールでMarkdownから変換しているようです)が、ツールへの依存を増やしたくないので、書き方を勉強して手書きしようとしています。具体的にはmdocという記法で、
というページを参考にしています。
それ(v0.6リリース)が終わったら、Luaで書かれたコードをStandard MLに移行したいです。LunarMLを作ってきた目的の一つです。ソースコードはStandard MLで書いても、配布は従来通りLuaスクリプトとして行えるようにします。
ところで、静的型言語からLuaに変換する系のやつを改めて調べると
みたいなやつが増えていました(2020年ごろはなかった or 知名度が低かったと思います)。まあLunarMLを作ってしまったのでLunarMLでやります。
こっちの作業もブランチを切って少しずつ進めています。
コンパイルに使うLunarMLはまだリリースしていない状態で、他人が使うには難があるので、ClutTeXのSML版を出す前にLunarMLのバージョン0.1をリリースしたいです。ただし、ClutTeXのSML版が書ける程度に標準ライブラリーを充実させたいです。
SMLへの移行が終わったら、本格的なバグ修正や機能追加に移ります。バグ修正としては、BibTeXの .bib
ファイルを更新した際に再処理を行うようにしたいです(Biberに関しては最近プルリクがあって実装して頂きました)。
機能追加としては、ユーザーごとの(プロジェクトに依存しない)設定ファイルを実装したいです。設定項目はターミナルの色付けや、終了時のアクション(「PDFビューワーで開く」などのコマンドを実行できるようにする)を登録できるようにしたいです。フォーマットはTOMLを考えています(なので、TOMLパーサーを書かなくてはいけない)。
まとめると、以下の順序と時期で進めていきたいです。
数ヶ月前にやりたいことリストという記事を書きましたが、相変わらず(?)やりたいことに対して時間が少なく感じます。
そろそろv0.1をリリースしたいです。記事も準備しています。
ただ、ClutTeXで必要な最低限の機能は揃えてからリリースしたい気もします。直近ではClutTeXで欲しくなったので BinIO
と String.isSubstring
を実装しました。
10月中にリリースできなくても、11月にはリリースするようにしたいです。
BibTeX関連で具体的な修正箇所が判明したので直しています。
直したらリリースするべきですが、GitHubの方に来ているPRを先にマージした方が良いのか悩んでいます。まあこまめにリリースすればいいんですけど。
Standard MLへの書き換えも気が向いた時に進めていて、手足となるモジュールは大体移植した(あるいはLuaコードのラッパーをSMLで書いた)と思います。あとは一番大事なメイン部分です。
SIMD周りの作業は休止中です。
32ビットArm向けのクロスコンパイラーをビルドしようとして遭遇した問題を(原因をある程度特定した上で)バグ報告したりしました。
書きたい記事はいくつかあります。
Handbook of Constructive Mathematicsは気になった章をつまみ食い的に読んでいます。
それで、構成的数学のモデル(?)みたいなものをもっとちゃんと勉強するべきだと思って、SGLを読んでみようかと思っています。しかしどうやって時間を捻出するかが問題です。
10月に入ってから安達太良山に行きましたが、若干物足りなかったので、もう少し秋山に行きたいです。しかし泊まりで行くと大掛かりになるので、近場で済ませるかもしれません。
ミラーレス一眼が欲しいけど先送りにするのは前の記事に書きました。当面は一眼レフを使い続けます。
ただ、一眼レフで使っているレンズが、保管環境の管理をサボっていた時期があったせいか、像が微妙な感じになっている気がします。なので新しいレンズを入手したいのですが、一眼レフの全盛期が過去のものになったせいか、レンズのラインナップが以前と比べて減っている気がします。どうしたものか。
どっちみち今年は色々大きな出費があった(iPhone、登山靴、ミニPC)ので、出費を躊躇しています。
前の記事で言及したGitHub Sponsorsを始めてみましたが、まだ勝手がよくわかりません。まあどっちみちあまり期待はしていないのですが。
この記事は20分で書きました。
今年の夏はいくつか山行を立てた。この記事ではそれらを簡単に振り返りたい。
続きを読むアルゴリズムの擬似コードを書く際は、いわゆる手続き型のスタイルで書くことが多いかと思います。つまり、更新可能な変数とループを使います。
一方、私がよく書くのは関数型言語で、これは更新可能な変数やループの代わりに末尾呼び出しを使用します。
では、アルゴリズムを提示してそれを関数型言語で実装する、というスタイルの文章を書く場合、アルゴリズムの擬似コードはどう書けばいいのでしょうか?
(ここでは、アルゴリズムの停止性、計算量、不変条件の明示等の観点から擬似コードの方が有益であり、関数型のコードだけを書けば良いというものではない、という立場を取ります。)
続きを読む前にこういう記事を書きました:
かいつまんで説明しておくと、Universal Machineというのは2006年のICFP Programming Contestで挑戦者が実装する必要のあるVMです。これは速ければ速いほどいいので、JITコンパイルに挑戦したくなります。2年前の記事ではAArch64向けのJITコンパイラーを書きました(私の家の最速マシンがM1 Macだったので)。
時は流れ、私の家の最速のマシンはM1 MacからRyzen搭載ミニPCへ交代しました。なので、x86_64版のJITコンパイラーも書きたくなりました。
今回対応したのはUnix系で、Windows版は未実装です。
続きを読む