Public Theta Blog

QEMU

2024-10-19T06:19:35.545Z

x86_64のUbuntuでqemu-aarch64-staticする

2024-10-19T06:19:13.117Z

x86_64のUbuntu（環境はGitHub ActionsのUbuntu 22.04のランナー）で、qemu-aarch64-staticを使ってaarch64のバイナリを実行する際に、少しハマったのでメモ。

単純に、qemu-user-staticをインストールして実行しようとすると、次のようなエラーが出る。

sudo apt-get update
sudo apt-get install qemu-user-static

qemu-aarch64-static bin

/lib/ld-linux-aarch64.so.1: No such file or directory

これはaarch64向けのlibcないために起こるためで、このunix.stackexchange.comにある通りarm64のアークテクチャを追加して、libc6:arm6をインストールすればよい。

ただし、ただ追加してapt-get updateしても404エラーが出る。

sudo dpkg --add-architecture arm64

sudo apt-get update

E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal/multiverse/binary-arm64/Packages  404  Not Found [IP: 91.189.91.81 80]
E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal-updates/multiverse/binary-arm64/Packages  404  Not Found [IP: 91.189.91.81 80]
E: Failed to fetch http://security.ubuntu.com/ubuntu/dists/focal-security/main/binary-arm64/Packages  404  Not Found [IP: 91.189.91.83 80]
E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal-backports/main/binary-arm64/Packages  404  Not Found [IP: 91.189.91.81 80]
E: Some index files failed to download. They have been ignored, or old ones used instead.

これはそのままlibc6:arm6がリポジトリに見つからないことを指すエラーなので、このaskubuntu.comにある通り、ソースを追加すると解決できる。

つまり例えば、/etc/apt/sources.list.d/arm64.listを作成して、次のように記述する。

deb [arch=arm64] http://ports.ubuntu.com/ focal main restricted
deb [arch=arm64] http://ports.ubuntu.com/ focal-updates main restricted
deb [arch=arm64] http://ports.ubuntu.com/ focal universe
deb [arch=arm64] http://ports.ubuntu.com/ focal-updates universe
deb [arch=arm64] http://ports.ubuntu.com/ focal multiverse
deb [arch=arm64] http://ports.ubuntu.com/ focal-updates multiverse
deb [arch=arm64] http://ports.ubuntu.com/ focal-backports main restricted universe multiverse

これをコマンドで行う場合は例えばこう。

UBUNTU=$(lsb_release -cs)

sudo tee /etc/apt/sources.list.d/arm64.list <<EOF
deb [arch=arm64] http://ports.ubuntu.com/ $UBUNTU main restricted
deb [arch=arm64] http://ports.ubuntu.com/ $UBUNTU-updates main restricted
deb [arch=arm64] http://ports.ubuntu.com/ $UBUNTU universe
deb [arch=arm64] http://ports.ubuntu.com/ $UBUNTU-updates universe
deb [arch=arm64] http://ports.ubuntu.com/ $UBUNTU multiverse
deb [arch=arm64] http://ports.ubuntu.com/ $UBUNTU-updates multiverse
deb [arch=arm64] http://ports.ubuntu.com/ $UBUNTU-backports main restricted universe multiverse
EOF

加えて、デフォルトの/etc/apt/sources.listを現在のアーキテクチャ専用に書き換えておく必要がある。

# 念の為バックアップ
sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak

# 例えばamd64
ARCH=$(dpkg --print-architecture)

# 置換
sudo sed -i "s/deb /deb [arch=$ARCH] /g" /etc/apt/sources.list

これで、libc6:arm6をインストールでき、qemu-aarch64-staticによるaarch64バイナリの実行が可能になるはず。

sudo apt-get install libc6:arm6

qemu-aarch64-static bin

Windows

2024-10-19T05:44:07.333Z

Windows上でのi686-pc-windows-gnu向けRustビルドで"linker `i686-w64-mingw32-gcc` not found"が出る

2024-10-19T05:38:40.472Z

GitHub ActionsのWindowsのランナーでターゲットをi686-pc-windows-gnuにしてRustのバイナリーをビルドしようとしたら、以下のエラーが出た。

text

error: linker `i686-w64-mingw32-gcc` not found
  |
  = note: program not found

原因は、ターゲットを追加してもコンパイルに必要なrust-mingwというコンポーネントがインストールされないこと（rust-lang/rustup#607）だったので、インストールのコマンドを次のようにすることで解決した。

bash

rustup toolchain install stable-i686-pc-windows-gnu
rustup default stable-i686-pc-windows-gnu

Rustのtargetディレクトリをあるディレクトリ以下で共有する

2024-06-14T04:08:21.822Z

Rustのビルドによるアーティファクトはビルドのキャッシュを含め、すべてtargetディレクトリに出力される。

https://doc.rust-lang.org/cargo/guide/build-cache.html

デフォルトでは、targetディレクトリはプロジェクトのルートディレクトリ、すなわち（ワークスペースであればワークスペースの）Cargo.tomlがあるディレクトリに作成されるが、複数のプロジェクトで多くの同じパッケージを依存関係として持つ場合、同じものをプロジェクトごとにビルドすることになるため、ビルド時間的にもディスク容量的にもかなりの重複が生じることになる。

plaintext

project-a/target/...
project-b/target/...
project-c/target/...

より高度な方法として、sccacheのようなツールを使うこともできるが、単純な方法として、Cargoの設定でtargetディレクトリに同じディレクトリを使うように指定することができる。

https://doc.rust-lang.org/cargo/reference/config.html#buildtarget-dir

環境変数CARGO_TARGET_DIRを設定したり、

bash

export CARGO_TARGET_DIR="/path/to/shared/target"

$CARGO_HOME/config.tomlにbuild.target-dirを設定したり、

toml

[build]
target-dir = "/path/to/shared/target"

といった方法があるが、実はこれらより先に、現在のディレクトリ以上にある.cargo/config.tomlを下から上へと再帰的に読んでくれるという仕組みがあるので、これを使うと、プロジェクトごとだったり、親ディレクトリごとだったりに、targetディレクトリを指定することもできる。

https://doc.rust-lang.org/cargo/reference/config.html#hierarchical-structure

.cargo/config.tomlの相対パスは、.cargoのあるディレクトリを基準として解釈される。

https://doc.rust-lang.org/cargo/reference/config.html#config-relative-paths

なので、例えば次のような.cargo/config.tomlを作成することで、そのディレクトリ以下のすべてのプロジェクトで同じtargetディレクトリ（.cargo/target）を使うようにできる。

toml

[build]
target-dir = ".cargo/target"

plaintext

.cargo/config.toml
.cargo/target/...
project-a/
project-b/
project-c/

その際、あるプロジェクトだけ例外として扱いたい場合は、現在のディレクトリを含めてより近いディレクトリにある.cargo/config.tomlが優先されるので、そのプロジェクトのディレクトリに次のような.cargo/config.tomlを作成して、targetディレクトリを指定すれば良い。

toml

[build]
target-dir = "target"

例えば、project-cにこのファイルを追加した場合、project-cのビルド結果はproject-c/targetに出力されるようになる。

plaintext

.cargo/config.toml
.cargo/target/...
project-a/
project-b/
project-c/.cargo/config.toml
project-c/target/...

このような使い方をする場合、.gitignore_globalなどに.cargo/config.tomlを追加しておくと良いかもしれない。

gitignore

.cargo/config.toml

ただし、その場合は逆にtargetディレクトリを.gitignoreに追加することを忘れないようにしなければならないだろう。

gitignore

/target

webpackでswcを使う

2024-05-20T11:19:20.373Z

webpackでTypeScriptをトランスパイルする際に、ts-loaderの代わりにesbuild（esbuild-loader）を使うこともできるが、swc（swc-loader）を使うこともできる。

依存関係には、@swc/coreとswc-loaderを追加する。

bash

# npm
npm install -D @swc/core swc-loader
# yarn
yarn add -D @swc/core swc-loader
# pnpm
pnpm add -D @swc/core swc-loader

あとは、ts-loaderの代わりにswc-loaderを使うように設定する。

webpack.config.js:

module.exports = {
    module: {
        rules: [
            {
                test: /\.([jt]sx?)?$/,
                exclude: /node_modules/,
                use: {
                    loader: "swc-loader",
                    // https://swc.rs/docs/configuration/compilation
                    options: {
                        jsc: {
                            parser: {
                                syntax: "typescript",
                                tsx: true,
                            },
                        },
                    },
                },
            },
        ],
    },
};

設定にはoptionsを使ってもいいが、.swcrcを使っても良い。

webpack.config.js:

module.exports = {
    module: {
        rules: [
            {
                test: /\.([jt]sx?)?$/,
                exclude: /node_modules/,
                use: "swc-loader",
            },
        ],
    },
};

.swcrc:

json

{
    "jsc": {
        "parser": {
            "syntax": "typescript",
            "tsx": true
        }
    }
}

npmのserveパッケージを使ってローカルサーバーを立てる

2024-05-20T10:35:31.892Z

serve（vercel/serve）を使うと、ローカルサーバーを簡単に立てることができる。

特に、Node.jsが既にインストールされている環境であれば、npxやdlxを使って環境を汚さずその場でサーバーを立てることができる。

bash

# npm
npx serve
# yarn
yarn dlx serve
# pnpm
pnpm dlx serve

もちろん依存関係に追加して、package.jsonのscriptsに追加するなどしても良い。

bash

# npm
npm install -D serve
# yarn
yarn add -D serve
# pnpm
pnpm add -D serve

json

{
    "scripts": {
        "serve": "serve"
    }
}

グローバルインストールするならこう。

bash

# npm
npm install -g serve
# yarn
yarn global add serve
# pnpm
pnpm add -g serve

コマンドラインオプションは、-h（--help）で確認できる。

bash

serve -h
serve --help

ディレクトリを指定する場合は、引数に指定する。デフォルトはカレントディレクトリ。

bash

serve public

ポートを指定する場合は、-pまたは-l（--listen、より複雑な指定が可能）を使う。デフォルトは3000。

bash

serve -p 8080
serve -l 8080

serve.jsonを使って設定を行うこともできる。プロパティの詳細は、https://github.com/vercel/serve-handler#options を参照。

