LuneScript は golang へのトランスコンパイルをサポートしている。 golang 対応の付加機能として、LuneScript には限定的な非同期処理を提供している。 今回は、この「限定」を緩和する方法を検討する。 非同期処理を「限定」する理由 非同期処理を限定する主な理由は、非同期処理を安全に実行するためだ。 では、非同期処理のなにが危険なのかといえば、データアクセスの競合だ。 Rust では、データアクセスの競合が発生しないように、 言語の syntax で論理
LuneScript は golang へのトランスコンパイルをサポートしている。 golang 対応の付加機能として、LuneScript には限定的なスレッド機能を提供している。 「限定的」の大きな理由の一つとして、 golang 向け LuneScript ランタイムのマルチスレッド対応問題がある。 golang 向け LuneScript ランタイム golang 向け LuneScript ランタイムは、幾つか機能を持っている。 その機能の中には、次のものを含む。 and or 演算子の処理を実現するためのスタック。 lua ランタイム制御。 LuneScript は元々 Lua 向けのトランス
Language Server Protocol (LSP) の調査メモ。 後でまとめる予定だが、まずは調べた情報を列挙していく。 LSP とは LSP は、プログラミング開発する上で役立つ様々なサポート機能を定義するプロトコル。 従来は、エディタの開発者や、エディタの拡張機能開発者が プログラミング言語毎に様々なサポート機能の開発を行なっていた。 これにより、同じプログラミング言語でも、エディタごとに異る実装が必要で、 あるエディタでは使える機能が、別のエディタでは使えない
LuneScript は、モジュールを利用する際に import 命令を使用する。 この import 命令は、次の処理を行う。 指定のモジュールの .lns ファイルを解析し、何を定義しているかを調べる shebang などで起動した場合は、指定のモジュールをロードする 今回は、前者の話をする。 meta 情報 モジュールがどんなクラスや関数や変数を定義しているのかを示す情報を、 LuneScript では meta 情報と呼ぶ。 この meta 情報は、 そのモジュール内で pub (あるいは pro) 宣言されている情報からなる。 これには次の情
Rapberry pi 4 で簡易的な NAS を構築している。 メイン PC の OS が Windows なので、 NAS で使っている HDD を Windows PC と直接接続してアクセスすることを考えて、 NTFS フォーマットの USB HDD を raspi にマウントしていた。 しかし、これだとパフォーマンスが全く出ない(ntfs-3g が重すぎる)。 次回の windows 10 アップデートで、 WSL2 の機能をつかった ext4 マウントがサポートさるようなので、 USB HDD のファイルシステムを NTFS から ext4 に変更することにした。 これによって、NTFS の時は smb
go1.16 から embed が利用可能になりました。 <https://golang.org/pkg/embed/> embed によって、 プログラムにバイナリデータを埋め込む処理が簡単に行なえるようになります。 LuneScript のコンパイラは、 go でビルドした際に Lua 環境がなくても動作するように、 Lua 用のセルフホストコードをコンパイラ内部に埋め込み、 実行時に埋め込んであるセルフホストコードをロードしています。 以前は、 Lua 用のセルフホストコードを []byte として定義するコードを生成するスクリプトを 自前で実行して、それをビ
raspberry pi でローカルサーバを立ち上げているが、 この sdcard 寿命が気になったので調べてみた。 sdcard はでなく、 hdd や ssd で運用する方法もあるが、 sdcard で運用できる方がランニングコストが良いので、できれば sdcard で運用したい。 sdcard の寿命の見積り iostat -h で sdcard への書き込み量を調べると、 1日約 1GB の書き込み がある。 この書き込みが sdcard の 何ブロックを書き換えているのか不明 なので、 とりあえず 10 倍の 10GB 相当 のブロックを書き換えたとする。 次に sdcard が SLC か MLC か TLC かだ
LuneScript の解説サイトは、 hugo を使用して構築している。 その解説サイトに掲載しているソースコードは、 hugo によって解析されて、色付けに必要な <span class=""> が付加され、 css で色付けを行なっている。 なお、 ソースコードの解析自体は hugo というよりも、 hugo が chroma の API を呼び出して利用している。 しかし LuneScript は超マイナー言語なので、 chroma の対応言語には当然 LuneScript が入っていない。 これだと LuneScript のサンプルコードのハイライトが付かないため、コードを読み難い。 そこで、L
WSL2 と virtual BOX が共存できるようになったらしいので、 家の環境に WSL2 を入れてみました。 セットアップ自体は上手くいきましたが、 結果として virtual BOX のパフォーマンス(DISK IO？)は 1,2 割程度落ちたようです。 WSL2 のパフォーマンスが WSL2 無効時の virtual BOX と同等程度なので、 virtual BOX から WSL2 に完全移行できるなら問題ないと思いますが、 WSL2 に完全移行できず、かつ、1,2 割程度のパフォーマンスダウンが許容出来ない場合は、 従来通り WSL2 無効で運用すること
LuneScript の CI 環境として github actions を使用している。 この CI のテスト時にビルドした go 版 LuneScript のシングルバイナリを、 google drive にアップロードして公開するように対応した。 <https://drive.google.com/drive/folders/1S5NgeM6qIOIUC0rkBHqnWZcuhmsTqB2w> 今回は、この手順について説明する。 公開方法 基本的には次の手順に従えば出来るが、 Google の UI の一部が変っているので、そこを主に補足していく。 <https://qiita.com/satackey/items/56729c8551aabb2ae7cc> skicka google drive へのアップロードは skicka を利用する。 skicka は OSS だ。 この skicka を利用するためには、 OAuth2 認証 ClientID と Client Secret が必要になる。 OAuth2 認証は、ウェブサービス
