Posts

org-mode ドキュメントの翻訳ツール検討

私は org-mode を使って LuneScript のリファレンスを作成しています。 日本語のリファレンスを書くのも大変ですが、 それを英訳しようとすると気が遠くなります。 そこで機械翻訳を使う予定ですが、 .org ファイルをそのまま機械翻訳で処理すると、 コードブロックや org-mode の区切り記号まで変換され、 意図した結果を得られません。 そこで今回は、org-mode の機械翻訳をスムーズに行なえるツールを検討します。 構成 今回検討する org-mode 翻訳ツールは、以下の構成

LuneScript のトランスコンパイル高速化 (スタック割り当て)

今回の記事は、 先日検討した LuneScript のクラスのオブジェクトを スタックに割り当てて高速化できるかどうか?の検討結果です。 結果 今回の検討結果は以下の通りです。 「スタック割り当て自体は有効ですが、 スタック割り当てから escape されないように設計しないと効果を得られません。」 なんだか当たり前な検討結果ですが、そうなんだから仕方がない。 では、なぜそのような結果になったかを説明していきます。 検討内容 LuneScript でオブジェクトをスタック

LuneScript のトランスコンパイル高速化 (トランスコンパイル時間を 2273 パーセント改善)

先月から続いて、LuneScript のトランスコンパイル高速化作業をしています。 セルフホストのトランスコンパイル時間 今回の時間短縮は以下の通りです。 lua VM 版 go ビルド版 lua/go 改善前 5/6 (6e5661a9) 25.69 sec 5.84 sec 440% 改善後 5/25 (364095ef) 17.42 sec 2.22 sec 785% 改善後2 6/7(52df422b) 17.57 sec 1.82 sec 965% 改善後3 6/29(8898c475) 18.07 sec 1.13 sec 1599% 改善率(改善前/改善後3) 142% 517% この表は、セルフホスティングしているソースのトランスコンパイル時間の計測結果を 示しています。 lua VM で動作させた lnsc と、go でビル

LuneScript のセルフホストのマルチスレッド化 (トランスコンパイル時間を 1412 パーセント改善)

LuneScript の高速化のため、マルチスレッド化を行ないました。 今回は、LuneScript のどこをマルチスレッド化したのか、 マルチスレッド化で何故高速化できるのかを説明します。 ビルド時間 今回の時間短縮は以下の通りです。 lua VM 版 go ビルド版 lua/go 改善前 5/6 (6e5661a9) 25.69 sec 5.84 sec 440% 改善後 5/25 (364095ef) 17.42 sec 2.22 sec 785% 改善後2 6/7(52df422b) 17.57 sec 1.82 sec 965% 改善率(改善前/改善後2) 146% 329% この表は、セルフホスティングしているソースのトランスコンパイル時間の計測結果を 示してい

LuneScript のこれからの予定

今月上旬に TypeScriptToLua の存在を知ったことで、 「Lua のトランスコンパイラ」という LuneScript の主な 存在意義 がほとんど消えてしまいました。 それによって LuneScript 開発に対するモチベーションが一気に下りましたが、 よくよく考えてみれば、今迄も自分以外の誰かが使っていた訳でもないし、 独自言語開発は元々自分がやりたかったこと でもあるので、 TypeScriptToLua があろうとなかろうと 今迄と然程違いはないんじゃないか、 という結論になりました。 そんな訳で、Lune

LuneScript のトランスコンパイル時間を 1157 パーセント改善した件

前回から引き続き LuneScript のトランスコンパイル時間短縮を行なっています。 今回の時間短縮は以下の通りです。 lua go lua/go 改善前(6e5661a9) 25.69 sec 5.84 sec 440% 改善後(364095ef) 17.42 sec 2.22 sec 785% 改善率(改善前/改善後) 147% 263% この表は、セルフホスティングしているソースのトランスコンパイル時間の計測結果を 示しています。 lua VM で動作させた lnsc と、go でビルドした lnsc で計測しています。 改善前の 6e5661a9 は、5/6 のバージョンです。 改善後の 364095ef

LuneScript のスレッドにおける mutable 制御

LuneScript は golang へのトランスコンパイルをサポートしている。 golang 対応の付加機能として、LuneScript には限定的な非同期処理を提供している。 今回は、この「限定」を緩和する方法を検討する。 非同期処理を「限定」する理由 非同期処理を限定する主な理由は、非同期処理を安全に実行するためだ。 では、非同期処理のなにが危険なのかといえば、データアクセスの競合だ。 Rust では、データアクセスの競合が発生しないように、 言語の syntax で論理

Go の関数パフォーマンス

LuneScript は golang へのトランスコンパイルをサポートしている。 golang 対応の付加機能として、LuneScript には限定的なスレッド機能を提供している。 「限定的」の大きな理由の一つとして、 golang 向け LuneScript ランタイムのマルチスレッド対応問題がある。 golang 向け LuneScript ランタイム golang 向け LuneScript ランタイムは、幾つか機能を持っている。 その機能の中には、次のものを含む。 and or 演算子の処理を実現するためのスタック。 lua ランタイム制御。 LuneScript は元々 Lua 向けのトランス

Language Server Protocol (LSP) メモ

Language Server Protocol (LSP) の調査メモ。 後でまとめる予定だが、まずは調べた情報を列挙していく。 LSP とは LSP は、プログラミング開発する上で役立つ様々なサポート機能を定義するプロトコル。 従来は、エディタの開発者や、エディタの拡張機能開発者が プログラミング言語毎に様々なサポート機能の開発を行なっていた。 これにより、同じプログラミング言語でも、エディタごとに異る実装が必要で、 あるエディタでは使える機能が、別のエディタでは使えない

LuneScript の import と meta

LuneScript は、モジュールを利用する際に import 命令を使用する。 この import 命令は、次の処理を行う。 指定のモジュールの .lns ファイルを解析し、何を定義しているかを調べる shebang などで起動した場合は、指定のモジュールをロードする 今回は、前者の話をする。 meta 情報 モジュールがどんなクラスや関数や変数を定義しているのかを示す情報を、 LuneScript では meta 情報と呼ぶ。 この meta 情報は、 そのモジュール内で pub (あるいは pro) 宣言されている情報からなる。 これには次の情