公開ディレクトリを指定する場合は、publicプロパティを使う。

json

{
    "public": "public"
}

Jest + TypeScriptで`SyntaxError: Unexpected token 'export'`が出る

2022-06-24T13:14:13.064Z

TypeScriptのプロジェクトにts-jestを使ってJestを導入しようとしたところ、次のようなエラーが出た。

text

export {};
    ^^^^^^

    SyntaxError: Unexpected token 'export'

よく見ると、ビルド後のJavaScriptファイル（ここではdist内にあるとする）がテストファイルとして認識されていたことが原因だったので、jest.config.jsに次のような設定を追加した。

module.exports = {
    // 追加:
    testPathIgnorePatterns: ["<rootDir>/node_modules/", "<rootDir>/dist/"],
    // デフォルト:
    // testPathIgnorePatterns: ["/node_modules/"],
}

testPathIgnorePatternsには、ファイルのフルパスに対してマッチされる正規表現を文字列で指定するようになっている。<rootDir>はプロジェクトのルートディレクトリに置き換えられる。

特定のディレクトリのみからテストファイルを探させたい場合はrootsを使うこともできる。ただし、そのディレクトリが存在しない場合はエラーが出るようなので注意が必要。

module.exports = {
    // 追加:
    roots: ["<rootDir>/src/", "<rootDir>/tests/"],
    // デフォルト:
    // roots: ["<rootDir>"],
}

Jest

2022-06-24T13:14:13.064Z

リンク

公式サイト: https://jestjs.io
リポジトリ: https://github.com/facebook/jest
ドキュメンテーション: https://jestjs.io/docs/getting-started
- API（グローバル）: https://jestjs.io/docs/api
- API（expect）: https://jestjs.io/docs/expect
- 設定: https://jestjs.io/docs/configuration
- CLI: https://jestjs.io/docs/cli

Cloudflare Pagesのダイレクトアップロードでビルド済みの静的サイトをそのままデプロイする

2022-06-11T20:34:02.771Z

Cloudflare PagesでCIやローカルからビルド済みのコンテンツをそのままアップロードするには「ダイレクトアップロード」を使う。

ドラッグ&ドロップによるアップロードもできるが、

https://developers.cloudflare.com/pages/platform/direct-upload/#drag-and-drop

ここではWranglerを使った方法を紹介する。

https://developers.cloudflare.com/pages/platform/direct-upload/#wrangler-cli

Wrangler

現在のバージョンは、

shell

wrangler --version

text

2.0.9

もしWrangler 1を使っている場合は、Wrangler 2に移行する必要がある。

shell

# Wrangler 1
npm uninstall -g @cloudflare/wrangler
# Wrangler 2
npm install -g wrangler

https://developers.cloudflare.com/workers/wrangler/migration/migrating-from-wrangler-1/

アップロード

アップロードは次のコマンドで行う。

shell

wrangler pages publish [DIRECTORY] [OPTIONS]

distディレクトリをアップロードしたい場合は、

shell

wrangler pages publish dist

新しくデプロイする場合は、プロンプトでまずプロジェクトを作成することになる。

既存のプロジェクト名を指定したい場合は、

shell

wrangler pages publish dist --project-name my-project

プロジェクト

既存のプロジェクトを確認するには、

shell

wrangler pages project list

プロジェクトを作成するには、

shell

wrangler pages project create [PROJECT-NAME] [OPTIONS]

例えばmy-projectという名前のプロジェクトを作成するには、

shell

wrangler pages project create my-project

さらにプロダクション用のブランチ名を指定するには、

shell

wrangler pages project create my-project --production-branch main

参考リンク

RustでCargoの仮想ワークスペース（virtual workspaces）使用時にのみ依存パッケージのコンパイルに失敗する

2022-05-29T09:24:05.542Z

RustでゲームエンジンのBevyを使ってパッケージとして書いていたものをワークスペースに移行してビルドしてみると、なぜか突然依存パッケージのコンパイルに失敗するようになった。

調べてみると仮想ワークスペースではパッケージのようにエディションを指定しないので、依存関係の解決アルゴリズムに古いバージョンのものがデフォルトで使われてしまうことが原因のようで、resolver = "2"を指定すると解決した。

toml

[workspace]
members = ["crates/*"]
resolver = "2"

https://doc.rust-lang.org/cargo/reference/resolver.html#resolver-versions

なお解決したあとで検索してみるとBevyの非公式チートブックにもよくある落とし穴としてしっかり記載されていた。

https://bevy-cheatbook.github.io/pitfalls/build-errors.html#multi-crate-workspaces

Storybook + React + MDX で TypeError `(0 , _mdx_js_react__WEBPACK_IMPORTED_MODULE_2__.mdx) is not a function` が出る

2022-05-26T12:55:50.409Z

Storybookの構築時にハマったのでメモ。ビルドは正常にされるが、Storybookを開いた時に次のようなTypeErrorが出た。

text

(0 , _mdx_js_react__WEBPACK_IMPORTED_MODULE_2__.mdx) is not a function

原因はどうやらMDX 2を使っていたことのようだったので、

https://storybook.js.org/docs/react/writing-docs/mdx#mdx-2

に書かれている通り、

shell

npm install @storybook/mdx2-csf --save-dev

.storybook/main.js:

module.exports = {
    // ...
    features: {
        previewMdx2: true,
    },
}

を追加すると解決した。

Storybook

2022-05-26T12:55:50.409Z

リンク

公式サイト: https://storybook.js.org
リポジトリ: https://github.com/storybookjs/storybook/

FFmpegで動画をGIF化する

2022-05-14T23:01:59.795Z

shell

ffmpeg -i video.mov video.gif

フレームレートは-rで、サイズは-vf scale=で指定できる。-1はアスペクト比を保つという意味。

shell

ffmpeg -i video.mov -r 30 -vf scale=1280:-1 video.gif

FFmpeg

2022-05-14T23:01:59.795Z

リンク

公式サイト: https://ffmpeg.org

GIF

2022-05-14T23:01:59.795Z

Graphics Interchange Formatの略。設計者（Steve Wilhite）による読み方は「ジフ」。

Netlifyでローカルビルドをそのまま静的ホストする

2022-05-10T02:47:01.890Z

Netlifyの手動デプロイを使うと、ブラウザまたはCLIからフォルダをアップロードして静的ホストすることができる。

https://www.netlify.com

ブラウザ（各種メニューの「手動デプロイ」、Netlify Drop）からデプロイすることもできるが、ここではNetlify CLIを使う。

https://github.com/netlify/cli/

インストール

今回はCI環境では使わないので、グローバルインストールする。

shell

npm install netlify-cli -g

もしCI環境でもNetlify CLIを使うのであれば、開発依存パッケージとしてインストールする。（ビルドには別のCIサービスを使い、デプロイ先だけNetlifyにしたいような場合に便利。）

shell

npm install --save-dev netlify-cli

コマンドが実行できるかを確認するには次を実行する。

shell

netlify

デプロイ

デプロイにはnetlify deployコマンドを使う。

shell

netlify deploy

何もなしで実行するとカレントディレクトリの中身全てをそのままプレビュー環境にデプロイすることになる。ちなみに初回実行時はディレクトリとサイトが結び付けられていないので、コマンドライン上のプロンプトでサイトを作成または選択することになる。

多くの場合プロジェクトのルートディレクトリにカレントディレクトリがあり、その下にあるビルドディレクトリをアップロードすることになると思う。そのような場合、--dirオプションと使うとアップロードするディレクトリを指定できる。例えばビルドディレクトリがカレントディレクトリの./distにあるとすると次のようになる。

shell

netlify deploy --dir=dist

上記を実行してもデプロイ先はプレビュー環境になる。本番環境にデプロイし公開したい場合は--prodオプションをつける。

shell

netlify deploy --dir=dist --prod

もちろんカレントディレクトリの中身全てを公開したい場合は、--dirを省けばよい。

shell

netlify deploy --prod

既存のサイトに対して手動デプロイを行う場合は、--siteオプションでサイト名またはサイトIDを指定してアップロードすることもできる。

shell

netlify deploy --dir=dist --site=my-site --prod

既存のサイトの一覧は次のコマンドで確認できる。

shell

netlify sites:list

既存サイトとのリンク

サイトの設定はディレクトリ内の.netlify/state.jsonに保持される。

サイトとディレクトリを結び付けるには次を実行する。

shell

netlify link

上記のように何もオプションを指定しないと、プロンプトでサイトを選択することになる。

サイト名を使って結び付けたい場合は、次のように--nameオプションを使用する。

shell

netlify link --name my-site

なお先述の通り、既存サイトの一覧は次のコマンドで確認できる。

shell

netlify sites:list

逆にリンクを解除したい場合は、次を実行する。

shell

netlify unlink

新規サイトの作成

新しくサイトを作成してディレクトリとリンクするには、次のコマンドを実行する。

shell

netlify sites:create

サイト名を指定して作成するには、--nameオプションを使用する。

shell

netlify sites:create --name my-site

参考リンク

変更履歴

2022-06-12

Cloudflare Pagesでも「ダイレクトアップロード」ができるようになっていたので、できないとしていた記述を改訂。

Netlify

2022-05-10T02:47:01.890Z

リンク

公式サイト: https://www.netlify.com
Netlify CLI: https://cli.netlify.com
Netlify Docs: https://docs.netlify.com

Bevyの座標系

2022-05-02T21:25:43.713Z

Bevyでは座標系として、Y軸上向きの右手系が使われている。

これはMayaやGodot、Minecraftなどとは同じだが、UnityとはZ軸の正負が逆となっている。

軸	符号	向き
X	+	右
X	-	左
Y	+	上
Y	-	下
Z	+	後
Z	-	前

参考リンク

3D

2022-05-02T21:25:43.713Z

Bevy

2022-05-02T21:25:43.713Z

リンク

公式サイト: https://bevyengine.org
公式ブック: https://bevyengine.org/learn/book/
リポジトリ: https://github.com/bevyengine/bevy
docs.rs: https://docs.rs/bevy/latest/bevy/
チートブック: https://bevy-cheatbook.github.io/

`vscode.dev`に開発中の拡張機能をローカルから読み込む

