VirtualBox/VMWare と WSL2 は共存可能です。 しかし、共存させると VirtualBox/VMWare 上の GuestOS にオーバーヘッドがかかります。 今回はオーバーヘッドの概要と、共存と排他の設定切り替え方法のネタです。 VirtualBox と WSL2 共存のオーバーヘッド 以下に VirtualBox と WSL2 の実行時の階層図を示します。 この図は、次の 4 つの状態を表わしています。 (A) 従来の Windows で VirtualBox を動かす状態 (B) Windows で WSL2 を動かす状態 (C) Windows で WSL2 と VirtualBox を動かす状態(異常時) (D) Windows で WSL2 と VirtualBox を動かす状態(正常時) (A) は、 WSL サポート前の Windows で VirtualBox を

自作ツールで、MS Teams に対して投稿を read/write する方法について書きます。 Teams の管理者権限の許可が必須 「 Teams の管理者権限の許可が必須 」です。 大事なことなので始めに書きます。 自作ツールで、MS Teams に任意に投稿を read/write するには、 「 Teams の管理者権限の許可が必須 」です。 たとえ自分自身のアカウントを使って投稿したくても、 自作ツールから行なうには管理者権限の許可が必須 なんです。 MS Graph API へのアクセス MS Graph API は、以下のサイトにリファレンスが

asciidoctor-pdf を利用すると asciidoc を pdf 化できます。 ここでは、 asciidoctor-pdf のセットアップと pdf 化時のレイアウト変更方法について説明します。 asciidoctor-pdf のセットアップ asciidoctor-pdf が既にインストールされている場合、 日本語フォントのインストール時に conflict することがあるので、 ここでは docker を利用します。 docker を使わなくても、ローカル環境に ruby をインストールし、 Dockerfile の RUN と同等の手順を実行してもインストールできます。 asciidoctor-pdf が conflict した場合は、 asciidoctor-pdf をアンインストールしてから asciidoctor-pdf をインストー

先日の記事に書いた org-mode ドキュメントの翻訳ツールを作成したので、 今回はそのツールの使用方法を書きます。 セットアップ golang がインストールされている環境で、以下を実行してください。 go install -tags gopherlua github.com/ifritJP/trans-orgmode@latest GCP の設定 GCP アカウントを既に持っていることを前提に説明します。 アカウントが無い場合は、作成してください。 プロジェクトの作成 以下の手順に従って作業します。 <https://cloud.google.com/translate/docs/setup?hl=ja#project> これにより、以下を行ないます。 プロジェクトを作成 API の有効化 サービスアカ

私は 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

前回から引き続き 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