私は org-mode を使って LuneScript のリファレンスを作成しています。 日本語のリファレンスを書くのも大変ですが、 それを英訳しようとすると気が遠くなります。 そこで機械翻訳を使う予定ですが、 .org ファイルをそのまま機械翻訳で処理すると、 コードブロックや org-mode の区切り記号まで変換され、 意図した結果を得られません。 そこで今回は、org-mode の機械翻訳をスムーズに行なえるツールを検討します。 構成 今回検討する org-mode 翻訳ツールは、以下の構成
今回の記事は、 先日検討した LuneScript のクラスのオブジェクトを スタックに割り当てて高速化できるかどうか?の検討結果です。 結果 今回の検討結果は以下の通りです。 「スタック割り当て自体は有効ですが、 スタック割り当てから escape されないように設計しないと効果を得られません。」 なんだか当たり前な検討結果ですが、そうなんだから仕方がない。 では、なぜそのような結果になったかを説明していきます。 検討内容 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% 改善後3 6/29(8898c475) 18.07 sec 1.13 sec 1599% 改善率(改善前/改善後3) 142% 517% この表は、セルフホスティングしているソースのトランスコンパイル時間の計測結果を 示しています。 lua VM で動作させた lnsc と、go でビル
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% この表は、セルフホスティングしているソースのトランスコンパイル時間の計測結果を 示してい
今月上旬に TypeScriptToLua の存在を知ったことで、 「Lua のトランスコンパイラ」という LuneScript の主な 存在意義 がほとんど消えてしまいました。 それによって LuneScript 開発に対するモチベーションが一気に下りましたが、 よくよく考えてみれば、今迄も自分以外の誰かが使っていた訳でもないし、 独自言語開発は元々自分がやりたかったこと でもあるので、 TypeScriptToLua があろうとなかろうと 今迄と然程違いはないんじゃないか、 という結論になりました。 そんな訳で、Lune