2022-04-11T17:39:44.728Z

vscode.devでは、ローカルで開発中の拡張機能をマーケットプレイスなどに公開することなく、実際にインストールして試すことができる。

仕組みとしては、ローカルサーバーでホストした拡張機能をlocaltunnelを使ってグローバルにアクセスできるようにし、それをvscode.devのDeveloper: Install Web Extensionコマンドによってサイドロードする、という流れになっている。

なお、localtunnelによるトンネリングに使うサーバーにはデフォルトでhttps://localtunnel.meが使われるようになっているが、自前でホストすることも可能。もちろんトンネリングには別のツールを使ってもいいのだが、VS Codeの公式ドキュメントで紹介されていたので、ここではそのままlocaltunnelを使うことにする。

方法

ローカルサーバーのポート番号としてここでは8080を使うことにする。

まずターミナルを一つ開いてローカルサーバーを立ち上げ拡張機能をホストする（ビルドが必要な場合あらかじめビルドしておく）:

shell

npx serve --cors -l 8080

次に別のターミナルを開いてトンネリングを開始する:

shell

npx localtunnel -p 8080

ここで発行される次のようなURLをコピーしてメモしておく:

text

your url is: https://hungry-mole-48.loca.lt/

まずURLブラウザでこのURLを開き、そこで表示される

text

Click to Continue

という青いボタンを、注意を読んだ上で押す。

あとはvscode.devのコマンドパレットから:

text

Developer: Install Web Extension...

を実行し、発行されたURLを入力欄にペーストしてEnterすると、拡張機能の読み込みが実行される。

参考リンク

公式ドキュメント: Web Extensions - Test your web extension in on vscode.dev
- https://code.visualstudio.com/api/extension-guides/web-extensions#test-your-web-extension-in-on-vscode.dev

VS Code

2022-04-11T17:39:44.728Z

リンク

公式サイト: https://code.visualstudio.com/
リポジトリ: https://github.com/microsoft/vscode

VS Code拡張機能

2022-04-11T17:39:44.728Z

リンク

公式ドキュメンテーション: https://code.visualstudio.com/api

TypeScriptのイテレーターとジェネレーター

2022-04-04T02:08:06.486Z

ECMAScriptの反復処理インターフェース

ECMAScript（現行: 2023）では、反復処理（iteration）のためのインターフェースとして、

の5つが定義されている。

Iterable

Iterableは、Iteratorにしたがうオブジェクトを返す関数@@iterator（Symbol.iterator）をプロパティとして必ず持つことを示すインターフェースである。

TypeScriptではそのまま次のように定義されている。

src/lib/es2015.iterable.d.ts#L30-L32

interface Iterable<T> {
    [Symbol.iterator](): Iterator<T>;
}

※引用するコードにもともとあったコメントは省略してある。以下同様。

この@@iteratorは、for...of文、yield*式、...演算子などを使った際にも暗黙的に呼ばれる（抽象操作GetIteratorを参照）。

for (const item of [1, 2, 3, 4]) {
    console.log(item)
}

AsyncIterable

AsyncIterableは、Iterableの非同期版で、AsyncIteratorにしたがうオブジェクトを返す関数@@asyncIterator（Symbol.asyncIterator）をプロパティとして必ず持つことを示すインターフェースである。

こちらもTypeScriptではそのまま次のように定義されている。

src/lib/es2018.asynciterable.d.ts#L19-L21

interface AsyncIterable<T> {
    [Symbol.asyncIterator](): AsyncIterator<T>;
}

この@@asyncIteratorも、for await...of文、yield*式、などを使った際に暗黙的に呼ばれうる（同じく抽象操作GetIteratorを参照）。

Iterator

Iteratorは、IteratorResultを返す関数nextをプロパティとして必ず持ち、オプションとして同じくIteratorResultを返す関数return、throwを持つことを示すインターフェースとなっている。

TypeScriptでの定義は次のようになっている。

src/lib/es2015.iterable.d.ts#L23-L28

interface Iterator<T, TReturn = any, TNext = undefined> {
    next(...args: [] | [TNext]): IteratorResult<T, TReturn>;
    return?(value?: TReturn): IteratorResult<T, TReturn>;
    throw?(e?: any): IteratorResult<T, TReturn>;
}

反復はnextを呼ぶことによって進められる。nextは引数を任意で1つとり、IteratorResultを返す。ECMAScriptの仕様には、一度doneがtrueのIteratorResultが返されたら、それ以降返されるIteratorResultのdoneはすべてtrueであるべき旨が書かれているが、一方でこの要求は強制的なものではないとも書かれている。

またECMAScriptの仕様には、Iteratorはnextが引数なしで呼ばれることもあることを前提としなければならない旨の注釈も付け加えられてある。TypeScriptでのnextの引数がタプルで表現されているのはそのチェックを厳密にするためであると思われる（省略したソースコード中のコメントにそのような旨が記載されている）。

returnとthrowはそれぞれIteratorに反復処理の終了やエラーによる中断を知らせるためのもので、ECMAScriptの仕様では、典型的な振る舞いはvalueで指定した値をvalueとして持つIteratorResultを返したり、eで指定した値をthrowしたりして、以降のIteratorResultのdoneをtrueにすることであるが、実際の振る舞いはIteratorがどのように実装されているかに依存するとされている。

AsyncIterator

AsyncIteratorは、Iteratorの非同期版で、プロパティとしてもつ関数がすべて、IteratorResultの代わりにIteratorResultのPromiseを返すインターフェスである。

TypeScriptでの定義は次のようになっている。

src/lib/es2018.asynciterable.d.ts#L12-L17

interface AsyncIterator<T, TReturn = any, TNext = undefined> {
    next(...args: [] | [TNext]): Promise<IteratorResult<T, TReturn>>;
    return?(value?: TReturn | PromiseLike<TReturn>): Promise<IteratorResult<T, TReturn>>;
    throw?(e?: any): Promise<IteratorResult<T, TReturn>>;
}

IteratorResult

イテレーターから返されるIteratorResultは、doneとvalueの二つの値をプロパティーとして持ちうるインターフェースである。doneはtrueまたはfalse、valueは任意のECMAScriptの値をとるが、存在しない可能性もある。

doneがfalseまたは存在しない場合、valueの値は反復の一要素として解釈される。一方、doneがtrueである場合、それは反復の終了を意味し、そのときのvalueはイテレーター自体の返却値として解釈される。

これをTypeScriptでは次のように表現している。

src/lib/es2015.iterable.d.ts#L11-L21

interface IteratorYieldResult<TYield> {
    done?: false;
    value: TYield;
}

interface IteratorReturnResult<TReturn> {
    done: true;
    value: TReturn;
}

type IteratorResult<T, TReturn = any> = IteratorYieldResult<T> | IteratorReturnResult<TReturn>;

組み込みの反復可能オブジェクト

ECMAScriptで定義されている次の組み込みオブジェクトはIterableインターフェースを満たしてる。

そのため、これらのオブジェクトは、for...ofなどで直接反復させることができる。

for (const char of "abc") {
  console.log(char)
}

イテレーターの反復可能性

IterableIterator

ECMAScriptで定義されている上記のようなIteratorを満たすオブジェクトは、そのイテレーター自身（this）を返す@@iterator（Symbol.iterator）をプロパティとして持つプロトタイプ%IteratorPrototype%を継承しているため、イテレーター自身もIterableインターフェースを満たしている。

これをTypeScriptでは次のように再帰的に表現している。

src/lib/es2015.iterable.d.ts#L34-L36

interface IterableIterator<T> extends Iterator<T> {
    [Symbol.iterator](): IterableIterator<T>;
}

これを使って例えばArrayのinterfaceの一部は、次のように定義されている。

src/lib/es2015.iterable.d.ts#L38-L56

interface Array<T> {
    [Symbol.iterator](): IterableIterator<T>;
    entries(): IterableIterator<[number, T]>;
    keys(): IterableIterator<number>;
    values(): IterableIterator<T>;
}

AsyncIterableIterator

ECMAScriptで定義されているAsyncIteratorを満たすオブジェクトもまた、そのイテレーター自身（this）を返す@@asyncIterator（Symbol.asyncIterator）をプロパティとして持つプロトタイプ%AsyncIteratorPrototype%を継承しているため、イテレーター自身がAsyncIterableインターフェースを満たすようになっている。

これもTypeScriptでは同様に次のように再帰的に表現している。

src/lib/es2018.asynciterable.d.ts#L23-L25

interface AsyncIterableIterator<T> extends AsyncIterator<T> {
    [Symbol.asyncIterator](): AsyncIterableIterator<T>;
}

イテレーターと反復可能オブジェクトの作成

先に挙げたインターフェースを満たすようにオブジェクトを作成すれば、自身でイテレーターや反復可能オブジェクトを作成することもできる。

たとえば、次のコードは1から10を出力する。

const ONE_TO_TEN = {
  [Symbol.iterator]() {
    let i = 0;
    return {
      next: () => {
        i += 1;
        return i <= 10 ? {
          value: i,
        } : {
          done: true
        }
      }
    }
  }
}

for (const i of ONE_TO_TEN) {
  console.log(i)
}

ジェネレーター関数とジェネレーター

組み込みの反復可能オブジェクトのように、IteratorでありかつIterable、あるいはAsyncIteratorでありかつAsyncIterableであるようなイテレーターを作成するために、ECMAScriptではジェネレーター関数というものが用意されている。

GeneratorFunctionは、IteratorでありかつIterableなオブジェクトGeneratorを返す関数であり、function*を使って定義される。

AsyncGeneratorFunctionはその非同期版で、AsyncIteratorでありかつAsyncIterableなオブジェクトAsyncGeneratorを返す関数であり、async function*を使って定義される。

これらのジェネレーター関数の中では、値を反復の一要素として出力するyieldや、処理を別のジェネレーターや反復可能オブジェクトに委任するyield*が使えるため、反復処理を柔軟に記述することができる。

たとえば、ONE_TO_TENを定義して作成した1から10を出力するコードは、loからhiまで（両端含む）のnumberを列挙するrange関数をジェネレーター関数として定義することで、次のように書き直すことができる。

function* range(lo: number, hi: number): Generator<number> {
  for (let i = lo; i <= hi; i++) {
    yield i;
  }
}

for (const i of range(1, 10)) {
  console.log(i)
}

Generatorは、TypeScriptでは次のように定義されている。

src/lib/es2015.generator.d.ts#L3-L9

interface Generator<T = unknown, TReturn = any, TNext = unknown> extends Iterator<T, TReturn, TNext> {
    next(...args: [] | [TNext]): IteratorResult<T, TReturn>;
    return(value: TReturn): IteratorResult<T, TReturn>;
    throw(e: any): IteratorResult<T, TReturn>;
    [Symbol.iterator](): Generator<T, TReturn, TNext>;
}

IterableIteratorとの違いは、returnとthrow、およびそれらの引数にあった?がついていない点で、典型的なIteratorの振る舞いとして先に述べておいた、returnの場合valueをそのまま返して終了し、throwの場合eをthrowして終了する、という既定の動作が自動で定義されるようになっている。

またnextに対して与えた引数は、yieldの返却値として与えられるようになっており、ジェネレーター関数内で受け取れるようになっている。

function* makeLogger(limit: number): Generator<void, void, string> {
    for (let i = 0; i < limit; i++) {
        console.log(yield)
    }
}

const logger = makeLogger(3)
logger.next("hello") // "hello"
logger.next("hello") // "hello"
logger.next("hello") // "hello"
logger.next("hello") // 出力されない

async function*を使って定義されるAsyncGeneratorFunctionはその非同期版で、返されるAsyncGeneratorはTypeScriptで次のように定義されている。

src/lib/es2018.asyncgenerator.d.ts#L3-L9

interface AsyncGenerator<T = unknown, TReturn = any, TNext = unknown> extends AsyncIterator<T, TReturn, TNext> {
    next(...args: [] | [TNext]): Promise<IteratorResult<T, TReturn>>;
    return(value: TReturn | PromiseLike<TReturn>): Promise<IteratorResult<T, TReturn>>;
    throw(e: any): Promise<IteratorResult<T, TReturn>>;
    [Symbol.asyncIterator](): AsyncGenerator<T, TReturn, TNext>;
}

これも返される値（および返される値としてあたえる値）がPromiseとなっていることを除いて、Generatorと同様である。

async function* fetchAllText(urls: string[]): AsyncGenerator<string> {
  for (const url of urls) {
    const res = await fetch(url)
    yield await res.text()
  }
}

async function main() {
  for await (const text of fetchAllText([])) {
    console.log(text)
  }
}

main().catch(console.error)

参考リンク

MDN: JavaScript
- Guide: Iterators and Generators
  - https://developer.mozilla.org/docs/Web/JavaScript/Guide/Iterators_and_Generators
- Reference: Iteration protocols
  - https://developer.mozilla.org/docs/Web/JavaScript/Reference/Iteration_protocols
- Reference: function*
  - https://developer.mozilla.org/docs/Web/JavaScript/Reference/Statements/function*
- Reference: function* expression
  - https://developer.mozilla.org/docs/Web/JavaScript/Reference/Operators/function*
- Reference: yield
  - https://developer.mozilla.org/docs/Web/JavaScript/Reference/Operators/yield
- Reference: yield*
  - https://developer.mozilla.org/docs/Web/JavaScript/Reference/Operators/yield*
- Reference: for...of
  - https://developer.mozilla.org/docs/Web/JavaScript/Reference/Statements/for...of
- Reference: for await...of
  - https://developer.mozilla.org/docs/Web/JavaScript/Reference/Statements/for-await...of
- Reference: Symbol.iterator
  - https://developer.mozilla.or/docs/Web/JavaScript/Reference/Global_Objects/Symbol/iterator
- Reference: Symbol.asyncIterator
  - https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Symbol/asyncIterator
- Reference: Generator
  - https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Generator
- Reference: GeneratorFunction
  - https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/GeneratorFunction
TypeScript: Documentation
- Iterators and Generators
  - https://www.typescriptlang.org/docs/handbook/iterators-and-generators.html
TypeScript: Source
- src/lib/es2015.symbol.d.ts
  - https://github.com/microsoft/TypeScript/blob/main/src/lib/es2015.symbol.d.ts
- src/lib/es2015.iterable.d.ts
  - https://github.com/microsoft/TypeScript/blob/main/src/lib/es2015.iterable.d.ts
- src/lib/es2015.generator.d.ts
  - https://github.com/microsoft/TypeScript/blob/main/src/lib/es2015.generator.d.ts
- src/lib/es2018.asynciterable.d.ts
  - https://github.com/microsoft/TypeScript/blob/main/src/lib/es2018.asynciterable.d.ts
- src/lib/es2018.asyncgenerator.d.ts
  - https://github.com/microsoft/TypeScript/blob/main/src/lib/es2018.asyncgenerator.d.ts
ECMAScript® Language Specification
- 6.1.5.1 Well-Known Symbols
  - https://tc39.es/ecma262/multipage/ecmascript-data-types-and-values.html#sec-well-known-symbols
  - Table 1: Well-known Symbols
    - https://tc39.es/ecma262/multipage/ecmascript-data-types-and-values.html#table-well-known-symbols
- 7.4 Operations on Iterator Objects
  - https://tc39.es/ecma262/#sec-operations-on-iterator-objects
- 13.15 Assignment Operators
  - https://tc39.es/ecma262/#sec-assignment-operators
- 14.7 Iteration Statements
  - https://tc39.es/ecma262/multipage/ecmascript-language-statements-and-declarations.html#sec-iteration-statements
- 15.5 Generator Function Definitions
  - https://tc39.es/ecma262/multipage/ecmascript-language-functions-and-classes.html#sec-generator-function-definitions
- 15.6 Async Generator Function Definitions
  - https://tc39.es/ecma262/multipage/ecmascript-language-functions-and-classes.html#sec-async-generator-function-definitions
- 27.1 Iteration
  - https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-iteration
- 27.3 GeneratorFunction Objects
  - https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-generatorfunction-objects
- 27.4 AsyncGeneratorFunction Objects
  - https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-asyncgeneratorfunction-objects
- 27.5 Generator Objects
  - https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-generator-objects
- 27.6 AsyncGenerator Objects
  - https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-asyncgenerator-objects

計算量の漸近記法（Θ記法・O記法・Ω記法・o記法・ω記法）

2022-04-03T17:36:57.843Z

『アルゴリズムイントロダクション第3版』（原著: Introduction to Algorithms）で用いられている次の5つの漸近記法について、まとめておく。詳細は第3章（総合版でp.36-）を参照。

Θ記法（big-theta notation、上界と下界をあたえる、タイトな限界という）
O記法（big-o notation、上界のみをあたえる、タイトな限界であるとは限らない）
Ω記法（big-omega notation、下界のみをあたえる、タイトな限界であるとは限らない）
o記法（little-o notation、タイトな限界ではない上界をあたえる）
ω記法（little-omega notation、タイトな限界ではない下界をあたえる）

たとえば、

$2 n^2 = \Theta(n^2)$
$2 n^2 \ne \Theta(n^3)$
$2 n^2 \ne \Theta(n)$
$2 n^2 = O(n^2)$
$2 n^2 = O(n^3)$
$2 n^2 = \Omega(n^2)$
$2 n^2 = \Omega(n)$
$2 n^2 \ne o(n^2)$
$2 n^2 = o(n^3)$
$2 n^2 \ne \omega(n^2)$
$2 n^2 = \omega(n)$

Θ記法

定義

ある関数 $g(n)$ について、 $\Theta(g(n))$ とは、ある正の定数 $c_1, c_2, n_0$ が存在して、すべての $n \ge n_0$ に対して、 $0 \le c_1 g(n) \le f(n) \le c_2 g(n)$ を満たすような関数 $f(n)$ の集合である。

説明

Θ記法（big-theta notation）は、漸近的な上界と下界をあたえる。

すなわち、 $f(n)$ が $\Theta(g(n))$ である（属する）とは、 $n$ が十分大きいければ（ $n \ge n_0 \ge 0$ ）、 $f(n)$ が $g(n)$ の定数倍（ $c_1 g(n)$ および $c_2 g(n)$ ）につねに挟まれることを意味する。

$n \ge n_0$ において、 $g(n)$ はつねに $f(n)$ と定数倍の範囲で等しくなるので、Θ記法で与えられる $g(n)$ を特に、漸近的にタイトな限界（asymptotically tight bound）という。

たとえば、 $2 n^2 = \Theta(n^2)$ であるが、 $2 n^2 \ne \Theta(n^3)$ 　、 $2 n^2 \ne \Theta(n)$ である。

（正確には $2 n^2 \in \Theta(n^2)$ だが、このように略記する。詳しくは「等式および不等式における漸近記法」総合版でp.41-を参照。）

なお、他の文献ではΘ記法の意味でO記法が用いられる場合もある。

O記法

定義

ある関数 $g(n)$ について、 $O(g(n))$ とは、ある正の定数 $c, n_0$ が存在して、すべての $n \ge n_0$ に対して、 $0 \le f(n) \le c g(n)$ を満たすような関数 $f(n)$ の集合である。

説明

O記法（big-o notation）は、漸近的な上界をあたえる。

すなわち $f(n)$ が $O(g(n))$ である（属する）とは、 $n$ が十分大きいければ（ $n \ge n_0 \ge 0$ ）、 $f(n)$ が $g(n)$ の定数倍（ $c g(n)$ ）よりつねに小さくなる（上からおさえられる）ことを意味する。

たとえば、 $2 n^2 = O(n^2)$ であるが、上界しか示さないので、 $2 n^2 = O(n^3)$ も成り立つ。

なお、他の文献ではΘ記法の意味でO記法が用いられる場合もある。

Ω記法

定義

ある関数 $g(n)$ について、 $\Omega(g(n))$ とは、ある正の定数 $c, n_0$ が存在して、すべての $n \ge n_0$ に対して、 $0 \le c g(n) \le f(n)$ を満たすような関数 $f(n)$ の集合である。

説明

Ω記法（big-omega notation）は、漸近的な下界をあたえる。

$f(n)$ が $\Omega(g(n))$ である（属する）とは、 $n$ が十分大きいければ（ $n \ge n_0 \ge 0$ ）、 $f(n)$ が $g(n)$ の定数倍（ $c g(n)$ ）よりつねに大きくなる（下からおさえられる）ことを意味する。

たとえば、 $2 n^2 = \Omega(n^2)$ であるが、下界しか示さないので、 $2 n^2 = \Omega(n)$ も成り立つ。

o記法

定義

ある関数 $g(n)$ について、 $o(g(n))$ とは、任意の正の定数 $c \gt 0$ に対して、ある正の定数 $n_0 \gt 0$ が存在して、すべての $n \ge n_0$ に対して $0 \le f(n) \lt c g(n)$ を満たすような関数 $f(n)$ の集合である。

説明

o記法（little-o notation）は、漸近的にタイトな限界ではない、漸近的な上界をあたえる。

すなわち、たとえば $2 n^2 = o(n^3)$ であるが、 $2 n^2 = \Theta(n^2)$ であるため、 $2 n^2 \ne o(n^2)$ となる。

o記法では、 $n$ が大きくなるにつれて、 $f(n)$ は $g(n)$ に対して相対的に無限小に近づくので、

\lim_{n \to \infty} \frac{f(n)}{g(n)} = 0

が成立する。

ω記法

定義

ある関数 $g(n)$ について、 $\omega(g(n))$ とは、任意の正の定数 $c \gt 0$ に対して、ある正の定数 $n_0 \gt 0$ が存在して、すべての $n \ge n_0$ に対して $0 \le c g(n) \lt f(n)$ を満たすような関数 $f(n)$ の集合である。

説明

ω記法（little-omega notation）は、漸近的にタイトな限界ではない、漸近的な下界をあたえる。

すなわち、たとえば $2 n^2 = \omega(n)$ であるが、 $2 n^2 = \Theta(n^2)$ であるため、 $2 n^2 \ne \omega(n^2)$ となる。

ω記法では、 $n$ が小さくなるにつれて $f(n)$ は $g(n)$ に対して相対的に無限大に近づくので、

\lim_{n \to \infty} \frac{f(n)}{g(n)} = \infty

が成立する。

漸近関係の性質

推移性は、Θ、O、Ω、o、ωのすべてにおいて成り立つ。すなわち、

$f(n) = \Theta(g(n)) \land g(n) = \Theta(h(n)) \implies f(n) = \Theta(h(n))$
$f(n) = O(g(n)) \land g(n) = O(h(n)) \implies f(n) = O(h(n))$
$f(n) = \Omega(g(n)) \land g(n) = \Omega(h(n)) \implies f(n) = \Omega(h(n))$
$f(n) = o(g(n)) \land g(n) = o(h(n)) \implies f(n) = o(h(n))$
$f(n) = \omega(g(n)) \land g(n) = \omega(h(n)) \implies f(n) = \omega(h(n))$

反射性は、Θ、O、Ωにおいてのみ成り立つ。すなわち、

$f(n) = \Theta(f(n))$
$f(n) = O(f(n))$
$f(n) = \Omega(f(n))$

対称性は、Θにおいてのみ成り立つ。すなわち、

$f(n) = \Theta(g(n)) \iff g(n) = \Theta(f(n))$

また、OとΩ、oとωのそれぞれについて転置対称性が成り立つ。すなわち、

$f(n) = O(g(n)) \iff g(n) = \Omega(f(n))$
$f(n) = o(g(n)) \iff g(n) = \omega(f(n))$

これらの性質について、実数の同値関係・順序関係と比較すると、

$\Theta \approx a = b$
$O \approx a \le b$
$\Omega \approx a \ge b$
$o \approx a \lt b$
$\omega \approx a \gt b$

のような類似性が見出されるが、漸近関係についてはかならずしもどれかひとつが成立するとは限らないことに注意。

参考

『アルゴリズムイントロダクション第3版総合版』2013年、近代科学社
- 原著: Introduction to Algorithms
  - Thomas H. Cormen
  - Charles E. Leiserson
  - Ronald L. Rivest
  - Clifford Stein
- 翻訳:
  - 浅野哲夫
  - 岩野和生
  - 梅尾博司
  - 山下雅史
  - 和田幸一
- ISBN: 978-4764904088

アルゴリズム

2022-04-03T17:36:57.843Z

データ構造

2022-04-03T17:36:57.843Z

Denoをはじめる

2022-04-02T20:53:03.766Z

煩雑な設定なしにTypeScriptを実行/テスト/リント/フォーマットできる環境を試してみたかったので、Denoを改めて使ってみる。

準備

ここではmacOS/VS Codeで進めていく。

Denoのインストール

参考リンク: https://github.com/denoland/deno_install

macOSでHomebrewを使う場合は:

shell

brew install deno

公式のインストールスクリプトも用意されている。

Shell（macOS/Linux）の場合:

shell

curl -fsSL https://deno.land/x/install/install.sh | sh

PowerShell（Windows）の場合:

shell

iwr https://deno.land/x/install/install.ps1 -useb | iex

DenoのCLI

参考リンク: https://deno.land/manual/getting_started/command_line_interface

バージョンの確認は次のコマンドで行う:

shell

deno --version

更新は次のコマンドで行う:

shell

deno upgrade

ヘルプは次のコマンドで表示される:

shell

deno help
deno -h
deno --help

Denoの設定ファイル

Denoではすべてデフォルトのままで使う場合、設定ファイルは必要ない。ただし、TypeScriptやリンター、フォーマッターの設定を記述したい場合、--configオプションで渡すことのできる.jsonファイルまたは.jsoncファイルを用意しておくことができる。

デフォルトの名前は決められていないが、将来的なサポートのためにdeno.jsonまたはdeno.jsoncという名前が推奨されている。

IDEの設定

参考リンク: https://deno.land/manual/getting_started/setup_your_environment

VS Code

参考リンク: https://deno.land/manual/vscode_deno

Deno公式拡張機能のhttps://marketplace.visualstudio.com/items?itemName=denoland.vscode-denoをインストールし、設定からDeno: Enable（deno.enable）を有効にする。Deno: Initialize Workspace Configurationコマンドで.vscode/settings.jsonを作成してもよい。

.vscode/settings.jsonの例:

json5

{
    "deno.config": "./deno.json",
    "deno.enable": true,
    "deno.lint": true,
    "deno.unstable": true,
    "[typescript][typescriptreact][javascript][javascriptreact][json][jsonc][markdown]": {
        "editor.defaultFormatter": "denoland.vscode-deno"
    }
}

なお、設定ファイルの名前にdeno.jsoncまたはdeno.jsonを使っている場合は自動で認識されるので、deno.configで設定する必要はない。

tasks.jsonで使えるタスク定義やプロブレムマッチャーも提供されている。

.vscode/tasks.json

json5

{
    "version": "2.0.0",
    "tasks": [
        {
            "type": "deno",
            "command": "run",
            "args": ["src/main.ts"],
            "problemMatcher": ["$deno"]
        },
        {
            "type": "deno",
            "command": "test",
            "problemMatcher": ["$deno-test"]
        },
        {
            "type": "deno",
            "command": "lint",
            "problemMatcher": ["$deno-lint"]
        }
    ]
}

JetBrainsのIDE

JetBrains公式プラグインのhttps://plugins.jetbrains.com/plugin/14382-denoをインストールする。

ファイルの実行

参考リンク: https://deno.land/manual/getting_started/command_line_interface

Denoでファイルを実行するにはdeno runコマンドを用いる。

hello.ts:

console.log("Hello, World!");

コマンド:

shell

deno run hello.ts

出力:

text

Hello, World!

リモートのファイルも実行できる。

コマンド:

shell

# 最新版
deno run https://deno.land/std/examples/welcome.ts
# 0.133.0
deno run https://deno.land/std@0.133.0/examples/welcome.ts

出力:

text

Welcome to Deno!

ファイル名の後の引数はすべてスクリプトに対する引数となる。

shell

deno run main.ts --help

パーミッション

参考リンク: https://deno.land/manual/getting_started/permissions

Denoではデフォルトでネットワークやファイルシステムへのアクセスがすべてオフになっている。プログラムからのアクセスを許可するには、実行時にオプションやプロンプトから許可を与える必要がある。

以下、オプションを列挙するが、実際にdeno runを実行するには実行するファイル名が引数として必要となるとなることには注意。

shell

# ネットワークアクセス
deno run --allow-net
deno run --allow-net=github.com,localhost:8080
# ファイルシステムアクセス（読み取り）
deno run --allow-read
deno run --allow-read=
# ファイルシステムアクセス（書き込み）
deno run --allow-write
deno run --allow-write=
# 環境変数
deno run --allow-env
deno run --allow-env=HOME,PATH

# 高分解能時間測定（high-resolution time measurement）
deno run --allow-hrtime

DenoはV8エンジンのサンドボックス機能を使うことでセキュアな実行をサポートしているが、コマンドやFFIはサンドボックス外での実行を許可することになるので、注意が必要となる。

shell

# コマンド（サブプロセス）の実行
deno run --allow-run
deno run --allow-run=imagemagick,ffmpeg

# FFI（外部関数インターフェース）によるダイナミックライブラリの読込・実行
deno run --allow-ffi

上記のすべてを許可するには--allow-allまたは-Aが使えるが、当然注意が必要となる。

shell

# すべて許可
deno run --allow-all
deno run -A

テスト

参考リンク: https://deno.land/manual/testing

テストの記述

ファイル名が以下の形式のファイルが、テストファイルとして認識される。

test.ts
*.test.ts
*_test.ts

hello.test.ts

import { assert } from "https://deno.land/std@0.133.0/testing/asserts.ts"

Deno.test("Hello, Test!", () => {
    assert("Hello, Test!".includes("Test"))
})

Deno.testのAPIについては:

https://doc.deno.land/deno/stable/~/Deno.test

std/testing/asserts.tsモジュールについては:

https://doc.deno.land/https://deno.land/std/testing/asserts.ts

をそれぞれ参照。

テストの実行

shell

deno test

でカレントディレクトリ以下の{*_,*.,}test.{ts, tsx, mts, js, mjs, jsx, cjs, cts}、つまり、

text

hello/test.ts
hello.test.ts
hello_test.ts

のようなファイルに記述されているテストがすべて実行される。

shell

# ディレクトリの指定
deno test hello/

shell

# ファイルの指定
deno test hello.test.ts

も可能。

import { assert } from "https://deno.land/std@0.133.0/testing/asserts.ts"

Deno.test("Hello, Test!", { permissions: { read: true } }, () => {
    assert(true)
})

のようにパーミッションが必要な場合は、deno runの場合と同様にオプションにより実行に許可を与える。

shell

deno test --allow-read

リント

参考リンク: https://deno.land/manual/tools/linter

コードのリントはdeno lintコマンドで行う。

shell

# すべてのファイル（カレントディレクトリ以下）
deno lint
# 指定したディレクトリ
deno lint src/
# 指定したファイル
deno lint src/main.ts　src/lib.ts

ルールの一覧は:

https://lint.deno.land/

を参照。

設定ファイルで、含めるファイルやリントのルールを指定できることもできる。

json

{
    "lint": {
        "files": {
            "include": ["src/"],
            "exclude": ["src/testdata/"]
        },
        "rules": {
            "tags": ["recommended"],
            "include": ["ban-untagged-todo"],
            "exclude": ["no-unused-vars"]
        }
    }
}

フォーマット

参考リンク: https://deno.land/manual/tools/formatter

コードのフォーマットはdeno fmtコマンドで行う。

shell

# すべてのファイル（カレントディレクトリ以下）
deno fmt
# 指定したディレクトリ
deno fmt src/
# 指定したファイル
deno fmt src/main.ts　src/lib.ts

設定ファイルで、含めるファイルやフォーマットのオプションを指定することもできる。

json

{
    "fmt": {
        "files": {
            "include": ["src/"],
            "exclude": ["src/testdata/"]
        },
        "options": {
            "useTabs": true,
            "lineWidth": 80,
            "indentWidth": 4,
            "singleQuote": true,
            "proseWrap": "preserve"
        }
    }
}

依存パッケージの管理

`deps.ts`

参考リンク: https://deno.land/manual/examples/manage_dependencies

依存パッケージを何らかのファイルにまとめて管理したい場合は、一つの慣習として次のような名前のファイルにリモートの依存先を記述し、そこからimportして使う。

deps.ts（dependencies）
dev_deps.ts（devDependencies）

src/deps.ts:

export * as yaml from "https://deno.land/std@0.133.0/encoding/yaml.ts"

src/main.ts:

import { yaml } from "./deps.ts"

const article = yaml.parse(`
title: Hello, Deno!
description: An introduction to Deno.
`)

console.log(article)

`lock.json`

参考リンク: https://deno.land/manual/linking_to_external_code/integrity_checking.md

複数の環境で本当に同一のパッケージが使われているか整合性を確かめるには、ロックファイルを使う。

ファイル名は公式マニュアルの例ではlock.jsonとなっているが、個人的にはdeno.lock.jsonを使いたい。

ロックファイルを生成するには:

shell

deno cache --lock-write --lock=deno.lock.json src/deps.ts

ロックファイルを使ってキャッシュを再読み込みするには:

shell

deno cache --reload --lock=deno.lock.json src/deps.ts

感想

Node.jsへの反省として発表されてからしばらく経っているが、当初思ったよりは普及しておらず、開発中の機能も多い。

特に、外部ライブラリを使う起点となるパッケージ管理の仕組みについては、Goが結局go.modやgo.sumを導入したように、ファイルでまとめて管理するように戻してしまったほうがいいのではという感がいなめなず、結果として、外部ライブラリを使うときにこそ良さを発揮するであろうサンドックス機能の恩恵にも与りにくくなっている。

とはいえ、TypeScriptとawaitがそのまま使えるのと、テストランナーやフォーマッター、リンターがデフォルトでついてくるのは、プロジェクトをミニマルに保ちたい場合にはうれしい利点となっている。

当面はTypeScriptのみで外部ライブラリさえ使わない小さな個人プロジェクトで使いつつ、今後の行く末に期待したい。 $

Deno

2022-04-02T20:53:03.766Z

リンク

公式サイト: https://deno.land/
公式マニュアル: https://deno.land/manual
リポジトリ: https://github.com/denoland/deno
ランタイムAPI: https://doc.deno.land/deno/stable
標準ライブラリ: https://deno.land/std

Next.jsで静的サイトとしてエクスポートする

2022-03-21T17:02:27.182Z

bash

next build && next export

スクリプトを、

json

{
  "scripts": {
    "build": "next build && next export"
  }
}

のようにしておくと便利。

参考

Next.jsでSass/SCSSを有効にする

2022-03-21T16:51:53.757Z

Sassの追加:

bash

npm i -D sass

TypeScriptを作っている場合、custom.d.tsのようなファイルを作り:

declare module "*.module.css"
declare module "*.module.sass"
declare module "*.module.scss"

参考

https://nextjs.org/docs/basic-features/built-in-css-support#sass-support

Sass/SCSS

2022-03-21T16:46:33.543Z

リンク

公式サイト: https://sass-lang.com
リポジトリ: https://github.com/sass/dart-sass

Prettier

2022-03-21T16:34:03.186Z

公式サイト: https://prettier.io
リポジトリ: https://github.com/prettier/prettier

Next.jsのプロジェクトに`prettier`を追加する

2022-03-21T16:32:22.689Z

依存パッケージの追加:

bash

npm i -D prettier eslint-config-prettier

.eslintrc.jsonへの追記:

json

{
  "extends": ["next/core-web-vitals", "prettier"]
}

.prettierignoreへの追記:

/.next/
/out/

npmスクリプトの追加（任意）:

json

{
  "scripts": {
    "format": "prettier --write ."
  },
}

Goアプリケーションの作成

2022-03-21T15:52:39.293Z

プロジェクトの作成

bash

go mod init example/hello

次のようなgo.modが生成される:

go-mod

module example/hello

go 1.18

main.goを作成する（ファイル名は任意）:

package main

import "fmt"

func main() {
    fmt.Println("Hello, World!")
}

実行は:

bash

go run .

パッケージの追加

例えば:

bash

go get github.com/labstack/echo/v4

main.goを次のように書き直して:

package main

import (
	"net/http"

	"github.com/labstack/echo/v4"
)

func main() {
	// Echo instance
	e := echo.New()

	// Routes
	e.GET("/", hello)

	// Start server
	e.Logger.Fatal(e.Start(":1323"))
}

// Handler
func hello(c echo.Context) error {
	return c.String(http.StatusOK, "Hello, World!")
}

実行すると:

bash

go run .

http://localhost:1323/

で"Hello, World!が表示されるようになる。

`create-next-app`を使って現在のディレクトリにTypeScriptのNext.jsプロジェクトの雛形を生成する

2022-03-17T21:11:11.180Z

npm:

bash

npx create-next-app@latest --ts .

yarn:

bash

yarn create next-app --ts .

pnpm:

bash

pnpm create next-app --ts .

Next.jsの設定ファイルの型定義

2022-03-11T09:53:49.488Z

next.config.mjs:

// @ts-check
"use strict"

/**
 *
 * @param { string } phase
 * @param {{ defaultConfig: import("next").NextConfig }} config
 * @returns { Promise<import("next").NextConfig> }
 */
export default async function createNextConfig(phase, { defaultConfig }) {
    return {
        reactStrictMode: true,
    }
}

参考

https://github.com/vercel/next.js/blob/e57d621fb38562b1d5ae02fb6f7efd343e1db405/packages/next/server/config-shared.ts#L475-L481

Next.js

2022-03-11T09:53:49.488Z

リンク

公式サイト: https://nextjs.org/
リポジトリ: https://github.com/vercel/next.js

フォントのウェイト名と数値の対応表

2022-03-10T20:52:36.745Z

数値	名前
100	Thin
200	Extra Light (Ultra Light)
300	Light
400	Normal
500	Medium
600	Semi Bold (Demi Bold)
700	Bold
800	Extra Bold (Ultra Bold)
900	Black (Heavy)

css

.font-weight {
    font-weight: 100; /* thin */
    font-weight: 200; /* extra light */
    font-weight: 300; /* light */
    font-weight: 400; /* normal */
    font-weight: 500; /* medium */
    font-weight: 600; /* semi bold */
    font-weight: 700; /* bold */
    font-weight: 800; /* extra bold */
    font-weight: 900; /* black */
}

参考

CSS

2022-03-10T20:52:36.745Z

リンク

仕様: https://www.w3.org/TR/css/
WG: https://www.w3.org/Style/CSS/
MDN: https://developer.mozilla.org/docs/Web/CSS

フォント

2022-03-10T20:52:36.745Z

リンク

仕様

True Type Font（ttf、仕様）
Open Type Font（otf、仕様）
Web Open Font Format（woff、仕様）
Web Open Font Format 2.0（woff2、仕様）

資料

Microsoft Typography
- https://docs.microsoft.com/typography/
Adobe
- https://helpx.adobe.com/fonts/using/adobe-type-resources-faq.html
- https://github.com/adobe-type-tools/font-tech-notes
FontForge Technical References
- https://fontforge.org/docs/techref.html
- https://fontforge.org/docs/appendices/bibliography.html
Google
- https://fonts.google.com/knowledge
- https://googlefonts.github.io
SIL International

CSS

CSS Fonts: https://www.w3.org/TR/css-fonts/
CSS Fonts (Draft): https://drafts.csswg.org/css-fonts/
MDN @font-face: https://developer.mozilla.org/docs/Web/CSS/@font-face
web.dev - Fonts: https://web.dev/tags/fonts/

ブログ

実装

.NET (WPF)
- Language: C#
- Source: https://github.com/dotnet/wpf
  - MS.Internal
  - System.Windows.Media
- Documentation: https://docs.microsoft.com/dotnet/
  - System.Windows.Media
- Note: Developed by Microsoft. Used by Windows.
Core Text
- Language: C with Objective-C/Swift API
- Source: Closed.
- Documentation: https://developer.apple.com/documentation/coretext
- Note: Developed by Apple. Used by iOS, macOS, tvOS, and watchOS.
Adobe Font Development Kit for OpenType (AFDKO)
- Language: C
- Source: https://github.com/adobe-type-tools/afdko
- Documentation: https://adobe-type-tools.github.io/afdko/
- Note: Developed by Adobe.
FreeType
- Language: C
- Source: https://gitlab.freedesktop.org/freetype/freetype/
- Documentation: https://www.freetype.org/freetype2/docs/documentation.html
- Note: Used by iOS, Android, Chromium, GNU/Linus, and more.
HarfBuzz
- Language: C++
- Source: https://github.com/harfbuzz/harfbuzz
- Documentation: https://harfbuzz.github.io
- Note: Used with FreeType by Android, Chromium, Firefox, and more.
fontTools
- Language: Python
- Source: https://github.com/fonttools/fonttools
- Documentation: https://fonttools.readthedocs.io
- Note: Used by Google and Adobe.
OpenType Sanitizer
- Language: C++
- Source: https://github.com/khaledhosny/ots
- Documentation: https://github.com/khaledhosny/ots/tree/main/docs
- Note: Used by Chromium and Firefox to validate font files.
golang.org/x/image/font
- Language: Go
- Source: https://github.com/golang/image
- Documentation: https://pkg.go.dev/golang.org/x/image/font
- Note: Go's library.

`html-webpack-plugin`でReactをテンプレートに使う

2022-03-10T12:56:45.979Z

テンプレートに指定したファイルからmodule.exportsでstringまたはそれを返す関数、Promiseを出力すればいいので、

const HtmlWebpackPlugin = require("html-webpack-plugin")

module.exports = {
    // ...
    plugins: [
        // ...
        new HtmlWebpackPlugin({
            filename: "index.html",
            template: "src/index.html.tsx",
        }),
    ],
};

のように設定し、index.html.tsxで、

tsx

import React from "react"
import { renderToStaticMarkup } from "react-dom/server"

export default function () {
    return (
        `<!DOCTYPE html>` +
        renderToStaticMarkup(
            <html lang="en">
                <head>
                    <meta charSet="utf-8" />
                    <meta
                        name="viewport"
                        content="width=device-width,initial-scale=1.0"
                    />
                    <title>Title</title>
                </head>
                <body>
                    <p>Hello, html-webpack-plugin.</p>
                </body>
            </html>
        )
    )
}

のように、renderToStaticMarkupを使って文字列を返す関数をexportすればよい。

React

2022-03-10T12:56:45.979Z

リンク

公式サイト: https://reactjs.org
リポジトリ: https://github.com/facebook/react/

TypeScript

2022-03-06T21:08:08.625Z

リンク

公式サイト: https://www.typescriptlang.org/
リポジトリ: https://github.com/microsoft/TypeScript
FAQs: https://github.com/microsoft/TypeScript/wiki/FAQ
古い仕様: https://github.com/microsoft/TypeScript/blob/main/doc/spec-ARCHIVED.md
コンパイラ資料: https://github.com/microsoft/TypeScript-Compiler-Notes/

TypeScriptでNominalな型付けを実現する

2022-03-06T21:06:25.109Z

TypeScript公式リポジトリのWiki内にあるFAQ「Can I make a type alias nominal?」でワークアラウンドとして紹介されているように、交差型（&）を利用する。

たとえば次のような型を用意しておけば:

type Nominal<T extends string> = {
    __nominal__: T
}

次のように型でのみ区別可能な文字列型を作ることができる:

type PlaceId = string & Nominal<"PlaceId">
type EventId = string & Nominal<"EventId">

ただし次のように型アサーションが必要となる:

const placeId = "place1" as PlaceId
const eventId = "event1" as EventId

HTMLの特殊文字をJavaScriptでエスケープする

2022-03-05T17:37:12.065Z

function escape(html: string) {
    return html.replaceAll(/[<>&'"]/g, c => {
        switch (c) {
            case "<":
                return "&lt;"
            case ">":
                return "&gt;"
            case "&":
                return "&amp;"
            case "'":
                return "&apos;"
            case '"':
                return "&quot;"
            default:
                return c
        }
    })
}

HTML

2022-03-05T17:37:12.065Z

リンク

HTML Standard: https://html.spec.whatwg.org/multipage/
MDN: https://developer.mozilla.org/docs/Web/HTML

JavaScript

2022-03-05T17:37:12.065Z

リンク

ECMAScript Language Specification: https://tc39.es/ecma262/multipage/
HTML Standard 8.1 Scripting: https://html.spec.whatwg.org/multipage/webappapis.html#scripting
MDN: https://developer.mozilla.org/docs/Web/JavaScript

Cargo

2022-03-04T14:45:09.081Z

リンク

The Cargo Book: https://doc.rust-lang.org/cargo/
リポジトリ: https://github.com/rust-lang/cargo/

Cargoのワークスペース

2022-03-04T14:42:43.821Z

RustのパッケージマネージャーであるCargoには、複数のパッケージの依存パッケージのバージョンや、出力ディレクトリ、プロファイルなどの設定を共有できるワークスペース機能がある。

ワークスペースのマニフェスト

ワークスペースは[workspace]セクションのあるCargo.tomlによって定義され、そのマニフェストファイルのあるディレクトリはワークスペースのルートディレクトリと呼ばれる。

toml

[workspace]
members = []
default-members = []
exclude = []

[workspace]セクションは[package]セクションを持つパッケージのマニフェストにも追加可能で、その場合そのパッケージはワークスペースのルートパッケージと呼ばれる。反対に[package]セクションを持たないワークスペースのマニフェストは、バーチャルマニフェストと呼ばれる。

ワークスペースのメンバー

ワークスペース内のパッケージは、ワークスペースのメンバーと呼ばれる。

メンバーは[workspace]セクションのmembersキーで指定することができる（?や*などのグロブパターンが使用可能）。

toml

[workspace]
members = ["path/to/member1", "../external/member2", "members/*"]

その他、ルートパッケージやメンバーのマニフェストに記載されている依存パッケージのうち、ワークスペースのルートディレクトリに含まれるpathによって指定されているもの（path dependency）も、自動的にワークスペースのメンバーとなる。

そのため、ルートパッケージの[workspace]セクションが空となることもありうる。

toml

[package]
name = "my-root-package"
version = "0.1.0"

[dependencies]
member1 = { path = "./member1" }

[workspace]

pathによる依存パッケージが自動でメンバーに追加されるのを防いだり、一部パッケージをグロブパターンから除外したりのするには、excludeキーを使うことができる。なおexcludeではグロブパターンは使えず、指定されたパス以下のすべてのパッケージがメンバーから除外される仕様になっている。

toml

[workspace]
members = ["crates/*"]
exclude = ["crates/bar"]

ワークスペースの認識

ワークスペースのマニフェストはCargoによって、自動的に親ディレクトリへと遡って探索される。ワークスペースのメンバーがルートディレクトリ外にある場合などのようにこの動作の上書きがしたい場合は、パッケージのマニフェストでpackage.workspaceキーを用いることで、パッケージの属するワークスペースを指定することができる。

toml

[package]
name = "member"
version = "0.1.0"
workspace = "../../path/to/workspace"

ワークスペースの機能

ワークスペースによってメンバーは以下を共有することになる。

依存パッケージの解決
- Cargo.lockファイルはワークスペースのルートディレクトリにのみ置かれる
出力ディレクトリ
- デフォルトではワークスペースのルートディレクトリ直下のtarget
Cargo.tomlの[patch]、[replace]、[profile.*]セクション
- ワークスペースのマニフェストのもののみが認識され、メンバーのマニフェストのものは無視される

toml

[workspace]
members = ["crates/*"]

[profile]
opt-level = s

また、cargo newやcargo initで行われるgitリポジトリの初期化も、作成されるパッケージが属することになるワークスペースが既にバージョン管理されている場合は行われなくなる。

そのほかpackage.metadataと同様にworkspace.metadataテーブルも許容されており、Cargo以外のツールが自由に使うことが可能となっている。

toml

[workspace]
members = ["crates/*"]

[workspace.metadata.site]
title = "Project Site"
icon = { path = "icon.png" }

CLIのオプション

Cargoのコマンドでは、-p（--package）オブションを使うことで、カレントディレクトリが属するワークスペース内にあるパッケージを指定することができる。

bash

cargo run -p member1

また--workspaceオプションを使うと、カレントディレクトリが属するワークスペース内にあるすべてのパッケージを対象に、そのコマンドが実行される。

bash

cargo test --workspace

何も指定しなかった場合は、カレントディレクトリが属するパッケージに対して、コマンドが実行される（メンバーのディレクトリ内ではない場合は、ルートパッケージ）。

bash

cargo build

属するパッケージがなく、代わりにバーチャルマニフェストに属するディレクトリで実行した場合は、デフォルトでは--workspaceを指定した場合と同様に振る舞うが、default-membersキーを用いるとその際実行されるメンバーを指定しておくことができる。なおdefault-membersでもグロブパターンは使えるが、メンバーに含まれないパッケージが選択されることはない。

toml

[workspace]
members = ["crates/*", "others/*"]
default-members = ["crates/*"]
exclude = ["crates/bar"]

参考

https://doc.rust-lang.org/cargo/reference/workspaces.html

Rustのスローガンが「効率的で信頼できるソフトウェアを誰もがつくれる言語」になったタイミング

2022-03-02T20:40:09.848Z

Rust Blogの2018-11-29の記事「A new look for rust-lang.org」に次の記載がある:

We have also revised the slogan. Historically, it has been:

Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.

Like the bullet list of features, this doesn't convey what you can do with Rust. So we've updated the slogan:

Rust: The programming language that empowers everyone to become a systems programmer.

ここで「システムプログラミング言語」としてのRustから、現在の「効率的で信頼できるソフトウェアを誰もがつくれる言語（A language empowering everyone to build reliable and efficient software.）」としてのRustに変わったらしい。

Monaco Editorをwebpackのプロジェクトに追加する

2022-03-01T17:43:22.787Z

monaco-editor-webpack-pluginを使うのが簡単:

bash

npm i -D monaco-editor-webpack-plugin

次のようにプラグインとして追加するだけで、勝手に設定してくれる:

const MonacoEditorWebpackPlugin = require("monaco-editor-webpack-plugin")

module.exports = {
    plugins: [new MonacoEditorWebpackPlugin()],
}

プレビュー用にここでは以下を追加:

bash

npm i -D webpack-cli webpack-dev-server html-webpack-plugin

webpack.config.js:

const path = require("path")
const MonacoEditorWebpackPlugin = require("monaco-editor-webpack-plugin")
const HtmlWebpackPlugin = require("html-webpack-plugin")

module.exports = {
    entry: path.resolve(__dirname, "src", "index.js"),
    plugins: [new MonacoEditorWebpackPlugin(), new HtmlWebpackPlugin()],
    // webpack 6 ではいらなくなるはず:
    experiments: {
        css: true,
    },
}

例えば次のようなJavaScriptとCSSを読み込むと:

src/index.js

import * as monaco from "monaco-editor"
import "./index.css"

monaco.editor.create(
    document.body.appendChild(document.createElement("div")),
    {
        language: "javascript",
        value: `console.log("Hello, 世界")`,
    }
)

src/index.css

css

html,
body,
body > div {
    height: 100%;
}

画面いっぱいにMonaco Editorが表示されるはず:

bash

webpack serve --mode development

Monaco Editor

2022-03-01T17:43:22.787Z

リンク

公式サイト: https://microsoft.github.io/monaco-editor/
リポジトリ: https://github.com/microsoft/monaco-editor
API: https://microsoft.github.io/monaco-editor/api/index.html
- monaco.d.tsが生成元

webpack

2022-03-01T17:43:22.787Z

リンク

公式サイト: https://webpack.js.org/
リポジトリ: https://github.com/webpack/webpack

RFC 2119: RFCにおいて要求レベルを示すために用いるキーワード

2022-03-01T07:59:17.799Z

RFC 2119は、各種RFCにおいて次の用語や表現がどの程度の要求レベルを示すと解釈されるべきかを定義している。

MUST
MUST NOT
REQUIRED
SHALL
SHALL NOT
SHOULD
SHOULD NOT
RECOMMENDED
MAY
OPTIONAL

すべてのRFCがこの解釈に従うわけではないが、多くのRFCがこのRFCを参照することで、表現を厳密に解釈できるようにしている。

本文は:

https://datatracker.ietf.org/doc/html/rfc2119

日本語訳には、たとえば:

https://www.ipa.go.jp/security/rfc/RFC2119JA.html

なおRFC 8174は大文字で表記されている場合のみRFC 2119の意味で解釈することで曖昧さをなくそうというRFCであり、RFC 2119とともに参照されることが多い。

しなければならない（必要）

MUST（「しなければならない」）
REQUIRED（「要求される」）
SHALL（「することになる」）

は仕様を満たすには絶対必要であることを示す。

強い要求なので、この表現を用いる場合は、細心の注意が必要となる。

してはならない（禁止）

MUST NOT（「してはならない」）
SHALL NOT（「することはない」）

は仕様を満たすには絶対禁止であることを示す。

強い要求なので、この表現を用いる場合は、細心の注意が必要となる。

すべきである（推奨）

SHOULD（「すべきである」）
RECOMMENDED（「推奨される」）

は特定の条件における正当な理由なく、その項目を無視してはならないことを示す。

その項目を無視するには、細心の注意が必要となる。

すべきでない（非推奨）

SHOULD NOT（「すべきでない」）
NOT RECOMMENDED（「推奨されない」）

は特定の条件における正当な理由なく、その項目を満たしてはならないことを示す。

その項目を満たすには、細心の注意が必要となる。

してもよい（任意）

MAY（「してもよい」）
OPTIONAL（「任意である」）

は、その項目を満たすか満たさないかが実装者に任されることを示す。

逆にいえば、その項目を満たしてる実装も満たしていない実装も両方仕様を満たしているものとして正当に扱わなければならない。

RFC

2022-03-01T07:59:17.799Z

リンク

Cloudflare Pagesでエラー`Only file and data URLs are supported by the default ESM loader`がでる

2022-02-26T08:54:37.708Z

Cloudflare PagesでNode.jsのプロジェクトをビルドする際に、次のようなエラーが出た。

txt

Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]: Only file and data URLs are supported by the default ESM loader

原因はどうやら現時点でのCloudflare PagesのデフォルトのNode.jsのバージョンが12.18.0であることだったようなので、環境変数のNODE_VERSIONをひとまず16に設定すると解決した。

なお.nvmrcや.node-versionなどのファイルもサポートされているので、これで指定しておくとより取り回しがきくかもしれない。

Cloudflare

2022-02-26T08:54:37.708Z

リンク

公式サイト: https://www.cloudflare.com/

Cloudflare Pages

2022-02-26T08:54:37.708Z

リンク

公式サイト: https://pages.cloudflare.com/

husky

2022-02-26T08:11:40.016Z

リンク

公式サイト: https://typicode.github.io/husky/
リポジトリ: https://github.com/typicode/husky

`husky`を追加する

2022-02-26T08:11:05.392Z

shell

npm install husky -D

shell

npm set-script prepare "husky install"
npm run prepare

shell

npx husky add .husky/pre-commit "npm run precommit"

例えば、

shell

npm set-script precommit "npm run check && npm run lint && npm run format"

プライバシーポリシー

2022-02-16T11:28:12.186Z

本サイトはGoogleの提供するGoogleアナリティクスを利用しています。

Googleアナリティクス

本サイトはGoogleの提供するGoogleアナリティクスを利用しています。またそれによって、Cookie、モバイルデバイスの識別情報（Android の広告識別子、iOS の広告識別子など）、およびその他データの収集に使われる類似の技術なども利用しています。Googleアナリティクスでデータが収集、処理される仕組みについては、「ユーザーが Google パートナーのサイトやアプリを使用する際の Google によるデータ使用」をご覧ください。

Rust

2022-02-13T15:27:42.376Z

リンク

公式サイト: https://www.rust-lang.org/
リポジトリ: https://github.com/rust-lang/rust

RustでREADME.mdをドキュメントコメントとしてインクルードする

2022-02-13T15:25:26.303Z

rust

#![doc = include_str!("../README.md")]

Rustで文字列スライスのポインタ間の距離を測る

2022-02-13T15:24:44.489Z

rust

pub fn distance_ptr(a: &str, b: &str) -> usize {
    (b.as_ptr() as usize) - (a.as_ptr() as usize)
}

コンパイルすると:

asm

movq %rdx, %rax
subq %rdi, %rax
retq

補足

これを使うと、ある文字列（source）に対してその部分文字列（span）がどの位置や範囲にあるかを、追加情報なしに取得することができるはず（安全な操作かどうかは正直なところ分からない）。

なお_unwrapのついている関数では、spanとして与えられた文字列スライスが本当にsourceの範囲内にあるかを確認してOptionで返すようになっている。

rust

fn position_ptr_unwrap(source: &str, span: &str) -> usize {
    let source_start = source.as_ptr() as usize;
    let span_start = span.as_ptr() as usize;
    span_start - source_start
}

fn position_ptr(source: &str, span: &str) -> Option<usize> {
    let source_start = source.as_ptr() as usize;
    let span_start = span.as_ptr() as usize;

    if span_start < source_start {
        return None;
    }

    let source_end = source_start.checked_add(source.len())?;
    let span_end = span_start.checked_add(span.len())?;

    if source_end < span_end {
        return None;
    }

    Some(span_start - source_start)
}

fn range_ptr_unwrap(source: &str, span: &str) -> core::ops::Range<usize> {
    let source_start = source.as_ptr() as usize;
    let span_start = span.as_ptr() as usize;
    let range_start = span_start - source_start;
    range_start..(range_start + span.len())
}

fn range_ptr(source: &str, span: &str) -> Option<core::ops::Range<usize>> {
    let source_start = source.as_ptr() as usize;
    let span_start = span.as_ptr() as usize;

    if span_start < source_start {
        return None;
    }

    let source_end = source_start.checked_add(source.len())?;
    let span_end = span_start.checked_add(span.len())?;

    if source_end < span_end {
        return None;
    }

    let range_start = span_start - source_start;
    let range = range_start..(range_start + span.len());
    Some(range)
}

Public Theta Blog

QEMU

x86_64のUbuntuでqemu-aarch64-staticする

Windows

Windows上でのi686-pc-windows-gnu向けRustビルドで"linker `i686-w64-mingw32-gcc` not found"が出る

Rustのtargetディレクトリをあるディレクトリ以下で共有する

webpackでswcを使う

npmのserveパッケージを使ってローカルサーバーを立てる

Jest + TypeScriptで`SyntaxError: Unexpected token 'export'`が出る

Jest

リンク

Cloudflare Pagesのダイレクトアップロードでビルド済みの静的サイトをそのままデプロイする

Wrangler

アップロード

プロジェクト

参考リンク

RustでCargoの仮想ワークスペース（virtual workspaces）使用時にのみ依存パッケージのコンパイルに失敗する

Storybook + React + MDX で TypeError `(0 , _mdx_js_react__WEBPACK_IMPORTED_MODULE_2__.mdx) is not a function` が出る

Storybook

リンク

FFmpegで動画をGIF化する

FFmpeg

リンク

GIF

Netlifyでローカルビルドをそのまま静的ホストする

インストール

ログイン

デプロイ

既存サイトとのリンク

新規サイトの作成

参考リンク

変更履歴

2022-06-12

Netlify

リンク

Bevyの座標系

参考リンク

3D

Bevy

リンク

`vscode.dev`に開発中の拡張機能をローカルから読み込む

方法

参考リンク

VS Code

リンク

VS Code拡張機能

リンク

TypeScriptのイテレーターとジェネレーター

ECMAScriptの反復処理インターフェース

Iterable

AsyncIterable

Iterator

AsyncIterator

IteratorResult

組み込みの反復可能オブジェクト

イテレーターの反復可能性

IterableIterator

AsyncIterableIterator

イテレーターと反復可能オブジェクトの作成

ジェネレーター関数とジェネレーター

参考リンク

計算量の漸近記法（Θ記法・O記法・Ω記法・o記法・ω記法）

Θ記法

定義

説明

O記法

定義

説明

Ω記法

定義

説明

o記法

定義

説明

ω記法

定義

説明

漸近関係の性質

参考

アルゴリズム

`deps.ts`

`lock.json`