krymtkts

PowerShell Local Resource Manager Part 6 - pslrm-bump-action

Tue, 14 Apr 2026 09:00:00 +0900

krymtkts/pslrm を使って lockfile を更新・ PR を作成する third-party action krymtkts/pslrm-bump-action を作ってる。

Marketplace 公開目的で GitHub Actions を作るのが始めてなので、知らないことが多く中々難航してる。でもとりあえず repository を公開できる程度には出来上がってきた。 push したら早速 self smoke test がコケたが。このあと tag を打って release 作って Marketplace に公開し、 tag base で使えるようにするのが 1 つの目標地点。

初めて third-party action を作ったけど、自分の repository 用に書くのと随分違った。 JavaScript で書くやる気ないなと思い、 YAML ベースで composite action 的にしつつ、ややこしい場所を PowerShell script に逃している。具体的には PowerShell と Windows PowerShell の差分吸収とかを PowerShell script に逃がした。 Windows PowerShell の PowerShellGet しかないところに確実に PSResourceGet を用意するとかが厄介なためだ。 jobs.<job_id>.steps[*].shell の値は、起動時点で決定されている必要がある様子。そのため YAML 上でその 2 パターンを取り扱おうとすると冗長になる。だから PowerShell script 内で handling した方が simple だった。

ちなみに composite action の引数で受けた値を shell に渡すなら問題ない。だが third party action の場合は相対パスで composite action の YAML を探すところが信用できないみたい。例えば current directory を third-party action を呼ぶまでに変えられてたりとかで、相対パスでは参照できない場合があるみたい？まだこういったケースをわたし自身理解してないが、不確定要素をここで抱える意味もないなと思った。なので気は進まなかったが PowerShell script で色々やることにした。

利用者がどういう使い方をして、 action 側は決定論的に module 解決するためにどうすべきか。 PAT を使わないと commit と pull request で後続の GitHub Actions を起動できないからどう documentation するとか。知らない事が多いだけに学びも多いが、中々難しいな。 GitHub Copilot に色々聞きながらやってるから進められるが、これは単独趣味プロでやってたらもっと時間がかかるだろうな。

Pester による unit testing と nektos/act で integration testing してる。けど最終的な疎通確認は、生の GitHub repository でやらないといけないのがハードル高いな。生の repository 相手だと CI に組み込むのも flaky だし、手動テストという形なる。まだそのためのテスト用 repository は作れてない。 action 公開勢はみんなテスト用 repo 作ってやってるのかな？謎。テストの度に PR が作成されたり面倒そうだが、これしか方法はないのかな。 sandbox できなものがあればいいのだけど見つけられなかったので、実 repository でやる想定。

それらが終わったら Marketplace に公開したいのだけど、公式文書には workflow が含まれたらだめとか書いてある。 Workflow syntax for GitHub Actions - GitHub Docs 何故。

でも actions/checkout とか代表的な action 見る限り .github/workflow が含まれてるし、はて？となっている。他にも、なんか文脈的に tag 打ちで GitHub CLI で作成する release には Marketplace への publish ができなそうに見えるとか諸々心配点がある。よくわからんがまずは SHA base で自前テストしてみてから考えるかー。

随分気づくのが遅くなったが、 krymtkts/pslrm-bump-action がおもくそ private のママだったので public にした。まだ CI コケてるし、はよ直して test repo で試してみたいところ。

PowerShell Local Resource Manager Part 5

Sun, 05 Apr 2026 09:00:00 +0900

krymtkts/pslrm の開発をした。

前回話していた Update-PSLResource を使った psreq.lock.psd1 の Bump workflow を直した。

pslrm/.github/workflows/bump.yml at d9a96677d1690fb5b7465a992bbbd3f55772103a · krymtkts/pslrm

name: Bump dependencies

on:
  schedule:
    - cron: "0 20 * * 5" # Every Friday at 06:00 JST
  workflow_dispatch:

concurrency:
  group: bump-dependencies
  cancel-in-progress: false

# NOTE: no permissions are needed.
permissions: {}

jobs:
  bump:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v6
        with:
          ref: main
          # NOTE: to trigger the workflow on a push to the bump branch.
          token: ${{ secrets.PSLRM_BUMP_TOKEN }}
      - name: Bump dependencies
        shell: pwsh
        run: |
          Set-PSResourceRepository PSGallery -Trusted
          Import-Module ./pslrm.psd1 -Force
          Update-PSLResource
      - name: Detect lockfile changes
        id: lockfile
        shell: pwsh
        run: |
          $diff = git status --porcelain -- psreq.lock.psd1
          if ($diff) {
            "changed=true" >> $env:GITHUB_OUTPUT
            Write-Host "Lockfile changes detected."
          } else {
            "changed=false" >> $env:GITHUB_OUTPUT
            Write-Host "No lockfile changes detected."
          }
      - name: Create or update pull request
        if: steps.lockfile.outputs.changed == 'true'
        env:
          GH_TOKEN: ${{ secrets.PSLRM_BUMP_TOKEN }}
        shell: pwsh
        run: |
          git config user.name 'github-actions[bot]'
          git config user.email '41898282+github-actions[bot]@users.noreply.github.com'

          $branch = 'chore/bump-pslrm-dependencies'
          git switch --force-create $branch
          git add -- psreq.lock.psd1

          $stagedLockfile = git diff --cached --name-only -- psreq.lock.psd1
          if (-not $stagedLockfile) {
            Write-Host 'No staged lockfile changes to commit.'
            exit 0
          }

          $title = 'Bump pslrm dependencies.'
          git commit --message $title
          git push --force --set-upstream origin $branch

          $baseBranch = 'main'
          $prNumber = gh pr list --base $baseBranch --head $branch --state open --json number --jq '.[0].number'
          if ($prNumber) {
            Write-Host "Pull request #$prNumber already exists."
          } else {
            $body = 'Automated dependency bump generated by Update-PSLResource.'
            gh pr create --base $baseBranch --head $branch --title $title --body $body
          }

Managing your personal access tokens - GitHub Docs

直に URL に PAT を指定する方法を始め使おうと思ったが、やめた。どうも actions/checkout で token に PAT を渡せば PAT で認証された HTTPS remote を使うようだったのでそれを採用した。その方が、見た目がスッキリしてよろしい。

PAT には Content read/write と Pull Request read/write を設定するので、 workflow 自体の認証が要らなくなる。指定の仕方がわからなかったが、これは公式文書上に書いてあった。

Defining access for the GITHUB_TOKEN scopes | Workflow syntax for GitHub Actions - GitHub Docs

permissions: {}

ちょっと見慣れない書き方だが、今回のケースはコレがハマるはず。

コレをベースに pslrm の third-party actions を作り始めてみたが、この週末体調が優れずあんま進んでない。休日を有効活用できず残念だが、一歩くらいは進んでるのでよしとする。今回使った actions/checkout の token に PAT を渡す方法は、 third-party action の場合だと checkout を内包すべきでないだろうし、使わない想定。少しずつ仕様を詰めていってはよ v0 の bump-pslrm-action として公開したいな(そして自分の repos で使うのだ)。

PowerShell Local Resource Manager Part 4

Sun, 29 Mar 2026 09:00:00 +0900

krymtkts/pslrm の開発をした。

Update-PSLResource を使えば、実行後に psreq.lock.psd1 の差分から依存関係の更新を検知できる。それを使って Dependabot のような自動的な更新したくてそういう GitHub Actions workflow をこしらえた。

pslrm/.github/workflows/bump.yml at d42f35ea69c63159ff5043106bbdfc4a1b5113d1 · krymtkts/pslrm

name: Bump dependencies

on:
  schedule:
    - cron: "0 20 * * 5" # Every Friday at 06:00 JST
  workflow_dispatch:

concurrency:
  group: bump-dependencies
  cancel-in-progress: false

permissions:
  contents: write
  pull-requests: write

jobs:
  bump:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v6
        with:
          ref: main
      - name: Restore modules from PSGallery
        shell: pwsh
        run: |
          Set-PSResourceRepository PSGallery -Trusted
          Import-Module ./pslrm.psd1 -Force
          Restore-PSLResource
      - name: Bump dependencies
        shell: pwsh
        run: |
          Import-Module ./pslrm.psd1 -Force
          Update-PSLResource
      - name: Detect lockfile changes
        id: lockfile
        shell: pwsh
        run: |
          $diff = git status --porcelain -- psreq.lock.psd1
          if ($diff) {
            "changed=true" >> $env:GITHUB_OUTPUT
            Write-Host "Lockfile changes detected."
          } else {
            "changed=false" >> $env:GITHUB_OUTPUT
            Write-Host "No lockfile changes detected."
          }
      - name: Create or update pull request
        if: steps.lockfile.outputs.changed == 'true'
        env:
          GH_TOKEN: ${{ github.token }}
        shell: pwsh
        run: |
          git config user.name 'github-actions[bot]'
          git config user.email '41898282+github-actions[bot]@users.noreply.github.com'

          $branch = 'chore/bump-pslrm-dependencies'
          git switch --force-create $branch
          git add -- psreq.lock.psd1

          $stagedLockfile = git diff --cached --name-only -- psreq.lock.psd1
          if (-not $stagedLockfile) {
            Write-Host 'No staged lockfile changes to commit.'
            exit 0
          }

          $title = 'Bump pslrm dependencies.'
          git commit --message $title
          git push --force --set-upstream origin $branch

          $baseBranch = 'main'
          $prNumber = gh pr list --base $baseBranch --head $branch --state open --json number --jq '.[0].number'
          if ($prNumber) {
            Write-Host "Pull request #$prNumber already exists."
          } else {
            $body = 'Automated dependency bump generated by Update-PSLResource.'
            gh pr create --base $baseBranch --head $branch --title $title --body $body
          }

つい昨日いい感じに動き PR #1 は作成されたのだが、運用してみてちょっとした問題があるとわかった。単純な話だが GitHub Actions の仕様で bot が作った PR に対して CI の GitHub Actions workflow が起動しないというものだ。 pull_request の節には書いてないようだが check_run check_suite には書いてある様子。

CI が pull_request じゃなく pull_request_target を使っていれば起動できるが、そこは本質じゃない。あるべき像としては pslrm の GitHub Actions workflow 側で GitHub CLI の GH_TOKEN に権限を持った PAT を使うのがいいっぽい。 GitHub App を使う手もあるが、その方式が一番一般的ぽい。次のステップとしては PowerShell Gallery に公開している pslrm を使う third-party Action を作りたく、その場合も PAT がいいみたい。なのでその方向でも調整していこうと思っているが、リアルで旅の途中なので着手はできてない。

他にも PR のために作成する branch name が固定だったり、 description が簡素過ぎたりもある。 Dependabot ぽくするなら label もつけたいしな。その辺りも含めて機能を揃えられたら、 third-party Action として良さげかなと考えている。如何せん third-party Action を作ったことがないから、手探りで進めていく予定。

続く。

PowerShell Local Resource Manager Part 3 - pslrm 0.0.1-alpha

Sun, 22 Mar 2026 09:00:00 +0900

krymtkts/pslrm の開発をした。

0.0.1-alpha として PowerShell Gallery に公開した。まだ使い勝手はかなり悪いが、最低限の版として一度公開しておきたかった。コレまでの機能実装からは特に機能的な拡充をしてなくて、専らに CI/CD を中心に整備した。 release したかったのは、この CI/CD 周りの最後の動作確認をしたかったからでもある(そして build script の不具合が見つかり目論見通り動作確認の意味があった)。

pull request 時や push 時の CI は元々作ってあった。これに加えて release note 更新、 PowerShell Gallery への公開と GitHub の Release 作成の流れを GitHub Actions に起こした感じ。特に release note に関しては、 PowerShell Gallery の事例を見つつなるべくマシな形になるよううまく整理したんじゃないかなと。

これまで自分で作ってきた PowerShell module は管理がてきとーだったので release note を作ってこなかった。今回からは真面目にやろうと考えて、 PowerShell の module manifest に含まれる ReleaseNotes の更新なんかも真面目に検討した。ここでいう release note は changelog の一部であると考えてもらいたい。 PowerShell module には release note の属性が用意されているが、そこに何を書くかは明確に定義されていない。

わたしの知る限り、 PowerShell Gallery に公開されてる module では大体以下のパターンが存在する。

release note への外部リンク(URL 文字列)
累積の release note
何もなし

1 は、大体 GitHub の release とか changelog のファイルへの外部リンクが多い。中には全然関係ない URL もあったりするようだ。この場合 PowerShell Gallery に表示されたら、リンクになっている。 Get-Module や Get-InstalledPSResource で得た ReleaseNotes はただの URL 文字列だ。代表例は Pester なんかがそう。

> Get-InstalledPSResource -Name pester -Scope AllUsers | % ReleaseNotes
https://github.com/pester/Pester/releases/tag/6.0.0-alpha5

module manifest の ReleaseNotes の更新も URL 文字列をブチ込むだけなので簡単。だからこれは運用最適化のパターンで、利用者としてはその場で確認できないという意味でちょっと味気ないなと感じている。

2 はちょっとややこしい。始まった頃からの累積 release note と、 major や minor 毎の累積 release note がありそう。開発者は ReleaseNotes を自動生成・更新するなり手で更新する必要がある。また module manifest が肥大化する恐れがある(サイズ制限の有無は不明)。運用の負荷が一番高いが、利用者は URL をたどる必要がないので情報を得やすい。パッと見、 PSResourceGet はこの minor version 毎の累積 release note っぽい。 pull request を見るに module manifest は手で更新してるのかな～と思ってる。そのためか、ファイルが肥大化しないように changelog を version で分割してるみたい。

> Get-InstalledPSResource -Name *PSResourceGet -Scope AllUsers -Version 1.2.0-rc3 | % ReleaseNotes
## 1.2.0-rc3

## Bug fix
- Packages that depend on a specific version should search for the dependency with NormalizedVersion (#1941)

## 1.2.0-rc2

## Bug fix
- For packages with dependency on a specific version use specific version instead of version range (#1937)

... 略

3 は simple だ。何もなし。開発者は ReleaseNotes には何もしなくて良い。利用者は ProjectUri から自力でたどり着く必要がある。開発者は楽だが利用者に対して親切ではないかなと考えている運用。代表例は PSScriptAnalyzer また、利用者が ProjectUri を辿ってもそこに release note が存在する保証はない。わたしのこれまでの module はこれにあたる。

PowerShell module の release note 事情はこのように現時点での正解はないと思っている。であれば自分で考える正解を突き進むのが良かろうと思った。個人的には release note はあった方が良い。また運用負荷は下げたくて手作業はやりたくない。 module manifest の肥大化も避けたい。というわけで以下のルールとした。

CHANGELOG.md を source of truth にする
直近 3 release 分の release note を module manifest の ReleaseNotes に含める
以降は省略し ReleaseNotes 最下部に full release note である CHANGELOG.md への URL を記載する
GitHub Release には release 対象 version の release note を記載する(当たり前)

情報を示しつつ完全版への道筋も示す 1 と 2 の複合版が多分いま一番マシなんじゃないかなと考えた。

CHANGELOG.md は Keep a Changelog を参考にしつつ、情報の付加や自動化に有利な独自のルールを付加している。具体的に言うと Notes で release ごとの付加情報を添えたのと、自動化を簡単にするため footer の区切りとして --- を入れたところ。ほかは Keep a Changelog に倣っている。

今どきは conventional commit が多いが、個人的に好きではないので使ってないのもあり、利用者向けの情報となる release note は人間がまとめる方針とした。 CHANGELOG.md を source of truth にして ReleaseNotes と GitHub Release への反映を自動化した task を用意している。

0.0.1-alpha の場合以下のようになった。多分そんなに変なことにはなってないはず。

> Get-InstalledPSResource -Name pslrm -Scope AllUsers | % ReleaseNotes
## [0.0.1-alpha]

### Added

- Add project-local PowerShell resource management based on PSResourceGet.
- Add requirements and lockfile workflows with `Install-PSLResource` and `Update-PSLResource`.
- Add lockfile restore and removal workflows with `Restore-PSLResource` and `Uninstall-PSLResource`.
- Add `Get-InstalledPSLResource` for reading installed project resources from the lockfile.
- Add `Invoke-PSLResource` for running commands from project-local resources in an isolated runspace.
- Add build, lint, unit test, and integration test tasks through `Invoke-Build`.

### Notes

- This is the initial alpha release track for `pslrm`.
- Supported PowerShell versions are Windows PowerShell 5.1 through PowerShell 7.x.
- Supported repository is PowerShell Gallery.
- `Invoke-PSLResource` uses `IsolatedRunspace` execution. `InProcess` execution is not implemented.

Full CHANGELOG: https://github.com/krymtkts/pslrm/blob/main/CHANGELOG.md

準備には手間がかかったが、コレによって PowerShell Gallery や module 自体に理解しやすい release note を提供できる。また CHANGELOG.md 自体への導線も保ちつつ、自動化で付加も低減できた。個人開発で release note をするのは今回が初めてなので、真面目に検討した価値があったんじゃないかな。当面この感じで使ってみて問題点現れないかやってみるつもり。

PowerShell Local Resource Manager Part 2

Sun, 15 Mar 2026 09:00:00 +0900

krymtkts/pslrm の開発をした。

これまでは、 Pester のように設定が独自 object だと型の解決に問題があるので、 pslrm では実行できなかった。 Invoke-Build のような task runner 経由であればそういうことができるようにした。この対応、個人的にかなり難しく GitHub Copilot の導く方向もちょいちょい間違ってたので、要所要所手作りの温もりで調整したつもり。

このへんのコミットがそうなんだが、入れ子で呼び出される場合に Host の取り扱いが良くなかったみたい。 Write-Host が実行されたら null reference で落ちてしまってた。 GitHub Copilot は独自 Host 実装を作ればいいと言ってたが、んなあほな...ということで階層が深い場合は一番上の Host が使われるように調整して、いけるようになった。

GitHub Actions 上に CI も整備して cross platform のテストを回してみた。 Windows & PowerShell は問題なし。 Windows PowerShell の方は互換性を維持して置き換えたら動くようになった。 Ubuntu & PowerShell の方は成功するけどたまに Host 周りが失敗してるから、 flaky ぽい。 local で nektos/act で動かした限りは Ubuntu でも問題なく動いてそうなんやが。 macOS はまだ成功してるところを見たことないが、どうだろう。このテストは GitHub Copilot サンに書いてもらってるので理解浅いから、後追いで理解していかんと。特に、今回は背視したような入れ子の Host 問題みたいなケースで本質を追うのは GitHub Copilot サンには難しいから、自力でしか解決できんしな。

まだ結構イマイチな箇所が多いけど、 pslrm の開発で使うレベルでは徐々に Pester, PSScriptAnalyzer, Invoke-Build の実行はできるようになった。

例えば Pester v6 のように独自提供の型を使って設定を組み上げるようなケースは、煩雑だが以下のようにできる。

Invoke-PSLResource Invoke-Pester -Arguments @('-Configuration', (Invoke-PSLResource New-PesterConfiguration))

PSResourceGet しか入ってない Windows PowerShell でも動いてるので多分うまくいってるんじゃないかな。さらにいいところは以下。

pslrm/.github/actions/restore-and-test/action.yml at 0eb5c4d62508c80f6704feb404e69c61d56cc508 · krymtkts/pslrm

- name: Restore modules from PSGallery
  shell: ${{ inputs.shell }}
  run: |
    Set-PSResourceRepository PSGallery -Trusted
    Import-Module ./pslrm.psd1 -Force
    Restore-PSLResource

こんな風に依存関係の restore が Restore-PSLResource 一発で済んで simple になってるのでとてもいいなと思ってる。もうちょっといい感じになったら PowerShell Gallery へ publish しよう。

PowerShell Local Resource Manager Part 1

Sun, 08 Mar 2026 09:00:00 +0900

前回触れた PowerShell の project-local な依存管理を提供する薄い wrapper module を作り始めた。仮に名前は PowerShell Local Resource Manager ということで pslrm としている。

krymtkts/pslrm

まだ未完成だが、 project- local で動かせるんだなといのがわかったので、ひとまず repository 公開した。でもまだ PowerShell Gallery に公開するには使えなさ過ぎるので、やってない。

読みは acronym なので "P-S-L-R-M" でもいいし、親しみを込めて "ps-lurm"("Pee Slurm") と疑似的に読んでもいい。 AI 曰く、擬似的に読むなら "ps-lrm" -> "Pee Slurm" が自然な読み方で、日本語的に「ピーエスラーム」とはならんそうだ。

pslrm では PSResourceGet に PowerShell からの取得や依存関係の解決を任せている。だから pslrm がやる仕事は少ない。

project-local を指定して Save-PSResource すること。
project-local な module を global 汚染せず別 session で動かすこと。

しかしこれだけでもまだできない機能があるくらいなので、随分と面倒だ。特に「project-local な module を別 session」のは process か runspace を分けることになる。今のところ pslrm 0.0.1 では runspace を分けるだけにしている。 process を分けると起動が流石に遅いかと考えた。現状でもかなり遅いのだが、 runspace を分けて最低限 project-local な resource を動かせるところまでは確認できた。

以下は PSScriptAnalyzer を動かしてみた例だ。呼び出しが極めて面倒だが、動くのは動く。

> Import-Module .\pslrm.psd1 -Force
> get-command -Module pslrm

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Function        Get-InstalledPSLResource                           0.0.1      pslrm
Function        Install-PSLResource                                0.0.1      pslrm
Function        Invoke-PSLResource                                 0.0.1      pslrm
Function        Restore-PSLResource                                0.0.1      pslrm
Function        Uninstall-PSLResource                              0.0.1      pslrm
Function        Update-PSLResource                                 0.0.1      pslrm

> cat .\psreq.psd1
@{
    Pester = @{
        Repository = 'PSGallery'
        Prerelease = $true
    }
    PSScriptAnalyzer = @{
        Repository = 'PSGallery'
        Prerelease = $true
    }
}
> Install-PSLResource -Path . -Confirm:$false

Name        : PSScriptAnalyzer
Version     : 1.24.0
Repository  : PSGallery
IsDirect    : True
ProjectRoot : C:\Users\takatoshi\dev\krymtkts.github.com\krymtkts\pslrm

Name        : Pester
Version     : 6.0.0-alpha5
Repository  : PSGallery
IsDirect    : True
ProjectRoot : C:\Users\takatoshi\dev\krymtkts.github.com\krymtkts\pslrm

> Get-InstalledPSLResource -Path . -IncludeDependencies

Name        : PSScriptAnalyzer
Version     : 1.24.0
Repository  : PSGallery
IsDirect    : True
ProjectRoot : C:\Users\takatoshi\dev\krymtkts.github.com\krymtkts\pslrm

Name        : Pester
Version     : 6.0.0-alpha5
Repository  : PSGallery
IsDirect    : True
ProjectRoot : C:\Users\takatoshi\dev\krymtkts.github.com\krymtkts\pslrm

> Invoke-PSLResource -Path . -CommandName Invoke-ScriptAnalyzer -Arguments @('-Path', '.\src', '-Recurse')

RuleName : PSUseShouldProcessForStateChangingFunctions
Severity : Warning
Line     :
Column   :
Message  : Function 'New-PSLRMResourceObject' has verb that could change system state. Therefore, the
           function has to support 'ShouldProcess'.

RuleName : PSUseShouldProcessForStateChangingFunctions
Severity : Warning
Line     :
Column   :
Message  : Function 'New-Resource' has verb that could change system state. Therefore, the function has
           to support 'ShouldProcess'.

RuleName : PSUseSingularNouns
Severity : Warning
Line     :
Column   :
Message  : The cmdlet 'Get-LockfileResourceNames' uses a plural noun. A singular noun should be used
           instead.

RuleName : PSUseSingularNouns
Severity : Warning
Line     :
Column   :
Message  : The cmdlet 'ConvertTo-PSLResourceInvocationArguments' uses a plural noun. A singular noun
           should be used instead.

RuleName : PSUseOutputTypeCorrectly
Severity : Information
Line     :
Column   :
Message  : The cmdlet 'Uninstall-PSLResource' returns an object of type 'System.Object[]' but this type
           is not declared in the OutputType attribute.

コードも不格好でかなり遅いが、今はとりあえず project-local な依存関係の管理ができるというのがわかった。この後本当に使いやすさであるとか例外的に支えない PowerShell module があるかとかを検証していく必要がある。でも GitHub Actions 等での CI で個別に module を install することなく local と同じ version を使えるというのは、いいんじゃないかな。 PowerShell でも deterministic な module 管理をしたかったので気に入っている。

F# の PowerShell module template 作成からは寄り道しているが、当面 pslrm の機能を拡充していくつもり。 Pester のように設定が独自 object だと型の解決に問題があるので、それは cmdlet 直の実行でなく script を実行できるようにしたい。 template で依存する PowerShell module 管理を簡単にするため pslrm のアイデアが生まれたので、どん詰まりまではやってみてもよかろう。

F# の PowerShell Module の Template を作りたい Part 4 - PowerShell の project-base なモジュール管理

Sun, 01 Mar 2026 09:00:00 +0900

krymtkts/FsPowerShellTemplate の開発をした。 task runner の task を拡充をした。 unit/end-to-end testing, documentation, PowerShell Gallery への publish 等。あと coverage も足しておきたいなと考えてるが、まだ着手できていない。

Microsoft.Testing.Platform に対応した Coverlet ができたのでそれを使おうと考えてる。けど、他の v8 系は出ているけど MTP 版だけ NuGet に公開する権限の問題でまだ出てないらしい。以下の issue にそれが書かれている。

NuGet "coverlet.MTP" package does not exist? · Issue #1816 · coverlet-coverage/coverlet

上記以外は概ね揃えたつもりなのだけど、最後に PowerShell Module のモジュール管理を project-local でできないことが気になっている。 PSResourceGet だと project local に依存関係を管理する仕組みがないはず。 module の install は、 machine local か current user local が対象になる。これは開発環境では project 毎に複数の module version があると支障がある。 $PSModulePath を指定していても machine や user の module を拾ってしう。 (container で分けろという世界観なのかも知れないが)

今できる方法としては、わたしが作ってる他の PowerShell Module 同様に、 version を指定せずに使う。あるいは、愚直に script を書いて利用 version の固定をやればいいの。だが汎用性に欠けるし、そもそも開発環境でも CI でも同じ方法で管理できるのが一番うれしい。要は lockfile base で PowerShell Module を restore できるようなのが欲しい。

PowerShell のモジュール依存関係の管理として、昔から PSDepend がある。長らく開発停止してるみたい。わたしは使ったことがないが、見た感じでは lockfile がなくようなので求める機能がなさそう。仮に動いても、見たところ PowerShell Gallery 以外の source にも対応しているから結構多機能なのでこんなに重厚なやつが欲しいのではないかなという感じ。

Install-PSResource には -RequiredResourceFile, -RequiredResource という option がある。この option を使えば、 psd1 ファイルに exact version を記入することで擬似的に lockfile として使えそう。でも install で自動生成されないし、先に上げた user と machine の汚染は防げないから、隔離環境でしか使えない。なら Save-PSResource が requirements-base で動かせたらいいのだけど、残念ながらできない。

ないのであればということで、いま PSResourceGet をベースとして、上記の project-local な依存管理を提供する薄い wrapper module を試作している。仮に名前は PowerShell Local Resource Manager ということで pslrm としている。今の時代は略語が多すぎて何を考えても重複するリスクがあって、これも名前が衝突してるが、仕方ない。今はまだ実感として使える感じがなくて、わたしには珍しく private repository にして開発してる。歴史直したりするしな。 pslrm が多少愚直でも求める機能を提供できるようになったら、 template に組み込んで使うつもり。

将来的に PSResourceGet がその機能を持つこともあるかも知れないが、今はないので多分価値があるねんよな。 PSResourceGet で machine や user から分離した module management ができるようになったら、薄い wrapper module は要らなくなるはず。付け焼き刃の出番をなくすためにも、本体の進化を期待するばかり。

当面は pslrm 試作に時間を割くので、 template の方は手を付けないつもり。その間に MTP 版の Coverlet が NuGet に登録されたらいいなという淡い期待。

Windows の Dev Drive を有効にする

Mon, 23 Feb 2026 09:00:00 +0900

storage 貧者だったので使ってなかったが、 laptop 変えて増えたので Dev Drive を設定してみた。

Set up a Dev Drive on Windows 11 | Microsoft Learn
- よくわかってないが Dev Drive は ReFS を採用している。 Resilient File System (ReFS) overview | Microsoft Learn
Dev Drive のところにも載ってるが、 NuGet の cache などの directory について
- How to manage the global packages, HTTP cache, temp folders in NuGet | Microsoft Learn

Windows の UI から設定する。サイズは 256 GB にした。

Dev Drive の文書の NuGet の箇所をもとに cache などを Dev Drive に設定する。

> dotnet nuget locals all --list
http-cache: C:\Users\takatoshi\AppData\Local\NuGet\v3-cache
global-packages: C:\Users\takatoshi\.nuget\packages\
temp: C:\Users\takatoshi\AppData\Local\Temp\NuGetScratch
plugins-cache: C:\Users\takatoshi\AppData\Local\NuGet\plugins-cache

環境変数で設定できる様子。

setx NUGET_PACKAGES D:\nuget\packages
setx NUGET_HTTP_CACHE_PATH D:\nuget\http-cache\v3-cache

npm 等も Dev Drive の文書をもとに設定する。

> npm config get cache
C:\Users\takatoshi\AppData\Local\npm-cache
> npm config set cache D:\npm-cache --global

ついでに仕事用 laptop も Dev Drive 設定してみた。私物では使ってないが仕事で使う Yarn も Dev Drive を使わせてみた。

> setx YARN_CACHE_FOLDER D:\yarn-cache

仕事でよく利用する nektos/act, AWS CDK, OpenAI Codex とかも cache があるのだけど、今は設定してない。今回は cache だけ Dev Drive を使わせたが、 node_modules のような小さいファイルが大量にあるものは、本当は repo 丸ごと Dev Drive 配置がベストっぽい。だけど今はなんとなくやらなかった。

仕事で使う場合だと、 PHP と TypeScript を Docker で動かすため、 bind mount では ReFS の良くないところが目立つようなので中々手出しできなと思った。一般的にこのようなユースケースでは WSL2 側で git clone するのが良いようだが、 ghq で管理してるのもありやってない。

ここまでの Dev Drive の設定自体は何も困らなかった。ただ設定後に dotnet tool restore しても tool が見つからない状態になって、非常に困った。原因は以下のように dotnet tool の問題みたい。

'Dotnet tool restore' does not work correctly when NUGET_PACKAGES (global-packages) is set to an alternative location · Issue #11432 · dotnet/sdk

$env:USERPROFILE\.dotnet\toolResolverCache にある dotnet tool の path が cache されてるらしい。 cache を消去しないと dotnet tool が Dev Drive の path を見ず、正しい restore が行われない。やば。

確認してみたら中にはこういう cache があって path が古いままだった。

[{"Version":"5.0.0-alpha.22","TargetFramework":"net10.0","RuntimeIdentifier":"any","Name":"fable","Runner":"dotnet","PathToExecutable":"C:\\Users\\takatoshi\\.nuget\\packages\\fable\\5.0.0-alpha.22\\tools/net10.0/any/fable.dll"},{"Version":"5.0.0-alpha.23","TargetFramework":"net10.0","RuntimeIdentifier":"any","Name":"fable","Runner":"dotnet","PathToExecutable":"C:\\Users\\takatoshi\\.nuget\\packages\\fable\\5.0.0-alpha.23\\tools/net10.0/any/fable.dll"}]

cache を消す。

rm $env:USERPROFILE\.dotnet\toolResolverCache

この後 dotnet tool restore したらきれいに cache が再生成され、 Dev Drive を見るようになる。

これを自力で解決するのは難しいな。 AI は素っ頓狂なことを言うし、自力でググってよかった。 dnx ならこれが起こらんらしいが仕組みが違うっぽい。試してないのでわからん。

Dev Drive に変えてみて特に性能面で優れた点をまだ感じてないが、今後のデフォみたいだし徐々に利用範囲を広めたい所存。

Windows の Smart App Control を無効にする

Sun, 22 Feb 2026 09:00:00 +0900

ある日 ghq がブロックされた。

> ghq
ResourceUnavailable: Program 'ghq.exe' failed to run: An error occurred trying to start process 'C:\Users\takatoshi\go\bin\ghq.exe' with working directory 'C:\Users\takatoshi'. An Application Control policy has blocked this file.At line:1 char:1
+ ghq
+ ~~~.

event log 全文。

> Get-WinEvent -LogName "Microsoft-Windows-CodeIntegrity/Operational" | ? -Property Message -like '*ghq.exe*' | Select-Object -First 1 | % Message
Code Integrity determined that a process (\Device\HarddiskVolume3\Program Files\PowerShell\7-preview\pwsh.exe) attempted to load \Device\HarddiskVolume3\Users\takatoshi\go\bin\ghq.exe that did not meet the Enterprise signing level requirements or violated code integrity policy (Policy ID:{0283ac0f-fff1-49ae-ada1-8a933130cad6}).

さっぱりわからんかったが、 Windows 11 の Smart App Control という機能らしい。署名されてないアプリを全殺しするみたい。わたしは Go 系の tool は GitHub 直で local build しているのでそのせい。新しい laptop を使い始めて、最初の期間は評価モードで、その後 Windows Updates かなんかを機に強制モードとなり、ブロックされるようになったようだ。怖。

Go のバイナリ以外にも local で build してるものは全て使えなくなってると想像され面倒極まりないので、開発者には向いてないと判断した。決まった directory を除外するとかの細かいルールを定めるのも億劫なので、やることは定まってくる。除外ルール設定せず Privacy & security > Windows Security > App & browser control で Smart App Control を無効化する。これまでは一度 Off にすると clean install するまで再度 On にできなかったそうだが、 2026-02 の更新プログラムで再度有効できるよう修正された様子。そうならば一旦 Off にするのに何の躊躇もなく行えるので、無効にした。

久し振りに困った。非エンジニア向けの機能らしいが、めちゃくちゃ面倒な機能だな。いまでは Windows にも開発者向け機能の設定画面があるのだし、そこで設定できれば楽なのに。

F# の PowerShell Module の Template を作りたい Part 3

Sun, 15 Feb 2026 09:00:00 +0900

krymtkts/FsPowerShellTemplate の開発をした。 Cmdlet, Command-line predictor, Feedback Provider の相互の連携を作り、 task runner の整備をした。

ICommandPredictor と IFeedbackProvider を別 class で実装してるので、状態の共有を別の class を経由する必要がある。この場合は、コードの中枢を module に抽出するのが良い。 Core とした。 Cmdlet, Command-line predictor, Feedback Provider はそれを参照する薄い実装のみに留めるのが良いだろう。

Core がこんな感じ。

namespace SampleModule

open System.Threading
open System.Collections

module Core =
    type GreetingStore() =
        [<Literal>]
        let dirtyFlag = 1

        [<Literal>]
        let cleanFlag = 0

        let gate = obj ()
        let names = Generic.List<string>()
        let mutable dirty = cleanFlag

        member __.Add(name: string) =
            lock gate (fun () ->
                name |> names.Add
                dirty <- dirtyFlag)

        member __.Get() : seq<string> =
            lock gate (fun () ->
                // NOTE: Return a snapshot to avoid enumeration issues with concurrent updates.
                names |> Seq.toArray :> seq<string>)

        member __.Count() : int = lock gate (fun () -> names.Count)

        member __.Remove(name: string) =
            lock gate (fun () ->
                if name |> names.Remove then
                    dirty <- dirtyFlag)

        member __.ConsumeUpdated() : bool =
            Interlocked.Exchange(&dirty, cleanFlag) = dirtyFlag

    let greetingStore = GreetingStore()

Command-line predictor (長いので一部端折る) なんか今見てみたら GetSuggestion の実装がイマイチなのでより simple に直した方が良さそう。 OnSuggestionAccepted を呼ばせるには CanAcceptFeedback で true を返す必要がある。また suggestion に mini session ID も含ませていないと呼ばれなかった。これらの情報は多分 sample には載ってないのよね。 interface の説明¹²等からこの挙動を拾ったのだけど、他の文書に書いてないのかな。

// 略

type GreetingPredictor(guid: string) =
    let id = guid |> Guid.Parse

    let mutable miniSessionId = 0
    // 略

    interface ICommandPredictor with
        // 略

        member __.GetSuggestion
            (client: PredictionClient, context: PredictionContext, cancellationToken: CancellationToken)
            : SuggestionPackage =

            let suggestions =
                context.InputAst.Extent.Text
                |> function
                    // NOTE: suggestionEntries requires non-empty by Requires.NotNullOrEmpty.
                    // https://github.com/PowerShell/PowerShell/blob/eef334de1b0f648512859bd032356f9c8df7cb91/src/System.Management.Automation/engine/Subsystem/PredictionSubsystem/ICommandPredictor.cs#L278
                    | input when input |> String.IsNullOrWhiteSpace -> Seq.empty
                    | input ->
                        greetingStore.Get()
                        |> Seq.choose (fun name ->
                            if name.Contains(input, StringComparison.OrdinalIgnoreCase) then
                                PredictiveSuggestion(
                                    $"{suggestionPart1}{name}{suggestionPart2}",
                                    "A friendly greeting from F#!"
                                )
                                |> Some
                            else
                                None)
                |> Linq.Enumerable.ToList

            // NOTE: empty suggestionEntries is rejected by PowerShell's internal validation.
            if suggestions.Count = 0 then
                Unchecked.defaultof<SuggestionPackage>
            else
                // NOTE: SuggestionPackage must include a mini-session id; PowerShell uses it when calling OnSuggestionDisplayed/OnSuggestionAccepted.
                let session = Threading.Interlocked.Increment(&miniSessionId) |> uint32
                SuggestionPackage(session, suggestions)

        member __.CanAcceptFeedback(client: PredictionClient, feedback: PredictorFeedbackKind) : bool =
            DebugLogger.WriteLine $"CanAcceptFeedback: Feedback kind: {feedback}"

            // NOTE: to capture events, must be return true for expected feedback kinds.
            feedback = PredictorFeedbackKind.SuggestionAccepted

        // 略

        member __.OnSuggestionAccepted(client: PredictionClient, session: uint32, acceptedSuggestion: string) : unit =
            DebugLogger.WriteLine $"OnSuggestionAccepted: Accepted suggestion: {acceptedSuggestion}"

            let matches = acceptedSuggestion |> greetingPattern.Match

            if matches.Captures.Count = 1 then
                let removal = matches.Groups.["removal"].Value
                removal |> greetingStore.Remove
                DebugLogger.WriteLine $"OnSuggestionAccepted: Removed greeting for: {removal}"

        // 略

Feedback Provider は、多分既定では GetFeedback の引数 context³ をこねくり回して前の実行の文脈から処理対象を選び出すとかを想定されてる。ただ Cmdlet, Command-line predictor, Feedback Provider の連携が必要な場合はそれだと役に立たない。なので状態の共有が結果的に一番 simple になる。 template 用の sample 実装では global な状態を持たせてるから、同じ PowerShell session の中でだけ状態が共有される。 session をまたいで共有させたい場合は krymtkts/SnippetPredictor のように PowerShell の外の世界に永続化しないといけない。

// 略

type GreetingFeedbackProvider(guid: string) =
    // 略

    interface IFeedbackProvider with
        // 略
        member __.Trigger: FeedbackTrigger = FeedbackTrigger.Success

        member __.GetFeedback(context: FeedbackContext, token: Threading.CancellationToken) : FeedbackItem | null =
            DebugLogger.WriteLine "GetFeedback: Checking for feedback provision."

            // NOTE: Provide feedback only when there is an update.
            // NOTE: Using the greeting store directly here for simplicity and context does not provide suggestion acceptance status.
            if greetingStore.ConsumeUpdated() then
                let header = "Greeting Feedback"

                FeedbackItem(
                    header,
                    [ $"You have {greetingStore.Count()} greetings stored."
                      "Thank you for using the Greeting Predictor!" ]
                    |> Generic.List<string>,
                    "Feedback for the Greeting Predictor",
                    FeedbackDisplayLayout.Portrait
                )
            else
                null

改めて Command-line predictor が中枢だと思った。 Feedback Provider は、言葉は悪いが Command-line predictor に添えるアクセントのようなものというのが現状だろう。 Feedback Provider が登場したのは 2023 年の PowerShell 7.4 だが、いまのところ今後も残り続けるのかがよくわからん機能でもある。コミュニティもなんとなく使い所がよくわからない機能として扱ってる気もする(それは Command-line predictor も同じ話だが)。 Feedback Provider の GitHub Project はあるようだが 2026-02-15 時点で大きな動きはなさそう。 community が feedback しても先に進まん的な雰囲気があるのかも知れない。 Main · Feedback Provider Roadmap

もしかしたら community call に参加してたらなんかわかるのかな？そんな感じには思えないのだけど。

Command-line predictor, Feedback Provider は binary module なので、試した感じでは PowerShell だけで完結してサクッと書けない。 C# なり F# なりで書く必要があるから、それもあって feedback が集まりにくい状況になっているのかもな。実際、実装自体は ICommandPredictor と IFeedbackProvider を 1 つの class に実装すれば状態共有も単純だ。なので PowerFighter(PowerShell 使いの自作の造語) の言語をまたぐ心理的なハードルだけが普及の課題なんやろう。

ハードルを超えて Command-line predictor を書けば、結構いい感じに PowerShell 統合された追加機能を作れる。でも Feedback Provider はコマンド実行後の表示を賑やかすだけなので、あえて付ける必要があるかというのがこれまた難しい。

何にせよ実際に書いてみないと使い所や問題点もイメージできなかったし、今回書いてよかった。まだ廃止にもなってないし、自作 PowerShell module にも使ってみようと思っている。採用した後で廃止となれば、撤退作業のような普段経験しにくい作業も体験できるかも知れないし、やっておく経験が損になることはないかな。

あと task runner 。今回から psake じゃなく nightroman/Invoke-Build を使うようにした。 psake/psake は名前が最高だが parameter を渡すのはちょっと面倒だし、 Invoke-Build でならそのへん simple に改善できそうだったためだ。

build script の名は Invoke-Build の流儀に合わせ build.ps1 とした。 build script 直で呼んだ場合に Invoke-Build で起動し直す。 build script で呼べるので parameter 補完を PowerShell の仕組みに寄せた感じ。 parameter の一部を $Task としてたら予約されておりエラーになったので、そこだけ別名にしたため詰め直しが必要だった。使用感はなかなか良い。

<#
.Synopsis
    Invoke-Build tasks
#>

# Build script parameters
[CmdletBinding()]
[Diagnostics.CodeAnalysis.SuppressMessageAttribute('PSUseDeclaredVarsMoreThanAssignments', '', Justification = 'Variables are used in script blocks and argument completers')]
param(
    [Parameter(Position = 0)]
    [ValidateSet('Init', 'Clean', 'Lint', 'Build', 'Import')]
    [string[]] $Tasks = @('Build'),

    [ValidateSet('Debug', 'Release')]
    [string] $Configuration = 'Debug'
)

# If invoked directly (not dot-sourced by Invoke-Build), hand off execution to Invoke-Build.
if ($MyInvocation.InvocationName -ne '.') {
    $forward = $PSBoundParameters.GetEnumerator() | ForEach-Object -Begin { $acc = @{} } -Process {
        Write-Host "Processing parameter: ${_}" -ForegroundColor Yellow
        if ($_.Key -ne 'Tasks') {
            $acc[$_.Key] = $_.Value
        }
    } -End { $acc }
    Invoke-Build -File $PSCommandPath -Task $Tasks @forward
    exit $LASTEXITCODE
}

# 略

まだ Invoke-Build 準拠の help とか書いてない。けどなくてもいいかもしれんな。

あとは sample module の unit test や end-to-end test 、 documentation あたりを整備すれば一通りそろうかな。そしたらまず GitHub の template repository 化しよう。

F# の PowerShell Module の Template を作りたい Part 2

Sun, 08 Feb 2026 09:00:00 +0900

ようやく重い腰を上げて PowerShell Module を F# で書くときの template を作り始めた。 repository name は krymtkts/FsPowerShellTemplate にした。まだ完成してないから template repository にはしてない。

命名はちょっと気を使った。先頭に FSharp とか PowerSHell は持ってくるべきではないだろうし、個人の識別子が入るのも微妙だ。それでいて将来的に PowerShell Module 以外が含まれる可能性も考慮したうえで、いつか NuGet で template 配布するというのも考えて、今の形に。略称の Fs なら多少カジュアル感出るし、多分いい落とし所なはず。 Scaffold も考えたが、 NuGet では Template が一般的なのを考えたらそっちの方が見つけやすくなる。 NuGet の慣習的な dot 区切りだけはやめたが、それは repository name と合わせたくての妥協点だ。でも気が変わったら変える可能性ある。

ひとまず template の設計としては、 Cmdlet, Command-line predictor, Feedback provider を 1 つの project に同梱する。そしてこれらの連携が真骨頂なので、それの sample として十分な例を示しておけたらなと考えている。まだ作ってないけど。これらを無効にする術としては、ひとまずはコードを消すことで実現したらいいかなと考えている。そのため Cmdlet, Command-line predictor, Feedback provider が別ファイルで実装される。今はやってないけど連携のコアの部分も別ファイルで作る。そうすれば Feedback provider や Command-line predictor が不要ならファイルごと消せる感じということになる。これで自分が新しく作るときもそのテンプレに従って書くだけなのでかなり楽なのでは？と期待している。

と作り始めたもののなんだか花粉症かなと思ってたのが風邪っぽい？不調に変わってきたそんなに進んでない。でも Cmdlet, Command-line predictor, Feedback provider の作成まではやった。例にしてるのは何度も読んでる以下の文書。

Feedback provider は初めて作ったのだが、作ってみてこいつ単体の interface は simple なもんだというのに気づいた。上記文書の sample だと 1 つの class で Command-line predictor と Feedback provider の両方を実装してるのでゴチャついて見えるだけ。まだ Feedback provider の真髄である Command-line predictor や Cmdlet との連携を全くやってないので simple になっていると言うのもけど。いま template に実装したのは何とも連携してない Feedback provider で、それを参考として貼ると以下の通り。

FsPowerShellTemplate/src/SampleModule/FeedbackProvider.fs at 39cb16631a6cbc63812ba66ebff1a5b55290ed8e · krymtkts/FsPowerShellTemplate

namespace SampleModule

open System
open System.Collections
open System.Management.Automation.Subsystem.Feedback

type GreetingFeedbackProvider(guid: string) =
    let id = Guid.Parse(guid)

    [<Literal>]
    let name = "Greeting"

    [<Literal>]
    let description =
        "A feedback provider that handles feedback for the greeting predictor."

    interface IFeedbackProvider with
        member __.Id = id
        member __.Name = name
        member __.Description = description
        member __.FunctionsToDefine = null
        member __.Trigger: FeedbackTrigger = FeedbackTrigger.Success

        member __.GetFeedback(context: FeedbackContext, token: Threading.CancellationToken) : FeedbackItem | null =
            let header = "Greeting Feedback"

            FeedbackItem(
                header,
                [ "Was the greeting helpful?"; "Did you like the style of the greeting?" ]
                |> Generic.List<string>,
                "Feedback for the Greeting Predictor",
                FeedbackDisplayLayout.Portrait
            )

文書に載ってる sample でもわかるように、 GetFeedback が Feedback provider のコア。この中で FeedbackContext の結果に応じて処理を分ける等するのが期待されるので、とっ散らからないよう別の型に処理をまとめるなどが必要だろうな。

とりままだ連携機能を作ったワケではないので完全ではないけど、 Feedback provider を作った。これで作ったことがなかったものは 1 つクリアしたわけだ。作ってみていて、こういう Feedback provider の使い方はアリかもしれんな、とかアイデアの片鱗も掴めてた気がする。実際に実装してみるというのはやっぱり重要やな。

とりま連携部分とかの残りのタスクを進めるつもり。そんで今の一番の悩みは task runner を何にするか。長らく psake/psake を使ってるが nightroman/Invoke-Build も使ってみたい。 psake は名前が最高だが parameter を渡すのはちょっと面倒なのがなあ。あと fsprojects/FAKE を使うという手もある。でも fsx から PowerShell 呼ぶってのもどうなんかなあという気がするよな。楽しい悩みや。

HP OMEN Transcend 14 買った

Sun, 01 Feb 2026 09:00:00 +0900

従来機 Raze Blade Stealth 2017 も随分古く遅くなったし、昨今のメモリ高騰もあるしで、久し振りに laptop を新調した。購入したのは HP OMEN Transcend 14 の OMEN by HP Transcend 14-fb1011TX スプリームモデル G2 というやつ。セールでも 38 万円ほどした。なかなかの出費だ。主要な Spec は以下の通り。

Intel Core Ultra 9 285H (max 5.40GHz, cache 24MB)
14.0 inch 2.8K OLED
RAM 64GB (LPDDR5x-7467MT/s)
2TB PCIe Gen4 NVMe M.2 SSD TLC
NVIDIA GeForce RTX 5070 Laptop

この機種は GPU の消費電力が制限されておりフルパワーが出せなかったり、 13 inch が好きなので 14 inch はちょっと大きいとか色々気になる点はあった。 64GB の大容量メモリだと AMD Ryzen AI Max+ 395 が載った ROG Flow Z13 (2025) GZ302 もいいなと思っていた。でもいくら驚異的に速い integrated GPU を搭載しているからと言って、 UWQHD のような高解像度だと現時点では discrete GPU には叶わないのが調べてわかった。次買い替えるときには状況はわかってるかもだが、今久し振りにゲームもするならもうええかということで HP OMEN Transcend 14 にした。理想としては laptop のヒンジが 180 °開く機種を選びたかったのだけど、これも妥協点の 1 つ。ただ総じて Spec は高いので、従来機に比べて現時点極めて高速で満足している。

しかし Microsoft アカウントの気に入らない仕様を回避するのには苦労した。 Windows 11 では初期設定時の Microsoft アカウントのログインは諸々の設定が同期されるので極めて楽だが、代償として username がアカウントメアド先頭 5 文字になってしまう。 takatoshi~ が takat に。なんでなんだよ。仕事では面倒でそのまま気にせず使ってるが、私用機ではこれは許容しがたい。回避方法としてはネットワークを使わずに初期設定すれば local user を作って始めれるようなのだが、うっかり忘れて Wi-Fi に繋いでしまった。一度 Wi-Fi に繋いだあとどうやって解除するかわからなかったので、ひとまず Microsoft アカウントで初期設定したのだが、これが良くなかった。

初期設定後、 Microsoft アカウントの user を local user に変更、期待の名前の local user を作成し Microsoft アカウントに関連付けた。ここで Windows Hello の設定が成功しなかったり設定や OneDrive の同期が機能しなくなった。既存 user に設定していた Windows Hello と PIN の設定を外してもうまくいかなかったので一晩寝かしたところ、うまくいく様になった。クラウド側でキャッシュされてたのかな。

OneDrive の同期だけは全く解消されなかったので、 AI とトラシューの上別の端末として管理されてしまったのかもなと考えて既存 user に連携済みファイルを移動してみた。ここで急に同期が始まり Copy という suffix を持つ同じファイルが OneDrive にできてしまった... Copy 側を全部消して一旦同期済みになった。 Windows の設定が同期されないのはかなり痛いが、調べつつ個別に設定していった。

アプリケーション類のインストールは winget Chocolatey を使った。知らなかったのだが、昨今の Windows は winget がプリインストールされておりはじめから使える。初回の script での package manager をインストールする手間が省ける。今回は元々 winget で管理している package と Chocolatey を winget で、その他を Chocolatey でインストールした。 script 形式で配布されるアプリケーションはまだ winget ではインストールできないのもあるし、元々使ってるアプリケーションも Chocolatey で管理している。が、 winget も package が拡充され使用感が良くなってるようなので、 binary 系は winget に寄せるのもいいのかもな。

処理系と依存関係の設定、 Context menu 置き換え等の Registry 書換は自前の PowerShell Profile krymtkts/pwsh-profile で自動化している。 winget でも取れないアプリケーション、例えば Windows Terminal Canary は profile で自動化している。

あと今回から OneDrive で設定、 backup 、自作フォントを同期して使ってみた。旧 laptop で雑に管理されたファイルが新 laptop にも引き継がれてしまう点は懸念だが、移行はかなり楽になった。この方法なら Stylus の user CSS を OneDrive に出力しておけば Google Chrome でも Edge でも両方使えて便利だ。 dotfiles のうち sensitive な一部は OneDrive で同期してコピペした。 PowerToys も backup を OneDrive に出力し restore する方法を採用した。ただ例えば Command Palette のような一部の設定は出力されなかったようで、そこは手で変更している。

GnuPG の鍵束を移行するのにも手間取った。鍵束の移行は始めたやったのでコピペでやったのだけど、所有権の違いでエラーになって使えなかった。結局コピペは推奨されない方法ではあるものの、所有権を移せば利用できるようなので、今回はそれでしのいだ。

# 管理者権限で
gpgconf --kill all
# backup の `gnupg` を `$env:APPDATA/gnupg` に配置
takeown /F $env:APPDATA\gnupg /R /D Y
icacls $env:APPDATA\gnupg /reset /T
icacls $env:APPDATA\gnupg /inheritance:r
icacls $env:APPDATA\gnupg /grant:r takatoshi:F /T

これで多分全て設定終わってるはず。まだ微妙に痒いところが残ってるけど、それは追々調整していくものとする。

結局 1 月は対して開発もせずに過ごしたので、 2 月はもうちょい開発したいな。

F# の PowerShell Module の Template を作りたい

Sun, 01 Feb 2026 09:00:00 +0900

今年やったことないものに取り組むのを、何にしようかなと考えていた。結局 PowerShell の Feedback provider 辺りがいいかなと決定した。

ただ Feedback provider の本当の魅力は Command-line predictor との連携なんやが、何を連携させるかのアイデアがない。とはいえ F# で Feedback provider を書く変わり者もそういないし、それだけでも作る価値あるような気もしている。なもんで何を実装するのかのアイデアを決めるまでの場繋ぎが必要になった。

Feedback provider を作るだし、せっかくなので Template を作ってみよう思っている。 F# で作る PowerShell の Cmdlet, Command-line predictor, Feedback provider の Template だ。これまでコピペで作ってたしちょうどいいわ。

これを GitHub の Template にするのか NuGet の Template にするのかが悩ましかったので、 AI に聞いた。 ChatGPT に相談した感じだと、はじめは GitHub Template repository で型を作る。その後に NuGet の Template で簡単に展開できる版にできるぞということなので、それで行く。対応言語は F# のみ。自分が使うからな。参照するのは以下の文書かな。

Feedback provider と NuGet の Template は作ったことないが、他は作ったことある。始めやすく Cmdlet -> Command-line predictor -> Feedback provider -> NuGet Template の流れで作ったらいいかな。その内に Feedback provider が必要な機能のヒントを得られているかも知れない。

PowerToys CLI を使ってみる

Sun, 25 Jan 2026 09:00:00 +0900

PowerToys 0.97 is here: a big Command Palette update and a new mouse utility - Windows Command Line

In the last release we added CLI support for Peek, and we’re expanding that even further. FancyZones, Image Resizer, and File Locksmith can now all be controlled from the command line. Whether you want to switch layouts, resize a batch of images, or unlock files, it’s all possible through the CLI. Be sure to check the docs for the full list of supported commands.

どうも Fancy Zones とかを CLI 経由で呼べるようになったぽいのよね。想像通りであれば起動 script として有用なのか判断するため調査したい。

調べてみたら 0.97.0 から CLI 専用の実行ファイル FancyZoneCli.exe FileLocksmithCLI.exe が生えて、それを経由して使えるってことみたい。 PowerToys.ImageResizerCLI.exe と PowerToys.Peek.UI.exe は見当たらなかった。使ってないからなのか、謎。

> ll $env:ProgramFiles -filter *powertoys* | ll -Filter *CLI.exe

        Directory: C:\Program Files\PowerToys


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a---        2026-01-19     12:07         166984 󿬔  FancyZonesCLI.exe
-a---        2026-01-19     12:07         726560 󿬔  FileLocksmithCLI.exe

因みに上記 ll を Get-ChildItem の alias にしてる。

> Get-Alias ll

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Alias           ll -> Get-ChildItem

場所はわかったが、ここには大量のファイルがあるので Path を通したくない感じ。

> ll $env:ProgramFiles -filter *powertoys* | ll | measure

Count             : 703
Average           :
Sum               :
Maximum           :
Minimum           :
StandardDeviation :
Property          :

ひとまず cd して使ってみることにする。早速 Fancy Zones を試す。

> ./FancyZonesCLI --help
FancyZones CLI - Command line interface for FancyZones

Usage: FancyZonesCLI [command] [options]

Options:

Commands:
  open-editor, e                 Launch FancyZones layout editor
  get-monitors, m                List monitors and FancyZones metadata
  get-layouts, ls                List available layouts
  get-active-layout, active      Show currently active layout
  set-layout <layout>, s         Set layout by UUID or template name
  open-settings, settings        Open FancyZones settings page
  get-hotkeys, hk                List all layout hotkeys
  set-hotkey <key> <layout>, shk Assign hotkey (0-9) to a custom layout
  remove-hotkey <key>, rhk       Remove hotkey assignment

Examples:
  FancyZonesCLI --help
  FancyZonesCLI --version
  FancyZonesCLI get-monitors
  FancyZonesCLI set-layout focus
  FancyZonesCLI set-layout <uuid> --monitor 1
  FancyZonesCLI get-hotkeys

参照系だけ使ってみるか。

> ./FancyZonesCLI get-layouts
=== Built-in Template Layouts (6 total) ===

[T1] blank
    Zones: 0

    Visual Preview:
    (No zones)

[T2] focus
    Zones: 3

    Visual Preview:
    +-------+
    |       |
    | +-------+
    +-|       |
      | +-------+
      +-|       |
        ...
        (total: 3 zones)
        ...
        | +-------+
        +-|       |
          |       |
          +-------+

[T3] columns
    Zones: 3, Spacing: 16px

    Visual Preview:
    +---------+---------+---------+
    |         |         |         |
    |         |         |         |
    |         |         |         |
    |         |         |         |
    |         |         |         |
    |         |         |         |
    |         |         |         |
    +---------+---------+---------+

[T4] rows
    Zones: 3, Spacing: 16px

    Visual Preview:
    +-----------------------------+
    |                             |
    +-----------------------------+
    |                             |
    +-----------------------------+
    |                             |
    +-----------------------------+

[T5] grid
    Zones: 2

    Visual Preview:
    +--------------+--------------+
    |              |              |
    |              |              |
    |              |              |
    |              |              |
    |              |              |
    |              |              |
    |              |              |
    +--------------+--------------+

[T6] priority-grid
    Zones: 3, Spacing: 16px

    Visual Preview:
    +---------+---------+---------+
    |         |         |         |
    |         |         |         |
    |         |         |         |
    |         |         |         |
    |         |         |         |
    |         |         |         |
    |         |         |         |
    +---------+---------+---------+


=== Custom Layouts (1 total) ===
[1] Cockpit
    UUID: {04599F6F-0BB0-46DF-9809-2E631E026DBC}
    Type: grid (1x2 grid)

    Visual Preview:
    +---------------------------------------+
    |                   |                  |
    |                   |                  |
    |                   |                  |
    |                   |                  |
    |                   |                  |
    |                   |                  |
    |                   |                  |
    |                   |                  |
    |                   |                  |
    |                   |                  |
    |                   |                  |
    |                   |                  |
    +---------------------------------------+

Use 'FancyZonesCLI.exe set-layout <UUID>' to apply a layout.

ほー。なんか人間が目で見て判断する系の出力してる。自動化には向かなそう。 (Monitor Instance と Serial Number 等、一部の情報は伏せる)

> ./FancyZonesCLI get-monitors
=== Monitors (2 total) ===

Monitor 1:
  Monitor: SHP1493
  Monitor Instance: XXXXXXXXXXXXXXXXXXXXXX
  Monitor Number: 1
  Serial Number: XXXXXXXXXXXX
  Virtual Desktop: {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
  DPI: 192
  Resolution: 1600x900
  Work Area: 1600x900
  Position: (0, 0)
  Selected: False

  Active Layout: blank
  Zone Count: 0
  Sensitivity Radius: 0px
  Layout UUID: {2205FD22-B38D-4BA9-9550-2E59F6298B91}

Monitor 2:
  Monitor: DELA0F4
  Monitor Instance: XXXXXXXXXXXXXXXXXXXXXX
  Monitor Number: 2
  Serial Number: XXXXXXXXXXXX
  Virtual Desktop: {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
  DPI: 96
  Resolution: 3840x1600
  Work Area: 3840x1600
  Position: (-332, -1600)
  Selected: True

  Active Layout: custom
  Zone Count: 3
  Sensitivity Radius: 20px
  Layout UUID: {04599F6F-0BB0-46DF-9809-2E631E026DBC}

> ./FancyZonesCLI get-active-layout

=== Active FancyZones Layout(s) ===

Monitor 1: SHP1493
  Layout UUID: {2205FD22-B38D-4BA9-9550-2E59F6298B91}
  Layout Type: blank
  Zone Count: 0
  Sensitivity Radius: 0px

Monitor 2: DELA0F4
  Layout UUID: {04599F6F-0BB0-46DF-9809-2E631E026DBC}
  Layout Type: custom
  Zone Count: 3
  Spacing: -1px
  Sensitivity Radius: 20px

> ./FancyZonesCLI get-hotkeys
=== Layout Hotkeys ===

Press Win + Ctrl + Alt + <number> to switch layouts:

  [0] => {04599F6F-0BB0-46DF-9809-2E631E026DBC}

わたしの想像力が欠如してるのかも知れんが、これいまだとできることあんまないなという感じがした。指定の window を layout 内の何番の位置に飛ばすとかができたらいいかなと思ってたのだけど、そういうのは今ないみたい。個人的には UWQHD 使ってるのもあり Fancy Zones の使い方として起動後に layout を切り替えることもないから、今提供されている CLI 機能はほぼ使わんな。そういう細かな位置の調整は起動時に Workspaces でやってくれよってことなんかな。なんかいまいち同一アプリ複数 window を使いこなせなくて使ってないねんよな Workspaces 。

File Locksmith も見てみる。

> ./FileLocksmithCLI --help
Usage: FileLocksmithCLI.exe [options] <path1> [path2] ...
Options:
  --kill      Kill processes locking the files
  --json      Output results in JSON format
  --wait      Wait for files to be unlocked
  --timeout   Timeout in milliseconds for --wait
  --help      Show this help message

コッチは subcommand 形式じゃないんかい。でも --json があるお陰で使いやすくはあるか。試しに、 Desktop に転がってた PDF を開いて lock の状況を出してみる。

> ./FileLocksmithCLI ~/OneDrive/Desktop/sample.pdf --json
{"processes":[{"pid":3100,"name":"Acrobat.exe","user":"takatoshi","files":["C:\\Users\\takatoshi\\OneDrive\\Desktop\\sample.pdf"]}]}

> ./FileLocksmithCLI C:\Users\takatoshi\OneDrive\Desktop\sample.pdf --json | ConvertFrom-Json | % processes

 pid name        user      files
 --- ----        ----      -----
3100 Acrobat.exe takatoshi {C:\Users\takatoshi\OneDrive\Desktop\sample.pdf}

File Locksmith は Fancy Zones に比べて楽に PowerShell と連携できそう。ただ普段 File Locksmith のお世話にあんまならんからそんなに使わないだろうな。

取り敢えずざっと見てみてすぐ使いそうなものはないかな～という感覚は得た。 autocomplete を出力する option なんかもないから、使うなら自前で補助してやる必要がある。ひとまずは適当な wrapper function を PowerShell の profile に仕込んでおくとかはやってもいいかもな。

Windows の GnuPG と Gpg4Win の連携

Sun, 18 Jan 2026 09:00:00 +0900

つい先日 git commit したとき GnuPG での commit sign が通らなくなったので、その解消方法をログに残す。

まず前提を整理する。実際のところ commit sign するだけなら GnuPG だけでも良い。けど、 passphrase を入力する window が味気なく masking 解除できないのも好かんので、 Gpg4Win の pinentry.exe を使ってた。理想は pinentry-mode loopback で CLI 入力するのが好きだ。ただ Visual Studio Code と一緒に使うと支障があり、 Gpg4Win の pinentry.exe に落ち着いてた。

GnuPG と Gpg4Win はそれぞれ Chocolatey で入れてる。初回 install は以下のような感じだ。

choco install gnupg gpg4win

この構成で使っていて、まず年末年始頃に choco upgrade all -y したあと commit sign できなくなった。細かく調べてないが、どうも GnuPG 2.5 系になったため GPG の path が変わったからっぽい。

そのため ~/.gitconfig で指定する gpg の path を変更する必要があった。

[gpg]
 # program = C:\\Program Files (x86)\\gnupg\\bin\\gpg.exe
 program = C:/Program Files/GnuPG/bin/gpg.exe

それでも以下のように sign できなかった。 FC536D8DE73F2424 は GitHub で使ってるわたしの GPG Key ID だ。

> git commit -m 'Add a new post'
error: gpg failed to sign the data:
gpg: skipped "FC536D8DE73F2424": No secret key
[GNUPG:] INV_SGNR 9 FC536D8DE73F2424
[GNUPG:] FAILURE sign 17
gpg: signing failed: No secret key
fatal: failed to write commit object

今思えば Gpg4Win が GnuPG 2.5 系に追いついてなかったからなのだろうけど、 pinentry.exe が見つからなくなってるってのまでは理解できた。なので gpg-agent.conf で pinentry.exe が見つかるように指定してやれば解消できる。

cat $env:APPDATA/gnupg/gpg-agent.conf

default-cache-ttl 86400
max-cache-ttl 86400

pinentry-program C:\Program Files (x86)\Gpg4win\bin\pinentry.exe

これで pinentry.exe が見つかるようになり、 commit sign できるようになった。

ついでに、今までのように commit 時に passphrase を入力するようにしてたら、 GnuPG と Gpg4Win が繋がらなくなってた時の検知が遅れる。それは気になるので、 terminal 起動時に passphrase を cache するようにしてみた。

if (Get-Command -Name 'gpgconf' -ErrorAction SilentlyContinue) {
    gpgconf --launch gpg-agent | Out-Null
    # NOTE: open pinentry for caching passphrase.
    'warmup' | gpg --clearsign *> $null
}

これで一見落着したかに見えたが、後日 chocolatey で更新したらまた commit sign できなくなった。今度は Gpg4Win が 5 系に更新されて pinentry.exe の path が変わったからだ。 Program Files(x86) から Program Files に移ったようなので、一旦以下のように変えればいい。

default-cache-ttl 86400
max-cache-ttl 86400

pinentry-program C:\Program Files\Gpg4win\bin\pinentry.exe

gpg-agent を再起動して passphrase を cache し直せばいつも通りに戻る。

gpgconf --kill gpg-agent
gpgconf --launch gpg-agent | Out-Null
'warmup' | gpg --clearsign *> $null

ただこれだと pinentry.exe がどこに存在するかいちいちチェックしないといけない。なので PC 乗り換えのときに備えて gpg-agent.conf を更新するときに使う自前関数を更新し、 x86 でも x64 でも見つかるように修正した。

function global:Set-GPGConfig {
    $pinentryPath = ${env:ProgramFiles}, ${env:ProgramFiles(x86)} | ForEach-Object {
        $path = "${_}\Gpg4win\bin\pinentry.exe"
        if (Test-Path $path) {
            "pinentry-program ${path}"
        }
    } | Where-Object { $_ -ne $null } | Select-Object -First 1
    @"
default-cache-ttl 86400
max-cache-ttl 86400

$pinentryPath
"@ | Set-Content "$env:APPDATA/gnupg/gpg-agent.conf"

    # currently unused.
    @'
# loopback is not work with VS Code.
# VS Code hang up if you commit with signing.
# pinentry-mode loopback
'@ | Set-Content "$env:APPDATA/gnupg/gpg.conf"
}

これで一通り整った。

そもそも GnuPG と Gpg4Win が別々に入ってる構成が変な気もするので、そこを見直した方がいいのかもな。なんでこんな構成になってるのかも忘れてしまってるし。

Suave 3 のアクセスログ出力を Serilog でやる

Sun, 11 Jan 2026 09:00:00 +0900

以前 Suave 3 へ更新した際に Suave.Logging module がなくなった件に触れた。

あと今のところは Logging module がなくなって logger が使えなくなってた。 Logging がなくなったのは読み込まれたファイルのログが出なくなって dev server 的には地味に痛いのだが、ひょっとしたら別の方法で実現できたり復活の可能性もあるので、経過観測する。

それについて discussion に書かれてるのを見つけた。

v3.1.0 · SuaveIO/suave · Discussion #793

Everything should work pretty much the same way, the API hasn't changed significantly. For your logging needs you should use an alternative library like Serilog (https://serilog.net/).

標準の logger を積まなくなったので Serilog のような logging library を使えばいいらしい。 .NET の logging 事情は知らないので他に何があるか軽く調べた。 Microsoft.Extensions.Logging は標準に寄せるなら強いかなと思ったが、結果的に今は簡単さ重視で Serilog にした。 Serilog でも構造夏ログを使わないのであれば overkill な気がするけど広く使われていて利用も楽なので。といいつつ今後 Microsoft.Extensions.Logging に乗り換える可能性はある。

また、 Suave 2 の時と同じような logging をどう実装するかよくわからなかったので GitHub Copilot サンに聞いた。曰く、 simple にやるなら単に fish operator >=> で扱える WebPart を受けて返す関数を作ればいいらしい。

module Logging =
    open Serilog

    let logger =
        LoggerConfiguration()
            .MinimumLevel.Debug()
            .WriteTo.Console(
                outputTemplate = "[{Timestamp:yyyy-MM-dd HH:mm:ss.fff} {Level:u3}] {Message:lj}{NewLine}{Exception}"
            )
            .CreateLogger()

    let log (logger: ILogger) : WebPart =
        fun ctx ->
            async {
                logger.Information(
                    "HTTP {Method} {Path} -> {Status} {Reason}",
                    ctx.request.``method``.ToString(),
                    ctx.request.rawPath,
                    ctx.response.status.code,
                    ctx.response.status.reason
                )

                return Some ctx
            }

このような薄い module を拵えた。依存関係には Serilog と console 出力の実装である Serilog.Sinks.Console が要る。これで以下のように Suave 2 の頃と同じ様な使い方ができる。 Suave 2 利用時と比較するとこんな感じ。

-    let logger = Logging.Log.create "dev-server" // Suave 2 はこう

     choose [

-        path "/websocket" >=> handShake socketHandler
+        path "/sse" >=> EventSource.handShake sseHandler >=> Logging.log Logging.logger

         GET
         >=> Writers.setHeader "Cache-Control" "no-cache, no-store, must-revalidate"
         >=> Writers.setHeader "Pragma" "no-cache"
         >=> Writers.setHeader "Expires" "0"
         >=> choose [

             path $"/{root}/" >=> Files.browseFileHome $"{root}/index.html"
             path $"/{root}" >=> Redirection.redirect $"/{root}/"

             Files.browseHome

         ]
-        >=> log logger logFormat // Suave 2 はこう
+        >=> Logging.log Logging.logger

         Writers.setStatus HTTP_404
-        >=> logWithLevel Logging.Error logger logFormat // Suave 2 はこう
         >=> choose [
             Files.browseFileHome $"{root}/404.html"
             RequestErrors.NOT_FOUND "404 - Not Found" // NOTE: Fallback 404 page.
         ]
+        >=> Logging.log Logging.logger // TODO: ログレベルを指定できるようにする

     ]

この日記を書いてる最中にログレベル指定の対応忘れてるなと気付いたので後でやる。こんな感じのログ出力になる。

[2026-01-11 12:30:30.091 INF] HTTP GET /index.html -> 200 OK
[2026-01-11 12:30:30.189 INF] HTTP GET /pagefind/pagefind-ui.css -> 200 OK
[2026-01-11 12:30:30.198 INF] HTTP GET /css/style.css -> 200 OK
[2026-01-11 12:30:30.211 INF] HTTP GET /css/solarized-dark.min.css -> 200 OK
[2026-01-11 12:30:30.231 INF] HTTP GET /pagefind/pagefind-ui.js -> 200 OK
[2026-01-11 12:30:30.257 INF] HTTP GET /js/dev.js -> 200 OK
[2026-01-11 12:30:30.274 INF] HTTP GET /js/handler.js -> 200 OK
[2026-01-11 12:30:30.741 INF] HTTP GET /sse -> 200 OK

これでひとまず dev server のアクセスログも復活できて Suave 2 の頃と同様な使用感になった。

PowerShell Preview を使い始めた - PowerShell 7.6.0-preview.6

Sun, 11 Jan 2026 09:00:00 +0900

刺激を求めて PowerShell の Preview(v7.6.0-preview.6) を使うように変えた。 CLI での install には Chocolatey か WinGet が使える。ただ Chocolatey では prerelease で提供されてるので choco pin してないと choco upgrade all すると stable に落ちてしまう。これは面倒なので今回は winget を使うようにした。 install したときは PowerShell 7.6.0-preview.5 までしか winget の community repo に存在しなかった。でもタイミングよくすぐ更新されて PowerShell 7.6.0-preview.6 が降ってきた。以下のコマンドを実行すればよい。

winget install --id Microsoft.PowerShell.Preview

あと Windows Terminal でも GitHub Copilot Chat が使いたくて Canary に変えた。これは仕事用の PC では既に切り替えてあるので、そちらと合わせる意味もある。変えてからあんまり積極的に Windows Terminal で GitHub Copilot Chat を使ってるわけではないけど、いつも質問できる安心感的なのを得るためだ。

Windows Terminal Canary は chocolatey や winget では入れられない。なので自前で installer を download して起動するよう関数を profile に用意してる。いま単に installer を起動するだけにしてるが、どうも Add-AppxPackage が使えるみたい。それができたら installer の削除まで一貫して行えるので、次回試してみたい。コメントアウトしてるところがそれだ。

function Install-WindowsTerminalCanary {
    $installer = 'Microsoft.WindowsTerminalCanary.appinstaller'
    Invoke-WebRequest 'https://aka.ms/terminal-canary-installer' -OutFile 'Microsoft.WindowsTerminalCanary.appinstaller'
    Start-Process $installer
    # try {
    #     Add-AppxPackage -AppInstallerFile $installer
    # }
    # finally {
    #     Remove-Item $installer -Force -ErrorAction SilentlyContinue
    # }
}

PowerShell Preview に入れ替えたら、 Windows Terminal の profile にちょっと工夫が必要だった。 PowerShell の stable を入れてたときは "source": "Windows.Terminal.PowershellCore" だけで Preview を使えてた。けど stable を消したら認識しなくなってしまった。なので個別に指定する必要があるみたい。以下は GUI から操作して生成させたものなので、ひょっとしたら公式かどっかに落ちてる情報なのかな。

            {
                "colorScheme": "Solarized Dark - Patched",
                "guid": "{a3a2e83a-884a-5379-baa8-16f193a13b21}",
                "hidden": false,
                "name": "PowerShell 7 Preview",
                // "source": "Windows.Terminal.PowershellCore",
                "commandline": "\"C:\\Program Files\\PowerShell\\7-preview\\pwsh.exe\"",
                "icon": "ms-appx:///ProfileIcons/pwsh-preview.png",
                "startingDirectory": "%USERPROFILE%",
                "tabColor": "#001E27"
            },

Preview に入れ替えたせいか知らんが Get-ExperimentalFeature の出力が変わったような。最近見てなかったから定かではない。これまで更新してきた分の残骸かな？

> Get-ExperimentalFeature | Format-List

Name        : PSLoadAssemblyFromNativeCode
Enabled     : True
Source      : PSEngine
Description : Expose an API to allow assembly loading from native code

Name        : PSProfileDSCResource
Enabled     : False
Source      : PSEngine
Description : DSC v3 resources for managing PowerShell profile.

Name        : PSSerializeJSONLongEnumAsNumber
Enabled     : True
Source      : PSEngine
Description : Serialize enums based on long or ulong as an numeric value rather than the string
              representation when using ConvertTo-Json.

いま powershell.config.json に入ってるものは以下(整形済み)だった。随分多いな。

{
  "ExperimentalFeatures": [
    "PSFeedbackProvider",
    "PSCommandNotFoundSuggestion",
    "PSSubsystemPluginModel",
    "PSLoadAssemblyFromNativeCode",
    "PSNativeWindowsTildeExpansion",
    "PSSerializeJSONLongEnumAsNumber"
  ]
}

以下を見るに 7.5, 7.6 で mainstream になった feature が残ってたみたい。

Using Experimental Features in PowerShell - PowerShell | Microsoft Learn

experimental からなくなった feature は取り除いておいた。

最後に winget で管理してる application が増えたので更新のタイミングがわかりやすいよう profile に仕込んでみた。以下がこれまでに winget で入れるようになったもの。

Microsoft.OpenSSH.Preview
Microsoft.PowerShell.Preview
Microsoft.VisualStudioCode.Insiders

if (Get-Command Get-WinGetPackage -ErrorAction SilentlyContinue) {
    @(
        'Microsoft.VisualStudioCode.Insiders'
        'Microsoft.OpenSSH.Preview'
        'Microsoft.PowerShell.Preview'
    ) | ForEach-Object {
        $pkg = Get-WinGetPackage -Id $_
        if (($pkg -and $pkg.IsUpdateAvailable)) {
            Write-Warning "💡 Newer '${_}' is available. $($pkg.AvailableVersions | Where-Object {
                [version]$_ -gt [version]$pkg.InstalledVersion
            } | Sort-Object -Descending | Select-Object -First 1)"
        }
    }
}

Microsoft.WinGet.Client で簡単に操作できるのがありがたい。パッと見 AvailableVersions は降順に並ぶようだけど並び替えと絞り込みを入れておいた。 Get-WinGetPackage が使えるかもチェックしている。

これで更新があれば PowerShell 起動時にログが出て多分気付ける。その後の更新は command prompt から手で実行することになる想定。未だに PowerShell 内から PowerShell を更新する良い手順を知らない。

特に違いも感じずまだ刺激になってないけど、これからは preview を使っていこう。 VS Code も GitHub Copilot の機能をいち早く使うため Insider にしてるし、なんか unstable だれけになりつつある。

2026-01-11 追記。

VS Code で PowerShell Extension が利かなくなった。どうも Preview だけだと pwsh バイナリが見つからないみたい。なので設定で直に pwsh への path を指定してやる必要があった。

  "powershell.powerShellAdditionalExePaths": {
    "pwsh-preview": "C:\\Program Files\\PowerShell\\7-preview\\pwsh.exe"
  },
  "powershell.powerShellDefaultVersion": "pwsh-preview",

2026

Thu, 01 Jan 2026 09:00:00 +0900

例年通り目標をたてる。

テーマ: 不惑

2023 年から続くテーマ、不惑。わたしの探求は継続の中にこそあるって感じがしてきた。

2026 年の目標

継続目標の強度をすこし上げる。

積読消化 2 冊/月を超える
- 2025 年は 1.9 冊/月まできたので、ちょっと負荷を高める。頁数が多い本や難解な本を読み始めたらそれだけで詰みそうだが、そこはバランスとりつつで臨機応変に何とかならんかな。達成できたらこれを標準にしよう
F# の開発
- 新しいものを最低 1 つ作る
- pocof, blog-fable, SnippetPredictor, PSGameOfLife もやる
GitHub のストリークを継続する
- 秋には 1500 に達するので油断せず着実に進める
毎週ブログを書く
ギター練習を 5 / week
- 毎日コツコツ進めよう
深酒で怪我・二日酔いをしない
- 怪我だけでなく二日酔いによるパフォーマンス劣化にも注意する
自分メンテナンス
- 仕事にのめり込んでいる日は筋トレメニューを軽くしがちなので、毎日同じように続けるのを目標にしたい

仕事は年初から「高難易度だし忙しいけど暇」を解消するためのテコ入れを始めないといけない。幾つかすぐにやれる案はあるのでぼちぼちやってく。

振り返り 2025 年

Wed, 31 Dec 2025 09:00:00 +0900

2025 年を振り返る。

2025 年のテーマも「不惑」だった。

2025 年の目標と成果

比較的穏やかで順調だった。今年は妻が万博に熱を上げていたので春～秋にかけて家族一同頻繁に外出してたから、その間の活動は停滞しがちだった。

⭕️積読消化 1 冊/月を超える
- 順調に進んで 2024 年から続いてた 3 冊と 20 冊で 23 冊読めた。内 5 冊は再読。今日で 500 日連続読書になった。やったね
- ワインバーグ氏とデマルコ氏の著書はもはや古典だが読んでよかった。古典は良い
- 輪読会で読んだ入門・倫理学は booklog をつけるのが難しくてやめてしまったがなんとか最後まで読んだ。効率と倫理のバランスはすごく重要な要素と感じている。そのうち一人で読む機会を設けてちゃんと booklog つけるようにしたい
  - 読了
⭕️ F# の開発
- Command-line predictor plugin の krymtkts/SnippetPredictor を作った。地味に良い。普段から愛用してる
- 久しぶりに GUI やりたくて krymtkts/PSGameOfLife を作った。結果的に GUI より .NET の低レベルの理解が捗った。 Game of Life という題材は探求する余地が無限にあるので徐々にやっていきたい
- pocof と blog-fable もぼちぼち開発できてる。悩みはどれか 1 つをやってると他を放置してしまうこと。改善したい
- 次のネタも探して実装したい
⭕️GitHub のストリークを継続する
- 今 1200 を超えたくらい。来年は 1500 に達する。この先終わりはないができるところまで継続あるのみ
⭕️毎週ブログを書く
⭕️ギター練習を 4 / week
- IaC deploy 待ち、 Coding Agent 待ちと色々待ち時間があるのでちまちま練習。昔コピって弾けてない曲ばかりなのでちまちま補正してる
⭕️深酒で怪我をしない
- 単に機会がなかっただけ。酒に弱くなってきてるのもあってちょっと飲むと二日酔いしかけるので来年もっと注意が必要そう
⭕️自分メンテナンス
- メモに記録する非システマティックな方法で筋トレ習慣をちょっと改善できた。待ち時間増加の効果もあるか。そのおかげか Fat Gripz を使ってプルアップできるようになった。 Extreme ならサムレスだが Pro ならサムアラウンド。そこから先が進まなくてワンアームの手前にすら至れないのだけど。ワンレッグスクワットも練習しだして壁とかのアシストありなら数回できるようになった。ただ如何せん筋肉の柔軟性が壊滅的で足を伸ばせないのがわかったので、能動的ストレッチでそれを改善しようとしてる
- あと万博に同行するだけで 5 Kg くらい痩せて今もそれを維持してる。ちょっと軽すぎるし筋肉量増やすためにも摂取カロリーを増やした方が良いかもな

2025 年は仕事内容も充実してたし、概ねそれらを適切にこなせた。ただ 2025 年中頃から「高難易度だし忙しいけど暇」だと頻繁に感じていた。 2 周目以降じゃなく初めてやるようなものでも、初めは新鮮な刺激があるが少ししたら他の知識との関連やパターンが見つかって同じような感覚に陥る。時間をかけたらどうせできるしなという感覚、つまり学習負荷が低い状況になってるというところまでは認識してる。来年はそこをテコ入れして改善する。改善できないとおもしろくなさ過ぎて、つらい。

まとめ

結構習慣も落ち着いてきたし、来年はもうちょっと新たな刺激を注入したいなと考えてる。ただ油断してバランスを崩したら習慣が壊れてしまうこともあるし、いい感じに習慣をリアーキするのが必要なんやろなあ。さじ加減が難しい。

年末の大掃除

Sun, 28 Dec 2025 09:00:00 +0900

先日 krymtkts/blog-fable の dev server をいじってから、年末の大掃除的に他のも継続して修正してる。

細々した修正が主たるものだが、わかりやすいものだと blog-fable では振り返り日記をつけるにあたり、本を読んだ期間を本の link に添えたり #433 してみた。わかりやすく視認性が上がったので満足している。

他にも触ってるのは krymtkts/SnippetPredictor で、雑に扱ってた resource management を小綺麗にできないか #72 試しているところ。 Command-line predictor の plugin なので plugin が remove されたら全部 resource 掃除されるしいいかと思ってたが是正してみてる。 PowerShell だし思わぬ形で長生きされても困るしな。手法としては krymtkts/pocof で得た Volatile などの知識を流用して、実装は AI に書かせてみてる。毎日コツコツとリアル大掃除の方を進めているので、掃除中に実装してもらってレビューしている。

これらは大掃除が終わったら年を越す前に release してみたい気持ち。使用感が変わるわけでもないが、全くリリースなく年を越すよりはなんとなくいいかなと。あと数日大晦日まで時間があるので、その中でぼちぼち更新していきたい。

あと使い続けてる Iris Keyboard の key の chattering が大変なことになっていて、特に Enter key が重大な問題になってる。正しく打鍵どおりに入力できないから、しょうもないパスワード入力間違いや、実行したつもりの command が実行できてなかったり。これを解消したいのだけど今のところホコリをとっても直らないしあとは接点復活剤か key 自体の取り換えしか選択肢がない。年内に何らかの術でどうにか解消したいところだ。

これは機械接点に由来する問題だから mechanical switch の避けられない問題だ。なので今の時代だと磁気スイッチとかが狙い目かも知れんが、中々自作ハードルが高いな。

blog の Live reloading を WebSocket から SSE に切り替えた

Sun, 21 Dec 2025 09:00:00 +0900

先日 krymtkts/blog-fable の dev server を Suave 3.2.0 に更新した。その流れで dev server を refactor した。 #424

blog-fable では元々ファイル変更時に client へ event 通知する、要は live reloading するのに WebSocket で通知してた。でも相互通信が必要な訳ではなく、単に server -> client の単方向通知だけが目的だと過剰なので、 Server-Sent Events にしようと考えた。幸い Suave には EventSource module があって、それを使うことで簡単に実装できる。 EventSource module について何処かにあるのかも知れないが document は見当たらなかった。 Sample code には多少出現してそうなのだけど、そこからはあまり使い方がわからなかった。

GitHub Copilot(GPT-5.2) に方針を示したらサクッと実装してくれた。余談だが Fable の binding をサラッと書いてくれた辺りは中々やるなと思った。当然多少の手直しが必要なのは変わらないけど。

再帰を使ってた部分も単純な while loop に直した。コードが圧縮されて良いかなと。 CancellationToken は Suave の config の方に移ったのでここでの出番はなくなってる。

-    let socketHandler (ws: WebSocket) _ =
-        let rec refreshLoop (ct: CancellationToken) =
-            task {
-                ct.ThrowIfCancellationRequested()
-                do! refreshEvent.Publish |> Async.AwaitEvent
-
-                printfn "refresh client."
-                let seg = ASCII.bytes "refreshed" |> ByteSegment
-                let! _ = ws.send Text seg true
-
-                return! refreshLoop ct
-            }
-
-        let rec mainLoop (cts: CancellationTokenSource) =
-            socket {
-                let! msg = ws.read ()
-
-                match msg with
-                | Close, _, _ ->
-                    // use _ = cts
-                    cts.Cancel()
-
-                    let emptyResponse = [||] |> ByteSegment
-                    do! ws.send Close emptyResponse true
-                    printfn "WebSocket connection closed gracefully."
-                | _ -> return! mainLoop cts
-            }
-
-        let cts = new CancellationTokenSource()
-        refreshLoop cts.Token |> ignore
-        mainLoop cts
-
-    handleWatcherEvents, socketHandler
+    let sseHandler (conn: Connection) : Task<unit> =
+        task {
+            try
+                // NOTE: Tell the browser how long to wait before retrying the connection.
+                do! EventSource.retry conn 1000u
+
+                // NOTE: Initial event so the client can confirm it is connected.
+                do! EventSource.eventType conn "connected"
+                do! EventSource.data conn "ok"
+                do! EventSource.dispatch conn
+
+                while true do
+                    do!
+                        Async.StartAsTask(
+                            refreshEvent.Publish |> Async.AwaitEvent,
+                            cancellationToken = CancellationToken.None
+                        )
+
+                    do! EventSource.eventType conn "refresh"
+                    do! EventSource.data conn "refreshed"
+                    do! EventSource.dispatch conn
+            with
+            | :? OperationCanceledException -> ()
+            | :? SocketException -> ()
+        }
+
+    handleWatcherEvents, sseHandler

この関数を EventSource.handShake に渡すだけ。便利だ。 Suave 3 系になって handShake 系の関数は Task を要求する signature に変わってる。昔は Async だったなとしみじみと感じる。

     choose [

-        path "/websocket" >=> handShake socketHandler
+        path "/sse" >=> EventSource.handShake sseHandler

         GET
         >=> Writers.setHeader "Cache-Control" "no-cache, no-store, must-revalidate"

client 側は EventSource を使う。ここで Fable の binding が活きる。元々使っていた Fable.Browser.WebSocket の代わりに Fable.Browser.EventSource を使うというの手もあったが、使わなかった。 Fable.Browser.EventSource も小さい module だし利用箇所はもっと小さいので、自前の方が依存関係を減らせて何かと管理が楽だ。

 module Dev

 open Browser.Dom
-open Browser.WebSocket
+open Fable.Core

-let private initLiveReloading _ =
-    // NOTE: don't use string interpolation here, it will break the code because of importing String module.
-    let ws = WebSocket.Create <| "ws://" + window.location.host + "/websocket"
+[<Emit("typeof EventSource !== 'undefined'")>]
+let private hasEventSource: bool = jsNative
+
+[<AllowNullLiteral>]
+type private IEventSource =
+    abstract addEventListener: string * (obj -> unit) -> unit
+    abstract close: unit -> unit
+    abstract onmessage: (obj -> unit) with get, set
+
+[<Emit("new EventSource($0)")>]
+let private createEventSource (_url: string) : IEventSource = jsNative
+
+let private initLiveReloadingViaSse () =
+    let es = createEventSource "/sse"

-    ws.onmessage <-
-        fun _ ->
-            ws.close (1000, "reload")
-            window.location.reload ()
+    let reload (_: obj) =
+        es.close ()
+        window.location.reload ()

-    window.addEventListener ("beforeunload", (fun _ -> ws.close ()))
+    es.addEventListener ("refresh", reload)
+    es.onmessage <- reload
+
+    window.addEventListener ("beforeunload", (fun _ -> es.close ()))
+
+let private initLiveReloading _ =
+    // SSE only.
+    // If the browser doesn't support EventSource, do nothing.
+    if hasEventSource then
+        initLiveReloadingViaSse ()

 window.addEventListener ("load", initLiveReloading)

以上備忘のメモ。

今回のような普段書き直さないような部分の書き直しは新たな再発見があっていいな。あと log はまだ来てないようだし、 Suave 3 の更新がある限りはちまちまと触る機会になりそうで、良い。

Suave 3

Sun, 14 Dec 2025 09:00:00 +0900

krymtkts/blog-fable は開発時の preview や snapshot testing の web server に Suave を使っている。 Suave は F# で書かれた軽量な Web server で、 2023 年に出た 2.7.0-beta1 以降リリースは止まっていた。開発はポツポツ進んでいたみたいなのだけど。でもつい先日 dev server での preview ができなくなったので調べてみたら、なんと 2025-11 頃から 3 系 preview が NuGet で公開され出してた。 2025-12-11 の時点で preview でない 3.2.0 まで来てる。

活動再開を目にできるなんて実に喜ばしいことだ。 Bulma の時もそうだったが、そもそも活動再開でもなくてそういう開発スタイルとスパンなのかも知れんな。何にせよ利用者としては嬉しい限り。

Suave の 2 -> 3 ではごっそり書き換えが必要なレベルの設計変更はなかった。パフォーマンス最適化がメインで、内部で Task がより多く使われるようになってる。他は ArrayPool, Memory とかね。

あと今のところは Logging module がなくなって logger が使えなくなってた。 Logging がなくなったのは読み込まれたファイルのログが出なくなって dev server 的には地味に痛いのだが、ひょっとしたら別の方法で実現できたり復活の可能性もあるので、経過観測する。

blog-fable で一番影響があったのは一部 signature の変更かな。でも build error を直すだけ。 socket CE の中で使ってた use が使えなくなったのと defaultMimeTypesMap の signature 変更あたりが細かな修正点。これら blog-fable で影響のあった点を #422 でいい感じに対応した。実測した訳では無いのと target framework が net10.0 になってるのもあるだろうが、体感かなり速くなった気がする。

久しぶりに dev server 周りいじったので、この機会に他にも細かな改善などしていっていいかも知れんな。その間 krymtkts/pocof の方が放置されてしまうが、 blog-fable の修正は大した事ない物が多いからそんなに時間もかからないだろう。

NuGet の Dependabot がよくわからない

Sun, 07 Dec 2025 09:00:00 +0900

予定があって krymtkts/pocof の開発はできなかった。なのでちまちました改善をするに留めてたのだが、あらためて NuGet の Dependabot version updates の挙動がよくわからないなと思っている。

以前 project が見つからなくなった話をしたが、あれとはまた違う。今回のは特定の依存関係だけ更新されずに残っているという挙動に出会った。

blog-fable の repo root で dotnet list package --outdated したら以下が表示された。

> dotnet list package --outdated
Restore complete (1.2s)

Build succeeded in 1.3s

The following sources were used:
   https://api.nuget.org/v3/index.json

Project `App` has the following updates to its packages
   [net10.0]:
   Top-level Package        Requested   Resolved   Latest
   > Fable.Browser.Dom      2.19.0      2.19.0     2.20.0

Project `test` has the following updates to its packages
   [net10.0]:
   Top-level Package           Requested   Resolved   Latest
   > Microsoft.Playwright      1.56.0      1.56.0     1.57.0

いつも JST 金曜 06:00 に更新してるから、 Microsoft.Playwright の方は 2025-12-04 21:29:03Z でチェックの後に更新されたからわかる。ただ Fable.Browser.Dom の方は 5 ヶ月も前に更新されてるから拾えないのはおかしい。仕方ないのでどちらも手動で更新した。 #416

この過程で blog の code snippet が正しく改行されなくなっているのも発見した。これは困る。 Microsoft (Chromium )Edge だと正しく改行されて Google Chrome で改行されないみたい。

1Password の Google Chrome 拡張機能が有効だと改行コードが破壊さて Syntax highlighting もされなくなるところまで突き止めた。いまの version は 8.11.22.25 だった。

HTML 生成時点で code snippet は highlight.js の class が付与された状態に出力されているのだけど、 1Password 拡張機能付きで読み込むと動的に書き換えられてしまうみたい。なんじゃこりゃーー。似たような問題が報告されているのも確認できた。これは関連がありそうだ。

[BUG] Beta and Nightly extension degrade page's original functionallity | 1Password Community

通常はこう。

<code class="language-powershell"><span class="hljs-comment"># .NET 9 まで(.NET 10 でも動く)</span><br>dotnet add ./src/pocof package FSharp.Core <span class="hljs-literal">--version</span> <span class="hljs-number">10.0</span>.<span class="hljs-number">100</span><br><span class="hljs-comment"># .NET 10 から</span><br>dotnet package add FSharp.Core <span class="hljs-literal">--version</span> <span class="hljs-number">10.0</span>.<span class="hljs-number">100</span> <span class="hljs-literal">--project</span> ./src/pocof
</code>

でも 1Password が悪さするとこうなる。

<code class="language-powershell"><span class="token comment"># .NET 9 まで(.NET 10 でも動く)dotnet add ./src/pocof package FSharp.Core --version 10.0.100# .NET 10 からdotnet package add FSharp.Core --version 10.0.100 --project ./src/pocof</span>
</code>

ちょっと対応方法がわからないのでこれは様子見するかー。残念や。

F# で Cmdlet を書いてる pt.82 - pocof 0.22.0

Sun, 30 Nov 2025 09:00:00 +0900

krymtkts/pocof の開発をした。 0.22.0 をリリースをした。

最適化サポートを LTS の PowerShell 、今だと 7.4 なので .NET 8.0 を基準¹にして、その旨を README.md に明記した。

あと、クエリに変更がなければキャッシュした結果を使い回す機能をうっかり実装してしまった #403 ので、それもリリースに含めた。クエリに変更がないというのは、クエリ文字列・一致条件・組み合わせ・反転などが一致している状態を指す。これは当然 whitespace を打ち込んだ場合も cache を使えないということでもある。なので現時点ではカーソル移動の時だけ有効な感じ。とりあえずの出発点としてはこれでよいかと。

クエリ構築は結構重いので、生成しなくてよく無くなるだけで ms level ではあるが節約になる。

Method	QueryCount	Mean	Error	StdDev	Median	Ratio	RatioSD	Gen0	Gen1	Allocated	Alloc Ratio
prepare	1	1,389.987 ns	23.8900 ns	42.4645 ns	1,382.051 ns	1.001	0.04	0.7038	-	2944 B	1.00
prepareCached	1	7.167 ns	0.2167 ns	0.3963 ns	7.133 ns	0.005	0.00	-	-	-	0.00

prepare	3	2,739.519 ns	54.3090 ns	113.3631 ns	2,697.941 ns	1.002	0.06	1.3695	0.0038	5728 B	1.00
prepareCached	3	7.104 ns	0.2165 ns	0.3497 ns	7.149 ns	0.003	0.00	-	-	-	0.00

prepare	5	4,242.972 ns	83.1371 ns	224.7660 ns	4,166.865 ns	1.003	0.07	2.0294	0.0076	8512 B	1.00
prepareCached	5	7.288 ns	0.2180 ns	0.5054 ns	7.249 ns	0.002	0.00	-	-	-	0.00

prepare	7	6,242.056 ns	280.0643 ns	825.7758 ns	5,906.579 ns	1.017	0.19	2.7084	0.0076	11328 B	1.00
prepareCached	7	6.755 ns	0.2117 ns	0.3357 ns	6.662 ns	0.001	0.00	-	-	-	0.00

このクエリ構築が重いのは、キャッシュを履歴化するだとか、差分コンパイルするだとかで改善できると考えられるが、どこまでやるかやな。どのみちクエリの実行自体が最も重いので、こういうのは細かな調整レベルの話なのだが、色々考えることがあって楽しい。

prerelease は久しぶりに使ったのだけど、 prerelease 版と正規版がどちらもバージョン文字列の directory を利用することをすっかり忘れていた。お陰で PowerShell Gallery から最新版(正規版)を更新するとき、 PowerShell が FSharp.Core.dll を掴んだままで消せなくて手間取った。これは .NET がプロセスを死なせるまで握り続けてしまうからで、開いている PowerShell をすべて殺してから更新するしか術がない。この事象に出くわしたのも久しぶりで何？となったのだけど、これは .NET の未来永劫変わらないのかな。面倒なのでいつか改善してくれればいいのだけど。うっかり忘れがちなので pocof で prerelease を使う時は次の version まで飛ばしてしまう方が安定していて良いか。

あと 1 ヶ月程で 2025 年も終わるが、あと 1 回位は改善リリースができたら良さそうかな。まだ Multi targeting にした利点を全く活かせてないので、そこ攻めたいよな。

PowerShell Support Lifecycle - PowerShell | Microsoft Learn ↩

F# で Cmdlet を書いてる pt.82 - pocof 0.22.0-alpha

Sun, 23 Nov 2025 09:00:00 +0900

krymtkts/pocof の開発をした。 Multi targeting と bugfix を含めたものを 0.22.0-alpha としてリリースをした。初めて Multi targeting するのもありほんとにちゃんと publish されるのかなと不安があったので、久々の prerelease にした。

リリースに際してこれまで import した module ベースでの publish してたのをやめた。代わりにより再現性高い path ベースので publish に切り替えた。また今回は prerelease として出したのだけど、リリース用の psakefile を調整して prerelease version まで検査できるように直した。これはなかなか気に入っている。元は pocof を始めるとき参考にした blog の情報に基づき Import-LocalizedData を使ってた。でも pocof では多言語化意味ないので単純な Import-PowerShellDataFile に切り替えた。これによって System.Version で取り扱えない prerelease suffix もいい感じに扱える。

今回のリリース後に Linux でのみ crash する bug #397 を発見した。いつから壊れてるのかわからないが多分 StringBuilder を使いだしたころからかな。これは早めに対処したいが、 platform 依存の bug は対処難しいのでどうなることやら。

因みに今回の prerelease で .NET 6.0 と .NET Standard 2.0 の binary が配信されるようになったのだけど、両者にパフォーマンス上の違いはほぼなさそうだった。以下に未来の自分に対して target framework の変更程度で高速化するなんて儚い希望は持つなよという意味で結果を残しておく。

以下は benchmark の project を net 9.0 で回した場合。

TFM が netstandard2.0。

BenchmarkDotNet v0.15.7, Windows 11 (10.0.26200.7171/25H2/2025Update/HudsonValley2) Intel Core i7-8550U CPU 1.80GHz (Max: 2.00GHz) (Kaby Lake R), 1 CPU, 8 logical and 4 physical cores .NET SDK 10.0.100 [Host] : .NET 9.0.11 (9.0.11, 9.0.1125.51716), X64 RyuJIT x86-64-v3 DEBUG DefaultJob : .NET 9.0.11 (9.0.11, 9.0.1125.51716), X64 RyuJIT x86-64-v3

Method	Mean	Error	StdDev	Ratio	RatioSD	Gen0	Allocated	Alloc Ratio
invokeAction_Noop	138.4 ns	2.68 ns	2.38 ns	1.00	0.02	0.0248	104 B	1.00
invokeAction_AddQuery	862.1 ns	17.14 ns	25.12 ns	6.23	0.21	0.3920	1640 B	15.77
invokeAction_BackwardChar	476.1 ns	9.45 ns	7.89 ns	3.44	0.08	0.0248	104 B	1.00
invokeAction_BackwardWord	639.9 ns	12.34 ns	14.21 ns	4.63	0.13	0.0477	200 B	1.92
invokeAction_DeleteBackwardChar	235.5 ns	4.51 ns	5.01 ns	1.70	0.05	0.0248	104 B	1.00
invokeAction_DeleteBackwardWord	2,380.1 ns	46.32 ns	70.74 ns	17.21	0.58	0.8392	3512 B	33.77
invokeAction_SelectBackwardChar	516.8 ns	9.39 ns	9.64 ns	3.74	0.09	0.0401	168 B	1.62
invokeAction_SelectBackwardWord	566.6 ns	11.23 ns	14.99 ns	4.10	0.13	0.0629	264 B	2.54
invokeAction_RotateMatcher	160.2 ns	3.02 ns	2.96 ns	1.16	0.03	0.0496	208 B	2.00
invokeAction_CompleteProperty_NoSearch	139.3 ns	2.32 ns	1.94 ns	1.01	0.02	0.0248	104 B	1.00
invokeAction_CompleteProperty_Search	529.8 ns	10.45 ns	13.59 ns	3.83	0.12	0.1564	656 B	6.31
invokeAction_CompleteProperty_Rotate	420.9 ns	8.44 ns	10.05 ns	3.04	0.09	0.1392	584 B	5.62

TFM が net6.0 。

Method	Mean	Error	StdDev	Ratio	RatioSD	Gen0	Allocated	Alloc Ratio
invokeAction_Noop	136.4 ns	2.73 ns	3.83 ns	1.00	0.04	0.0248	104 B	1.00
invokeAction_AddQuery	829.1 ns	16.56 ns	17.72 ns	6.08	0.21	0.3920	1640 B	15.77
invokeAction_BackwardChar	463.7 ns	9.26 ns	9.09 ns	3.40	0.11	0.0248	104 B	1.00
invokeAction_BackwardWord	627.2 ns	11.09 ns	9.83 ns	4.60	0.14	0.0477	200 B	1.92
invokeAction_DeleteBackwardChar	230.9 ns	2.47 ns	1.93 ns	1.69	0.05	0.0248	104 B	1.00
invokeAction_DeleteBackwardWord	2,293.5 ns	40.80 ns	57.19 ns	16.83	0.62	0.8392	3512 B	33.77
invokeAction_SelectBackwardChar	498.0 ns	9.16 ns	7.15 ns	3.65	0.11	0.0401	168 B	1.62
invokeAction_SelectBackwardWord	569.3 ns	11.32 ns	12.58 ns	4.18	0.14	0.0629	264 B	2.54
invokeAction_RotateMatcher	161.7 ns	3.15 ns	2.79 ns	1.19	0.04	0.0496	208 B	2.00
invokeAction_CompleteProperty_NoSearch	141.1 ns	2.92 ns	3.58 ns	1.03	0.04	0.0248	104 B	1.00
invokeAction_CompleteProperty_Search	525.6 ns	10.31 ns	14.11 ns	3.86	0.15	0.1564	656 B	6.31
invokeAction_CompleteProperty_Rotate	460.4 ns	8.93 ns	7.91 ns	3.38	0.11	0.1392	584 B	5.62

悪あがきで試しに TFM が net8.0 の場合も取った。

Method	Mean	Error	StdDev	Ratio	RatioSD	Gen0	Allocated	Alloc Ratio
invokeAction_Noop	139.6 ns	2.80 ns	2.99 ns	1.00	0.03	0.0248	104 B	1.00
invokeAction_AddQuery	854.5 ns	16.77 ns	22.38 ns	6.12	0.20	0.3920	1640 B	15.77
invokeAction_BackwardChar	473.8 ns	9.30 ns	8.70 ns	3.39	0.09	0.0248	104 B	1.00
invokeAction_BackwardWord	624.0 ns	12.34 ns	13.21 ns	4.47	0.13	0.0477	200 B	1.92
invokeAction_DeleteBackwardChar	237.2 ns	4.74 ns	6.80 ns	1.70	0.06	0.0248	104 B	1.00
invokeAction_DeleteBackwardWord	2,400.6 ns	45.94 ns	54.68 ns	17.20	0.52	0.8392	3512 B	33.77
invokeAction_SelectBackwardChar	501.0 ns	9.87 ns	11.74 ns	3.59	0.11	0.0401	168 B	1.62
invokeAction_SelectBackwardWord	592.5 ns	11.65 ns	13.87 ns	4.25	0.13	0.0629	264 B	2.54
invokeAction_RotateMatcher	164.6 ns	2.76 ns	2.83 ns	1.18	0.03	0.0496	208 B	2.00
invokeAction_CompleteProperty_NoSearch	138.5 ns	2.70 ns	3.00 ns	0.99	0.03	0.0248	104 B	1.00
invokeAction_CompleteProperty_Search	525.2 ns	10.47 ns	13.62 ns	3.76	0.12	0.1564	656 B	6.31
invokeAction_CompleteProperty_Rotate	425.4 ns	8.46 ns	12.66 ns	3.05	0.11	0.1392	584 B	5.62

以下は benchmark の project を net10.0 で回した場合。

TFM が netstandard2.0。

BenchmarkDotNet v0.15.7, Windows 11 (10.0.26200.7171/25H2/2025Update/HudsonValley2) Intel Core i7-8550U CPU 1.80GHz (Max: 2.00GHz) (Kaby Lake R), 1 CPU, 8 logical and 4 physical cores .NET SDK 10.0.100 [Host] : .NET 10.0.0 (10.0.0, 10.0.25.52411), X64 RyuJIT x86-64-v3 DEBUG DefaultJob : .NET 10.0.0 (10.0.0, 10.0.25.52411), X64 RyuJIT x86-64-v3

Method	Mean	Error	StdDev	Ratio	RatioSD	Gen0	Allocated	Alloc Ratio
invokeAction_Noop	61.81 ns	0.711 ns	0.593 ns	1.00	0.01	0.0248	104 B	1.00
invokeAction_AddQuery	634.17 ns	12.236 ns	12.018 ns	10.26	0.21	0.3920	1640 B	15.77
invokeAction_BackwardChar	181.10 ns	2.864 ns	2.679 ns	2.93	0.05	0.0248	104 B	1.00
invokeAction_BackwardWord	269.64 ns	5.362 ns	6.585 ns	4.36	0.11	0.0477	200 B	1.92
invokeAction_DeleteBackwardChar	94.00 ns	1.895 ns	1.773 ns	1.52	0.03	0.0248	104 B	1.00
invokeAction_DeleteBackwardWord	1,820.17 ns	35.804 ns	42.623 ns	29.45	0.73	0.8392	3512 B	33.77
invokeAction_SelectBackwardChar	199.02 ns	3.845 ns	4.577 ns	3.22	0.08	0.0401	168 B	1.62
invokeAction_SelectBackwardWord	272.08 ns	5.230 ns	5.136 ns	4.40	0.09	0.0629	264 B	2.54
invokeAction_RotateMatcher	87.81 ns	1.705 ns	1.963 ns	1.42	0.03	0.0497	208 B	2.00
invokeAction_CompleteProperty_NoSearch	67.76 ns	1.424 ns	1.801 ns	1.10	0.03	0.0248	104 B	1.00
invokeAction_CompleteProperty_Search	363.46 ns	7.280 ns	9.207 ns	5.88	0.16	0.1564	656 B	6.31
invokeAction_CompleteProperty_Rotate	307.18 ns	6.190 ns	9.996 ns	4.97	0.17	0.1392	584 B	5.62

TFM が net6.0 。

BenchmarkDotNet v0.15.7, Windows 11 (10.0.26200.7171/25H2/2025Update/HudsonValley2) Intel Core i7-8550U CPU 1.80GHz (Max: 2.00GHz) (Kaby Lake R), 1 CPU, 8 logical and 4 physical cores .NET SDK 10.0.100 [Host] : .NET 10.0.0 (10.0.0, 10.0.25.52411), X64 RyuJIT x86-64-v3 DEBUG DefaultJob : .NET 10.0.0 (10.0.0, 10.0.25.52411), X64 RyuJIT x86-64-v3

Method	Mean	Error	StdDev	Ratio	RatioSD	Gen0	Allocated	Alloc Ratio
invokeAction_Noop	64.63 ns	1.324 ns	1.416 ns	1.00	0.03	0.0248	104 B	1.00
invokeAction_AddQuery	647.66 ns	12.872 ns	12.642 ns	10.03	0.28	0.3920	1640 B	15.77
invokeAction_BackwardChar	185.61 ns	3.599 ns	4.145 ns	2.87	0.09	0.0248	104 B	1.00
invokeAction_BackwardWord	309.75 ns	6.180 ns	8.863 ns	4.79	0.17	0.0477	200 B	1.92
invokeAction_DeleteBackwardChar	95.88 ns	1.965 ns	3.117 ns	1.48	0.06	0.0248	104 B	1.00
invokeAction_DeleteBackwardWord	1,802.35 ns	35.392 ns	33.106 ns	27.90	0.77	0.8392	3512 B	33.77
invokeAction_SelectBackwardChar	214.03 ns	4.136 ns	5.231 ns	3.31	0.11	0.0401	168 B	1.62
invokeAction_SelectBackwardWord	275.16 ns	5.398 ns	7.742 ns	4.26	0.15	0.0629	264 B	2.54
invokeAction_RotateMatcher	91.23 ns	1.822 ns	2.305 ns	1.41	0.05	0.0497	208 B	2.00
invokeAction_CompleteProperty_NoSearch	68.79 ns	1.428 ns	2.386 ns	1.06	0.04	0.0248	104 B	1.00
invokeAction_CompleteProperty_Search	365.48 ns	7.125 ns	9.988 ns	5.66	0.19	0.1564	656 B	6.31
invokeAction_CompleteProperty_Rotate	306.81 ns	6.065 ns	9.965 ns	4.75	0.18	0.1392	584 B	5.62

見ての通り、高速化されたといわれてる .NET 10 を benchmark project の Target framework にした場合は明らかに速かった。つまり実行するところの runtime が一番影響するから、 PowerShell であれば PowerShell 自体の .NET version が影響するって考えたらいいかな。

PowerShell 自体が速くなるのを待っても良いけど、新しい framework 向けの最適化を入れていきたいと検討してる。今回の prerelease で Multi targeting を実現したが、 prerelease を外す際にはサポートする platform のルール策定をしておきたい。一番シンプルなのは LTS の PowerShell に合わせる方法なので、現行 LTS の PowerShell 7.4 つまり .NET 8.0 を基準にするのが 1 つの選択肢かな。つまり今だと PowerShell 7.2 で .NET 8 が最適化サポート最低ライン。ほかは .NET Standard 2.0 になる。いま試しに Multi targeting を始めてみた時点では .NET 6.0 と .NET Standard 2.0 なので、それの最適化される方の閾値を上げる感じ。ひとつの問題として LTS が進んだらどんどん最適化ラインから外されてしまうという課題もあるのだけど、 PowerShell の LTS を考えたら妥当と思える。とりまサポート戦略を決めたら README.md に書くなりして alpha 外した 0.22.0 として publish してみるのがよさそうかな。

F# で Cmdlet を書いてる pt.81 - Central Package Management と .NET 10

Sun, 16 Nov 2025 09:00:00 +0900

krymtkts/pocof の開発をした。開発というかメンテ。

まずは Central Package Management を導入した話。

ちょっと前に .NET の Dependabot version updates の挙動が変わって壊れたとき、 dependabot.yml を書き換えた内容が間違ってたみたい。それが原因で一部の package が更新されない状態が続いてたのに気付いた。それは pocof に限った話じゃないのだけで、自作の PowerShell cmdlet の repository 全体的に直した。 #377

それで期待通り Dependabot が働き始めたのだけど、 pocof のような 1 solution に複数(pocof は 4) project ある package 管理が面倒に感じた。いい機会なので Central Package Management(CPM) を導入してみた。 #382

もともと Directory.Build.props は Ionide.Analyzer を全 project へ導入するのに使ってた。 CPM ではこれとは別に Directory.Packages.props を置く。そこで <PackageVersion> を定義して package ごとの version を集中管理する。配下の各 project では PackageReference に Version 属性を指定せず、 Directory.Packages.props で集中管理する。これにより複数 project で参照される同一 package も同じ version を使うので手間が省けるってことみたい。

CPM を使うと、これまで project の管理に入れてなかった F# の package FSharp.Core も明示的に入れる必要があり、管理が厳密化された。また CentralPackageTransitivePinningEnabled=true にしてる。これは transitive dependencies に同じ package がいた場合も強制するための設定。他に CentralPackageVersionOverrideEnabled というのもあって、これは中央管理してる version の上書きを許可するかを指定できる。 pocof は指定忘れたので既定値で動いてるはず(既定値が true false どちらかは文書に書いてなかった)。ガチガチ管理を進めるなら明示的に false が良さそう。これは後ほど変更しておきたい。

CPM だと package 更新は手で直すしかないのかなと気になって試してみた。以下の通り dotnet CLI で CPM でもうまく Directory.Packages.props を更新できた。あと地味に .NET 10 から sub command 体系が変わってるのをここで知った。 What's new in the SDK and tooling for .NET 10 | Microsoft Learn

# .NET 9 まで(.NET 10 でも動く)
dotnet add ./src/pocof package FSharp.Core --version 10.0.100
# .NET 10 から
dotnet package add FSharp.Core --version 10.0.100 --project ./src/pocof

ただ Directory.Packages.props に体裁を整えるための改行とか入れてると全部吹っ飛ぶので、まあ考えどころやな。

CPM 導入により package version がひとつのファイルにまとまっただけだが、結構 package の見通しが良くなったと気がするので、気に入っている。

次は .NET 10 に上げた話。

毎年恒例の最新 .NET 10 が出たので、 pocof は #389 で対応した。やることは決まりきってるのでそんなに困ることもないが、いつもと少し手順を変えている。今回はいつも使ってる Chocolatey では .NET 10 SDK がまだ承認されてなかったので、 winget を使うことにした。いま自分の PC の package 管理で winget を使ってるのは OpenSSH だけなので、使い方を忘れるしメモっておく。以下のコマンドで .NET 10 SDK を install した。

# これだと確認 prompt が面倒
winget install --id Microsoft.DotNet.SDK.10
# これで完全自動化できる(管理者権限で実行すると)
winget install --id Microsoft.DotNet.SDK.10 --silent --accept-package-agreements --accept-source-agreements --exact

コメントのとおりだが winget はデフォで確認プロンプトが面倒なのでゴテゴテと options をつけないといけないのが少し残念。 Chocolatey なら choco upgrade dotnet -y やからな。

あとは手で SDK version を書き換える感じだけど、今回は PowerShell で簡単に global.json を変更できる関数を作った(初版 AI に作らせて)。

function Set-DotnetGlobalJson {
    [CmdletBinding()]
    param(
        # Path to global.json (default: ./global.json)
        [Parameter(Position = 0)]
        [Alias('PSPath')]
        [ValidateNotNullOrEmpty()]
        [string]
        $Path = 'global.json',
        # Target major version (e.g. 10, 9)
        [int]
        $Major = 10,
        # rollForward value to write
        [ValidateSet('disable', 'latestPatch', 'minor', 'latestMinor', 'major', 'latestMajor', 'latestFeature')]
        [string]
        $RollForward = 'latestFeature'
    )

    function Get-LatestDotnetSdkVersionForMajor {
        param(
            [int]$Major
        )

        $sdks = dotnet --list-sdks 2>$null
        if (-not $sdks) {
            throw 'No dotnet SDKs found. Make sure dotnet is on PATH.'
        }

        $versions = $sdks |
            ForEach-Object {
                # "10.0.100 [C:\...]" → "10.0.100"
                ($_ -split '\s+')[0]
            } |
            Where-Object {
                $_ -match '^\d+\.\d+\.\d+' -and $_.StartsWith("$Major.")
            } |
            ForEach-Object {
                [version]$_
            }

        if (-not $versions) {
            throw "No .NET $Major SDKs found. Please install .NET $Major SDK first."
        }

        ($versions | Sort-Object -Descending | Select-Object -First 1).ToString()
    }

    try {
        $version = Get-LatestDotnetSdkVersionForMajor -Major $Major
        Write-Host "Detected latest .NET $Major SDK: $version"

        $jsonObject = @{
            sdk = @{
                version = $version
                rollForward = $RollForward
            }
        }

        $json = $jsonObject | ConvertTo-Json -Depth 3

        $resolved = Resolve-Path -Path $Path -ErrorAction SilentlyContinue
        if ($null -eq $resolved) {
            $targetPath = Join-Path (Get-Location) $Path
            Write-Host "Creating new global.json at: $targetPath"
            $json | Set-Content -Encoding UTF8 $targetPath
        }
        else {
            Write-Host "Updating existing global.json at: $($resolved.Path)"
            $json | Set-Content -Encoding UTF8 $resolved.Path
        }

        Write-Host "global.json updated to use SDK $version (rollForward=$RollForward)." -ForegroundColor Green
    }
    catch {
        Write-Error $_
    }
}

この関数を作った動機は dotnet CLI に指定する full version をいちいち覚えてないから自動で設定したいというものだ。 dotnet new globaljson --force --sdk-version 10 でも full version が入ってほしいがそうはいかない。あと dotnet new globaljson --force で global.json の末尾改行が削れるのも好きじゃない。ちょっと安全じゃないかもなという気はすれど、自前でやるのがいいかなと考えた。これで Set-DotnetGlobalJson -Major 10 のようにして簡単に 10.0.100 に変更できる。楽だ。 (SDK を事前に install 済みである必要があるが)

まだ pocof しか .NET SDK を更新してないから、他の repository でもちまちま更新していく予定。その間 pocof は放置気味になるかも知れんが、できる限りぼちぼち進めたい。 Multi targeting にしたことで netstandard2.0 と net6.0 でパフォに差があるのかとか benchmark を見てないから測定するとか。速くなってるなら、ここらで次の version として公開するのもいいしね。 Multi targeting した初回は怖いので alpha が妥当かも知れん。

F# で Cmdlet を書いてる pt.80 - Multi targeting

Sun, 09 Nov 2025 09:00:00 +0900

krymtkts/pocof の開発を少し進めた。必要最低限の Multi targeting を実現する変更をした。 #376

PowerShell module で Multi targeting で build した dll を配信するなら、 .NET の Multi targeting の情報だけでは準備が足りない。 platform に適切な dll を読み込めるように PowerShell の module 構成についても知る必要がある。前回、 PowerShell の loader script について書いてる文書がないと書いたが、見つけた。ちゃんと準備されてたみたいで見つけられなかったのが恥ずかしい。ここに PSScriptAnalyzer の例が載ってる。これが公式版といえそう。

Modules with compatible PowerShell Editions - PowerShell | Microsoft Learn

PSScriptAnalyzer の repository のものはこちら。

PSScriptAnalyzer/Engine/PSScriptAnalyzer.psm1 at main · PowerShell/PSScriptAnalyzer · GitHub

$PSEdition を利用する方法と loader script で細かく制御する方法の 2 つがあると書いてある。ただ loader script という熟語は出てこないので、これは俗語みたいなもんか。

$PSEdition を利用する方法は PowerShell 5.1 以上で利用できるらしいので、 Windows PowerShell 5.1 と PowerShell すべてで使えることになる¹。因みに使える変数はいくつかあるが、使えないものを参照すると error になる。

PS C:\Users\takatoshi\dev\github.com\krymtkts\pocof> import-Module .\publish\pocof\pocof.psd1
Import-Module: The module manifest 'C:\Users\takatoshi\dev\github.com\krymtkts\pocof\publish\pocof\pocof.psd1' could not be processed because it is not a valid PowerShell module manifest file. Remove the elements that are not permitted: At C:\Users\takatoshi\dev\github.com\krymtkts\pocof\publish\pocof\pocof.psd1:12 char:22
+     RootModule = if ($PSVersionTable) {
+                      ~~~~~~~~~~~~~~~
A variable that cannot be referenced in restricted language mode or a Data section is being referenced. Variables that can be referenced include the following: $PSCulture, $PSUICulture, $true, $false, $null, $PSScriptRoot, $PSEdition, $EnabledExperimentalFeatures.

$PSEdition を使った分岐は記述が簡素になるが、今回は loader script を採用した。これはなるべく広く PowerShell を最適化するために下限を .NET 6 としたため、 loader script でないと書けないからだ。 .NET 6 の PowerShell 7.2 はもう EOL してるので要らないといえばそうなので、そのうち .NET 8 を下限に変える可能性はある。

pocof では以下のようにした。

RootModule は loader script を指定。

    # Script module or binary module file associated with this manifest.
    RootModule = 'pocof.psm1'

pocof.psm1 で $PSVersionTable.PSVersion を検査し load し分ける。

#
# Script module for module 'pocof'
# Based on https://learn.microsoft.com/en-us/powershell/gallery/concepts/module-psedition-support?view=powershellget-3.x#targeting-multiple-editions
#
Set-StrictMode -Version Latest

$PSModule = $ExecutionContext.SessionState.Module
$PSModuleRoot = $PSModule.ModuleBase

# NOTE: Import the appropriate nested binary module based on the current PowerShell version.
# https://learn.microsoft.com/en-us/powershell/scripting/install/powershell-support-lifecycle?view=powershell-7.5#powershell-end-of-support-dates
if ($PSVersionTable.PSVersion -lt [Version]'7.2') {
    $targetFramework = 'netstandard2.0'
}
else {
    $targetFramework = 'net6.0'
}
# NOTE: Build paths separately for Windows PowerShell compatibility.
$binaryModuleRoot = Join-Path -Path $PSModuleRoot -ChildPath $targetFramework
$binaryModulePath = Join-Path -Path $binaryModuleRoot -ChildPath 'pocof.dll'
$binaryModule = Import-Module -Name $binaryModulePath -PassThru

Write-Verbose "pocof: Loaded $targetFramework binary from $binaryModulePath" -Verbose

# NOTE: When the module is unloaded, remove the nested binary module that was loaded with it.
$PSModule.OnRemove = {
    Remove-Module -ModuleInfo $binaryModule
}

loader script は後方互換を意識しないと、対応したい古い PowerShell で利用できない可能性がある。例えば Join-Path で AdditionalChildPath が使えるのは PowerShell 6.0 以降なので、後方互換のため複数回呼ぶ。

あと、わたしがまだ Multi targeting に慣れてないので Write-Verbose で読み込む module の情報を出力するようにしている。

このようにして Multi targeting された project は明示的に framework option で対象を指定しないと build できない。 net6.0 と netstandard2.0 を明示的に指定するよう build script を調整した。 build した dll を publish 用の directory 出力するよう project の調整も必要だ。

    <!-- Deploy the produced assembly -->
    <PublishDir>../../publish/pocof/$(TargetFramework)/</PublishDir>

これで publish 用の directory にあるファイルはすべて Publish-PSResource で publish されるはず。 module 構成は以下のようにした。

C:\USERS\TAKATOSHI\DEV\GITHUB.COM\KRYMTKTS\POCOF\PUBLISH\POCOF
|   .gitkeep
|   pocof-Help.xml
|   pocof.psd1
|   pocof.psm1
|
+---net6.0
|       FSharp.Core.dll
|       pocof.dll
|
\---netstandard2.0
        FSharp.Core.dll
        pocof.dll

配信ファイルが増えてサイズが大きくなるがそれは許容するしかないか。あとほんとにこれで publish が上手くいくか試してないので、テスト用の module で挙動をチェックしたい感じではある。

Multi targeting で注意したい点がいくつかある。

まず net6.0 を target して build した場合に Nullable 有効化時の検査が netstandard2.0 より厳しくなる。これは null 避けすればいいだけだが、再現が難しい path は coverage を下げる原因にもなり得る。また F# 開発を Visual Studio Code + Ionide で行っているが、 Multi targeting していると片方の build error しか検知できない。 Ionide は TargetFrameworks の先頭に書いた framework で build するようなので、よりチェックが厳しい net6.0 を先頭にした。開発時に netstandard2.0 での build 結果を見ることができないのは少し不安だが、 build script と CI でその点をカバーするつもり。

あと、今後 framework の conditional compilation symbols で分岐するので、 unit testing や coverage もそれぞれ実行する必要がある。 test project が pocof の project 参照しているため、 parameter を付与して指定の TargetFramework で build できるよう変更した。

  <ItemGroup>
    <ProjectReference Include="..\pocof\pocof.fsproj"
                      Properties="TargetFramework=$(TestTargetFramework)"
                      Condition="'$(TestTargetFramework)' != ''" />
    <ProjectReference Include="..\pocof\pocof.fsproj"
                      Condition="'$(TestTargetFramework)' == ''" />
  </ItemGroup>

これで 2 つの framework で実行できるので、まとめて実行するのは build script で吸収する。まだ benchmark や memory layout を確認する project ではこれに対応していないので、特に benchmark については必要になり次第調整したい。

2 つの TargetFramework で coverage 計測したら当然 report も 2 つになる。 pocof では CI の coverage report に Codecov を使っているが、幸い複数 report に対応しているのでまとめて送りつけることにした。

- name: Execute All Tests
  id: run_tests
  shell: ${{ inputs.shell }}
  run: |
    Invoke-Psake -taskList TestAll
    if (-not $psake.build_success) { exit 1 }
    $reports = (Get-ChildItem ./src/pocof.Test/TestResults/coverage.*.cobertura.xml) -join ','
    "REPORT_PATHS=$reports" | Out-File -FilePath $env:GITHUB_OUTPUT -Append
- name: Upload coverage reports to Codecov
  uses: codecov/codecov-action@v5
  if: runner.os == 'Linux'
  with:
    file: ${{ steps.run_tests.outputs.REPORT_PATHS }}
  env:
    CODECOV_TOKEN: ${{ inputs.codecov_token }}

この日記を書いてる途中に気付いたが、 file は非推奨なので files に変えるのが正しいな。あとで直す。

とりま build 構成と PowerShell module 構成についてのまとめはこんな感じかな。ここまでやればこれまでの開発と同じように Multi targeting での開発もできるはずだ。あとは conditional compilation symbols を使った実装で、 net6.0 と netstandard2.0 の両方でうまく開発する工夫が必要になってくる。これは開発を進める中でよい落とし所を模索していきたい。

PowerShell Support Lifecycle - PowerShell | Microsoft Learn の表を参照 ↩

F# で Cmdlet を書いてる pt.79 - pocof 0.21.0

Sun, 02 Nov 2025 09:00:00 +0900

今週末はビールとワインのイベントにのもあって krymtkts/pocof の開発はできてない。代わりにこれまでの改善を含めた 0.21.0 をリリースをした。 2025-11 は .NET 10 が来るので、 pocof を .NET 10 で開発する準備として、これまでの改善をリリースを挟んでおくのが良いと考えた。

0.21.0 での変更点は基本的に速度面メモリ面でのパフォ改善に尽きるので、 bug を仕込んでなければ特に使用感の変化なく使えるはずだ。さらりと触ってる感覚では、内部的な最適化よりも描画の効率化が一番利いており、キビキビ描画されるようになった気がする。

今後考えている pocof 開発の大きな変更点としては、 Multi targeting に挑戦してみたいと考えている。やはり .NET Standard 2.0 に縛られたままだと高速化に限界があるので、新し目の platform に関してより最適化するならこれしかない。ここで手を加えておくことによって、万が一にでも Windows PowerShell がくたばったとしても次に繋げやすいはずだ。

ただこれまでの単純な PowerShell module 構造でなくなるので多少勉強が必要だが、多分やれる。それもいい経験になるだろう。これまで loader script で import する dll を切り分けるような PowerShell module はいくつか見たことがある。アレの具体的な仕組みは勉強したことないので、これを機に学ぶ。探し方が良くないのかそれを示した具体的な公式文書は見たことがないし、ダメもとでまずそれを探すところからかな。これまで経験的にはそういうのは公式になさそうなので、検証用の module で色々試して、まとめればよいかと考えている。

これは日記に何度も書いていることだが、仕事ではコスパ的にバランスしなくてやらないようなことでも、趣味プロならとことんやることができる。改めて、これはほんと良いなと感じる。

F# で Cmdlet を書いてる pt.78

Sun, 26 Oct 2025 09:00:00 +0900

krymtkts/pocof を開発した。

前回に続き query の構文解析と実行部分に手を入れた。 #373

query の構文解析は、従来の正規表現の利用をやめ自前の parser で組み立てるようにした。前の日記のときとさほど変わってないかと。

before

Method	QueryCount	Mean	Error	StdDev	Ratio	RatioSD	Gen0	Allocated	Alloc Ratio
prepareNormalQuery	1	1.353 us	0.0343 us	0.1007 us	1.01	0.10	0.6523	2.66 KB	1.00
preparePropertyQuery	1	1.428 us	0.0277 us	0.0330 us	1.06	0.08	0.6866	2.8 KB	1.05

prepareNormalQuery	3	2.672 us	0.0522 us	0.0813 us	1.00	0.04	1.2970	5.3 KB	1.00
preparePropertyQuery	3	2.845 us	0.0560 us	0.0803 us	1.07	0.04	1.3657	5.58 KB	1.05

prepareNormalQuery	5	4.018 us	0.0741 us	0.1317 us	1.00	0.05	1.9379	7.95 KB	1.00
preparePropertyQuery	5	4.299 us	0.0852 us	0.2229 us	1.07	0.07	2.0370	8.34 KB	1.05

prepareNormalQuery	7	5.332 us	0.1034 us	0.1669 us	1.00	0.04	2.5864	10.59 KB	1.00
preparePropertyQuery	7	5.651 us	0.1125 us	0.1156 us	1.06	0.04	2.7237	11.13 KB	1.05

after

Method	QueryCount	Mean	Error	StdDev	Ratio	RatioSD	Gen0	Allocated	Alloc Ratio
prepareNormalQuery	1	1.307 us	0.0308 us	0.0903 us	1.00	0.10	0.6638	2.71 KB	1.00
preparePropertyQuery	1	1.278 us	0.0254 us	0.0465 us	0.98	0.08	0.6809	2.78 KB	1.03

prepareNormalQuery	3	2.447 us	0.0487 us	0.0813 us	1.00	0.05	1.3199	5.4 KB	1.00
preparePropertyQuery	3	2.532 us	0.0501 us	0.0634 us	1.04	0.04	1.3542	5.53 KB	1.02

prepareNormalQuery	5	4.473 us	0.2554 us	0.7449 us	1.03	0.24	1.9760	8.09 KB	1.00
preparePropertyQuery	5	3.852 us	0.0760 us	0.1519 us	0.88	0.15	2.0218	8.28 KB	1.02

prepareNormalQuery	7	4.879 us	0.0973 us	0.2073 us	1.00	0.06	2.6321	10.77 KB	1.00
preparePropertyQuery	7	5.087 us	0.1007 us	0.1655 us	1.04	0.05	2.7008	11.04 KB	1.02

次に手を加えたのは、絞り込みのための述語を生成していた部分。わかりやすさのために関数を分けていたのを統合し、再帰による繰り返しを減らした。そして色々試してより良くする方法を探した結果、コードクォートの利用をやめて lambda expression と loop に書き直した。クエリの数が増えるほど効果があるのでコードクォートを使っていたが、実際のところ 10 クエリも組み合わせることがなく、 overhead が目立つと考えた。また loop を使う等他の再帰化も合わせれば断然 lambda expression の方が速くてメモリも軽くできるので、コードクォートをやめ結局元に戻った。

before

Method	EntryCount	QueryCount	Mean	Error	StdDev	Median	Gen0	Gen1	Allocated
run_obj_normal	100	1	542.6 us	10.11 us	18.99 us	535.4 us	15.6250	0.9766	63.91 KB
run_dict_normal	100	1	541.9 us	10.68 us	16.31 us	539.3 us	15.6250	0.9766	64.04 KB
run_obj_property	100	1	257.3 us	4.62 us	5.50 us	256.6 us	4.8828	4.3945	21.38 KB
run_dict_property	100	1	260.2 us	5.10 us	7.31 us	261.3 us	4.8828	4.3945	21.38 KB
run_obj_normal	100	5	792.0 us	22.19 us	61.85 us	771.3 us	35.1563	-	148.65 KB
run_dict_normal	100	5	771.8 us	15.32 us	29.15 us	775.6 us	35.1563	-	148.64 KB
run_obj_property	100	5	262.8 us	5.24 us	8.75 us	262.5 us	4.8828	4.3945	21.48 KB
run_dict_property	100	5	258.5 us	4.76 us	6.35 us	258.5 us	4.8828	4.3945	21.48 KB
run_obj_normal	100	10	1,040.2 us	20.52 us	34.29 us	1,037.0 us	62.5000	1.9531	255.39 KB
run_dict_normal	100	10	1,039.5 us	20.41 us	36.80 us	1,033.0 us	62.5000	1.9531	255.39 KB
run_obj_property	100	10	259.9 us	5.14 us	8.01 us	259.5 us	4.8828	4.3945	21.6 KB
run_dict_property	100	10	261.1 us	5.11 us	7.64 us	259.8 us	4.8828	4.3945	21.6 KB
run_obj_normal	1000	1	539.5 us	10.77 us	12.82 us	538.3 us	15.6250	0.9766	63.9 KB
run_dict_normal	1000	1	539.7 us	10.67 us	15.98 us	539.0 us	15.6250	0.9766	63.9 KB
run_obj_property	1000	1	256.6 us	5.11 us	5.89 us	256.0 us	4.8828	4.3945	21.38 KB
run_dict_property	1000	1	265.8 us	5.29 us	14.11 us	261.6 us	4.8828	4.3945	21.38 KB
run_obj_normal	1000	5	769.6 us	15.05 us	24.30 us	766.6 us	35.1563	-	148.64 KB
run_dict_normal	1000	5	775.4 us	14.84 us	19.82 us	765.8 us	35.1563	-	148.64 KB
run_obj_property	1000	5	262.3 us	5.20 us	8.39 us	263.0 us	4.8828	4.3945	21.48 KB
run_dict_property	1000	5	260.7 us	5.10 us	7.48 us	259.6 us	4.8828	4.3945	21.48 KB
run_obj_normal	1000	10	1,054.5 us	19.16 us	33.05 us	1,052.0 us	62.5000	1.9531	255.39 KB
run_dict_normal	1000	10	1,031.6 us	20.54 us	30.74 us	1,031.5 us	62.5000	1.9531	255.39 KB
run_obj_property	1000	10	261.9 us	4.59 us	6.59 us	259.7 us	4.8828	4.3945	21.6 KB
run_dict_property	1000	10	259.9 us	5.10 us	6.98 us	258.9 us	4.8828	4.3945	21.6 KB

after

Method	EntryCount	QueryCount	Mean	Error	StdDev	Median	Gen0	Gen1	Allocated
run_obj_normal	100	1	71.51 us	1.311 us	1.227 us	71.35 us	12.4512	-	50.85 KB
run_dict_normal	100	1	61.02 us	0.835 us	0.740 us	60.98 us	18.0664	0.2441	73.76 KB
run_obj_property	100	1	45.92 us	1.737 us	4.928 us	44.66 us	6.8359	-	27.75 KB
run_dict_property	100	1	39.69 us	0.785 us	1.880 us	39.13 us	3.9063	-	16.06 KB
run_obj_normal	100	5	68.25 us	1.129 us	1.056 us	67.89 us	12.9395	-	52.46 KB
run_dict_normal	100	5	59.26 us	0.780 us	0.729 us	59.08 us	18.0664	-	73.28 KB
run_obj_property	100	5	44.90 us	1.366 us	3.874 us	44.39 us	6.8359	-	27.84 KB
run_dict_property	100	5	39.88 us	0.797 us	1.815 us	40.17 us	3.9063	-	16.13 KB
run_obj_normal	100	10	65.97 us	0.596 us	0.528 us	65.81 us	12.4512	0.2441	50.87 KB
run_dict_normal	100	10	61.32 us	0.718 us	0.671 us	61.38 us	16.8457	-	68.59 KB
run_obj_property	100	10	43.40 us	0.867 us	2.010 us	43.09 us	6.8359	-	27.96 KB
run_dict_property	100	10	38.44 us	0.767 us	0.788 us	38.41 us	4.0283	-	16.26 KB
run_obj_normal	1000	1	440.59 us	8.743 us	19.734 us	435.38 us	109.3750	3.9063	444.76 KB
run_dict_normal	1000	1	368.63 us	7.227 us	11.463 us	368.76 us	215.8203	0.9766	874.71 KB
run_obj_property	1000	1	254.84 us	6.116 us	17.647 us	250.79 us	50.2930	-	204.5 KB
run_dict_property	1000	1	159.27 us	3.195 us	9.010 us	159.45 us	16.1133	-	65.35 KB
run_obj_normal	1000	5	421.16 us	8.228 us	13.972 us	421.89 us	112.3047	-	456.53 KB
run_dict_normal	1000	5	360.14 us	7.111 us	16.481 us	359.22 us	216.7969	-	878.04 KB
run_obj_property	1000	5	252.63 us	6.263 us	18.170 us	248.13 us	50.2930	-	204.58 KB
run_dict_property	1000	5	163.12 us	4.105 us	11.974 us	161.47 us	16.1133	-	65.45 KB
run_obj_normal	1000	10	369.26 us	7.483 us	21.708 us	364.90 us	111.3281	-	457.44 KB
run_dict_normal	1000	10	343.91 us	6.037 us	12.468 us	344.69 us	199.2188	-	809.26 KB
run_obj_property	1000	10	257.50 us	6.539 us	19.073 us	251.57 us	50.2930	-	204.71 KB
run_dict_property	1000	10	156.66 us	3.260 us	9.247 us	155.36 us	16.1133	-	65.56 KB

コードクォートは非常に魅力的だが、式の複雑化で node が増えると重くなる・ IL の最適化が効かないといったところで活かしきれなかった。今後速さを求められるメタプロが必要な場面なら活かせるかなと。 pocof ではなさそうだが。

修正して benchmark を取って... の繰り返しだととにかく benchmark 取得のための時間が必要なので、なかなか実装進められず疲れた。改善アイディアを実装するたびに 5 ~ 10 分の検証時間がかかるのは結構ストレスだし、限られた時間しかない状態だと中々許容しにくい。でも家事の隙間に benchmark を回したりで工夫したおかげでそこそこ満足がいく最適化にはなったかなという感触。これで pocof の次の version を出して使い始められる。 benchmark はなんかもう少し気軽に回せるような改善ができないか考えたい。

この先もちまちま最適化していく。クエリ関連では、述語を構築する際に差分コンパイルができたらいいなと考えているので、実験してみたい。以前も触れたが、最適化において .NET Standard 2.0 で使えない機能を使いたい場面が増えた。そろそろ Windows PowerShell だけ .NET Standard 2.0 にして他はより新しい target framework にするとか考えた方が良いかも知れない。多少なりとも複雑性をもたらすからおいそれと始められないけど、いい経験にはなりそうだ。

あと 2025-11 は .NET 10 が来るので、乗り換えて高速化されるのを期待したい。

F# で Cmdlet を書いてる pt.77

Sun, 19 Oct 2025 09:00:00 +0900

krymtkts/pocof を開発した。

とりあえず query を正規表現で分割してから組み立てるのでなくて自前の parser で組み立てるのに書き直し始めたところ。 Parser Combinator にするっつってたが、アレはやめた。どうしても抽象度が上がって関数の数が増えることによる overhead で、さほど速くならないのがわかったからだ。結局 pocof のような小規模な構文だと、小さな関数にまとめた方が圧倒的に速いのがわかってそうした。速さは正義だ。

まず既存のコードに不足しているテストを足して benchmark を足して、そんでからまず単純に書き換えた版を作った。 #372

benchmark は以下の通り。

before(regular expression)

Method	QueryCount	Mean	Error	StdDev	Median	Ratio	RatioSD	Gen0	Allocated	Alloc Ratio
prepareNormalQuery	1	1.455 us	0.0291 us	0.0638 us	1.429 us	1.00	0.06	0.6828	2.79 KB	1.00
preparePropertyQuery	1	1.658 us	0.0327 us	0.0573 us	1.652 us	1.14	0.06	0.7210	2.95 KB	1.06

prepareNormalQuery	3	2.872 us	0.0574 us	0.1353 us	2.830 us	1.00	0.07	1.3275	5.45 KB	1.00
preparePropertyQuery	3	3.310 us	0.0650 us	0.1067 us	3.330 us	1.16	0.06	1.4267	5.84 KB	1.07

prepareNormalQuery	5	4.249 us	0.0847 us	0.1484 us	4.224 us	1.00	0.05	1.9989	8.19 KB	1.00
preparePropertyQuery	5	5.064 us	0.0920 us	0.2187 us	5.011 us	1.19	0.07	2.1439	8.78 KB	1.07

prepareNormalQuery	7	5.615 us	0.1081 us	0.1585 us	5.626 us	1.00	0.04	2.6550	10.84 KB	1.00
preparePropertyQuery	7	6.571 us	0.1270 us	0.1901 us	6.597 us	1.17	0.05	2.8381	11.6 KB	1.07

after(tokenizer + parser)

Method	QueryCount	Mean	Error	StdDev	Ratio	RatioSD	Gen0	Allocated	Alloc Ratio
prepareNormalQuery	1	1.273 us	0.0241 us	0.0237 us	1.00	0.03	0.6828	2.79 KB	1.00
preparePropertyQuery	1	1.334 us	0.0261 us	0.0428 us	1.05	0.04	0.7210	2.95 KB	1.06

prepareNormalQuery	3	2.446 us	0.0485 us	0.0539 us	1.00	0.03	1.3313	5.45 KB	1.00
preparePropertyQuery	3	2.640 us	0.0527 us	0.0881 us	1.08	0.04	1.4267	5.84 KB	1.07

prepareNormalQuery	5	3.735 us	0.0730 us	0.1179 us	1.00	0.04	1.9989	8.19 KB	1.00
preparePropertyQuery	5	3.968 us	0.0778 us	0.1115 us	1.06	0.04	2.1439	8.78 KB	1.07

prepareNormalQuery	7	4.959 us	0.0979 us	0.1005 us	1.00	0.03	2.6550	10.84 KB	1.00
preparePropertyQuery	7	5.168 us	0.0983 us	0.1244 us	1.04	0.03	2.8381	11.6 KB	1.07

after(parser index)

Method	QueryCount	Mean	Error	StdDev	Ratio	RatioSD	Gen0	Allocated	Alloc Ratio
prepareNormalQuery	1	1.208 us	0.0238 us	0.0491 us	1.00	0.06	0.6523	2.66 KB	1.00
preparePropertyQuery	1	1.239 us	0.0245 us	0.0490 us	1.03	0.06	0.6866	2.8 KB	1.05

prepareNormalQuery	3	2.358 us	0.0467 us	0.1054 us	1.00	0.06	1.2970	5.3 KB	1.00
preparePropertyQuery	3	2.517 us	0.0492 us	0.0875 us	1.07	0.06	1.3657	5.58 KB	1.05

prepareNormalQuery	5	3.524 us	0.0691 us	0.1155 us	1.00	0.05	1.9455	7.95 KB	1.00
preparePropertyQuery	5	3.753 us	0.0741 us	0.1530 us	1.07	0.06	2.0370	8.34 KB	1.05

prepareNormalQuery	7	4.680 us	0.0932 us	0.1861 us	1.00	0.06	2.5864	10.59 KB	1.00
preparePropertyQuery	7	4.999 us	0.0990 us	0.1810 us	1.07	0.06	2.7237	11.13 KB	1.05

before(regular expression) が元で、 after(parser index) が最終形。 after(tokenizer + parser) は中間の状態で、元の tokenizer と parser が別れてたやつ。これも統合したほうが速くなった。結果的に、普通の query と property query 共に元の 2 割ほど実行時間を短縮できた。

さらにここから、差分 compile を導入するだとか、コードクォートで filtering の predicate を構築するのが別れてるのを統合するだとかができたら、更に良さそう。

今回書いてみて思ったのが、効率が良い自前の parser を書くのは、実際のところ .NET Standard 2.0 を target framework にしてると厳しい。 benchmark を取った訳では無いが、多分 ReadOnlySpan を使えばまだ追求できるんじゃないかな。やっぱ文字列操作が重いからな。でも .NET Standard 2.0 では使えないから仕方がないね。

将来的に multi target で build して配布するというのもアリかも知れないが、ややこしいしまだ本気では考えてない。でも Windows PowerShell がいつなくなるかも決まってないから、 multi target が今後性能を追求していくとしたら一番現実的かな。

query の parser を自前で書くのに着手する前は、気持ちを整えるため、ムダに割当されていた List の除去だったり諸々の改善と、その過程で見つけた旧来からの bug を修正していた。結構しょぼい bug が残ってたので、前にも触れたがテストケースを更新するのも重要になってきたな～。 #370 #371

結構書き換わってる気がするので、もうそろそろ新しいの出して自分の日々の仕事でも使おうかな。

F# で Cmdlet を書いてる pt.76

Sun, 12 Oct 2025 09:00:00 +0900

漸くまとまった時間が取れるようになった。とりあえず毎週何もできないとかは当面ないと思われる。

早速 krymtkts/pocof を開発した。主に String 操作の効率化だ。 hot path ではなるべく F# の String module も使わないようにしてみている。 #368

benchmark をとってもみて極端に良くできたところもあれば、何故速くなった・遅くなったかわからないところもある。効果が顕著そうなところを benchmark ピックアップする。

修正前。

Method	Mean	Error	StdDev	Gen0	Allocated
QueryState_getCurrentProperty	89.43 ns	2.249 ns	6.595 ns	0.0267	112 B

Method	Mean	Error	StdDev	Gen0	Allocated
QueryCondition_toString	26.93 us	0.862 us	2.486 us	2.0142	8.38 KB

Method	Mean	Error	StdDev	Gen0	Allocated
invokeAction_AddQuery	1.144 us	0.0228 us	0.0577 us	0.4005	1.64 KB

Method	Mean	Error	StdDev	Gen0	Allocated
invokeAction_BackwardChar	590.3 ns	11.59 ns	24.44 ns	0.0248	104 B
invokeAction_BackwardWord	681.4 ns	12.35 ns	14.70 ns	0.0477	200 B

修正後。

Method	Mean	Error	StdDev	Gen0	Allocated
QueryState_getCurrentProperty	51.49 ns	1.229 ns	3.547 ns	0.0153	64 B

Method	Mean	Error	StdDev	Allocated
QueryCondition_toString	4.406 ns	0.0873 ns	0.2361 ns	-

Method	Mean	Error	StdDev	Gen0	Allocated
invokeAction_AddQuery	1.093 us	0.0217 us	0.0434 us	0.4005	1.64 KB

Method	Mean	Error	StdDev	Gen0	Allocated
invokeAction_BackwardChar	535.8 ns	10.61 ns	18.57 ns	0.0248	104 B
invokeAction_BackwardWord	689.1 ns	12.58 ns	22.68 ns	0.0477	200 B

String.length が不要な箇所は直に String.Length を使ってみるのは、実際に StringModule.Length の呼び出しがなくなる分僅かに速くなる。 invokeAction の AddQuery や BackwardChar はそれに当たるとだろう。何故か BackwardWord は遅くなってしまったが軽微な差なので誤差かな。

QueryState.getCurrentProperty は中間文字列を生成していたのをやめて 4 割ほど高速化した。

         let getCurrentProperty (state: QueryState) =
             let s =
-                state.Query
-                |> String.upToIndex state.Cursor
-                |> fun x -> String.fromIndex <| x.LastIndexOf " " + 1 <| x
+                let q, c = state.Query, state.Cursor
+                let start = if c > 0 then q.LastIndexOf(' ', c - 1) + 1 else 0
+                q.Substring(start, c - start)

また QueryCondition.toString に関しては list の生成と中間文字列の生成を一切なくすことで、比較にならないほど劇的に速くメモリも少なくできた。代わりに愚直な match expression を採用したので、全てのケースがベタ書きされているので、一見するとギョッとする。でもある意味 match expression で経路も網羅できてるし「正しい」使い方ではあるかな。速さと省メモリは正義なのだ。

今回修正を試みた中で、完全に読みが外れたのは String interpolation だ。以下に例を示す。

    module InternalState =
        let queryInfo (state: InternalState) (count: int) =
            $" %s{state.QueryCondition |> QueryCondition.toString} [%d{count}]"

    module InternalState =
        let queryInfo (state: InternalState) (count: int) =
            String.Concat(" ", QueryCondition.toString state.QueryCondition, " [", string count, "]")

これらは C# での表現だと以下に compile されていた。

[CompilationArgumentCounts(new int[] { 1, 1 })]
public static string queryInfo(InternalState state, int count)
{
    return PrintfModule.PrintFormatToStringThen(new PrintfFormat<string, Unit, string, string, Tuple<string, int>>(" %s%P() [%d%P()]", new object[2]
    {
        QueryConditionModule.toString(state.QueryCondition@),
        count
    }, null));
}

[CompilationArgumentCounts(new int[] { 1, 1 })]
public static string queryInfo(InternalState state, int count)
{
    return " " + QueryConditionModule.toString(state.QueryCondition@) + " [" + ((IFormattable)(object)count).ToString(null, CultureInfo.InvariantCulture) + "]";
}

String.Concat の方が期待しない形になっているのがよく分かる。なので断然 String interpolation の方が速い。

Method	Mean	Error	StdDev	Median	Allocated
InternalState_queryInfo	0.0462 ns	0.0330 ns	0.0968 ns	0.0 ns	-

Method	Mean	Error	StdDev	Median	Allocated
InternalState_queryInfo	0.1410 ns	0.0528 ns	0.1516 ns	0.0935 ns	-

このような細かいチューニングで、しかも最も遅いところから着手するわけでないという進め方は、仕事だと中々できない。やはり趣味のプログラミングだからこそ、そのような重箱の隅をドリルしまくれる。

当然、これらの分析と改善は今 pocof が使ってる .NET 9 でのみこうなるという可能性が十分にある。それでもこういう挙動を少しずつ頭の中に積んでいくことで、一般的に F# のチューニングで言われているようなパターンの原理を理解できて、良い感じがする。

F# で Cmdlet を書いてる pt.75

Sun, 05 Oct 2025 09:00:00 +0900

krymtkts/pocof を開発した。でも週末の家族のお出かけがずっと続いていて、まとまった時間が取れず簡単なもののみ。今日は大して実装もできてないし、今後の方針を定めるメモを記しておく。要はただの時間稼ぎだ。

#365 しか merge してないが、コツコツと効果を測っては改善、あるいはコードが不整合な部分を徐々に直しているつもり。そのプロセスの中で感じた課題感がいくつかある。

例えば pocof の Sample-based testing が結構穴があるのは前から知ってたが、今回 refactoring 始めてみて改めて実感している。微妙にエッジケースを外してたりして心もとない感じ。そのへんも強化するとなれば Property-based testing に書き直すまとまった時間が必要となり、これまたハードルが高い。でもそういう作り直しこそやる意味がある点ではある。

他に、カーソルの制御に関してはもう実装が各所に散りすぎてるので、大幅に整理しないと自分でも何が起こってるかわからない感じはしてきた。内部状態の整理はずっと課題感あったが億劫でやってなかった。そろそろ本格的にやるしかないか。

あとキー入力から始まる一連の処理の中で、文字列操作が処理速度の中でそれなりに支配的であることが理解できてきた。これについては比較的着手が容易だ。なのでこれからは文字列の操作を減らしていく方向でも調整したいと考えている。具体的には中間文字列の生成を減らすのが目的になる。そうすることで heap に積む量を減らすのが狙いだ。

InternalState や QueryState ではそれなりに単発の String 操作しかされない形になっているので、それ以外の箇所で中間文字列を作成しているような箇所を減らす。ここまで対応したい内容が狭まると、自ずと対象も定まる。 pocof では入力した query を正規表現で分割するし、その結果を取り回すのも文字列操作だ。なので query を読み取ってデータ構造に落とし込むには自前の parser を作るのがいいねという話になる。これについては既に最近でいうと 8 月ごろに触れてる。つまり自分でもわかってたけど放置してただけの課題だ。

2025-10 の半ばも過ぎれば毎週末何処かに行くような状況ではなくなるはずなので、なんとかまとまった時間が取りたい。ただこの言葉自体何度も言っているし、もしそれも叶わないなら、今の生活スタイル自体を改める必要がある。具体的には平日に個人開発の時間を確保するような感じ。でもそれも家事育児で難易度が高い現状なので、仕事の成果を落とさず稼働時間を減らすような試みが必要なのかもなーというのが最近の悩み。うまく実現できれば一段レベルアップできるかな。

F# で Cmdlet を書いてる pt.74 - Reference Tuple と Struct Tuple

Sun, 28 Sep 2025 09:00:00 +0900

krymtkts/pocof を開発した。

#364 で Reference Tuple を Struct Tuple に置き換えて allocation を抑えた。全てのケースではないが一部高速化に寄与した。色々勉強になったので、メモがてら記録しておく。

Reference Tuple は System.Tuple に compile される。 Struct Tuple は System.ValueTuple に compile される。そのため F# の Struct Tuple は C# と Visual Basic の tuple と相互運用できる特徴があるらしい。これらの情報は Microsoft Learn のページが詳しい(当然か)。

Tuples - F# | Microsoft Learn

Reference Tuple は、(64 bit なら) object header の 8B と method table pointer の 8B の計 16B がデフォルトで確保される¹。追加で定義した field 分のメモリが heap に確保される。 value type ではこの object header/method table pointer 分が節約できる。代わりに引数等で渡したときに参照アドレスでなく値がコピーされる。つまりサイズが大きい tuple だとコピー効率が悪くなって遅くなることがある。小さい tuple であれば十分速くてメモリ効率もよく、特に hot path で改善効果が見込める。概ね節約分に収まれば大丈夫だろう。

ここまではわたしも知っていた value type の特徴だ。

ここからは今回初めて知った Reference Tuple の振る舞いについて。よく知られたものと思われるが、個人的におもしろかったので残しておく。

先述の通り Reference Tuple を使っていると heap 割当が発生しそうで全部 Struct Tuple に変えたくなる。だが benchmark 計測してみると、必ずしも heap 割当が発生するわけではなく、小さな Struct Tuple でも遅くなることもある。

例えば以下は ILSpy で F# のコードを decompile して C# のコードで表したものだ。前者は関数内の値の受け渡しに Struct Tuple を使っていた版で、後者は Reference Tuple を使っていた版。

// pocof, Version=0.20.0.0, Culture=neutral, PublicKeyToken=null
// Pocof.Handle
using Microsoft.FSharp.Core;

[CompilationArgumentCounts(new int[] { 1, 1 })]
internal static (Data.InternalState, Query.QueryContext) deleteForwardInput(Data.InternalState state, Query.QueryContext context)
{
    int num = StringModule.Length(state.QueryState@.Query@);
    Data.InputMode inputMode = state.QueryState@.InputMode@;
    (Data.InternalState, Query.QueryContext, int) valueTuple;
    int num2;
    if (inputMode.Tag != 1)
    {
        valueTuple = (state, context, state.QueryState@.Cursor@);
    }
    else
    {
        num2 = inputMode.count;
        int num3 = state.QueryState@.Cursor@;
        int num4 = state.QueryState@.Cursor@ - num2;
        int num5 = ((num3 >= num4) ? num4 : num3);
        (Data.InternalState, Query.QueryContext) tuple = FSharpFunc<int, Data.InputMode>.InvokeFast(setCursor, num5, Data.InputMode.Input, state, context);
        valueTuple = (tuple.Item1, tuple.Item2, num5);
    }
    Data.InternalState state2;
    Query.QueryContext context2;
    (state2, context2, num2) = valueTuple;
    return removeCharsWithInputMode(Direction.Forward, num - num2, state2, context2);
}


// pocof, Version=0.20.0.0, Culture=neutral, PublicKeyToken=null
// Pocof.Handle
using Microsoft.FSharp.Core;

[CompilationArgumentCounts(new int[] { 1, 1 })]
internal static (Data.InternalState, Query.QueryContext) deleteForwardInput(Data.InternalState state, Query.QueryContext context)
{
    int num = StringModule.Length(state.QueryState@.Query@);
    Data.InputMode inputMode = state.QueryState@.InputMode@;
    Data.InternalState state2;
    Query.QueryContext context2;
    int num2;
    if (inputMode.Tag != 1)
    {
        state2 = state;
        context2 = context;
        num2 = state.QueryState@.Cursor@;
    }
    else
    {
        int num3 = inputMode.count;
        int num4 = state.QueryState@.Cursor@;
        int num5 = state.QueryState@.Cursor@ - num3;
        int num6 = ((num4 >= num5) ? num5 : num4);
        (Data.InternalState, Query.QueryContext) tuple = FSharpFunc<int, Data.InputMode>.InvokeFast(setCursor, num6, Data.InputMode.Input, state, context);
        Data.InternalState item = tuple.Item1;
        Query.QueryContext item2 = tuple.Item2;
        state2 = item;
        context2 = item2;
        num2 = num6;
    }
    return removeCharsWithInputMode(Direction.Forward, num - num2, state2, context2);
}

Reference Tuple の方は、最適化で Reference Tuple の存在が消し去られているのだろうとわかる。 Struct Tuple の方は、そのまま関数内の値の受け渡しにも tuple が使われたままになることがあった。その tuple がある分のコストがかかるので、この場合は Reference Tuple の方が速いしメモリの割当も少ない。このような tuple が公開されていない場合は Struct Tuple が不利となる場合があると理解できる。

でも例えば、公開された関数の戻り値が Reference Tuple の場合は、確実に Reference Tuple の利用が発生する。以下は、前者は戻り値の型が Struct Tuple を使っていた版で、後者は Reference Tuple を使っていた版の F# → (decompile) → C# のコード。

public override (int, int, int, int) Invoke(Unit unitVar0)
{
  int windowHeight = this.@this.rui.GetWindowHeight();
  return (0, 1, 2, windowHeight - 3);
}

public override Tuple<int, int, int, int> Invoke(Unit unitVar0)
{
    int windowHeight = this.@this.rui.GetWindowHeight();
    return new Tuple<int, int, int, int>(0, 1, 2, windowHeight - 3);
}

このケースでは前者が圧倒的に良い。メモリも 4 + 4 + 4 + 4 = 16 byte のみ。 Reference Tuple なら object header + method table pointer = 16 byte が更に乗って 32 byte だからだ。

端的に言えば Reference Tuple は F# の compile 時の optimization で優遇されているみたい、というのが今回具体的にわかった。この特徴からも、よく言われる「 Benchmark を測って利用が最適か評価する」必要があるということになる。いちいち計測するのも時間がかかって大変だが。勉強になったわ～。

どうも The Book of the Runtime を読めばそれがわかるらしいが調べられてない。わたしは ObjectLayoutInspector を使ってその存在を知っているだけだ。また、いくつかの古い文書では可視化されたそれらの画像を確認できる。 Managed object internals, Part 1. The layout - Developer Support は ObjectLayoutInspector 作者の記事。 .NET Framework Internals: How the CLR Creates Runtime Objects | Microsoft Learn の ObjectInstance の節とか。 ↩

Chocolatey で install した pyenv-win を uninstall する

Sun, 21 Sep 2025 09:00:00 +0900

休みの日が家族とのお出かけで潰れがちで開発ネタが無くなってきたので、今日は小ネタを書く。

uv を使うまでは長らく pyenv-win を使ってた。でも uv 導入後は使わなくなって以降もそのまま放置していたので、思い立って pyenv-win を uninstall してみた。

pyenv-win を Chocolatey で install してたのでまずは chocolatey で uninstall する。わたしはいつも chocolatey を使うときは cmd でやる。 PowerShell を更新するときとかに面倒だからだ。

Chocolatey Software | pyenv-win 3.1.1

管理者権限で以下を実行した。 (Sudo for Windows が使えるようになってるがまだ余り試していないので古き良き手法で)

C:\Users\takatoshi>choco uninstall pyenv-win -y
Chocolatey v2.5.1
Uninstalling the following packages:
pyenv-win

pyenv-win v3.1.1
 Skipping auto uninstaller - No registry snapshot.
 pyenv-win has been successfully uninstalled.
Environment Vars (like PATH) have changed. Close/reopen your shell to
 see the changes (or in powershell/cmd.exe just type `refreshenv`).

Chocolatey uninstalled 1/1 packages.
 See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).

Chocolatey の package によくある uninstall は何もしないやつだった。なのでバイナリの除去とばらまかれた環境変数の掃除は自分でやる必要がある。

まず、ばらまかれた環境変数に何があるかは以下の文書が参考になる。

Add System Settings | pyenv-win/docs/installation.md at master · pyenv-win/pyenv-win

この辺を消せば良さそうだとわかる。

[System.Environment]::SetEnvironmentVariable('PYENV',$env:USERPROFILE + "\.pyenv\pyenv-win\","User")
[System.Environment]::SetEnvironmentVariable('PYENV_ROOT',$env:USERPROFILE + "\.pyenv\pyenv-win\","User")
[System.Environment]::SetEnvironmentVariable('PYENV_HOME',$env:USERPROFILE + "\.pyenv\pyenv-win\","User")
[System.Environment]::SetEnvironmentVariable('path', $env:USERPROFILE + "\.pyenv\pyenv-win\bin;" + $env:USERPROFILE + "\.pyenv\pyenv-win\shims;" + [System.Environment]::GetEnvironmentVariable('path', "User"),"User")

しかしわたしの環境では上記とは違った。 Chocolatey で入れてるからかな。 User variable の path に含まれる pyenv-win の値は文書通りだった。

[System.Environment]::GetEnvironmentVariables("User").GetEnumerator() | ? Name -Like pyenv
# 出力なし
[System.Environment]::GetEnvironmentVariables("Machine").GetEnumerator() | ? Name -Like pyenv
#
# Name                           Value
# ----                           -----
# PYENV                          %USERPROFILE%\.pyenv\pyenv-win\
#
[System.Environment]::GetEnvironmentVariable('Path', 'User') -split ';' | ? {$_ -match 'pyenv'}
#
# C:\Users\takatoshi\.pyenv\pyenv-win\bin
# C:\Users\takatoshi\.pyenv\pyenv-win\shims
#

以下を管理者権限で実行して消す。 SetEnvironmentVariable の第 2 引数を '' と $null にしても環境変数を消せなかったため reg 直に消した。

$pyenv = Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment' -Name 'PYENV'
Remove-ItemProperty -Path $pyenv.PSPath -Name 'PYENV'

$filtered = [System.Environment]::GetEnvironmentVariable('path', 'User') -split ';' | ? {$_ -notmatch 'pyenv'}
[Environment]::SetEnvironmentVariable('Path', $filtered -join ';', 'User')

pyenv-win のバイナリがどこにあるかを確認し、消す。

Get-Command pyenv
#
# CommandType     Name                                               Version    Source
# -----------     ----                                               -------    ------
# ExternalScript  pyenv.ps1                                                     C:\Users\takatoshi\.pyenv\pyenv-win\bin\pyenv.ps1
#
rm -Recurse -Force ~/.pyenv

ファイル数が多くて古い自機だと削除に十数秒かかった。

多分これできれいになったはず。他にも使わなくなったものが溜まってるだろうけど、目についたら消すって感じで。今年買い替えるつもりだったがなんか時期を逃してしまって、いつまでこの古い Razer blade stealth 2017 を使うかわからない。新しいのに買い替えるなら、ガッツリ使えるタイミングで買い替えたいもんな。

F# で Cmdlet を書いてる pt.73 - pocof 0.20.0

Sun, 14 Sep 2025 09:00:00 +0900

krymtkts/pocof を開発した。

0.20.0 をリリースをした。

benchmark 上は 100 万件とかの追加だともとより遅くなってそうだが、メモリ効率は良くなっているし全ての件数に於いて走査は速くなって。あとは実際に使ってみて変な bug が無いかを見たい。次はこれまた細かい効率化の修正を入れていこうと考えている。

今回のリリースで更新を忘れていた Command help(pocof-Help.xml) に word 単位の操作の shortcut が反映された。その作業自体はたいしたことなかったが、最新の PlatyPS を使うのが結構面倒だった。 #361

今の最新は Microsoft.PowerShell.PlatyPS v1.0.1 。多分前回は 1.0.0-preview1 を使ってるのかな？随分変わってる。この手の作業はいつもわからなくなるので psake の task にまとめているが、今まで通りのやり方だと出力結果がめちゃくちゃになるので、1 つずつ手で行った。余談として、いつものことだが PowerShell Gallery の検索が機能してないときは、 /packages/ の後ろに直に package 名を打ち込んで飛ぶのが良い。

まず最初に Update-MarkdownCommandHelp で既存の Markdown help を更新してみた。この手順でセクション内の要素が何故か 2 重 3 重に出力されてしまうのでもうダメだなと判断。既存ファイルを削除して New-MarkdownCommandHelp を実行後、差分を反映した。こんな感じ。

New-MarkdownCommandHelp -ModuleInfo (Get-Module pocof) -OutputFolder .\docs\ -HelpUri 'https://github.com/krymtkts/pocof/blob/main/docs/pocof/Select-Pocof.md' -Locale en-US

前回リリース時にどの version を使ったか忘れてしまったが、 parameter に余分な ParameterValue: [] が生えて問題だった。それが v1.0.1 だと解消されていた。これは version up によるいいところだが、個人的には悪いところの方が多いと感じた。

他、 Markdown の表の中に . があると余計な改行が挟まれて表が崩れるようだった。幸い実装予定から削った shortcut の除去により . が消えて正しく生成されるようになった。

そして最後の問題が、 Export-MamlCommandHelp 。 MAML help export 後に example の各 code block 直後に <maml:para></maml:para> が差し込まれてしまう。なんじゃこりゃ。以下の issue と同じ問題に悩まされた。

Export-MamlCommandHelp doesn't handle fenced code blocks in examples · Issue #799 · PowerShell/platyPS

上記の issue を読むに、この挙動は PlatyPS の仕様であり、 code block による sample code の例示が非推奨であるような印象を受けた。ただし「bug ではありません。仕様です。」で issue が閉じられて以降は特に回答もなく、推奨される example の書き方はわからないままだ。結局自動化の policy に反するが、出力結果に含まれる余計な <maml:para></maml:para> を手で削って MAML help を仕上げた。実に残念や。

今回はこれで乗り切ったが、次回もこれだとちょっと嫌だな。挙動が意図したものか否かがわからないってのは結構きつい。なのでもう少し PlatyPS の設計(/docs にあるみたい)を読んで理解を深めたい。分量的にまありえられるものがなさそうだけど。

パッと見 PlatyPS 自体は PlatyPS を使ってない。 PowerShell Gallery を見ても downloads が他の PowerShell の package に比べてかなり低い。これらから考えるとあまり使われてなくて機能が磨かれてないと見るのが妥当か。こういう状況なので、自力でなんとかして調べていくための動機づけが中々難しいが、 AI サンに手伝ってもらったりで誤魔化しつつ進めていくかー。

F# で Cmdlet を書いてる pt.72 - Single-producer/single-consumer append-only buffer 改善

Sun, 07 Sep 2025 09:00:00 +0900

krymtkts/pocof を開発した。

ConcurrentQueue に代わる collection の実装をまだやってた。 #358 #359 で実施。

分岐の改善、 property access の削減等ちまちました改善と、あと bug が混入してたので coverage 100% にするためのテストを AI に追加させてみた。大幅に性能が改善された感じではない。でも個人的には勉強なったものもある。例えば Happened-before や MethodImplOptions.AggressiveInlining 。

元々 SPSC append-only buffer では件数の読み書きと次の segment の更新に Volatile を利用していた。次の segment の読みに Volatile.Read が不要なのは happens-before 関係があるためだった。実はこの次の segment の更新も同様みたいで、結局件数の読み書きによって次の segment の更新は保証されてるようだった。以下にざっくり変更箇所を示す。

type SpscSegment<'T>(capacity: int) =
     let mutable next: SpscSegment<'T> | null = null
     member __.Items = items
     member __.Capacity = items.Length
-    // NOTE: Non-volatile read: safe after reader has observed published count.
-    member __.Next = next
-    // NOTE: Writer-side publish with volatile write to establish happens-before with count increment.
-    member __.PublishNext(seg: SpscSegment<'T>) = Volatile.Write(&next, seg)
+    // NOTE: Non-volatile reads/writes are safe once the reader has observed the published SpscAppendOnlyBuffer.count.
+    member __.Next
+        with get () = next
+        and set v = next <- v

...

type SpscAppendOnlyBuffer<'T>() =
     let readCount () = Volatile.Read(&count)
     let writeCount (v: int) = Volatile.Write(&count, v)

+    [<MethodImpl(MethodImplOptions.AggressiveInlining)>]
     member __.Add(item: 'T) : unit =
         // NOTE: Acquire local view of the current tail segment.
         let t = tail
         let idx = tailIndex
+        let cap = t.Capacity

-        if idx >= t.Capacity then
+        if idx >= cap then
             // NOTE: Current segment is full: create a new one, link it, and advance tail.
-            let newSeg = SpscSegment<'T>(min (t.Capacity <<< 1) segSizeMax)
+            let newSeg = SpscSegment<'T>(min (cap <<< 1) segSizeMax)
             // NOTE: Publish linkage before the element becomes observable via count.
-            t.PublishNext newSeg
+            t.Next <- newSeg
             tail <- newSeg
             // NOTE: Write into the new tail
             newSeg.Items[0] <- item
             tailIndex <- 1
         else
             t.Items[idx] <- item
             tailIndex <- idx + 1

         // NOTE: Publish new count after the element write (happens-before for reader).
         // NOTE: A volatile read is not required because SPSC guarantees a single writer.
         writeCount (count + 1)

AI に説明させたり順を追って注意深く読むとわかるのだけど、一目で「あ～ happens-before 関係やな(ｷﾘｯ」といえるくらいには理解したいな。

あと MethodImplOptions.AggressiveInlining を初めて知った。 .NET の JIT に対して(少しは AOT に対しても) inlining したいというヒントを強く与える属性みたい。あくまでヒントで必ずではない。例えばクソデカメソッドなんかだと inlining されないらしい。 SPSC append-only buffer の場合は元々付与したいメソッドが小さいので付けてなくても inlining されることが多いようだが、 hot path では付与する価値がある。 F# の inline は IL を複製するパターンで、こちらは JIT の実行時に複製を判断するという違いがある。

今振り返ると MoveNext と Add にはつける意味あるが GetEnumerator は呼び出し回数がさほど多くないだろうし意味なさそうだ。まとめて属性を付けて bench 結果が改善したようだったのでそのままにしてたけど、削っていいな。

最終的な benchmark はこんな感じだった。

Add

Method	EntryCount	Mean	Error	StdDev	Ratio	RatioSD	Gen0	Gen1	Gen2	Allocated	Alloc Ratio
ConcurrentQueue	100	1,853.6 ns	49.35 ns	141.60 ns	1.01	0.11	1.0529	-	-	4.31 KB	1.00
SpscAppendOnlyBuffer	100	829.8 ns	16.53 ns	33.40 ns	0.45	0.04	0.2575	-	-	1.05 KB	0.24

ConcurrentQueue	10000	278,770.7 ns	5,498.68 ns	9,773.89 ns	1.00	0.05	41.5039	41.5039	41.5039	257.83 KB	1.00
SpscAppendOnlyBuffer	10000	88,778.9 ns	1,691.91 ns	3,177.83 ns	0.32	0.02	19.4092	-	-	79.66 KB	0.31

ConcurrentQueue	1000000	23,523,948.8 ns	438,956.52 ns	505,502.98 ns	1.00	0.03	125.0000	93.7500	93.7500	16387.36 KB	1.00
SpscAppendOnlyBuffer	1000000	27,094,229.8 ns	427,652.16 ns	357,108.92 ns	1.15	0.03	1281.2500	937.5000	-	7868.55 KB	0.48

Iterate

Method	EntryCount	Mean	Error	StdDev	Median	Ratio	RatioSD	Gen0	Allocated	Alloc Ratio
ConcurrentQueue_iterate	100	950.3 ns	18.94 ns	54.04 ns	950.3 ns	1.00	0.08	0.0172	72 B	1.00
SpscAppendOnlyBuffer_iterate	100	733.9 ns	14.60 ns	22.29 ns	737.6 ns	0.77	0.05	0.0134	56 B	0.78

ConcurrentQueue_iterate	10000	79,012.7 ns	1,571.08 ns	2,989.13 ns	78,779.6 ns	1.00	0.05	-	72 B	1.00
SpscAppendOnlyBuffer_iterate	10000	65,541.9 ns	1,287.66 ns	2,541.71 ns	65,775.4 ns	0.83	0.04	-	56 B	0.78

ConcurrentQueue_iterate	1000000	12,770,833.4 ns	727,602.69 ns	2,099,300.27 ns	12,829,000.0 ns	1.03	0.25	-	74 B	1.00
SpscAppendOnlyBuffer_iterate	1000000	8,072,519.3 ns	442,006.93 ns	1,232,138.74 ns	7,454,282.8 ns	0.65	0.15	-	62 B	0.84

大量件数の追加以外は ConcurrentQueue より良さそう。 ConcurrentQueue は 32 ~ 1,048,576(1024 * 1024) の範囲で segment の要素数を決めてる。これが大量件数の場合に利いてくるっぽい。 runtime/src/libraries/System.Private.CoreLib/src/System/Collections/Concurrent/ConcurrentQueue.cs

代わりに bench で gen2 が発生してるし、多分大量の要素があるケースで LOH が発生することは諦めてる設計と思われる。まあ確かに queue にそんな件数溜まるのは、データが適切に捌けてないケースだけか。

PowerShell の場合だと、 Cmdlet は呼び出しが終われば破棄されるが、そのときに LOH があると破棄のときに必ず回収されるものではない。つまり同じ PowerShell の session で Cmdlet の実行を繰り返すと LOH が溜まり続けることになる。この認識で合ってるかな。こうしてみると、 pocof はなるべく LOH を発生させないようにして session を clean に保った方が無難に思えるな。いま LOH の発生を嫌って segment 内の配列サイズを最大 1024 にしてる。もし ConcurrentQueue と同じようなクソデカ segment 方式にすれば多分速くなるけど LOH が発生しメモリが肥大化し続けそう。 .NET や PowerShell Cmdlet のメモリの仕組みに詳しくないので、もっと研究しておく必要があるな。

とりあえず今のままが一旦良さそうに思えてきたな。一応この現状で良さそうな踏ん切りはついてきたので、いい加減 pocof を新しい version で公開する方向で動くか。

booklog はじめて 1 年間過ぎてた

Sun, 31 Aug 2025 09:00:00 +0900

気づいたら booklog を始めてから 1 年間を超えてた。 2024-08-19 から booklog が始まって、昨日時点で 377 日連続して読書できてるらしい。在宅勤務で失われてた読書習慣を取り戻した感じには十分なってんじゃないかな。

1 年とちょっとの間、再読・つまみ読み・読み終わっていない本も含め 24 冊読めた。真面目に選り分けた訳ではないのでアレだが、だいたい積読消化と買った本で半々くらいの割合になってると思われる。今は昔ほど何でもかんでも気になった本を買ってるわけじゃないけど、今くらいのスピード感で買いつつ積読消化しつつをバランスよく運用するのが、現状ベストか。当時とて読書スピードが積読スピードに負けて溜まっていくばかりだったし。

単純計算して 1 ヶ月で 1 ~ 2 冊は読めてるのだけど、積読量が多いからもっと処理できる冊数を増やせると嬉しいところだ。ただそうなると現状の booklog をつけるだけでは強制力が足りなくて、より多く時間を確保するための習慣が必要になるだろう。例えば昼飯の休憩をきっかり 1 時間取って、その間に読めるだけ読み切るとか。とはいえ瞬時に昼飯を処理して仕事を再開・フロー状態を維持するというような休憩の仕方なので、どうかな。仕事は極めて裁量が高いので時間はどうとでも調整できるだろうけど、日中は割とずっと仕事モード ON なので影響がなあ。

あと 1 年ほど続けてみてわかったのは、寝る前に読書するよりもなるべく夕方ぐらいまでに読書が済んでいる方が、自分の生活では就寝までのリズムがスムースなところ。寝る前に落ち着いて読書して就寝、みたいなのも憧れるが、子どもの世話をしてるとそうはいかないし、読みきれなかったら寝る時間が遅くなって寝不足になりそうなので良くない。子どもの宿題を見るタイミングで自分も読書するのが一番好みの感じだったのだが、あまり上手くいかなかった。やれる日もあるが、並行して家事をする必要がある日になると確実に読書できるわけじゃなく、結局夕食後や寝る前の読書になりがちだった。自分の習慣に関しては、締切に追われて何かするより、もっと制御できている計画通り感がほしい。

ということで、今既に 2 年目に突入しているが、差し込みたい変化としては読むタイミングの調整を意識的に行うことかな。当然予定がある休日等は日中の読書ができないわけだが(今日が早速まさにそう)、そこも何か別の手法を編み出したい。 1 年間できたらもうこの先も同じ負荷なら絶対できるというのが手にとってわかるのは、実によろしい。絶対にできるという実感があれば、多少の変化でリスクを持ち込むのも楽しいものになる。

F# で Cmdlet を書いてる pt.71 - Single-producer/single-consumer append-only buffer

Sun, 24 Aug 2025 09:00:00 +0900

krymtkts/pocof を開発した。

ConcurrentQueue に代わる collection の実装 #357 に関して。書き込み / 読み込み thread が 1 つずつで追加しかしないという限定用途から Single-producer/single-consumer append-only buffer と呼ぶことにした。前回は、 MPMC の ConcurrentQueue より機能が少ない SPSC append-only buffer の方が遅くて残念な結果だったので、色々直した。その結果、 ConcurrentQueue を置き換える価値があるものにできた。以下に比較の benchmark を記す。

書き込みは以下の通り。

Method	EntryCount	Mean	Error	StdDev	Ratio	RatioSD	Gen0	Gen1	Gen2	Allocated	Alloc Ratio
ConcurrentQueue	100	1,803.8 ns	43.06 ns	124.25 ns	1.00	0.10	1.0529	-	-	4.31 KB	1.00
SpscAppendOnlyBuffer	100	794.2 ns	15.84 ns	30.14 ns	0.44	0.03	0.2575	-	-	1.05 KB	0.24

ConcurrentQueue	10000	283,355.0 ns	5,653.88 ns	13,326.85 ns	1.00	0.07	41.5039	41.5039	41.5039	257.83 KB	1.00
SpscAppendOnlyBuffer	10000	89,695.3 ns	1,787.21 ns	2,886.01 ns	0.32	0.02	31.0059	7.6904	-	127.38 KB	0.49

ConcurrentQueue	1000000	29,405,508.3 ns	1,432,592.75 ns	4,178,940.60 ns	1.02	0.20	125.0000	93.7500	93.7500	16387.36 KB	1.00
SpscAppendOnlyBuffer	1000000	26,947,905.9 ns	522,309.93 ns	436,152.45 ns	0.93	0.13	1281.2500	1187.5000	-	7878 KB	0.48

読み込みは以下の通り。

Method	EntryCount	Mean	Error	StdDev	Ratio	RatioSD	Gen0	Allocated	Alloc Ratio
ConcurrentQueue_iterate	100	948.1 ns	19.01 ns	51.73 ns	1.00	0.08	0.0172	72 B	1.00
SpscAppendOnlyBuffer_iterate	100	858.9 ns	17.18 ns	30.09 ns	0.91	0.06	0.0134	56 B	0.78

ConcurrentQueue_iterate	10000	81,575.8 ns	1,601.53 ns	2,445.71 ns	1.00	0.04	-	72 B	1.00
SpscAppendOnlyBuffer_iterate	10000	74,501.3 ns	1,406.56 ns	1,674.41 ns	0.91	0.03	-	56 B	0.78

ConcurrentQueue_iterate	1000000	9,323,906.6 ns	184,295.18 ns	270,137.50 ns	1.00	0.04	-	78 B	1.00
SpscAppendOnlyBuffer_iterate	1000000	7,588,917.4 ns	123,090.41 ns	155,669.97 ns	0.81	0.03	-	59 B	0.76

書き込みで中規模まで大幅優位で、大規模でもわずかながら優位な感じ。大規模でも性能を落としてきてるのは、 segment の拡張戦略があまり良くないことによるみたい。ここはもっと改善ができたら良さそう。

読み込みは全サイズで優位そう。大規模(1M)での効果が高く、全体的にメモリ確保量が半分以下なので、これも良さそう。 segment がでかすぎて長寿命化(Gen1 昇格)してるみたいなので、ここはもっと改善ができそうかな。ただし segment のサイズを縮めた場合は segment の数が増えて列挙の遅さに繋がる可能性がある。

性能改善に大きく寄与した具体的な変更は以下の通り。備忘のため GitHub Copilot と分析した結果も添えておく。

Volatile.Read Volatile.Write を極力少なくする
- volatile 利用により、 .NET の JIT 最適化の制限とメモリアクセス増加で遅くなる
(読みのみ)IEnumerator 実装に seq を使わず専用の struct enumerator を実装する
- seq の汎用コードを使わないことで JIT 最適化したのと、 struct 化によるヒープ除去

Volatile を少なくした改善はちょっとややこしかった。

 type SpscSegment<'T>(capacity: int) =
     let items: 'T array = Array.zeroCreate capacity
     let mutable next: SpscSegment<'T> | null = null
-    member _.Items = items
-    member _.Capacity = items.Length
-
-    member _.Next
-        with get () = Volatile.Read(&next)
-        and set (v) = Volatile.Write(&next, v)
+    member __.Items = items
+    member __.Capacity = items.Length
+    // NOTE: Non-volatile read: safe after reader has observed published count.
+    member __.Next = next
+    // NOTE: Writer-side publish with volatile write to establish happens-before with count increment.
+    member __.PublishNext(seg: SpscSegment<'T>) = Volatile.Write(&next, seg)

[<Sealed>]
 type SpscAppendOnlyBuffer<'T>() =
     // 略

     // NOTE: Volatile helpers for count.
     let readCount () = Volatile.Read(&count)
     let writeCount (v: int) = Volatile.Write(&count, v)

     member __.Add(item: 'T) : unit =
         // NOTE: Acquire local view of the current tail segment.
         let t = tail
         let idx = tailIndex

         if idx >= t.Capacity then
             // NOTE: Current segment is full: create a new one, link it, and advance tail.
             let newSeg = SpscSegment<'T>(min (t.Capacity <<< 1) segSizeMax)
             // NOTE: Publish linkage before the element becomes observable via count.
-            t.Next <- newSeg
+            t.PublishNext newSeg
             tail <- newSeg
             // NOTE: Write into the new tail
             newSeg.Items[0] <- item
             tailIndex <- 1
         else
             t.Items[idx] <- item
             tailIndex <- idx + 1

         // NOTE: Publish new count after the element write (happens-before for reader).
         // NOTE: A volatile read is not required because SPSC guarantees a single writer.
         writeCount (count + 1)

この seq を使った IEnumerator 実装は遅かった。

     interface IEnumerable<'T> with
-        member __.GetEnumerator() : IEnumerator<'T> =
-            // NOTE: Snapshot the count once; traverse segments accordingly.
-            let snapshotCount = readCount ()
-            let mutable remaining = snapshotCount
-            let mutable seg = head
-            let mutable idx = 0
-
-            (seq {
-                while remaining > 0 do
-                    if idx >= seg.Capacity then
-                        seg <- seg.Next
-                        idx <- 0
-
-                    yield seg.Items[idx]
-                    idx <- idx + 1
-                    remaining <- remaining - 1
-            })
-                .GetEnumerator()

struct enumerator を実装することでコードは増えたが断然速くなった。

+[<Struct>]
+type SpscSegmentEnumerator<'T> =
+    val mutable private remaining: int
+    val mutable private seg: SpscSegment<'T>
+    val mutable private items: 'T array
+    val mutable private cap: int
+    val mutable private idx: int
+    val mutable private current: 'T
+
+    new(head: SpscSegment<'T>, total: int) =
+        let items = head.Items
+
+        { remaining = total
+          seg = head
+          items = items
+          cap = items.Length
+          idx = 0
+          current = Unchecked.defaultof<'T> }
+
+    // NOTE: for F# pattern enumeration optimization (zero allocation via struct enumerator).
+    member __.Current = __.current
+
+    // NOTE: for F# pattern enumeration optimization (zero allocation via struct enumerator).
+    member __.MoveNext() =
+        if __.remaining <= 0 then
+            false
+        else
+            if __.idx >= __.cap then
+                match __.seg.Next with
+                | null -> __.remaining <- 0
+                | next ->
+                    __.seg <- next
+                    let items = next.Items
+                    __.items <- items
+                    __.cap <- items.Length
+                    __.idx <- 0
+
+            if __.remaining > 0 then
+                let i = __.idx
+                __.current <- __.items[i]
+                __.idx <- i + 1
+                __.remaining <- __.remaining - 1
+                true
+            else
+                false
+
+    // NOTE: No resources to release.
+    member __.Dispose() = ()
+
+    interface IEnumerator<'T> with
+        member __.Current = __.current
+
+    interface IEnumerator with
+        member __.Current = box __.current
+        member __.MoveNext() = __.MoveNext()
+        member _.Reset() = raise (NotSupportedException())
+
+    interface IDisposable with
+        member __.Dispose() = __.Dispose()

SpscSegmentEnumerator で count 書き側の release (Volatile.Write) と読み側の acquire (Volatile.Read) が噛む publish 境界(happens-before の境界)になっている。なので単調に一方向へ連結された segment の、読み込みに必要な範囲については余計な volatile を省ける。読み込み時は最初に snapshot した count の要素数分は書き終えていることが保証され、残り要素数が 0 なら next にアクセスすることもない。だから next の読みは volatile なしでも安全に読める。実は書き側も理論上 next の Volatile.Write を外せるようなのだが、まだちゃんと確認しきれていない。 release/acquire 、 happens-before といったキーワードをもっと理解したら削ってみるか。

またこのデータ型は、大前提として SPSC append-only という限定用途のみにしか適さないので、他の用途が出てきたら使い物にならなくなる。でも pocof であれば、今のところ他の用途の可能性がないので、多分当分このままでいける。

改善できそうなところがまだ少し残ってるし、もう少し改善できたら良さげ。 ConcurrentQueue が pocof の性能の支配的な部分ではないからここばかり改善しても大差ないのだが、趣味なのでヨシッ！

F# で Cmdlet を書いてる pt.70 - Single-producer/single-consumer lock-free buffer(仮)

Sun, 17 Aug 2025 09:00:00 +0900

krymtkts/pocof 開発をした。

StreamWriter.AutoFlush を無効にした console output の最適化は失敗した。カーソル位置の計算が難しく、期待通りの挙動をさせるには、書き込みの都度 StreamWriter.Flush する必要があり、意味ないなと諦めた。代わりに Console.Write の呼び出し回数を減らすための改善をした。 #351 I/O が減った分、 CPU が忙しいときも多少キビキビするようになった気はするかな。 StreamWriter.AutoFlush 作戦は、経験を積んだあと再挑戦してもいいか。

他にも hot path での list 生成をなくすとか struct を利用することで heap 割り当てをなくすとか。 #352 #354 #356 劇的に性能に影響のある修正ではないので、コツコツ積み重ねるようなものばかり。

list 生成を減らすパターンは極端に hot な箇所なら劇的な効果があるが、今回特に顕著な差はなかった。これ系の最適化を進めていると、やはり pocof の状態管理を担っている record が気になってくるところ。小さい record に分割するか、 byref を組み合わせるか。この話はもう何度も書いてるが着手してないのはひとえに先述のようにそこまで劇的な変化がないからやる気が出ないのかもな。

他方、今気になってるのは絞り込み対象のデータを保管するのに ConcurrentQueue を利用している点だ。書き込みのみの thread と読み込みのみの thread が分かれているので、安全に読み書きするためにと思って .NET にすでにある順序を保持するデータ構造を採用したらこうなった。このケースはいわゆる Single-producer/single-consumer (SPSC) というパターンみたいで、 lock-free なデータ構造でも捌けるみたい。内部的には分割された array を持っているだけで、参照は head の、追加は tail の pointer を参照する。例えば .NET の ArrayList 実装はサイズ拡張時に内部配列を swap するので、そのときに競合しうる。 SPSC lock-free buffer(仮) だと参照で決まったサイズまでしか読まないので書き込みと競合しない。

ConcurrentQueue は複数 thread からの書き込みに対応してる点からも書き込み時点で順序保持するため何らかの lock をしていそうと考えた。であれば lock-free なデータ構造よりも追加時の overhead がある。なので、もしかしたらデータ構造の変更で速くなるかもなと検証を始めた。

ところが試しに実装してみたところ成果が出なかった。 BenchmarkDotNet で追加だけ 100 件・ 10,000 件・ 1,000,000 件を計測してみた。 10,000 件はなぜか順調だが、 100 件は差がなく、 1,000,000 件のような大量件数だとむしろ遅い。#357 segment のサイズを固定にしてるので、件数が少ないとメモリが過剰だが、多いときは良さそう。

// Benchmark Process Environment Information:
// BenchmarkDotNet v0.14.0
// Runtime=.NET 9.0.8 (9.0.825.36511), X64 RyuJIT AVX2
// GC=Concurrent Workstation
// HardwareIntrinsics=AVX2,AES,BMI1,BMI2,FMA,LZCNT,PCLMUL,POPCNT VectorSize=256
// Job: DefaultJob

Method	EntryCount	Mean	Error	StdDev	Ratio	RatioSD	Gen0	Gen1	Gen2	Allocated	Alloc Ratio
ConcurrentQueue	100	5.413 us	0.1075 us	0.2492 us	1.00	0.06	5.2948	0.0076	-	21.63 KB	1.00
SpscAppendOnlyBuffer	100	5.507 us	0.1088 us	0.2069 us	1.02	0.06	6.2103	-	-	25.41 KB	1.17

ConcurrentQueue	10000	2,019.421 us	40.3491 us	76.7684 us	1.00	0.05	351.5625	230.4688	82.0313	2279.87 KB	1.00
SpscAppendOnlyBuffer	10000	1,071.990 us	20.8937 us	35.4790 us	0.53	0.03	353.5156	335.9375	-	2102.62 KB	0.92

ConcurrentQueue	100000	54,099.111 us	1,072.9361 us	1,235.5948 us	1.00	0.03	4100.0000	2400.0000	800.0000	22354.19 KB	1.00
SpscAppendOnlyBuffer	100000	56,827.114 us	2,239.2215 us	6,167.4668 us	1.05	0.12	4181.8182	2454.5455	818.1818	21093.03 KB	0.94

当然だが ConcurrentQueue は相当速いな。実装見てなかったので調べてみたら、同じ原理を利用して極力 lock-free で動くようになってた。実装をみたらわかるが、 Compare And Swap (CAS)というパターンを使っているみたい。なので lock が必要になるような競合が発生しない限りは十分に速いわ。振り出しに戻ってしまった。

runtime/src/libraries/System.Private.CoreLib/src/System/Collections/Concurrent/ConcurrentQueue.cs
FAQ :: Are all of the new concurrent collections lock-free? - .NET Blog
- ConcurrentQueue and ConcurrentStack are completely lock-free in this way. They will never take a lock, but they may end up spinning and retrying an operation when faced with contention (when the CAS operations fail).

薄々気づいてはいたが、もうデータ保持の形式に関しては trie を採用しない状態でできることはなさそうな感じしてきた。でも pocof での SPSC append-only な用途の方が明らかにやること少ないし、このまま諦めるのはなんか違う気がするな。少しでも何かできることないんかな～。悪あがきしたい。特に今回計測した追加のときよりも絞り込みのときの速度改善が肝(なんで今やらないかな)なので、そこも含めて見極めたいな。

続く。

F# で Cmdlet を書いてる pt.69 - Task.Run と task expression

Sun, 10 Aug 2025 09:00:00 +0900

krymtkts/pocof 開発をした。

keyboard 入力を読み取り描画イベントを起こす main loop を async + tail recursion から task + while loop に変えた。はじめ単純に async expression を task expression に変えてみたが、処理が始まらなくなってしまった。これは current thread で即座に task が実行されるから期待しない blocking が発生していたことによるらしい。 task expression は do! のような非同期操作を切り替わりのタイミングとして、別の thread に移るらしい。なので初めから別 thread で動く Task.Run で実行するようにし、さらに結果を待ち受けるタイミングも変える必要があった。考えたこともなかったが、 Task.Run と task expression は実行が初めから別 thread に乗るか乗らないかの違いがあるらしい。これは async expression で開始方法が様々提供されてるのと違う点なのかな。以下の引用辺りか。

Task expressions - F# | Microsoft Learn
- The task is started immediately after this code is executed and runs on the current thread until its first asynchronous operation is performed (for example, an asynchronous sleep, asynchronous I/O, or other primitive asynchronous operation).
Task.Run Method (System.Threading.Tasks) | Microsoft Learn
- Queues the specified work to run on the thread pool and returns a proxy for the task returned by function.

今回の変更により、元の async + tail recursion から多少の overhead は減ったろうが、 tail recursion 最適化があるし速度への寄与は微々たるものと思われる。でもこの基礎的な挙動をちゃんと理解できたという点で収穫ありかな。 .NET 力の低さを多少は改善できただろう。

これからやりたいこととしては、やっぱり console output の最適化はやりたいなと考えている。標準出力の StreamWriter.AutoFlush を無効にして、手動で flush するやつ。 Console.WriteLine を利用するための行数の調整が必要になるので多少難しかろうが。 100 万件を pocof で操作するような自機(Razer blade stealth 2017)の CPU 負荷が高いときだと顕著に描画が遅くモッサリ感あるので、速くしたい。

クエリ構築部分も、正規表現で文字列を分割するようなのでなく、自前で parser を書いて構築するやつにしたい。

あと全体的な高速化を一番やらないといけない。だが、 state の受け渡し箇所を byref を使って heap 割当を避けコピー削減するようなパターンしか思いつかない。この部類の最適化は効果がさほどでないことも多いしあまり期待はできない。一番遅いであろう ConcurrentQueue の絞り込み部分をどうにかせんと極限のパフォーマンスに迫らないのだけど、まだ解決策を考えられてない。非同期で描画する対応のとき手っ取り早く使える方法として ConcurrentQueue を使ったが、読みと書きの thread が別れてるだけなのでより良い方法があるような。より最適なデータ構造を選択するなり作るのが良さそうな気配はしてる。

今後は、とりま抜本的な改善を GitHub Copilot なんかと相談しつつ、まず実装イメージが掴めている console output の最適化とクエリの parser 実装かな。

F# で Cmdlet を書いてる pt.68 - WaitHandle を使う

Sun, 03 Aug 2025 09:00:00 +0900

今週はまるで開発の時間が取れなかったが、久しぶりに krymtkts/pocof 開発をした。 krymtkts/PSGameOfLife でいくつか高速化に関わる Tips を手に入れたので、それを輸入しようという魂胆だ。ただ今のところは、それらをすぐに pocof で実現するのは難しそうだ、という結論になった。

ひとつは、 Console.Out を StreamWriter.AutoFlush を無効にした StreamWriter で置き換える方法。書き込み完了後に Flush することで Console の書き込み性能を高められる。 PSGameOfLife の CUI では非常に上手くいったが、 pocof の方は単純に導入できるものではなさそうだった。 Console.WriteLine を使わないと 1 行の改行が適切に出力されない¹ため、狙った印字にならない。 pocof は初期カーソル位置下部に必要な数の行を出力して描画スクリーンを作っている関係で、 Console.WriteLine で自動で出力される改行と相性が悪いので、その調整が必要そう。閾値の調整位で済めば導入も容易いのだけど、ややこしい部分なので億劫だ。

もう 1 つは async expression を task expression に置き換える方法。置き換えるだけなのでとても簡単なのだが、 pocof では F#らしく async expression と末尾再帰による無限 loop をしているので、 task だと末尾再帰を最適化できない。つまり再帰をやめて while に変える必要がある。それは性能のために F# らしさをやめるということで、 pocof ではどうするかというのが悩ましい。速いは正義なのでそれでいいのだけど、もうちょっと悩んでもいいかなと思ってやらなかった。

そんな感じで打つ手がなくなってしまった。仕方ないので、これらの代わりに pocof での main loop(UI Thread) に相当する箇所の効率化を試しているところ。最早 PSGameOfLife から得たアイディアでもない。外出中に pocof のコードを読んでて Thread.Sleep があるのを思い出したので、これは良くないなと GitHub Copilot に相談して出てきたアイディア。再帰による無限 loop で Thread.Sleep を使っていたところを WaitHandle で置き換えることで、 CPU の無駄使いを取り除く。 #347

diff --git a/src/pocof/Pocof.fs b/src/pocof/Pocof.fs
index d31c9c9..b29993b 100644
--- a/src/pocof/Pocof.fs
+++ b/src/pocof/Pocof.fs
@@ -188,6 +188,8 @@ module Pocof =
         let renderStack: RenderEvent Concurrent.ConcurrentStack =
             Concurrent.ConcurrentStack()

+        let event = new AutoResetEvent(false)
+
         [<TailCall>]
         let rec getLatestEvent (h: RenderEvent) (es: RenderEvent list) =
             match h with
@@ -205,9 +207,14 @@ module Pocof =
             | [] -> RenderMessage.None
             | h :: es -> getLatestEvent h es |> RenderMessage.Received

-        member __.Publish = renderStack.Push
+        member __.Publish e =
+            renderStack.Push e
+            event.Set() |> ignore
+
+        member __.Receive(block: bool) =
+            if block then
+                event.WaitOne() |> ignore

-        member __.Receive() =
             let items =
                 match renderStack.Count with
                 // NOTE: case of 0 is required for .NET Framework forward compatibility.
@@ -222,9 +229,12 @@ module Pocof =

     [<TailCall>]
     let rec render (buff: Screen.Buff) (handler: RenderHandler) =
-        match handler.Receive() with
+        match handler.Receive(block = true) with
         | RenderMessage.None ->
-            Thread.Sleep 10
+            // NOTE: for backward compatibility.
+#if DEBUG
+            Logger.LogFile [ "render received RenderMessage.None." ]
+#endif
             render buff handler
         | RenderMessage.Received RenderEvent.Quit -> ()
         | RenderMessage.Received(RenderEvent.Render(state, entries, props)) ->
@@ -257,7 +267,7 @@ module Pocof =
         | StopUpstreamCommands

     let renderOnce (handler: RenderHandler) (buff: Screen.Buff) =
-        match handler.Receive() with
+        match handler.Receive(block = false) with
         | RenderMessage.None -> RenderProcess.Noop
         | RenderMessage.Received RenderEvent.Quit -> RenderProcess.StopUpstreamCommands
         | RenderMessage.Received(RenderEvent.Render(state, entries, props)) ->

元々 Thread.Sleep していた箇所は取り除き、 WaitOne で待ち受ける。 ProcessRecord から呼び出される描画処理を詰まらせないために non-blocking な option も提供する。

いい感じなのだが、これらの差分はまだ実装途中で merge もしてない。というのも pocof は結構 coverage が厳しいので、 engine 部分以外はゆるい PSGameOfLife と違い下手は変更が許容されないのを忘れてた。 RenderMessage.None は発生することがないので消したいがまだ消せてない。おかげで coverage が低下している。なんとかせな。

自分が書いてる F# の中では poof は legacy な部類なので、この様な形でちょいちょい更新していけたら良いなと考えている。

多分続く。

確か改行コードや ANSI escape sequence でもダメだったと記憶だが今度再確認する ↩

F# でミニゲームを書いてる Part 9

Sun, 27 Jul 2025 09:00:00 +0900

krymtkts/PSGameOfLife の開発をした。

世代交代の並列化と main loop を async expression から task expression に置き換えた。 #17 これで瞬間最大風速 3000 FPS 超えまできた(1 cell 10x10 dot の 50 x 50)。 2017 Razer blade stealth で。速いなー。つまり理論上 300 ~ 400ns で 1 frame 描いてるのか。これまで F# で書いてきたプログラムは async と task を使わけなくても async で十分速いケースが多かった。また async の方が機能のサポートが手厚いし中々 task を使うことがない。でも実際に 1ms 以下の処理時間が必要なケースだと task の方が .NET の最適化や overhead の少なさで速いみたい。もっと積極的に task を使ってもいいなと。いい経験になった。

ただ、この改善により UIThread が詰まるという現象が発生、 window を終了できなくなる問題が再発した。今回のは何のことはない、 Dispatcher で実行する優先順位が Render では高すぎて、 closed 等の event を block してしまうみたい。代わりに何を選ぶべきか、提供されてる DispatcherPriority の文書を見てみたが、順位がよくわからなかった。書いてないようだけど。

結局 Avalonia の DispatcherPriority のコードを直に参照した。読み間違いがなければ、優先順位は以下の通りだった。

9: MaxValue, Send
8: Normal
7: (obsolete) DataBind
6: (private) AsyncRenderTargetResize
5: (private) BeforeRender
4: Render
3: (internal) AfterRender
2: (private) UiThreadRender
1: Loaded
0: Default, (internal) MinimumForegroundPriority
-1: Input
-2: Background
-3: ContextIdle
-4: ApplicationIdle
-5: SystemIdle, (internal) MinimumActiveValue
-6: Inactive, (internal) MinValue
-7: Invalid

これに基づいて、強すぎず弱すぎずな Input にしておいた。正直 Default でも問題なかろうが、 Background 寄りは優先されて他の割り込みを許容するよう、調整してみたつもり。 GUI mode を作ってみて結構 Avalonia は文書に書いてないから、コードを見た方が理解しやすいこともわかってきた。

GUI mode 追加に伴って MAML ヘルプファイル等の文書も整えた。 #18 あとで PowerShell Gallery に公開しよう。心配なのは大量の依存関係がある Cmdlet を公開したことがないので、上手くいくのかというところかな。それも経験しないとわからんので、やってみるしかないな。

今後は、PSGameOfLife には他にも追加していきたい機能があるので、それに着手しようか。あるいは PSGameOfLife で得た知見を他のツールに反映するか。

F# でミニゲームを書いてる Part 8

Sun, 20 Jul 2025 09:00:00 +0900

krymtkts/PSGameOfLife の開発をした。

前回こう書いた。

ゲームの core な部分はまだ改善できそう。 array を使うようにはしてるけど、 array の再生成を最小限にするとかの最適化はそれほどやってないし。ただそこに手をいれるには現状の simple な盤面の管理を二重にしてやる必要があって、気が進まない。

面倒だったのだけど試しに array の生成をやめてみたら FPS が 2 倍ほど高速化された。流石に笑える。なので気が進まないとかそっちのけで対応した。描画範囲外の隣接 cell を除外するところで Array.choose を使って array を生成していたので、単純な for loop に置き換え。 FP ぽくないが性能のためには仕方ないのだ。

またこれも前回触れた二重 buffer 方式を一番単純な関数の引数にとる形で実装した。世代交代の度に 2 つの buffer を入れ替えて使う。そのため outref を用いて mutable な操作を使うように変えている。コードは以下のようにした。処理を関数に小分けして分かりやすくしていたのもやめて全部統合したので、ちょっと見通しは悪いかも知れない。

let nextGeneration (buffer: outref<Cell[,]>) (board: outref<Board>) =
    let columns = int board.Column
    let rows = int board.Row
    let tmp = buffer

    for y in 0 .. rows - 1 do
        for x in 0 .. columns - 1 do
            let mutable lives = 0

            for dx, dy in neighborOffsets do
                let nx, ny = x + dx, y + dy

                if nx >= 0 && nx < columns && ny >= 0 && ny < rows && board.Cells.[ny, nx].IsLive then
                    lives <- lives + 1

            tmp.[y, x] <- nextCellState board.Cells.[y, x] lives

    buffer <- board.Cells
    board.Generation <- board.Generation + 1
    board.Lives <- tmp |> countLiveCells
    board.Cells <- tmp

これらの対応により、愚直な実装にしては結構速くなったんじゃないかな。今のところ GUI は CUI より速いのだけど、瞬間最高風速 1800 FPS 台だったので、理論上 0.5ms くらいで 1 frame 描画してる。速いなー。でも game of life ガチ勢は専用の algorithm を採用し、極めて大きな盤面でももの凄い高速の simulation ができるらしい。盤面が大きいとこちらは数十 FPS なのでまだまだやな。まだ並列化を施してないから改善の余地は残されてる。

他に対応したいものは、これも前回触れた Linux でのみ shortcut key で終了すると window が残る bug だ。 Windows では発生しなくて、 Ubuntu on WSL2 でのみこの現象を確認している。純 Linux は持ってないのでわからん。まだ原因がわかっておらず対処できてない。

調査の過程で 1 つわかったのは、 Avalonia の UIThread に InvokeAsync したところで何か処理が詰まっていそうということだ。一応 InvokeAsync に cancellation token を渡せる overload があったし、ワンチャン願ってお作法的に渡すようには変えた。でも結果は変わらず。また InvokeAsync で得られた Avalonia の DispatcherOperation を Abort を実行してもこの詰まりは解消されなかった。 log を仕込んで動きを追ってみても、 cancellation token による中断で例外が発生するでもなく、単に詰まっているようにみえる。この見解があってるのかもよくわからん。

原因がさっぱりなので、この現象の再現のために個別の project を作って細かく見るしかないなという感じ。イつ解決できるかもわからないし、 PSGameOfLife の暫定対応として Linux では shortcut key による終了を無効化した。 Avalonia 単体で使えば問題ないのか、 PowerShell module として Application を破棄せず持ってることに問題があるのか、色々調べないとわからん。因みに ClassicDesktopStyleApplicationLifetime を Shutdown しても消えない。どうやったら消えるんだよ。現状把握している唯一 window を消すのが可能な方法は、 process 自体を止めること。

取り敢えず現状臭い物に蓋をしたので、世代交代の並列化をして高速化し、 PowerShell Gallery に公開したあと、腰を据えて取り組んでみるかー。

F# でミニゲームを書いてる Part 7

Sun, 13 Jul 2025 09:00:00 +0900

krymtkts/PSGameOfLife の開発をした。

#7 で cell のサイズ指定に対応した。 #10 で CUI にも FPS の debug 機能を追加した。 CUI の FPS が見られるようになったことで、 GUI で同等の FPS が出せてるのもわかっていい感じ。あと #9 #11 でちょっとした描画処理の改善した。

前回、 cell のサイズが小さいと SIMD 命令の恩恵を受けられなくなる話を書いた。現状の実装は以下の通り。 Vector<byte>.Count に満たないデータはエラーになって使えないから、使わないようにしている。 (cell の byte 数が小さいと createCellTemplate で Vector が作られないから書き込み時も Vector を使わない)

    let createCellTemplate (cellSize: int) (color: byte * byte * byte * byte) : byte array * Vector<byte> array =
        let b, g, r, a = color
        let byteLength = cellSize <<< 2
        let bytes = Array.zeroCreate<byte> byteLength

        for x in 0 .. cellSize - 1 do
            let idx = x <<< 2
            bytes.[idx] <- b
            bytes.[idx + 1] <- g
            bytes.[idx + 2] <- r
            bytes.[idx + 3] <- a

        let nvec = byteLength / vectorSize
        let vectors = Array.init nvec (fun i -> Vector<byte>(bytes, i * vectorSize))
        let offset = nvec * vectorSize
        let rem = if byteLength > offset then bytes.[offset..] else [||]
        rem, vectors

    // 略

    let writeTemplateSIMD (dst: nativeptr<byte>) (vectors: Vector<byte> array) (rem: byte array) =
        let baseAddr = NativePtr.toNativeInt dst

        for i = 0 to vectors.Length - 1 do
            Unsafe.WriteUnaligned((baseAddr + nativeint (i * vectorSize)).ToPointer(), vectors.[i])

        let offset = vectors.Length * vectorSize

        if rem.Length > 0 then
            let dstRemPtr = NativePtr.add dst offset
            // NOTE: pinning the template array to avoid GC moving it.
            use ptr = fixed &rem.[0]

            Unsafe.CopyBlockUnaligned(NativePtr.toVoidPtr dstRemPtr, NativePtr.toVoidPtr ptr, uint32 rem.Length)

このため、 1x1 みたいな極端に dot の数が小さい cell の場合に SIMD を使わないので書き込みメモリ効率が落ちる。これを改善したかったので、試しに毎 frame stackalloc で確保した buffer へデータを溜め込んで行データをまとめて SMID で書き込む方法を試してみたのだけど、大差なかった。現状の定義済み Vector と余りの byte を書き込む方法だと、毎 frame で BGRA のための loop や Vector の生成が不要なので同等に速いみたい。なんか直感的にはまだまだできそうな感じはするけどな～、今はまだ技量が足りない。他に思いつく高速化は byref で破壊的操作をして copy を減らすとかかな。効果あるかな...

あと、現状 GUI で可能な最大サイズ 1000x1000 にすると、 2 FPS とかで極めて重い。 cell の数を減らして、代わりに size を増やして window が大きくしても描画が劣化しないので、多分 cell が多いことに起因してる。ゲームの core な部分はまだ改善できそう。 array を使うようにはしてるけど、 array の再生成を最小限にするとかの最適化はそれほどやってないし。ただそこに手をいれるには現状の simple な盤面の管理を二重にしてやる必要があって、気が進まない。 game of life は cell の生死を判断するのに周りの cell の状態に依存するから、逐次書き換えができないのよね。都度盤面を copy するとそれだけ時間がかかるし、だとしたら二重 buffer しかないと。速さのためには多少の不満も受け入れないといけないか。当面大きい盤面での処理効率が向上しない間は全画面機能を追加せずいこう。

他にも Linux でのみ shortcut key で終了すると window が残る bug もあったりして、 cross platform は改めて難しいな～というのを感じている。現状はいちいち動作確認してるから、 GUI の end-to-end testing が要るのかなと思ってる。一応それに使えそうな Avalonia の Headless platform というのがあるらしい。実際に使えるのかは試してみないとちょっとわからんな。

何にせよもうそろそろ PowerShell Gallery へ公開してもいいなという気持ちになってきてる。 GUI 版のための document 拡充とかも始める頃合いか。自分の仕事 PC で game of life を流しながら休憩する未来はすぐそこにある。

F# でミニゲームを書いてる Part 6

Sun, 06 Jul 2025 09:00:00 +0900

krymtkts/PSGameOfLife の開発をした。なかなか大変だったが、終了処理の課題を解決できた。 #6

元々課題に思ってた終了処理が詰まるのも解決の手立てがなかった。 UI Thread が詰まってるから Window を閉じる操作をしても event に関連づいた処理が起動するのにどうしても時間がかかってしまうという感じか。 Avalonia 内部まで追ったわけではないがそういう挙動に見えた。

あとどうも WriteableBitmap の生成コストが結構高いようだというのがわかってきた。 WriteableBitmap を使い回す実装に変えたら 1 frame 当たりの処理時間が 1ms くらいは縮む。でも Avalonia.FuncUI か Avalonia.FuncUI.Elmish の制約で、参照が同じままだと変更を検知できなくて再描画できないみたい。あんま追えてないが Object.ReferenceEquals を使ってそう。 Avalonia.FuncUI.Elmish での実現は断念した。

この通り Avalonia.FuncUI と Avalonia.FuncUI.Elmish の制約が乗り越えられない壁になってたので、いっそのこと利用をやめてみた。代わりに描画処理を自前の event loop で実行する必要がある。末尾再帰で loop するようにした。 event loop 内で CancellationTokenSource に基づいて終了できるようにしたら、瞬時に終了処理が実行できるよう改善できた。きびきび反応していい感じ。 Avalonia.FuncUI の宣言的な DSL とか MVU の恩恵が受けられなくなったが、最低限の UX を提供するためには仕方ないのだ。 Avalonia.FuncUI と Avalonia.FuncUI.Elmish もパフォや機能的な制約がないのであれば問題ないし、共存の未知を探せるとよいが。

今回の変更による UI 更新と event loop のコードは以下の通り。宣言的 UI じゃなくなったので見通しは悪くなった。 event loop は一般的な再帰になってわかりやすいといえるが処理が増えたら煩雑化しそうではある。

    let stack, updateUI =
        let status1 =
            TextBlock(Background = Brushes.White, Foreground = Brushes.Black, Height = Main.statusRowHeight)

        let status2 =
            TextBlock(Background = Brushes.White, Foreground = Brushes.Black, Height = Main.statusRowHeight)

        let image = Image(Width = float width, Height = float height)

        let wb =
            new WriteableBitmap(PixelSize(width, height), Vector(96, 96), PixelFormat.Bgra8888, AlphaFormat.Opaque)

        image.Source <- wb

#if DEBUG || SHOW_FPS
        let fpsText =
            let tb =
                TextBlock(Foreground = Brushes.Yellow, Background = SolidColorBrush(Color.Parse("#80000000")))

            Canvas.SetTop(tb, 0.0)
            Canvas.SetRight(tb, 0.0)
            tb.SetValue(Canvas.ZIndexProperty, 100) |> ignore
            tb
#else
        let fpsText = null
#endif
        let canvas = Canvas(Width = float width, Height = float height)
        let stack = StackPanel()

        status1 |> stack.Children.Add
        status2 |> stack.Children.Add
        image |> canvas.Children.Add
        canvas |> stack.Children.Add
#if DEBUG || SHOW_FPS
        fpsText |> canvas.Children.Add
#endif

        let updateUI board =
            status1.Text <- $"#Press Q to quit. Board: {board.Column} x {board.Row}"
            status2.Text <- $"#Generation: {board.Generation, 10} Living: {board.Lives, 10}"
            renderBoard board wb
            image.InvalidateVisual()
#if DEBUG || SHOW_FPS
            fpsText.Text <- $"FPS: %.2f{FpsCounter.get ()}"
#endif
        stack, updateUI

    [<TailCall>]
    let rec loop board =
        async {
            if cts.IsCancellationRequested then
                return ()

            do!
                Dispatcher.UIThread.InvokeAsync(fun () -> updateUI board).GetTask()
                |> Async.AwaitTask

            do! Async.Sleep(int board.Interval)
            let currentBoard = nextGeneration board
            return! loop currentBoard
        }

これによって終了処理は改善されたが、同時に不可解な hangup が発生するようになった。 CPU ・ GPU が無風になる。それも毎回 hangup するのでなくて、特にゲームボードのサイズが大きくて cell の数が多いほど起動時に詰まる確率が高い。でもデフォのサイズでも確率が多少低いだけで発生することに変わりない。

原因不明で困ったが、なんとか原因らしき挙動は突き止めた。どうも WriteableBitmap が thread safe じゃないことによるみたい。 Parallel.ForEach を使って並列で重ならない address に書き込んでいても、内部で deadlock するっぽい。早い話が WriteableBitmap への並列書き込みが原因ということになる。つまり一時領域に並列で書きこんで、その結果を WriteableBitmap に一括コピーすれば回避可能なのがわかった。コピー効率は悪くなるが。コードは以下のようになった。

    let renderBoard (board: Board) (wb: WriteableBitmap) =
        let partitioner = Partitioner.Create(0, Array2D.length1 board.Cells)
        use tempPtr = fixed &tempBuffer.[0]
        let lenX = Array2D.length2 board.Cells - 1

        do
            Parallel.ForEach(
                partitioner,
                fun (startIdx, endIdx) ->
                    for y = startIdx to endIdx - 1 do
                        let yc = y * cellSize

                        for x = 0 to lenX do
                            let xc = x * cellSize

                            let vectors, bytes =
                                match board.Cells.[y, x] with
                                | Live -> templates.LiveVectors, templates.LiveBytes
                                | Dead -> templates.DeadVectors, templates.DeadBytes

                            for dy = 0 to cellSize - 1 do
                                let dstOffset = ((yc + dy) * width + xc) * 4

                                let dstLinePtr =
                                    NativePtr.add
                                        (NativePtr.ofNativeInt<byte> (NativePtr.toNativeInt tempPtr))
                                        dstOffset

                                Main.writeTemplateSIMD dstLinePtr vectors bytes
            )
            |> ignore

        // NOTE: Parallel write to WriteableBitmap cause a deadlock. so avoid it by using a temporary buffer.
        use fb = wb.Lock()
        System.Runtime.InteropServices.Marshal.Copy(tempBuffer, 0, fb.Address, bufferSize)

これで Razer Blade Stealth 2017 でも 50x50 で 700 FPS くらい、 100x80 だと 140 ~ 160 FPS くらい。 100x80 があまり高速化してないのだけど、全画面に近い 160x80 でも 120 FPS は出るようになって割と良いのではないかと。

ひとまず終了処理の課題と高速化も実現できて満足。

あと気になるのは、 SIMD 命令の効率。現状 SIMD 命令は 1 cell 毎に SIMD 命令でのコピーと端数のコピーが実行されてるのだけど、理論的には SIMD 命令の効率をもっと上げられるはず。でも実際に試してみたら、 SIMD 命令のために Vector<byte>[] を積み上げる箇所にどうにもコストがかかるみたいで大して速くならなかった。なので現状だと先述の通り理論上の SIMD 命令の効率は悪いが、現状の定義済みメモリをこまめに SIMD と端数に分けてコピる方式が最も速くなってる。

でもこれは動作確認する際の cell 数だとそうなるというだけだと思われる。 cell が 10x10 の固定サイズじゃなくて指定できるようになってたらもっと SIMD 命令の効率を上げないと FPS 上がらないんじゃないかなと。またちまちま試行錯誤して改善を繰り返したい。

描画効率が更に良くなったら全画面表示なんかも導入していい気がする。 GUI はやることが多くて勉強になるが、お陰で一向にゲームモードの追加とかに進まんのが難点やな。

F# でミニゲームを書いてる Part 5

Sun, 29 Jun 2025 09:00:00 +0900

krymtkts/PSGameOfLife の開発をした。あんまりやれてないが。

終了のためのショートカットを追加したり、世代とかのステータスを表示できるようにしてみたらぐっと使いやすくなった。 #4

そこで改めて気付いたが Interval 0ms にしていると描画は極めて高速でも終了まで時間がかかるようになった。処理が多すぎて UI(main) thread が詰まるみたい。 0ms の利用を推したいわけじゃないが、あまり気持ち良くないのでもう少し最適化できないか調べてみている。

とりあえず、 cell の数が多いほど計算量が増える状態なのは GitHub Copilot の指摘でもあったので、 1 frame 毎の演算量を減らしてみるとかその他の最適化を試みた。 GitHub Copilot の提案も含め以下を施した。

cell の生死を template 化して copy する
描画処理の並列化(描画反映が重ならないので可能)
描画処理の SIMD 命令利用

これらを #5 で実装してみた。 GitHub Copilot は並列化をやたら推すが、他のアイデアについては提案してくれなかったのでこちらからあれこれどうかと聞いてみた感じ。なんとなーく、段階的に高速化するような感じで 1 つずつ提案してくれるつもりだったのかも知れないが、そんな悠長なことはしてられないので。

F# で low layer は書いたことなかったので GitHub Copilot のレクチュアのもと行った。 1ms 以下の演算となると CPU キャッシュがとかメモリの転送量がとか、GC で address が変わるからコピーする間はピン留めする必要があるとか色々興味深く、中々いい経験になる。これらの要素を何となく理解できることから、改めてプログラマーのための CPU 入門を読んでて良かったなと身にしみて感じた。ちょっと残念だったのが、これは Avalonia の話だが WriteableBitmap の描画が 1 行単位にしか行えないらしいこと。お陰で 1 cell 10x10 を 10 回に書き分ける必要があった。まだ WriteableBitmap のことはいまいちわかってないからこれが本当に最善手かわからないし、もっと効率的にできる方法があるかもな。

これらの対応によって、 Razer Blade Stealth 2017 でも随分速くなった。ゲームのセルの数がデフォ 50x50 だと 120 FPS だったのが 400 FPS ~ に、 100x80 だと ~ 60 FPS が 120 FPS ~ に高速化されてる。

最適化に際して、描画処理の速度を測るため FPS を計測・表示する仕組みを作った。昔 Avalonia の Windows には VisualRoot.VisualRoot.Renderer.DrawFps が生えてたらしい。これは Avalonia.FuncUI の sample でもコメントの状態で見られる。でも今の Avalonia 11 にはそれがなくなってるのか見つけられなかったので、自前で簡単なのを作った。 FPS の計算と表示による負荷が気になったのだけど、 GitHub Copilot 曰く微々たるものとのことなので許容した。

あと初めて SIMD 命令を使ったので初めて知ったのだけど、 .NET は Release build じゃないと JIT で SIMD の最適化しないみたい。これについて触れられた文書はまだ探せてない。 Debug build だと SIMD の最適化がないのか、デフォのセル数で 250 FPS くらいになってた。かなり違う。実際に利用する場合の性能を測りたい。ということで、最初は #if DEBUG だけ FPS を表示してたのだけど、独自の symbol を指定した場合も表示できるようにした。

dotnet build -p:DefineConstants=SHOW_FPS

こういう command で独自の symbol を指定できる。ただ PSGameOfLife では psake に build task を一任してる。そのため dotnet 直じゃなく parameter を追加した場合のみ DefineConstants を追加できるようにしている。

現時点でも結構いい感じではなかろうか。でも元々課題に思ってた終了処理が詰まるのは多少軽くなったけどまだ詰まったまま。それと Ionide.Analyzers の警告に対応してなかったりするので、その辺直せたら PR を merge しようかな。週末時間取れない日が続くが少しずつ進められてるところも、中々良い。

F# でミニゲームを書いてる Part 4

Mon, 23 Jun 2025 09:00:00 +0900

最近週末お出かけばかりで時間が取れないので、今日代わりに休みを取って開発、日記とした。

krymtkts/PSGameOfLife の開発をした。

まず PSGameOfLife に GUI の prototype を実装した。 #1

NativeLibrary.SetDllImportResolver で native library 読み込みを調整するやつの目処がついたためだ。 NativeLibrary.SetDllImportResolver は native library の既定の読み込みを上書きする。なので既定の読み込みも活かすよう自分で実装する必要がある。 IntPtr.Zero を返すと library が見つからなかったことになるので、既定の読み込みに fallback する必要がある。結果このような形に落ち着いた。

    let resolver (ptrCache: Concurrent.ConcurrentDictionary<string, nativeint>) moduleDir extension =
        let tryLoadLibrary (moduleDir: string) (extension: string) (libraryName: string) =
            let libPath =
                let libPath =
                    if extension |> libraryName.EndsWith then
                        $"runtimes/{RuntimeInformation.RuntimeIdentifier}/native/{libraryName}"
                    else
                        $"runtimes/{RuntimeInformation.RuntimeIdentifier}/native/{libraryName}.{extension}"

                System.IO.Path.Combine(moduleDir, libPath)

            if libPath |> IO.File.Exists then

                libPath
                |> NativeLibrary.TryLoad
                |> function
                    | true, ptr -> ptr
                    | _ -> IntPtr.Zero
            else
                IntPtr.Zero

        DllImportResolver(fun libraryName assembly searchPath ->
            match libraryName |> ptrCache.TryGetValue with
            | true, ptr -> ptr
            | _ ->
                match tryLoadLibrary moduleDir extension libraryName with
                | ptr when ptr = IntPtr.Zero ->
                    // NOTE: fallback to the default behavior if the library is not found.
                    match NativeLibrary.TryLoad(libraryName, assembly, searchPath) with
                    | true, ptr ->
                        ptrCache.TryAdd(libraryName, ptr) |> ignore
                        ptr
                    | _ ->
                        // NOTE: Returning IntPtr.Zero means the library was not found. This will cause an error when P/Invoke is called.
                        IntPtr.Zero
                | ptr ->
                    ptrCache.TryAdd(libraryName, ptr) |> ignore
                    ptr)

これで Windows / Linux(Ubuntu on WSL) のいずれでもご機嫌な GUI が動く。

ただ #1 の実装は描画処理に問題があったみたいで、極端に遅かった。 10ms 毎の interval で描画を繰り返すと、描画が stuck した。なるべく CUI で出来てることを GUI でもやりたくて、 Cmdlet の parameter で指定できる Interval の範囲はなんとか動作保証したかったので、改善に着手した。 #2

(ほぼ AI にぶん投げて)調べたところ高速な描画を実装するのに対して、 2 つ良くない点があった。

1 つ目はここで、 Canvas に Rectangle で描画しているので描画が重かった。 cell の数が多くなるととてつもなく重くなるみたいなので game of life には向かないと。そりゃそうか。

これは単純に高速な画像の描画処理が必要なら WriteableBitmap を使えばいいみたい。手続き的な書き方で埋め尽くされたが、これでかなり速くなって、 interval 1ms くらいならさばけるようになった。

それでも interval 0ms 、要は待ち時間なしにすると stuck していた。これが 2 つ目の良くない点で、ここ。描画処理の完了を待たずに DispatcherTimer が次々と message を送ってくるから処理が追いつかなくなって、 queue が詰まったという感じみたい。

なので DispatcherTimer を使うのをやめて、描画が終わったら次の処理のための message を配信するという感じに書き換えた。再帰的になってる感じ。この書き換えには Cmd.OfAsyncImmediate.either を使った。単に Elmish を使いこなせてないだけかも知れないが、最初 Cmd.OfAsyncImmediate.perform してたら GUI を閉じたときに再帰的な処理が停止できてなかったみたい。そのせいで 2 回目以降の起動で描画処理にカクつきが見られた。この解消のために Cmd.OfAsyncImmediate.either で cancellation token が cancel されたときは何もしないようにしてで呼び出しを止めさせた。これで待ち時間 0ms(実際は計算時間があるためベストエフォート)の描画ができるようになった。

よく F# の game programming は最適化のため手続きっぽい書き方が増えるというのをいろんな人の blog で見ていたが、2 つの対応を通して、身にしみてわかった気がする。

まだ Avalonia や Elmish に慣れてないのもあるが、 Avalonia の v11 を使ってるから AI の suggest も v10 以前の知識で動いたりするのが面倒だった。過去の Avalonia を知らんので結構混乱する。また Avalonia.FuncUI.Elmish に関しては情報がそもそも少ない(多分ないよな？)から、 AI が出たらめいってくる。結局自分で関数の signature や直に実装を見て判断するしかない。慣れかな。

これで Windows / Linux でも高速な描画ができるようになった GUI mode の土台が整った。あとは画面のサイズの指定とか、 CUI モードとなるべくおなじ interface に汎化するとかを進めていければよさそう。もうちょい週末が穏やかだと嬉しいのだが。続く。

F# でミニゲームを書いてる Part 3

Sun, 15 Jun 2025 09:00:00 +0900

krymtkts/PSGameOfLife の開発。次は GUI でミニゲームを実行するようにしたいというやつだ。

krymtkts/fsharp-cmdlet-sandbox で Avalonia.FuncUI の練習をしてみた。 Avalonia.FuncUI 自体を利用するのは難なくできそうだが、 PowerShell Cmdlet 内から呼び出すのが極めて難しいなこれ。

dotnet run ~ のように実行形式で起動すれば Windows でも Linux(Ubuntu on WSL で確認した)でも問題ない。しかし PowerShell Cmdlet 内から起動すると DLL 等 native library が読み込まれない。

Windows 側は以下の hack を使うことで、事前に load した assembly がキャッシュされてる状態で GUI を起動できた。 runtimes/*/native/* を動的に load することで課題に対処した具合だ。

fsharp-cmdlet-sandbox/src/avalonia-funcui/Library.fs at dbc637c82935da48d14c0affc69d869a5e43751f · krymtkts/fsharp-cmdlet-sandbox

検証コードなので汚いが、まんまコピる。

        printfn
            $"OSArchitecture: {RuntimeInformation.OSArchitecture} OSDescription: {RuntimeInformation.OSDescription} FrameworkDescription: {RuntimeInformation.FrameworkDescription} ProcessArchitecture: {RuntimeInformation.ProcessArchitecture} RuntimeIdentifier: {RuntimeInformation.RuntimeIdentifier}"

        printfn "EndProcessing called"

        let moduleDir =
            System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location)

        printfn "Module directory: %s" moduleDir

        if RuntimeInformation.IsOSPlatform(OSPlatform.Windows) then
            [ $"runtimes/{RuntimeInformation.RuntimeIdentifier}/native/av_libglesv2.dll"
              $"runtimes/{RuntimeInformation.RuntimeIdentifier}/native/libHarfBuzzSharp.dll"
              $"runtimes/{RuntimeInformation.RuntimeIdentifier}/native/libSkiaSharp.dll" ]
        elif RuntimeInformation.IsOSPlatform(OSPlatform.OSX) then
            [ $"runtimes/{RuntimeInformation.RuntimeIdentifier}/native/libAvaloniaNative.dylib"
              $"runtimes/{RuntimeInformation.RuntimeIdentifier}/native/libHarfBuzzSharp.dylib"
              $"runtimes/{RuntimeInformation.RuntimeIdentifier}/native/libSkiaSharp.dylib" ]
        elif RuntimeInformation.IsOSPlatform(OSPlatform.Linux) then
            [ $"runtimes/{RuntimeInformation.RuntimeIdentifier}/native/libHarfBuzzSharp.so"
              $"runtimes/{RuntimeInformation.RuntimeIdentifier}/native/libSkiaSharp.so" ]
        else
            List.empty
        |> List.iter (fun skiaDll ->
            let skiaPath = System.IO.Path.Combine(moduleDir, skiaDll)

            try
                printfn "Loading SkiaSharp library from: %s" skiaPath

                if System.IO.File.Exists(skiaPath) then
                    printfn "SkiaSharp library found."
                    NativeLibrary.Load(skiaPath) |> ignore
            with e ->
                printfn "Failed to load SkiaSharp library: %s" e.Message
                ())

        let app =
            let lt =
                new Avalonia.Controls.ApplicationLifetimes.ClassicDesktopStyleApplicationLifetime()

            AppBuilder
                .Configure<App>()
                .UsePlatformDetect()
                .UseSkia()
                .LogToTextWriter(Console.Out, LogEventLevel.Verbose)
                .SetupWithLifetime(lt)
        // .SetupWithoutStarting()

        printfn "Avalonia FuncUI application configured."

        app

でも Linux では効果なかったから同じ方法を使えなかった。 library 解決の手法が Windows と違うそうなので、これは別途対応する必要がある。また Mac での挙動は端末がなくてチェックできない。 cross platform 対応のハードルは実に高いと実感している。

まるで詳しくないが、 NativeLibrary.SetDllImportResolver で native library の読み込み path を調整できるようなので、それを使うのが良さそう。 Linux での native library の読み込み問題さえ解決したら PSGameOfLife に組み込めるなーと思ってる。

別の課題もある。 PowerShell Cmdlet 内から Avalonia の普通の使い方をすると初回起動しか成功しない。 2 回目以降は Setup was already called on one of AppBuilder instances になる。どうも同一 process 内で Avalonia の AppBuilder の setup は一度限りというのが仕様みたい。先述の SetupWithLifetime もその対象。また Start 等も内部的に setup を行うので、 2 回目以降同様のエラーが発生する。 Avalonia の event loop は Avalonia.Threading.Dispatcher が担っているようだが、こいつも process で一度限りしか利用できないみたい。 2 回目以降の実行では Dispatcher が破棄されて使えなかった。 PowerShell Cmdlet はその session 内であればずっと同じ process なので、大変だこれ。

たどり着いた回避方法が、 process 内での AppBuilder の setup を 1 度限りにし、 Window を cmdlet 実行毎に生成することだ。 setup については先述の通りだが、 Window も同様で一度 Close すると再利用できなくなる。だから Window を毎回使い捨てる必要がある。いずれも GUI は概ね単一の process で実行されるから、 process 内で使い回せるようにしてないのが仕様なのかな。何にせよ、これで PowerShell の同一 session 内で何度も GUI を起動できるようになった。

fsharp-cmdlet-sandbox/src/avalonia-funcui/Library.fs at dbc637c82935da48d14c0affc69d869a5e43751f · krymtkts/fsharp-cmdlet-sandbox

既に引用した一部を省略してまま検証コードをコピったのが以下。

type MainWindow() as this =
    inherit HostWindow()

    do
        base.Title <- "Example"
        base.Height <- 300.0
        base.Width <- 300.0

        Elmish.Program.mkProgram Main.init Main.update Main.view
        |> Program.withHost this
        |> Program.run

    override this.OnClosed(e: System.EventArgs) : unit = base.OnClosed(e: System.EventArgs)


type App() =
    inherit Application()

    member val mainWindow: MainWindow | null = null with get, set
    member val desktopLifetime: IClassicDesktopStyleApplicationLifetime | null = null with get, set

    override __.Initialize() =
        __.Styles.Add(FluentTheme())
        __.RequestedThemeVariant <- Styling.ThemeVariant.Dark
        printfn "Application initialized with FluentTheme and Dark variant."

    override __.OnFrameworkInitializationCompleted() =
        match __.ApplicationLifetime with
        | :? IClassicDesktopStyleApplicationLifetime as (desktopLifetime: IClassicDesktopStyleApplicationLifetime) ->
            __.desktopLifetime <- desktopLifetime
            // __.mainWindow <- new MainWindow()
            // desktopLifetime.MainWindow <- __.mainWindow
            // desktopLifetime.ShutdownMode <- ShutdownMode.OnMainWindowClose
            printfn "MainWindow set as the main window."
        | _ -> ()

open System
open System.Diagnostics
open Avalonia.Logging

[<Cmdlet(VerbsDiagnostic.Test, "AvaloniaFuncUI")>]
[<OutputType(typeof<PSObject>)>]
type SelectPocofCommand() =
    inherit PSCmdlet()

    static let app =
        // 先述した通り。略

        app

    override __.BeginProcessing() = printfn "BeginProcessing called."

    override __.ProcessRecord() = printfn "Hello from AvaloniaFuncUI"

    override __.EndProcessing() =

        printfn "Starting Avalonia FuncUI application..."

        let app = (app.Instance :?> App)
        app.mainWindow <- new MainWindow()
        app.mainWindow.WindowStartupLocation <- WindowStartupLocation.CenterScreen
        app.desktopLifetime.MainWindow <- app.mainWindow
        app.desktopLifetime.ShutdownMode <- ShutdownMode.OnMainWindowClose

        let cts = new Threading.CancellationTokenSource()

        app.mainWindow.Closed.Add(fun _ ->
            printfn "MainWindow closed, shutting down application."
            cts.Cancel())

        app.mainWindow.Show()
        let ret = app.Run(cts.Token)
        printfn $"Avalonia FuncUI application started successfully. {ret}"

        app.mainWindow.Close()
        cts.Cancel()

        Console.WriteLine("\n\n\n\n\n\n\n\n\n\n")

この 2 つの課題は、 Avalonia の基礎を抑えてたら困らないのかも知れないが、文書量も多いし example から体当たりで対処してしまった。でも issue や discussion でも似たような話題があったから、わかりにくいところなんじゃないかなという気がせんでもない。もっと良い方法があれば知りたい。またこの調査をするに当たり、前例として他に PowerShell の中から GUI を起動する狂った事例ないか探してみたら、安定の Ironman Software さんが随分前にやってた。他にもそこから派生した project もあった。実現方法は違うが、 PowerShell でもできるということがわかり支えになった。

今回わたしがやろうとしてる F# で PowerShell Cmdlet を書いて Avalonia で GUI を表示するってのも、彼らに続く例がない狂った事例のはずだ。うまく実現できたらこれは胸を張って良いはだろう。誰も興味ないやろうけど。

まだ krymtkts/PSGameOfLife に反映してないし、 GUI 版の実装まで随分と時間がかかりそうだ。

F# でミニゲームを書いてる Part 2

Sun, 08 Jun 2025 09:00:00 +0900

前回から始めた Game of Life の実装がようやく一歩前進した。キャプチャは以下の通り。

PowerShell Gallery に v0.0.1 として publish したので、 repository krymtkts/PSGameOfLife も public にした。

結局ゲームの提供方法は PowerShell Gallery を利用することにした。つまり Cmdlet で実行できるゲームということだ。仕事をサボってプレイする PowerFighter(勝手に作った PowerShell ユーザの呼称) が出てくること間違いなし。自分の terminal で Game of Life を実行できるのはなんか良い。まだ単に眺めるだけのゲームだが、気に入っている。

実装力のショボさに故に CUI 版の実装自体に 1 週間ほどかかった。その後時間が確保できなくて publish の準備に取りかかれず 2 週間ほど放置、久しぶりに暇を確保したので、今日公開にこぎつけられた。

開発を通して Game of Life が極めて興味深い題材であり、作っていてのめり込んでしまう、いわば沼であることもわかった。 John Conway のルール以外にも様々なルールが有り、また初期配置もランダム・特定のパターン・アルゴリズムを利用するものがあるのを知った。 LifeWiki が極めて勉強になるし、読んでて楽しい。

今回作ったのはスタンダードな B3/S23 Conway's Life という rule pattern みたい。 rule pattern は指定できるようにしてみたいな。あと指定のパターンを読み込んで再生できるのが一般的らしい。

このように、掘り下げていくと永久に GUI へたどり着かなさそうなので、とりあえず簡単に指定できる仕組みだけ作り GUI へ移ることにした。 GUI の実装ができたらまた戻ってくればいい。

CUI 版の開発は pocof と同じように PSReadLine スタイルを採用した。カーソル下に行追加して screen を作り、処理が終わったら掃除をする方法だ。はじめはゲーム盤のサイズを指定できるようにしていたが処理が面倒すぎるのでコンソール全面を利用するように変えた。世代交代を直列で計算してるし、描画も全面的な書き直しをするようになってるので、処理効率は良くない。でも Windows Terminal では全画面にしても比較的 CPU load も低く、快適な動作になってた。 Visual Studio Code の terminal で試すとちょっと描画が重過ぎるみたいで、 Windows Terminal のように CPU load は低くならない既知の制約がある。

PSGameOfLife は pocof と違って TargetFramework を net8.0 にしている。サポート中の PowerShell を対象にしつつ、この先の GUI 化を見据えると net8.0 を下限にしておくのが無難そうだったからだ。まだ使うの確定ではないが Avalonia.FuncUI は net8.0 が下限みたい。結果、 Windows PowerShell では使えなくなったので至極残念。なんか回避方法あれば提供できる可能性ある。 PowerShell 7.4 以降に対応していて、一応 Windows と Ubuntu on WSL2 では動作確認できている。

因みにこの net8.0 に対応するのは思ったより手間取った。初めはゲーム本体の project だけ TargetFramework net8.0 にして、 test project は net9.0 にしてた。これだと何故か System.Runtime version 9.0.0.0 への参照が残ってしまい、 PowerShell 7.4 で Import-Module するときエラーになってしまった。結局どちらも net8.0 にすることで事なきを得たが、 test project の設定が何故影響したのか不明。

これで遂に GUI programming に着手する準備が整ってしまったワケだ。やれない理由がなくなってしまったし、そろそろ始めるかーという感じ。 test coverage はゲームのコア機能しかカバーしてなくて UI 部分をやってないので低いし、 UI 部分の interface 整理も含めて GUI 版の実装を進めるイメージでいる。 pocof でもそうだったが Console を使う部分をいい感じの testable にするの、未だにいい感じの方法がわかってないから、そこも模索する。いきなり GUI を PSGameOfLife に組み込み始めるのか、なんか sample 的な repo で練習してみるかは、後で考えよう。

続く。

F# で Playwright の Snapshot testing

Sun, 01 Jun 2025 09:00:00 +0900

krymtkts/blog-fable のための snapshot testing を Playwright for .NET で作った。

krymtkts/blog-fable はこのブログの基盤となる repo だ。最近はブログに機能を足すこともまあないので、もっぱら依存関係の更新が主たる修正となってる。 krymtkts/blog-fable に対して Dependabot Version Updates が作った PR を取り込む。 krymtkts/krymtkts.github.io はその歴史を取り込んで、依存関係が更新される。

この更新される依存関係は Fable 、 Feliz 、 marked 、 Bulma 等。大きな変更があったら、出力される HTML や style 等の内容が壊れるタイプのものなのだ。ごく稀に描画の結果が変わったりして(確か過去に)、気づかずそのまま出して慌てて週セ、みたいなのがあった。それで依存関係の更新時は自動で PR を merge せずに、手動で動かしてみて目視チェックして OK なら merge している。大した手間ではないが、それが面倒なのでどうにかしたいなと考えていた。

こういった HTML の出力結果の違いを検知するには Snapshot testing が最適だ。 Playwright は使いやすさがイケてるとずっと聞いてたが触ったことなかったし、いい機会なので実装してみた。動機が先述の通りなので、今のところ krymtkts.github.io では使わないつもり。日々の booklog や post を作るのが面倒になるだろうし。

Snapshot testing by krymtkts · Pull Request #350 · krymtkts/blog-fable

今回は snapshot testing にしたが、スタイルも含めた描画結果を visual comparison をするなら screenshot が一番いいだろう。 GitHub では履歴の画像の比較もできるし、そういう意味でも向いてるなと思った。

ただ screenshot にすると描画される端末の影響が少なからずある。これは自分の開発機で出力した結果と GitHub Actions に作った CI で出力した結果は必ずしも完全一致しない可能性があるということだ。問題が発生したときいちいち調べるのは極めて面倒なので、今回描画された HTML の snapshot を保存し、それで比較することにした。残念なことに Playwright for .NET の snapshot は style を含まない。もし Bulma の出力する CSS が変わるような破壊的な変更だと気付けないことになる。片手落ち感があるが仕方ないと一旦割り切る。

ちなみに snapshot を取る機能は Playwright for .NET に組み込まれているが、どうも npm の Playwright のように高機能ではないらしい。 [Question]: Visual comparisons Feature Parity · Issue #1854 · microsoft/playwright-dotnet

ただそれ以前の話 krymtkts/blog-fable では Expecto と Playwright の組み合わせでやったので、提供されてる unit test の base class がない。 Installation | Playwright .NET に記載があるのは MSTest 、 NUnit 、 xUnit だけある。なので ToMatchAriaSnapshotAsync のような便利な asserter が使えない。仕方ないので、 snapshot の保存と比較は愚直に自前で実装した。以下にほぼコピペママのコードを示す。 snapshot 毎に test を分けても良かったがこれも考えることが増えそうなので直列で実行する 1 ケースにした。

module Tests

open System
open Expecto
open Expecto.Flip

open Microsoft.Playwright

open DevServer
open Suave
open System.Threading

(*
This tests requires the Playwright CLI to be installed.
ex) PS> ./test/bin/Debug/*/playwright.ps1 install
*)

type DevServer() =
    let home = IO.Path.Join [| __SOURCE_DIRECTORY__; ".."; "docs" |]
    let port = port
    let root = "/blog-fable"
    let webServer = startWebServerAsync (suaveConfig home) (webpart root) |> snd
    let cancellationTokenSource = new CancellationTokenSource()

    do
        Async.Start(webServer, cancellationTokenSource.Token)
        printfn $"Dev server started at http://localhost:%d{port}%s{root}"

    member __.Port = port
    member __.Root = root

    interface IDisposable with
        member __.Dispose() =
            printfn "Stopping dev server..."
            cancellationTokenSource.Cancel()

type IPlaywright with
    member __.NewChromiumPage() =
        task {
            let! browser = __.Chromium.LaunchAsync()
            return! browser.NewPageAsync()
        }

type IPage with
    member __.GotoAndCheck(url: string) =
        task {
            let! response = __.GotoAsync(url)

            match response with
            | null -> return Error "Failed to load page: %s{url}"
            | r when not r.Ok -> return Error "Failed to load page: %s{url}"
            | r -> return Ok r
        }

let snapshotDir = IO.Path.Combine(__SOURCE_DIRECTORY__, "snapshots")

let ensureSnapshotDir () =
    if snapshotDir |> IO.Directory.Exists |> not then
        snapshotDir |> IO.Directory.CreateDirectory |> ignore

let getSnapshotPath (path: string) =
    if "http" |> path.StartsWith then
        failwith "Path should not start with 'http'. Use relative paths instead."

    let fileName = path.Replace("/", "_")
    IO.Path.Combine(snapshotDir, fileName + ".snapshot")

let saveSnapshot (path: string) (content: string) =
    IO.File.WriteAllTextAsync(path, content, Text.Encoding.UTF8)

let loadSnapshot (path: string) =
    task {
        if path |> IO.File.Exists then
            let! content = IO.File.ReadAllTextAsync(path, Text.Encoding.UTF8)
            return content |> Some
        else
            return None
    }


[<Tests>]
let tests =
    testList "snapshot testing" [

        testAsync "comparison" {

            let paths =
                [

                  "/index.html"
                  // ...直に URL を羅列している

                  ]

            use server = new DevServer()
            let baseUrl: string = $"http://localhost:%d{server.Port}%s{server.Root}"
            ensureSnapshotDir ()

            return!
                // TODO: i want to use testTask here, but i don't know how to convert it.
                task {
                    use! playwright = Playwright.CreateAsync()
                    let! page = playwright.NewChromiumPage()

                    for path in paths do
                        let url = baseUrl + path
                        let snapshotPath = getSnapshotPath path

                        printfn "Loading %s..." url

                        let! response = url |> page.GotoAndCheck

                        match response with
                        | Error msg -> failwithf "%s" msg
                        | Ok _ -> ()

                        let locator = "html" |> page.Locator
                        let! content = locator.AriaSnapshotAsync()
                        let! expectedContent = snapshotPath |> loadSnapshot

                        match expectedContent with
                        | Some expectedContent -> content |> Expect.equal $"Content mismatch for {url}" expectedContent
                        | None ->
                            do! saveSnapshot snapshotPath content
                            printfn $"Saved new snapshot for %s{url} to %s{snapshotPath}"

                }
                |> Async.AwaitTask
        }

    ]

Fable によって生成された HTML を file:// scheme で読み込んでも良かったが、 local server 経由にしている。元々開発用 server も Suave で作ってあるし、それを今回共通化する形で test project に取り入れた。つまり従来の開発用 server は起動のみを行い、 server の定義本体は test project を参照するようになった。

この開発用 server の流れで、当初は F# Interactive の script で snapshot testing も実装しようとしていた。しかし Playwright の初期設定に実行する ./test/bin/Debug/*/playwright.ps1 install が dotnet build されてる前提で、できなかった。数年前は回避法があった ↓ ようだが、今では配置が変わったようで使えなかった。ひょっとしたら別の回避方法があるかも知れないが。 Playwright in F# scripts · Issue #1590 · microsoft/playwright-dotnet

Playwright for .NET を F# で使うことに関しては、それほど困ることはなかった。ただ Expecto と Playwright for .NET の組み合わせをあまり御しきれなかった。 Playwright for .NET の機能は概ね Task を返すので、それをうまく使うには testTask が良いだろうと思ったのだが、ダメだった。 testTask は ValueTask を期待してたり use! で IAsyncDisposable を期待してたりで、つなぐための glue code が多くなりもうええか、と。結局 testAsync の中で task CE を Async.AwaitTask するというイケてなさそうな書き方が最もシンプルになった。これももっとうまく取り回せる方法があれば変えたい。

以上で最低限の簡単な snapshot testing 実装を終えた。今後これを洗練してく動機はあまりないけど、 testTask と Playwright の協調はもうちょっと頑張りたい気もするな。 snapshot の撮り直しも、今は作成済み snapshot を消して実行、という形だけなのでなんかあってもいいかも。でも今のも十分簡素でよいが。続くかも。

GitHub streak 1000

Sun, 25 May 2025 09:00:00 +0900

漸く GitHub の Current streak が 1000 を超えたので、それについて書く。

今日時点で streak は 1008 らしい。考えてみれば 1000 日以上続けられてるわけなので、コツコツ積み上げてこれた感じする。でも世の中には 2000 超えや 3000 間近の人がいるのも事実なので、今後もひたすらに積み重ねていくのみやなと思っている。

この積み重ねに何か意味があるのかという点にはついては、多分持たないと思ってる。ひょっとしたら今の段階でも commit する所作が磨き抜かれて常人よりも速くなってるかも知れない。でも 1000 を超えた今すごく変わったような実感はないので、 2000 でも 3000 でも同じ感想だろう。ひたすら没頭し気付いたら周りとは一線画す何かを習得してた、みたいなことになってたら狂気があって良いな(自覚ないのはメタ認知に問題ありとも言えるが)。

streak 2 年を達成するときの日記を読み返すと streak 自体がヌルゲーになってしまう危惧をしていたようだ。実際のところ、習慣化した今となってもオートモードでも時間を消費するのは変わらないので、そういう意味だとヌルゲーではないかな。 booklog も習慣化したし、とにかく毎日やらないといけない習慣が決まっているので、その時間の確保をするための行動や計画をしている感じはある。家族の予定や睡眠の時間を削るわけにはいかないし、如何にも効率厨的な作業ゲーなのかも知れない。

習慣と脳の科学を読んだことで、自身の習慣に対する解像度も上がった。 streak や booklog のような記録や行動の計画が継続に役立つという実感が、理論的な裏付けされたのが心強い。それもあって、大きな環境の変化がない限りは、この習慣が途切れることはないだろうという自信にもつながっている。

別に毎日続けなくてもいいねんよなというのはあるが、これは自分で決めた曲げられない自分ルールなので、今後も粛々と繰り返し積み重ねていくだけ。正直なところ次のマイルストーンを設定する必要もないのだけど、とりあえずもうちょっとで満 3 年なので、まずそこ。その次は毎周年を祝いつつ 2000, 3000 を記念できていけばいいか。明らかに満 2 年を達成したときより熱量が低くて淡々としており実によろしい。

F# でミニゲームを書きたい

Sun, 18 May 2025 09:00:00 +0900

前回で krymtkts/SnippetPredictor は落ち着いたつもり。 krymtkts/pocof もまだ弄りたいところはあるけどちまちましたもののつもり。なので今日は今後やりたいなと思ってることをメモしておく。

なんとなく最近触れてないタイプのテクノロジに触れたいなーと思っており、そういえばここ数年まともに GUI やってないなと気付いた。ここ数年の仕事では React やら PHP やらもっと前なら Delphi やら Visual Basic やらで GUI 色々やってた。けど趣味ではやったことはない。そこで、折角なので F# で GUI やれないかなと考えた。ネイティブ寄りの GUI を。やるならミニゲームやな。ゲーム開発となると全くの未経験なのでちょうどよかろう。

ひとまず GUI のフレームワークに関して。まずきょう時点のわたしが知る限りの、 F# の GUI 周りをまとめておく。とはいうものの、 F# の UI 事情がちょっとややこしくてわかってないので、振り返りも兼ねている。

最初は Elmish について。

最初 Elmish は Fable のものかと思ってたが、 WPF や Avalonia をターゲットにしてもいけるらしい。 Web だけじゃないんか。要は Elmish 自体はビルド先が何かは関係ない。 Elm-ish な Model-View-Update architecture を導入するメタパッケージ的なやつで、 platform に合わせた実装部分が切り離されてる。少なくとも 2025-05-17 時点では。

The goal of the architecture is to provide a solid UI-independent core to build the rest of the functionality around. Elm architecture operates using the following concepts, as they translate to Elmish:

Elmish のページにもそんなふうに書いてある。

次は、先に名前が上がったが、 Avalonia について。

Avalonia もよくわからん。 OSS の .NET の coss platform UI framework 。 Windows Forms 、 WPF や MAUI といった MS 謹製 UI framework とは別の世界にいるみたい。 F# で Avalonia を使うなら、 fsprojects/Avalonia.FuncUI があって、 FP らしい宣言的 UI の書き方ができる。 Avalonia.FuncUI はそれ単体で使えるけど、Avalonia.FuncUI.Elmish という package もあって「え... Elmish で使えんの？」というのもわかった。 Avalonia を Elm-ish に使うための package やと Avalonia.FuncUI の README.md に sample が載ってる。登場人物 2 名の時点でややこしくなってきた。

あと F# には Fabulous もあったわ。

Fabulous はモダンな宣言的 UI framework で、 Elmish 同様に MVU architecture を導入するためのメタパッケージ。それ自体は UI control を持たない。 ↓ に引用した文が Fabulous 2.0 | Fabulous に書いてあった。

Note that Fabulous itself does not provide UI controls, so you'll need to combine it with another framework like Xamarin.Forms, .NET MAUI or AvaloniaUI.

最後に Windows Forms や WFP (多少面倒らしい)は F# 直でも使え。 MAUI は無理なんか情報見当たらず。いったんこれは抜きに考えようか。

結局のところ以下になるのかな。ややこしすぎる。

何らかの UI のパターンを導入するなら Elmish, Avalonia.FuncUI, Fabulous の 3 つの選択肢
cross platform 抜きに考えたら Windows Forms, WPF, MAUI, Avalonia の 4 つの選択肢

もっと踏み込んだ話になると、 UI component 毎に得意な Platform がそれぞれ違うらしいが、もうそこまでは追いきれないからやめ。

とりあえず GUI 周りはこんな感じか。でもこれらが pixel 描画に向いてるかどうかは全く知らんのよね。これらの土俵じゃないんかなー。わからなさすぎて最高。可能であれば cross platform にいきたいけど、面倒そうなら最初は Windows Forms で始めて...みたいなのもありか。 System.Drawing を使えばいいのよな。

題材は、お試しなので Game of Life みたいなよく知られた簡単そうなやつから始められたら良さそう。ひとまず F# の CUI の Game of Life 実装があったから fork した。

krymtkts/conways-game-of-life-fsharp: F# implementation of Conway's game of life

試しに動かしてみたら、わたしの 2017 年の laptop ではパフォーマンスに問題があったので最適化してみた。そのコードをいじる過程に並行して Wikipedia の Game of Life のページを見たりして理解を深めたつもり。ゲームのコアの部分と描画部分は切り分け可能なので、こいつで得た知識をもとにコアを実装、 GUI は別途練習して、最後につなげるみたいな流れでできたらいいのかな。

日記に書く暇あったら sample だけでもはよ作れよという感じではあるが。

続く。

F# で command-line predictor を書いてる Part 8 - 0.4.0

Sun, 11 May 2025 09:00:00 +0900

krymtkts/SnippetPredictor の v0.4.0 をリリースした。

v0.4.0 は主に FSharp.Analyzer.SDK とか Dependabot の reviewers の置き換えととか、内部的なリソース管理の更新とか、機能に関係ない更新が多かった。その中で唯一 snippet に設定した group を部分一致で suggestion に表示する機能を追加した。この機能は、例えば個人の環境と仕事の環境で snippet が違うことはよくあって、その場合に何の group があるかインタラクティブに一覧できるといいかなという動機でつけた。自分が実際そういう使い方なので、あると記憶を引き出すのが楽かな的な。仮に利用者が自分でつけた group を覚えてたら使う機会もないだろう。

元々は Register-ArgumentCompleter みたいな補完候補を出してもらえると良いのではないかと考えた。でもその場合 : を擬似的な native command にして、そこから commandAst を分解して～みたいな手順になり、なんか違うなと。コマンドじゃないし。なので落とし所としては command-line predictor の仕組みに閉じるのが良いかなと判断した。

現状は入力似合わせて :group が suggestion に表示されるのみなので、もうちょっとリッチな表現にできんかな―という気もする。が、その場合 .snippet-predictor.json に group に関する付加情報を足すことになりそうだし、一旦やめた。 snippet の先頭数文字を切り出して tooltip に足してもいいかな。幅が全然足りなそうだけど。さらに言えば suggestion の表示優先順位を設定したいが、 command-line predictor にその仕組みがないから現状できない。そこはキーワード入力して絞り込んでいくことで代替するイメージ。

v0.2.0 を出したときに SnippetPredictor の開発は一段落したかといってそうならなかったが、今回で流石に一段落しただろう。またなんか新しいアイデア探すか、いま README.md が質素なのでその辺を AI に拡充させるとか、そんな感じかな。

F# で Cmdlet を書いてる pt.67 - Completed migration from FsUnit.xUnit to Expecto

Sun, 04 May 2025 09:00:00 +0900

krymtkts/pocof 開発をした。

FsUnit.xUnit v6.x を Expecto へ置き換えた。 #343

多くは単純な書き換え作業だったし、書き換え方を決めたりサンプル実装を示せば、あとは GitHub Copilot Agent にほぼ作業を任せられたのは楽だったと言えるか。ただしうまく働かせるにはそれなりの工夫が必要だった。

Copilot Agent にとって初めてのファイルので作業は、プロンプト等の参考になる情報を渡してもうまく作れなかった。代替手段として、同じファイル内にサンプル実装を足してやれば、自分で修正できるみたい。知名度的に学習ソースにないからか、 Expecto で利用可能な assertion が何か知らなくてその辺もサポートしてやる必要があった。

あと 1000 行超えるような長いファイルになると途端に処理が遅くなってダメだった。 CPU が天井に張り付いてたし、開発 PC の laptop が 2017 モノでしょぼいからだと思われる。 Agent 自体は local の性能そんなに必要としないと思ってたが違うようだ。でも module や type で小分けに作業を頼むと、遅いがなんとか少しずつ進められるようだった。 80 点くらいのコードは出せる感じなところも優秀な新人ぽい感触。なので頼んでは別のことをして、回答が揃ったら手直ししてやるみたいな進め方が一番良い。

ただこの方法でも、スコープ内のテストケースが多いとテストケースを削った結果を出力してきて困った。テストケースの数が減ってるから全ケースを書き直して出力して、と指示しても頑なに守れなかったので手で直して。この場合は回避手段あるのか怪しい。 Agent でも読み解けるような量のコードにする必要があるのかもな。

単純な書き換えのあとは、 xUnit と FsCheck の統合 PropertyAttribute を Expecto 形式に書き換えた。 FsUnit.xUnit 用の PropertyAttribute を使ってるのもあって、ちょっと書き換え面倒なのではと思ったが、 config に書き換えるだけだったのでさっくりいった。以下のように書き換えた。

    // FsUnit
    [<Property(Arbitrary = [| typeof<UnknownAction> |])>]
    let ``should return unknown action error.`` (data: string) =
        data
        |> Action.fromString
        |> shouldEqual (Error $"Unknown Action '{data}'.")
        |> Prop.collect data

    // Expecto
    [<Tests>]
    let tests_unknownAction =
        let configUnknown =
            { FsCheckConfig.defaultConfig with
                arbitrary = [ typeof<UnknownAction> ] }

        testList
            "Action.fromString (unknown)"
            [

              testPropertyWithConfig configUnknown "When unknown action, should return error"
              <| fun (data: string) ->
                  data
                  |> Action.fromString
                  |> Expect.equal "should return unknown action error" (Error $"Unknown Action '{data}'.")
                  |> Prop.collect data

              ]

コード量増えとるがな！というのは置いといて、依存関係の競合を解消するためには乗り換えるのが最善手だったので良いのだ。

これで終わりだと思っていたが、 BenchmarkDotnet を使っている benchmark の project で dotnet build 時にエラーが出るようになった。

Files in libraries or multiple-file applications must begin with a namespace or module declaration, e.g. 'namespace SomeNamespace.SubNamespace' or 'module SomeNamespace.SomeModule'. Only the last source file of an application may omit such a declaration.

どういうわけか BenchmarkDotnet を呼び出すための EntryPoint 付き main 関数が競合しているという。始めよくわからなかったが、コード上には競合がないし、自動生成される entry point なんやろなということろでピンときた。

benchmark の project は test 用の UI の mock を project reference で借りてきてる
test project は Expecto を利用するようになったので YoloDev.Expecto.TestSdk を使っている
YoloDev.Expecto.TestSdk は Microsoft.Testing.Platform に対応しており実行ファイルが生成される

つまりこいつが entry point を生成してるみたい。今考えたらそらそうかという感じなのだけど。

以下のように project の asset から除外するものを指定したらエラーを解消できた。 #344

    <ProjectReference Include="..\pocof.Test\pocof.Test.fsproj" >
      <ExcludeAssets>build; analyzers; buildtransitive</ExcludeAssets>
    </ProjectReference>

結構作業は多かったが乗り換え完了。念願果たせた。前回も触れたが testing framework の乗り換えってあまり人生でも起こらない(面倒でやらない)から、いい経験になった。

F# で Cmdlet を書いてる pt.66 - from FsUnit.xUnit to Expecto

Sun, 27 Apr 2025 09:00:00 +0900

krymtkts/pocof 開発をした。 krymtkts/SnippetPredictor の開発で得た知識を展開している。

FSharpLint に代わる FSharp.Analyzer.SDK Ionide.Analyzers の導入は簡単に済んだ。 #340 良い。 bool Partial active Pattern のような F# 9 で増えた feature はチェックできてないみたい？なのでそこは追って調べていくつもり。

次に念願であり一番の大物である FsUnit.xUnit v6.x の Expecto へ置き換えを始めた。これはちょっと時間がかかりそうだ。前にも触れたが、 FsUnit.xUnit v7 は xUnit v3 に依存してるが FsCheck は現状 v2 に依存している。これによって依存関係が塩漬けされているので、この際乗り換えようという算段だ。

まずひとつ学んだのは、 FsUnit.xUnit(というか xUnit v2) と Expecto は共存できるということ。ただし Expecto は YoloDev.Expecto.TestSdk を導入して Microsoft Testing Platform で動かす前提だ。 Expecto のテスト実行を以下のように EntryPoint に含めてもだめだった。ちゃんと調べてないが xUnit v2 のテスト検出の仕組みでは EntryPoint はただの compile を通すだけのハリボテて対象に含まれないのだと思われる。

module Program

open Expecto

[<EntryPoint>]
let main argv =
    runTestsInAssemblyWithCLIArgs [] argv // こうしても Expecto のテストが検出されない

先述の通り YoloDev.Expecto.TestSdk を使い以下の構成してみたらうまく両方のテストが実行されて素晴らしかった。 testing framework の共存・乗り換えってあまり人生でも起こらないし、いい経験になった。

  <!-- 略 -->
  <ItemGroup>
    <!-- ここから-->
    <PackageReference Include="Expecto" Version="10.2.3" />
    <PackageReference Include="YoloDev.Expecto.TestSdk" Version="0.15.3" />
    <!-- ここまでが増えた-->
    <!-- NOTE: FsCheck.Xunit does not support xUnit.v3 yet. -->
    <PackageReference Include="FsCheck.Xunit" Version="3.2.0" />
    <PackageReference Include="FsUnit.xUnit" Version="6.0.1" />
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.13.0" />
    <!-- NOTE: Replace xunit with xunit.v3 from FsUnit.xUnit 7. -->
    <PackageReference Include="xunit" Version="2.9.3" />
    <PackageReference Include="xunit.runner.visualstudio" Version="3.0.2">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
    <!-- 略 -->
  </ItemGroup>
  <!-- 略 -->

この辺なんでうまくいったのか理解できるような Microsoft Testing Platform の解像度を持ち得ていないので、そこを掘り下げるのは今後の宿題としたい。

これで FsUnit.xUnit 形式のテストを Expecto で書き換え始めたわけで、 test case の書き換えを始めた。 #343

変更に関しては、これまで以下の前者の形式だったやつを、後者の通りにするだけ。

    // FsUnit.xUnit
    module Option =
        // 略

        [<Fact>]
        let ``shouldn't call Dispose if Some.`` () =
        // 略

    // Expecto
    [<Tests>]
    let tests_Option =
        testList
            "Option"
            // このカッコの書き方は行を余計に確保するが、この方がテストケースを足すとか先頭末尾のカッコの重なりを回避できてよろしい
            [

              test "When Some." {
                  // 略
                  mock.disposed |> Expect.isTrue "should call Dispose"
              }

              ]

だがご覧の通り、 FsUnit.xUnit では module name と let で記述していたテストの内容を Expecto では name なり message に分割して記述する必要がある。これまでデタラメ English で書いてた test case の説明を校正するような感じ。

人力でやるの辛いなと思い GitHub Copilot に託してみた。最初 GitHub Copilot は Chat も Agent mode でもイマイチだったが、一度お手本を書いてやると良い感じに動き出した。恐ろしい学習力やな。 Copilot Agent はこの説明を校正するのを初手ではうまくやれなくて重複した文章を取り除いたりできなかったが、 session 中で回を重ねるとどんどん良くなる。恐ろしい子。

[<Fact>] → [<Test>] の書き換えは簡単にできるとわかったから、ざーっと全体を直してしまえそう。その後は FsUnit.xUnit の FsCheck 統合 [<Property>] を Expecto 形式に直すイメージで進める。

F# で command-line predictor を書いてる Part 7 - GitHub Code Scanning

Sun, 20 Apr 2025 09:00:00 +0900

krymtkts/SnippetPredictor の開発をした。

Fsharp.Analyzers.SDK で作成した Code Scanning Alerts の解消をした。 #48

ただ Code Scanning Alerts が解消されたにも関わらず Open なままだった。よくわからんなーと思っていたのだが、途中で Code Scanning の configuration を変えたらそうなるという仕様のようだった。なんてこったい。解消するには以下の通り、古いのと新しい configuration とが競合してることによるようなので、古い方を消したら良いようだ。

消してみたら全部の alerts が解消されてスッキリした。

因みに alert の内容は妥当な感じのやつだったが 1 つ困ったのがあった。このルール。

StructDiscriminatedUnionAnalyzer | ionide-analyzers

    [<RequireQualifiedAccess>]
    [<NoEquality>]
    [<NoComparison>]
    type SearchCaseSensitive =
        | CaseSensitive
        | CaseInsensitive

こういう DU を作って、それに Interlocked を使って atomic な操作をしてるところがあった。この DU を Struct Discriminated Unions にしてもいいよというヒント。メモリが無駄なのでって文脈だろう。構造体にすると Interlocked を使えなくなるし(参照型で wrap してもまじで意味ない)、どうしたもんかと。個別の alert を無効化する方法がわからなかったし、ヒントなので対応しなくても良いのだけど、 alert は 0 の方が安心感ある。この際なので Interlocked で DU を扱うのをやめて int に変換する形で mutable な変数に格納するように変えた。こんなんを使う。

   module CaseSensitivity =
        [<Literal>]
        let sensitive = 1

        [<Literal>]
        let insensitive = 0

    module SearchCaseSensitivity =
        let ofBool =
            function
            | true -> CaseSensitivity.sensitive
            | false -> CaseSensitivity.insensitive

        let stringComparison =
            function
            | CaseSensitivity.sensitive -> StringComparison.Ordinal
            | _ -> StringComparison.OrdinalIgnoreCase

因みにずっと知らずに生きてきたのだが、変数名が upper case で始まる場合 match expression の pattern に使えるみたい。そうなんや...よく今まで生きてこれたな。でも F# like な命名に即すると Upper camel case は違和感ある。この場合上記のように module で修飾すれば良い。

やっぱこういう気付きがあることからも、 F# のような強力な言語でも linter の類はあった方がいいよな。 FSharpLint を使いこなせなくなって久しかったので助かった。

FSharpLint のメンテに関しては、 2 週間ほど前に追加のメンテナをコミュニティで募集しよか？と Don さんが issue 立ててた。なんか変化起こるかなー。 Checking on on maintainers status · Issue #721 · fsprojects/FSharpLint

F# で command-line predictor を書いてる Part 6 - FSharp.Analyzer.SDK

Sun, 13 Apr 2025 09:00:00 +0900

krymtkts/SnippetPredictor の v0.3.0 をリリースした。

v0.3.0 の新しい機能は、前に触れていた snippet の検索の case-sensitivity を指定する option の追加だ。

ただこれは PSReadLine の挙動的には HistorySearchCaseSensitive で制御可能なので、設定ファイルに持たせた方がいいかも。

今度こそ一通りの機能が揃ったか。あと使い出して感じてるのが、よく使う snippet の表示順位を上げられたらいいなというところだが、この場合 snippet を選んだ履歴を記録する必要があるからなんともなという感じ。 .snippet-predictor.json とは別に二重で記録するわけになるからなんともな。これは本当に必要か検討を要する。

あと、 SnippetPredictor は長らく linter の類を CI に組み込んでなかったのだけど、追加したのでそれを記録しておく。

SnippetPredictor は pocof での経験から FSharpLint をうまく使えてないのもあって、 linter の類を CI に組み込んでなかった。しかし最近 Fsharp.Analyzers.SDK で解析できるのを知ったので、これを導入してコード解析する。知ったきっかけは Fantomas で使われてるのを見つけたから。スキャン結果の SARIF report を生成して GitHub の Code Scanning にアップロードしてた。

fantomas/.github/workflows/main.yml at 938160e6c9660af5bda33e4d20c7b522b8359789 · fsprojects/fantomas

数ヶ月 FSharpLint が使えなくなって無防備になってるわたしにとっては、こりゃ良さそうだと考えた。

導入の手順は Installation | FSharp.Analyzers.SDK と Ionide.Analyzers | ionide-analyzers を参考にした。

はじめに tool を導入する。

dotnet tool install fsharp-analyzers

次に解析対象の project に Ionide.Analyzers を追加する。初めてなので、単純化のため G-Research.FSharp.Analyzers の導入はしてない。最新 version がわからなかったので、 dotnet add ~ で追加してから IncludeAssets を編集した。

dotnet add ./src/SnippetPredictor package Ionide.Analyzers

    <!-- Analyzer configurations. -->
    <PackageReference Include="Ionide.Analyzers" Version="0.14.4">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>

Paket を使ってない場合、実行するには analyzer の path を --analyzers-path に指定する必要がある。 FSharp.Analyzers.SDK にはその path を知る方法が書いてない(熟練の .NET ユーザにならよく知られたものかも知れないが)。 Ionide.Analyzers の方はその点わかりやすく、具体的に NuGet で install された analyzer の配置先を取得するための手順が記載されている。これを使って以下のようにコマンドを構築でき、実行できるようになった。

$analyzerPath = dotnet build ./src/SnippetPredictor  --getProperty:PkgIonide_Analyzers
dotnet fsharp-analyzers --project ./src/SnippetPredictor/SnippetPredictor.fsproj --analyzers-path $analyzerPath
# C:\Users\takatoshi\dev\github.com\krymtkts\SnippetPredictor\src\SnippetPredictor\Snippet.fs(163,4): Hint IONIDE-012 : Consider adding [<Struct>] to Discriminated Union
# C:\Users\takatoshi\dev\github.com\krymtkts\SnippetPredictor\src\SnippetPredictor\Snippet.fs(314,28): Hint IONIDE-010 : Seq.filter |> Seq.map can be combined into Seq.choose
# C:\Users\takatoshi\dev\github.com\krymtkts\SnippetPredictor\src\SnippetPredictor\Snippet.fs(89,16): Info IONIDE-002 : Prefer postfix syntax for arrays.
# C:\Users\takatoshi\dev\github.com\krymtkts\SnippetPredictor\src\SnippetPredictor\Snippet.fs(144,15): Warning IONIDE-005 : Test for empty strings should use the String.Length property or the String.IsNullOrEmpty method.
# C:\Users\takatoshi\dev\github.com\krymtkts\SnippetPredictor\src\SnippetPredictor\Snippet.fs(319,18): Warning IONIDE-005 : Test for empty strings should use the String.Length property or the String.IsNullOrEmpty method.
# C:\Users\takatoshi\dev\github.com\krymtkts\SnippetPredictor\src\SnippetPredictor\Library.fs(65,20): Info IONIDE-002 : Prefer postfix syntax for arrays.

コマンドのオプションは文書に載ってなかったので、 --help で確認した。 SARIF report を出力するには --report に file path を指定するだけで良い。

とりあえずコード解析はうまくできるのがわかったので SnippetPredictor の CI に組み込んだ。 #45

CI 的には warn は error にして task をこかせたいところだが、今のところ --treat_as_error で個別の識別子を指定するしかないっぽい。どうしたもんかな。他にも、今は test の project を解析対象にしてないのもあるし、 Directory.Build.props で全体に反映するのがいいかな。 Fantomas では tool の fsharp-analyzers は使ってなくて MSBuild でやってるのだけど、同じ方法を採用するかはちょっと検討。

もうちょっと使ってみて、いい感じの設定ができたら pocof にも反映させよう。

NuGet の Dependabot で project が見つからないエラーを直した

Sun, 06 Apr 2025 09:00:00 +0900

2025-02E 頃から .Net (NuGet) の Dependabot version updates が失敗するようになって、なんでかわからんしそのうち直るかなと放置していた。ただ全然直らないし、 krymtkts/SnippetPredictor でもエラーになってるので、最近になってようやく重い腰を上げて調べてみたところ、以下のようなエラーが出いていた。例は krymtkts/pocof のもの。

nuget in /. - Update #992720506 · krymtkts/pocof@29eff1c

2025/04/03 21:16:53 INFO Temporarily removing `global.json` from `/home/dependabot/dependabot-updater/repo`.
2025/04/03 21:16:53 INFO Restoring `global.json` to `/home/dependabot/dependabot-updater/repo`.
2025/04/03 21:16:53 INFO Discovering build files in workspace [/home/dependabot/dependabot-updater/repo].
2025/04/03 21:16:53 INFO   Discovered [.config/dotnet-tools.json] file.
2025/04/03 21:16:53 INFO   Discovered [global.json] file.
2025/04/03 21:16:53 INFO   Discovering projects beneath [.].
2025/04/03 21:16:53 INFO   No project files found.
2025/04/03 21:16:53 INFO Discovery complete.
updater | 2025/04/03 21:16:53 INFO <job_992720506> Discovery JSON content: {
  ... 長いので省略 ...
}
updater | 2025/04/03 21:16:53 INFO <job_992720506> Discovery JSON path for workspace path [/] found in file [/home/dependabot/.dependabot/discovery_map.json] at location [/home/dependabot/.dependabot/discovery.1.json]
updater | 2025/04/03 21:16:53 INFO <job_992720506> Discovery JSON path for workspace path [/] found in file [/home/dependabot/.dependabot/discovery_map.json] at location [/home/dependabot/.dependabot/discovery.1.json]
updater | 2025/04/03 21:16:53 ERROR <job_992720506> Error during file fetching; aborting: Repo must contain .(cs|vb|fs)proj file.
  proxy | 2025/04/03 21:16:53 [024] POST /update_jobs/992720506/record_update_job_error
  proxy | 2025/04/03 21:16:53 [024] 204 /update_jobs/992720506/record_update_job_error
  proxy | 2025/04/03 21:16:53 [026] PATCH /update_jobs/992720506/mark_as_processed
  proxy | 2025/04/03 21:16:54 [026] 204 /update_jobs/992720506/mark_as_processed
updater | 2025/04/03 21:16:54 INFO <job_992720506> Finished job processing
updater | 2025/04/03 21:16:54 INFO Results:
Dependabot encountered '1' error(s) during execution, please check the logs for more details.
+---------------------------+
|          Errors           |
+---------------------------+
| dependency_file_not_found |
+---------------------------+
Failure running container 8fc2652dfc6bfe10bbe91cc64e0fa63347c0031374edc8419b45c3ce073dcff5
Cleaned up container 8fc2652dfc6bfe10bbe91cc64e0fa63347c0031374edc8419b45c3ce073dcff5
  proxy | 2025/04/03 21:16:55 3/13 calls cached (23%)
  proxy | 2025/04/03 21:16:55 Posting metrics to remote API endpoint
Error: Dependabot encountered an error performing the update

Error: The updater encountered one or more errors.

For more information see: https://github.com/krymtkts/pocof/network/updates/992720506 (write access to the repository is required to view the log)
🤖 ~ finished: error reported to Dependabot ~

No project files found. というログやら dependency_file_not_found というエラーがでて fsproj が見つからなくなってる。このとき dependabot.yml はこうしていた。

# Maintain dependencies for NuGet
- package-ecosystem: "nuget"
  directory: "/"

エラー発生以前は、この設定で指定した directory 配下に対して再帰的に fsproj を検索できていたという認識だが。ただ Copilot や ChatGPT に聞いてもそんなことはできないという。そこで Dependabot の文書をあたってみたところ、今回初めて知ったのだが、 directory は project などの依存関係を管理するファイルが直に配置されてないといけないようだ。

Dependabot options reference - GitHub Docs

Use to define the location of the package manifests for each package manager (for example, the package.json or Gemfile).

エラー発生以前の、 directory 配下に対して再帰的に fsproj を検索できていたのが、むしろ間違っていたと。なんてこったい。

krymtkts/pocof のように複数のディレクトリに依存関係を管理するファイルが配置されている場合は、複数指定できる directories を使うと良いそうだ。また、 directories では glob pattern が使える。それにより pocof では結果的に以下のように 1 要素だけの定義で済んだ。 krymtkts/SnippetPredictor も同様に対処した。

# Maintain dependencies for NuGet
- package-ecosystem: "nuget"
  # NOTE: dependabot raises dependency_file_not_found error with root directory.
  # NOTE: directories can use glob patterns.
  directories:
    - "/src/pocof*"

最後に、これはこの先絶対忘れそうだなということで、備忘のための note も残した。

再帰的に検索するほうが便利よなと考えるが、仕様に準拠してないとなればまあ直すよなという感じ。他の package manager 用の Dependabot と挙動が違うようでは尚更。何にせよ、自身の間違いに気づき、エラーが解決できてよかった。

global.json は JSONC

Tue, 01 Apr 2025 09:00:00 +0900

旅行中のため小ネタ。個人的な無知ゆえに知らなかったものだが、備忘のため記しておく。

global.json overview - .NET CLI | Microsoft Learn

Comments in global.json files are supported using JavaScript or C# style comments. For example:
{
  // This is a comment.
  "sdk": {
    "version": "8.0.300" /* This is comment 2*/
    /* This is a
  multiline comment.*/
  }
}

まじか。 pocof において macOS の GitHub Actions workflow でのみ dotnet tool restore がエラーになる問題があったとき、 .NET SDK を version 固定しないといけなかったのでそのメモを残すのに使った。

因みにもしやと思って他に思いつく .NET 系の設定ファイルで試したところ、 dotnet-tools.json はダメだった。

> dotnet tool restore
Json parsing error in file C:\Users\takatoshi\dev\github.com\krymtkts\pocof\.config\dotnet-tools.json : '/' is invalid after a value. Expected either ',', '}', or ']'. LineNumber: 5 | BytePositionInLine: 6.

dotnet-tools.json で jspnc をサポートしたいという提案は過去にもあったらしいが、頓挫したようだ。

JSON のコメントと空白をどう扱うべきかに関してふにゃふにゃだったので XML に軍配が上がったて流れぽい。議論も止まった様子。

とりあえず global.json だけでも JSONC が使えるということやが、この流れが他にも派生していくかというと、最近 sln が slnx になった流れを見てても XML 優勢なんかなと思えてくるな。

2025-04-01 追記。

このネタ普通に前の日記で書いてたわｗネタ帳から削り忘れてたか...

まあ slnx とも繋げたので全く同じではないか...ということでご愛嬌。

F# で command-line predictor を書いてる Part 5 - coverage 100% にする

Sun, 23 Mar 2025 09:00:00 +0900

krymtkts/SnippetPredictor の v0.2.0 をリリースした。

v0.2.0 の新しい機能は、前回触れた tooltip や snippet に付与した group での絞り込みや、他にも :snp 等の symbol 指定で絞り込む際に case-insensitive にしてみた。ただこれは PSReadLine の挙動的には HistorySearchCaseSensitive で制御可能なので、設定ファイルに持たせた方がいいかも。

あと今回の version から coverage 100% にしてみた。やはり 100% となると、 GitHub Actions で cross platform な test してるのもあって利用可能な全ての platform で一度はコードが実行されてエラーにならないのを保証できるので、安心感が違うなと感じる。今回 100% にするために、半ば無理やり全部通すような test を書いた。 unit test に適さない環境変数周りの処理や、 ICommandPredictor の使わない method のような通常利用で到達不能な部分もだ。

例えば以下の JsonIgnoreCondition.WhenWritingNull と JsonConverter 実装の組み合わせだと、 reader.GetString が null を返す場面がない。 null の処理が skip されることによるみたい。

type GroupJsonConverter() =
    inherit JsonConverter<string>()

    [<Literal>]
    static let pattern = "^[A-Za-z0-9]+$"

    static let regex = Regex(pattern)

    override _.Read(reader: byref<Utf8JsonReader>, _typeToConvert: Type, options: JsonSerializerOptions) =
        reader.GetString()
        |> function
            | null as value -> value // NOTE: unreachable when JsonIgnoreCondition.WhenWritingNull is used.
            | value when regex.IsMatch(value) -> value
            | value -> JsonException(sprintf "Invalid characters in group: %s" value) |> raise

    override _.Write(writer: Utf8JsonWriter, value: string, options: JsonSerializerOptions) =
        value |> writer.WriteStringValue

type SnippetEntry =
    { Snippet: string
      Tooltip: string
      [<JsonConverter(typeof<GroupJsonConverter>)>]
      [<JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingNull)>]
      Group: string | null }

しかも GroupJsonConverter を直接テストしようにも、シグネチャファイルに記載してなかったのでそのままだとテストできない。公開するつもりもない型なので足す気もないし。結果的に DEBUG 条件付きでシグネチャファイルに含めるようにして直接テストするようにした。

シグネチャファイルがこう。

#if DEBUG
type GroupJsonConverter =
    inherit System.Text.Json.Serialization.JsonConverter<string>

    new: unit -> GroupJsonConverter

    override Read:
        reader: byref<System.Text.Json.Utf8JsonReader> *
        _typeToConvert: System.Type *
        options: System.Text.Json.JsonSerializerOptions ->
            string

    override Write:
        writer: System.Text.Json.Utf8JsonWriter * value: string * options: System.Text.Json.JsonSerializerOptions ->
            unit
#endif

テストコードはこう。

#if DEBUG

module GroupJsonConverter =
    open System.Text.Json

    [<Tests>]
    let test_GroupJsonConverter =
        testList
            "GroupJsonConverter"
            [

              test "when the value is null " {
                  let json = """{"key": null}"""
                  let mutable reader = new Utf8JsonReader(System.Text.Encoding.UTF8.GetBytes(json))

                  reader.Read() |> ignore // {
                  reader.Read() |> ignore // "key"
                  reader.Read() |> ignore // null

                  let result: string | null =
                      GroupJsonConverter().Read(&reader, typeof<string>, JsonSerializerOptions())

                  match result with
                  | null -> ()
                  | _ -> failtest "Expected null but got a different value"
              }

              ]

#endif

あと F# ならではの coverage 100% の難しさとして、 IL(中間言語) に到達不可能な pass が生成されるケースがある。既知のものでいうと例えば string の slicing 。今回は新たに static let でも到達不能な pass が生成されるのを確認した。

例えば以下、 static let によって internal static int init@47 が生成され、 Read method に分岐が生えてしまう。

type GroupJsonConverter() =
    inherit JsonConverter<string>()

    [<Literal>]
    static let pattern = "^[A-Za-z0-9]+$"

    static let regex = Regex(pattern)

    override _.Read(reader: byref<Utf8JsonReader>, _typeToConvert: Type, options: JsonSerializerOptions) =
        reader.GetString()
        |> function
            | null as value -> value // NOTE: unreachable when JsonIgnoreCondition.WhenWritingNull is used.
            | value when regex.IsMatch(value) -> value
            | value -> JsonException(sprintf "Invalid characters in group: %s" value) |> raise

上記コードは ILSpy で decompile して C# 表示したらこうなる。 int@47 という属性の分岐が確認できる。

[Serializable]
[CompilationMapping(/*Could not decode attribute arguments.*/)]
internal class GroupJsonConverter : JsonConverter<string>
{
    internal static Regex regex;

    internal static int init@47;

    public override string? Read(ref Utf8JsonReader reader, Type _typeToConvert, JsonSerializerOptions options)
    {
        string @string = reader.GetString();
        string text = @string;
        string text2 = text;
        if (text2 != null)
        {
            string value = text2;
            if (init@47 < 2)
            {
                IntrinsicFunctions.FailStaticInit();
            }

初期化済みか判断する用途くさいが具体的に値が設定される箇所とかがわからなかった。取り敢えず static let を使うと期待しない分岐が発生するのはわかったので、別 module に切り出すことで分岐をなくした。

ややこしい気もするが 100% を目指すと汚れ仕事も必要なのだ。

SnippetPredictor の開発は機能的にはこれで一段落かな。あとは日常利用で、先述の case-insensitive にするやつとか細々とした気になる点に手をいれるくらいの予想。またなんか新しいアイデア探すか。

F# で command-line predictor を書いてる Part 4 - v0.2.0 むけの新機能

Sun, 16 Mar 2025 09:00:00 +0900

krymtkts/SnippetPredictor の開発をした。

新しい機能として、 tooltip での絞り込みと、 snippet に付与した group での絞り込みを追加した。 #22 #23

これによって以下の絞り込みのバリエーションが増えた。

:snp で snippet の絞り込み
:tip で tooltip の絞り込み
:{group} で指定した識別子の group で snippet の絞り込み

{
  "Snippets": [
    {
      "Snippet": "dotnet new classlib --name project --language F# --output ./src/project",
      "Tooltip": "Create a new F# class library project",
      "Group": "fsharp"
    },
    {
      "Snippet": "dotnet tool install fantomas --prerelease",
      "Tooltip": "Install or update Fantomas",
      "Group": "fsharp"
    },
    {
      "Snippet": "dotnet new sln",
      "Tooltip": "Create a new solution file",
      "Group": "project"
    }
  ]
}

みたいなんがあったとして、 :fsharp で絞れる。この例のように、 F# 関連でまとめておきたい snippet があって snippet や tooltip に F# を含まないような場合に "Group": "fsharp" でまとめておけるというメリットがあるはず。 group のこの用途だと実は tooltip の記述を工夫すれば代用できるが、 Get-Snippet で取得した snippet を Where-Object で楽に絞り込むには、やはり別の field を持っているのが最適だと考えた。

今のところ、この group の絞り込みを使うことで絞り込み対象の母数が減って速くなるということはない。愚直に snippet の sequence を絞り込むのに group の条件がついただけになってる。 snippet の登録件数がそんなに多くならないだろうし、空間計算量に寄せるほどでもないかなという直感だ。もし今後件数が増えまくったりして、 command-line predictor の 20ms の制限に触れてくるようなら再検討する。

Group field に設定する値に長さの制限はないが、文字種は [a-zA-Z0-9] しか使えなくしている。 Add-Snippet でも制限されているし、 .snippet-predictor.json 読み込み時にも制限されてる。また Group field は省略可能なので、従来(というほど古くもないけど)の .snippet-predictor の記述通り Group なしの snippet も読める。

Group field の制限は System.Text.Json Namespace を使ってこんなコードでできた。

type GroupJsonConverter() =
    inherit JsonConverter<string>()

    [<Literal>]
    static let pattern = "^[A-Za-z0-9]+$"

    static let regex = Regex(pattern)

    override _.Read(reader: byref<Utf8JsonReader>, _typeToConvert: Type, options: JsonSerializerOptions) =
        reader.GetString()
        |> function
            | null as value -> value // NOTE: unreachable when JsonIgnoreCondition.WhenWritingNull is used.
            | value when regex.IsMatch(value) -> value
            | value -> JsonException(sprintf "Invalid characters in group: %s" value) |> raise

    override _.Write(writer: Utf8JsonWriter, value: string, options: JsonSerializerOptions) =
        value |> writer.WriteStringValue

type SnippetEntry =
    { Snippet: string
      Tooltip: string
      [<JsonConverter(typeof<GroupJsonConverter>)>]
      [<JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingNull)>]
      Group: string | null }

F# 的には group には option を使うべきだろうけど、 .NET と直にやり取りしてるし変換コストを考えたらそのままがいいかなと。 F# 9 で Nullable Reference Type ができたことで、 null を取り扱わないといけないケースも option と遜色なく書けるようになった気がする。代わりに到達不能な branch ができたり coverage 的には頭を悩ますことが多いが。

group には :snp や :tip との一体感やタイプ回数を考えたら小文字英数 3 文字くらいの識別子が良かろうが、分かりやすさ的に英単語を使うのもありかな。いま個人的には英単語の方を、個別の識別子考えて覚える必要ないから使ってる。

いま if 連発で愚直に書いただけのロジックになってるのをリファクタリングしたら、 v0.2.0 としてリリースしたい。

F# で command-line predictor を書いてる Part 3 - Expecto

Sun, 09 Mar 2025 09:00:00 +0900

主に krymtkts/SnippetPredictor の開発をした。 2 ~ 3 月は公私ともに忙しくあまり進捗はないが、テスト周りを整備し始めた。

以前触れたように、 test framework には Expecto をしてみた。年末年始に調べた FsUnit と FsCheck を組み合わせた場合の xUnit version 固定のことを考えたら、より依存関係の少ない Expecto の方が制御可能だろうという見立て。

少し前に、 Microsoft の blog で主要な test framework が Microsoft.Testing.Platform に対応したという記事が流れてたが、その中に Expecto も含まれてる。因みに主要な、とあるようにこれは xUnit も v3 から対応してる。 FsCheck と共に使ってると v2 荷据え置きなので使えないけど。

Microsoft.Testing.Platform: Now Supported by All Major .NET Test Frameworks - .NET Blog

わたしは hobby F# Ninja で .NET のテスト事情門外漢のため、この対応によって安定性だとか移植性だとかが向上しているようだが、具体的に何が変わったのかというのは説明が難しい。たった 1 つ明確に言えることといえば、 Expecto も xUnit も test project の EntryPoint が不要になったところか。

module Program

[<EntryPoint>]
let main _ = 0

従来は明示的に [<EntryPoint>] を作っておかないとテスト実行できなかった。 pocof は今も xUnit を使っているので、 /src/pocof.Test/Program.fs がそうなってる。こういうおまじないがなくなっただけでも、割と十分かなと思っている。

Expecto を初めて使ってみた感触は、Expecto 基本的には関数でモリモリ書くような感じの使い心地。 repo にも書いてあったが使ってみた感じは framework というより library だ。 Attribute も少なく、今のところテスト対象を指定する [<Tests>] しか使ってない。

また Expecto.Flip を使いさえすれば pipe operator で流れるように test code を書けるので、 FsUnit 同等に使えるなという感触だ。事前にこのことを把握してなかったら移行してないくらい重要なこと。この Expecto.Flip については FsUnit の Issue も触れられてる。 FsUnit.Expecto · Issue #120 · fsprojects/FsUnit

いまは example-based test を Expecto で書いているが、 Expecto は FsCheck との統合も自然な感じなので、 PBT も早く試してみたいと考えている。 pocof でも少し PBT を書いているが未熟なので、初っ端から書くというのができてない状態だ。まずは Expecto の練習に努める。

Expecto 自体の話はここまで。次は SnippetPredictor のテストのし難さについてメモしておく。

まず snippet を保存する先がファイルなのもあって .NET の I/O 関連をよく使うのだけど、 Nullable reference type を有効にしてるので、 .NET 由来の library には頻繁に null の取り扱いを示さないといけない。これ自体は安全性のために良いのだけど、 SnippetPredictor で到達不能な pass に於いて発生するもんだから coverage に悪影響及ぼす。仕方ないこととはいえ可能な限り経路をチェックしたいので頭を悩ますポイントだ。

次にこれは一般論でもあるが I/O そのもののテストでの取り扱いも難しい。 0.1.0 は機能をリリースするために testability 考えず作ったので、 I/O 抜きでテストが難しい点がある。 pocof でも似たような課題があり、 unit test ではシンプルな currying ベースの injection を使って処理を差し替えることでテスト可能な範囲を広げたので、 SnippetPredictor でも I/O や環境変数へのアクセスで同様の方針で再構築を考えている。

ただこれの良くない点は実際のコードの一部がテストを通さない点で、即ち coverage に悪影響する。 Pester でのテストで確認できるのであれば不要とも考えることができるが、やはり個人開発で 1 週間とかの比較的長い繰り返し周期で開発するのであれば、 coverage はガチガチにチェックしてた方が安心なのでなんとかしたい。どうせすぐ実装忘れるし。今 I/O に関しては、環境変数で snippet のファイルを配置する directory を指定できる機能を設けてあるので、当面はそれで以てカバーするかも。

ただ Expecto はデフォで並列・非同期に動くらしいから、それを考慮した実装になってないと上記の手段で実装したテストは flaky になるだろう。なので SnippetPredictor 内部の snippet を保持する実装も module ベタに書くんじゃなくて同時実行性を考慮して改修する必要がある。

追加したい機能の案も浮かんでおり、やることは沢山ありそうやけど、そのへんとテストとをいい塩梅に進めていく。続く。

F# で Cmdlet を書いてる pt.65 - .NET SDK のエラーに引っかかった

Sun, 02 Mar 2025 09:00:00 +0900

多分次の release で解消されるであろう .NET SDK の issue を備忘のため記録しておく。

#329 の過程で発見した。

krymtkts/SnippetPredictor の開発を始めて krymtkts/pocof の開発は鈍化してるが、依存関係の更新は Dependabot version updates を使ってるのもあって、大体毎週何かしらの更新があるから追随している。ただ FsUnit.xUnit が v7 で xunit.v3 を使う様になり、 pocof で合わせて利用している FsCheck.XUnit が未だ xUnit.v3 に対応してないため、更新は据え置きの状態になってる。その結果 Dependabot の pull request をそのまま受け入れられない状態が続いたので、昨日そのへんの調整を施した。ただ、その施しはうまくいってるはずなのだけど GitHub Actions の macOS の job だけ絶対に成功しなくなった。

こういうとき、 GitHub Actions の失敗した job の log の末尾だけを見がちなのだけど、それだけだと何が原因かわからなかった。気を取り直して log 全体を見渡すと、先頭の方で他の platform と macOS で出力の違いを見つけた。

Windows と Ubuntu ではこう ↓。

psake version 4.9.1
Copyright (c) 2010-2018 James Kovacs & Contributors

Module: pocof ver0.19.0 root=/home/runner/work/pocof/pocof/src/pocof/ publish=/home/runner/work/pocof/pocof/publish/pocof/
Executing Init
Init is running!
Tool 'dotnet-fsharplint' (version '0.21.2') was restored. Available commands: dotnet-fsharplint
Tool 'fantomas' (version '7.0.1') was restored. Available commands: fantomas

macOS ではこう ↓。

psake version 4.9.1
Copyright (c) 2010-2018 James Kovacs & Contributors

Module: pocof ver0.19.0 root=/Users/runner/work/pocof/pocof/src/pocof/ publish=/Users/runner/work/pocof/pocof/publish/pocof/
Executing Init
Init is running!

Welcome to .NET 9.0!
---------------------
SDK Version: 9.0.200

Telemetry
---------
The .NET tools collect usage data in order to help us improve your experience. It is collected by Microsoft and shared with the community. You can opt-out of telemetry by setting the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to '1' or 'true' using your favorite shell.

Read more about .NET CLI Tools telemetry: https://aka.ms/dotnet-cli-telemetry

----------------
Installed an ASP.NET Core HTTPS development certificate.
To trust the certificate, run 'dotnet dev-certs https --trust'
Learn about HTTPS: https://aka.ms/dotnet-https

----------------
Write your first app: https://aka.ms/dotnet-hello-world
Find out what's new: https://aka.ms/dotnet-whats-new
Explore documentation: https://aka.ms/dotnet-docs
Report issues and find source on GitHub: https://github.com/dotnet/core
Use 'dotnet --help' to see available commands or visit: https://aka.ms/dotnet-cli
--------------------------------------------------------------------------------------
Failed to validate package signing.

Verifying dotnet-fsharplint.0.21.2

Signature type: Repository
  Subject Name: CN=NuGet.org Repository by Microsoft, O=NuGet.org Repository by Microsoft, L=Redmond, S=Washington, C=US
  SHA256 hash: 5A2901D6ADA3D18260B9C6DFE2133C95D74B9EEF6AE0E5DC334C8454D1477DF4
  Valid from: 2/16/2021 12:00:00 AM to 5/15/2024 11:59:59 PM

warn : NU3018: The repository primary signature found a chain building issue: RevocationStatusUnknown: An incomplete certificate revocation check occurred.
error: NU3037: The repository primary signature validity period has expired.
error: NU3028: The repository primary signature's timestamp found a chain building issue: ExplicitDistrust: The trust setting for this policy was set to Deny.

Package signature validation failed.

まず Windows & Ubuntu と macOS では dotnet CLI の version が 9.0.101 と 9.0.200 で違ってる。ただし当時の global.json が以下なので、この dotnet CLI の version の差異は想定内。

{
  "sdk": {
    "rollForward": "latestMinor",
    "version": "9.0.101"
  }
}

次に macOS では NU3018 NU3037 NU3028 が発生しているのがわかるので、こいつで調べると以下にたどり着いた。

dotnet tool restore started failing on macOS with NU3037 and NU3028 errors after 11th February · Issue #46857 · dotnet/sdk

これとこれを見ればわかるが、 macOS では NuGet package の署名検証がコケるから default で無効らしい。公式の文書は NuGet signed-package verification - .NET CLI | Microsoft Learn か。

でも 9.0.200 でデフォルト有効になってしまう変更があったらしい。これは DOTNET_NUGET_SIGNATURE_VERIFICATION = false でも回避できないとか。 issue の Milestone は 9.0.3xx なのですぐには直って落ちてこないかな。

まとめると、 9.0.3xx で直す予定みたいだが、現状の 9.0.200 だと回避できない。つまり workaround として有効な方法は、 9.0.103 に固定することのみと思われるので、今回はそのようにして回避した。

{
  // TODO: pin sdk version to 9.0.103 to prevent `dotnet tool restore` failure on MacOS due to `NU3018`, `NU3037` and `NU3028`.
  "sdk": {
    "rollForward": "disable",
    "version": "9.0.103"
  }
}

こういうトラシューは AI さんにも未だ解けないっぽいので当てにならん。 AI さんにこれをとかそうとしたらどこをどう調べるべきかをレクチュアせねばならず、自分でやるのより面倒だった。

とりあえず、その場しのぎだが CI を動かせるように直せた。調べてみて、現象の報告から 2 週間程度仕方ってないというのもあるかも知れないが、大して知られてない？ような感じ。これは macOS で dotnet 使う人がめちゃくちゃ少ないってことなのでは...

因みに、この過程で global.json に comment を書けることを初めて知った。要は JSON with Comments 。 global.json overview - .NET CLI | Microsoft Learn 多分時代の流れで System.Text.Json を使ってるので deserialize のときは comment が skip されてる。なので serialize するのは()dotnet new globaljson のときくらいしかないと思うが)消えるだろう。

tool manifest dotnet-tools.json でも同様かと思ったが、こちらはこちらで理由があって対応してないみたい。 JSON はコメントの振る舞いに関して定義がないからやらないって感じか。

F# で command-line predictor を書いてる Part 2 - SnippetPredictor 公開

Sun, 23 Feb 2025 09:00:00 +0900

前は sample を作っただけだが、最近 F# で command-line predictor を書くのを本格化した。

krymtkts/SnippetPredictor という。まだ prerelease だが PowerShell Gallery に SnippetPredictor で公開してある。事前に用意しておいた snippet を入力内容に応じて suggestion に表示するという単純な command-line predictor だ。 snippet を表示・追加・削除するための Cmdlet も一緒のバイナリで提供している。

因みに PowerShell の command-line predictor は PowerShell 7.2 ＆ PSReadLine 2.2.2 以降に導入された plugin 機能の 1 つだ。以下の Microsoft の記事が詳しい(当たり前だが)。

How to create a command-line predictor - PowerShell | Microsoft Learn

PSReadLine の experimental feature の PSSubsystemPluginModel を手動で有効化すると使えるようになる。また PSReadLine の option で PredictionSource=HistoryAndPlugin PredictionViewStyle=ListView の設定をする必要がある。

PSSubsystemPluginModel Using Experimental Features in PowerShell - PowerShell | Microsoft Learn

前にも触れたが command-line predictor の作り方は先に挙げた How to create a command-line predictor - PowerShell | Microsoft Learn を参照している。

多分このドキュメントと PowerShell team 謹製の PowerShell/CompletionPredictor とか、個人が作ってるようなのしか参考がないのが現状だろう。今回作ったやつが「個人が作ってるようなの」に仲間入りすることになれば最高やな。

今のところ command-line predictor の一部の機能しか使ってないので、大して困ったことは発生していない。ただいくつか気になる・工夫すべき点があるのは事実で、いかにそのいくつかを記す。

まず、実装して使ってみないと気付けなかった点として、 Name 属性の指定がある。 ICommandPredictor 実装 class に Name 属性で subsystem 実装の名前を定義するのだけど、これが suggestion 右端に [subsystem name] という感じで表示される。なので多少長い名前をつけているだけで幅の制限に引っかかって省略表記になってしまう。実際 SnippetPredictor だと長過ぎて省略されてしまったので Snippet に短縮した。 PowerShell が流行ることはないと思うが、万が一 subsystem が沢山増えた場合、名前の奪い合いみたいになってしまうであろうこと必至。

そして command-line predictor の実装の制約として、① suggestion を 1 行を収める必要があるのと、② 20ms 以内に表示する必要がある。これらは先述の作り方の記事にも書いてある。

① に違反すると PSReadLine が suggestion の ListView 用に確保しているスペースの再描画が崩れる。早い話が suggestion が消費する行の高さまで PSReadLine が計算してないためそうなってる。今のところはそれだけっぽいので気合で使おうと思えばどうにかなるが、見た目にもきれいじゃなく見にくくなるだけなので、やらないのが無難だろう。これが原因でエラーになるとかではないので、比較的ゆるい制約と言える。 ② に違反すると、 suggestion 荷表示されない。これは command-line predictor として役に立たないので非常に気に掛ける必要がある。

SnippetPredictor の場合、 snippet は JSON ファイルに保持している¹ので、読み込みに時間がかかるようなことを避けるべく SnippetPredictor の import 後にファイルの snippet をメモリ上に読み込んで suggestion の絞り込みに利用している。また、ファイルの変更を監視して変更があったら比較的リアルタイムに反映できるようにした。 ① に関しては今のところ機能的に制限していないので、 JSON ファイルに改行文字 \n が含まれたらダメな感じ。なので登録時か出力時に \n を読み替える必要があるかも。検討中だ。

最後に PowerShell で対話型のインタフェースを作ったときに困るのがエラーの表示だ。 pocof でも散々苦労したが、 command-line predictor も例に漏れず、専用のエラー表示 UI は持ってなさそうだ。現状 command-line predictor 自体は suggestion でユーザと対話するしかないので、仮にエラーがあればそこに表示するようにした。 SnippetPredictor の場合は snippet を出せない理由、例えば JSON ファイルのフォーマットが壊れてるとかが表示されることになる。

とりあえず PowerShell module として必要な最低限の要素(機能と help くらい)をざーっと作ったのみなので発見してない bug などあろうが、今のところ気に入っている。テストを全然書いてなかったり、開発を継続するのを楽にする CI とか作ってないので、今後充実していけたら良いなと思う。

他にも pocof で変えたいと思っている点も、 SnippetPredictor のようなまだ出来上がってない project だと導入しやすい。 pocof ではちょうど xUnit をやめて expecto に移行したい気持ちがあるので、 SnippetPredictor では先行して expecto をセットアップしてみたい。

.NET で依存関係なしで楽に実装できてユーザも比較的楽に編集できるのがこれくらいしかなかった。より良い方法は模索中。 ↩

Chocolatey の OpenSSH をやめて WinGet の OpenSSH にする 2025

Sun, 16 Feb 2025 09:00:00 +0900

最近の活動は、 pocof の benchmark に基づいた細かい改善とか、 Command-line predictor を作り始めたのとか。でも今日は最早わたしの中で恒例となった Chocolatey での OpenSSH 話を記す。

随分長い間気づいてなかったのだけど OpenSSH の Chocolatey の最新 prerelease 壊れとるね。

openssh 9.5.0-beta20240403 seems to contain OpenSSH_for_Windows_8.6p1, (#105) · Issues · DarwinJS / ChocoPackages · GitLab

気づかず使ってた。 repo 見ても最新は上記のママだし、変なバイナリ使ってたんかと思ってゾッとしたわ... 一応以下のコマンドで 1 つ前の正しいやつに戻せる。

choco install openssh --version=9.5.0-beta1 -params '"/SSHAgentFeature"' -y -pre --force
choco pin add --name='openssh'

念の為 9.5.0-beta1 に固定したけどこれからどうしよかね。 Windows 11 の標準の SSH が更新によって 9.5.2.1 になってる¹ので、 Chocolatey のやつを使う意味がないという。

Windows の OpenSSH の install に Universal Installer を使うのはもう長らく deprecated で、ただ chocolatey で管理するの楽なので依存し続けてた。 [Deprecated] Win32 OpenSSH Automated Install and Upgrade using Chocolatey · PowerShell/Win32-OpenSSH Wiki

今の公式な install 手段としては MSI 直か WinGet な感じはする。この手段でなら最新の beta も取れるし。 WinGet にはまだあんま踏み込んでないけど、この機会に始めるべきかな～そんで DSC も嗜む？みたいな。

何度か WinGet への移行は考えてたけど、ビミョーに痒いところに手が届かないのよな。 Maven がないとか(mvn はもう殆ど使わないのだけど krymtkts/MavenAutoCompletion がある関係で一応必要)。 Maven がないのは Scripted-Application って label が付いてる *.bat とか *.cmd とかの script として提供されてる application の install を WinGet の security policy で禁じてるからなので...どうしようもない。

でもずっと許可しないとか有り得んよな～と思って調べたら、やっぱ issue に挙がってきてた(それにしては随分最近でびっくりした)。

Support other portable application formats · Issue #5083 · microsoft/winget-cli

というわけで WinGet の今後に期待し、とりあえず新しいのを使いたいから一旦 OpenSSH だけ winget に移行した。

winget install --id Microsoft.OpenSSH.Preview --scope machine --override ADDLOCAL=Client

Chocolatey から WinGet へのスムースな移行とかもできるかわからんので当面は二刀流か。続く。

多分これか → OpenSSH for Windows の 2024 年 10 月の更新について | Microsoft Japan Windows Technology Support Blog ↩

GitHub 通知設定の Tips

Sun, 09 Feb 2025 09:00:00 +0900

わざわざ書き残すようなものでもないかと思ったが、全然知らなかったので残しておく。

GitHub の repo の Watch とか、 Issue や Pull Request の subscription の設定。アレをいちいちいつどこで何の理由で設定したとか覚えてなくて、たまに何ぞ？と思うような通知が来ることがある。

一括管理できないのかなと ChatGPT に聞いたところ、なんと https://github.com/watching と https://github.com/notifications/subscriptions で見れるらしい。初めて知った... これどこから辿れるんやと思って Notifications 画面を見てみたら、左下に確かにあった...

Configuring notifications - GitHub Docs

公式文書にも思いっきり書いてあった...

How can I see all the issues I'm watching on Github? - Stack Overflow

みんな結構知らないんやな。とても便利な機能でありがたい。

手動で Issue とか Pull Request の subscription をしたやつを一覧するには、 Reason を Manual で絞れば良いっぽい。 https://github.com/notifications/subscriptions?reason=manual

watch している repo 一覧は Github CLI でも取れるっぽい。 PowerShellForGitHub にはなさそう？

gh api user/subscriptions --paginate --jq '.[].full_name'
# fsprojects/fantomas
# fscheck/FsCheck
# fsprojects/FSharpLint
# PowerShell/platyPS
# PowerShell/PowerShell-RFC
# ...

最近自分で使ってる F# とか PowerShell の repo の activity が全部飛ぶように watch 設定してるから、今何が watch になってるか一覧できるのはとても助かる。

Issue や Pull Request のうち手動で subscribe したものは CLI でどうすれば一覧できるかわからなかった。 subscribe してる Issue や Pull Request は、大体何らかの bug を踏んだり気になる機能追加を追いたい場合に使ってるので、こっちも一覧したかったが... 一覧したところで何に使うねんというのはあるけどな。対応が終わった Issue や Pull Request から通知が飛ぶことはないから棚卸しして購読を外すなんてこともやらなくていいし。まあでも振り返ってみるときに一覧したいかも...

F# で Cmdlet を書いてる pt.64 - UnixStats がエラーになる

Sun, 02 Feb 2025 09:00:00 +0900

krymtkts/pocof 開発をした。

昨日 0.19.0 をリリースをした。 1 月中にリリースしたかったが、 Linux で予期せぬエラーが発生する修正をしてしまってたので、リリースが遅れた。

ずっと気づいてなかったが、 Linux 端末上で例えば UnixStats¹ のような platform 依存の property にアクセスすると以下のエラーが発生する。以下の例では Size だが User とか Mode とか UnixStats に属するもの全てエラーになる。

PS /mnt/c/Users/takatoshi> $ErrorView = 'DetailedView'
PS /mnt/c/Users/takatoshi> get-ChildItem | pocof -Layout TopDownHalf ':Size 1'
query>:Size 1                                                                                                                                                                                                                                                  match and [0]
Exception             :
    Type            : System.AggregateException
    InnerExceptions :
        Type           : System.Management.Automation.GetValueInvocationException
        ErrorRecord    :
            Exception             :
                Type    : System.Management.Automation.ParentContainsErrorRecordException
                Message : Exception getting "Size": "There is no Runspace available to run scripts in this thread. You can provide one in the DefaultRunspace property of the System.Management.Automation.Runspaces.Runspace type. The script block you attempted to invoke was: $this.UnixStat.Size"
                HResult : -2146233087
            CategoryInfo          : NotSpecified: (:) [], ParentContainsErrorRecordException
            FullyQualifiedErrorId : ScriptgetValueInvalidOperationException
        TargetSite     :
            Name          : InvokeGetter
            DeclaringType : psscriptproperty
            MemberType    : Method
            Module        : System.Management.Automation.dll
        Message        : Exception getting "Size": "There is no Runspace available to run scripts in this thread. You can provide one in the DefaultRunspace property of the System.Management.Automation.Runspaces.Runspace type. The script block you attempted to invoke was: $this.UnixStat.Size"
        InnerException :
            Type        : System.Management.Automation.PSInvalidOperationException
            ErrorRecord :
                Exception             :
                    Type    : System.Management.Automation.ParentContainsErrorRecordException
                    Message : There is no Runspace available to run scripts in this thread. You can provide one in the DefaultRunspace property of the System.Management.Automation.Runspaces.Runspace type. The script block you attempted to invoke was: $this.UnixStat.Size
                    HResult : -2146233087
                CategoryInfo          : InvalidOperation: (:) [], ParentContainsErrorRecordException
                FullyQualifiedErrorId : ScriptBlockDelegateInvokedFromWrongThread
            TargetSite  :
                Name          : GetContextFromTLS
                DeclaringType : scriptblock
                MemberType    : Method
                Module        : System.Management.Automation.dll
            Message     : There is no Runspace available to run scripts in this thread. You can provide one in the DefaultRunspace property of the System.Management.Automation.Runspaces.Runspace type. The script block you attempted to invoke was: $this.UnixStat.Size
            Source      : System.Management.Automation
            HResult     : -2146233079
            StackTrace  :
   at System.Management.Automation.ScriptBlock.GetContextFromTLS()
   at System.Management.Automation.ScriptBlock.InvokeWithPipe(Boolean useLocalScope, ErrorHandlingBehavior errorHandlingBehavior, Object dollarUnder, Object input, Object scriptThis, Pipe outputPipe, InvocationInfo invocationInfo, Boolean propagateAllExceptionsToTop, List`1 variablesToDefine, Dictionary`2 functionsToDefine, Object[] args)
   at System.Management.Automation.PSScriptProperty.InvokeGetter(Object scriptThis)
        Source         : System.Management.Automation
        HResult        : -2146233087
        StackTrace     :
   at System.Management.Automation.PSScriptProperty.InvokeGetter(Object scriptThis)
   at Pocof.Query.x@162.Invoke(Entry entry)
   at lambda_method453(Closure, Entry)
   at System.Linq.Parallel.OrderPreservingPipeliningSpoolingTask`2.SpoolingWork()
   at System.Linq.Parallel.SpoolingTaskBase.Work()
   at System.Linq.Parallel.QueryTask.BaseWork(Object unused)
   at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
...

RunSpace 割あたってると思ってたけどなんか違うらしい。 PSCmdlet.InvokeCommand.InvokeScript を main thread で実行してるだけなので、変なことなさそうなんやが。

実は 0.18.1 以前からのエラーは出てて、単に try ... with ... でエラーを捕捉した場合に property の値が取れなかったとして None を返す仕様にしてたので気づいてないだけだった。このエラー措置は元々 NullReferenceException 用に作ってた気がしたけど、結果的に他のエラーも救ってたことになる。 0.19.0 に含まれる修正で NullReferenceException の恐れがないとみなしこのエラー救護措置を取り除いたところ、ひょっこり現れたという形だ。

ひとまず従来の挙動とリリース優先を優先して try ... with ... でエラーを潰しただけなので、できればちゃんと対応したいところ。

Resolve errors when accessing Unix-dependent properties such as User, Group, UnixMode, Size, etc. · Issue #319 · krymtkts/pocof

あとの修正は、依存関係を更新したり、 benchmark とって改善したりだけだ。改善といっても大きくロジックを書き換えたのはなくて不要な list 変換を避けるとかそういうちまちましたものばかり。この過程で ILSpy で面白いことに気付いたので書き残しておく。

もし速さを追求して IL の命令数まで意識する必要がある場合、 F# っぽい書き方は C# っぽい書き方より overhead があって使いにくいかも知れないという話。

> dotnet --version
9.0.102
> dotnet fsi --version
Microsoft (R) F# Interactive version 12.9.101.0 for F# 9.0

でビルドして、 ILSpy で C# 12 と一部 IL で見た。また pocof の TargetFramework は netstandard2.0 だ。 F# が吐く IL は version up で改善が続いてるし、この見解は今だけの話かもしれないことに留意すること。

こういうコードがあるとして、 toString __ |> String.lower の部分の書き方で生成される IL の違いを見た。

    [<RequireQualifiedAccess>]
    [<NoComparison>]
    [<Struct>]
    type Matcher =
        | Eq
        | Like
        | Match

        override __.ToString() =  toString __ |> String.lower

// toString __ |> String.lower
public override string ToString()
{
    string s = toString(this);
    return LanguageExtension.String.lower(s);
}

// _.Property shorthand
public override string ToString()
{
    string text = toString(this);
    string text2 = text;
    return text2.ToLower();
}

.method public hidebysig virtual
    instance string ToString () cil managed
{
    .param [0]
        .custom instance void System.Runtime.CompilerServices.NullableAttribute::.ctor(uint8) = (
            01 00 00 00 00
        )
    // Method begins at RVA 0x9238
    // Header size: 12
    // Code size: 21 (0x15)
    .maxstack 3
    .locals init (
        [0] string 'Pipe #1 input at line 235',
        [1] string
    )

    IL_0000: ldarg.0
    IL_0001: ldobj Pocof.Data/Matcher
    IL_0006: call string Pocof.Data::toString<valuetype Pocof.Data/Matcher>(!!0)
    IL_000b: stloc.0
    IL_000c: ldloc.0
    IL_000d: stloc.1
    IL_000e: ldloc.1
    IL_000f: callvirt instance string [netstandard]System.String::ToLower()
    IL_0014: ret
} // end of method Matcher::ToString

inline expansion と _.Property shorthand は同じ IL になる。

// inline
public override string ToString()
{
    string text = toString(this);
    string text2 = text;
    return text2.ToLower();
}

C# ライクに書くのが最も命令数が少ない。

// (toString __).ToLower()
public override string ToString()
{
    return toString(this).ToLower();
}

.method public hidebysig virtual
    instance string ToString () cil managed
{
    .param [0]
        .custom instance void System.Runtime.CompilerServices.NullableAttribute::.ctor(uint8) = (
            01 00 00 00 00
        )
    // Method begins at RVA 0x9238
    // Header size: 1
    // Code size: 17 (0x11)
    .maxstack 8

    IL_0000: ldarg.0
    IL_0001: ldobj Pocof.Data/Matcher
    IL_0006: call string Pocof.Data::toString<valuetype Pocof.Data/Matcher>(!!0)
    IL_000b: callvirt instance string [netstandard]System.String::ToLower()
    IL_0010: ret
} // end of method Matcher::ToString

以下の >> と |> の結果から、関数合成は遅いという話は本当なんだ。また、 pipeline 演算するだけで余計にコピーしてるのはちょっとショック。

// >>
public override string ToString()
{
    Matcher matcher = this;
    FSharpFunc<Matcher, string> @_instance;
    @_instance = ToString@235.@_instance;
    FSharpFunc<string, string> @_instance2;
    @_instance2 = ToString@235-1.@_instance;
    Matcher matcher2 = matcher;
    return @_instance2.Invoke(@_instance.Invoke(matcher2));
}

// |>
public override string ToString()
{
    Matcher x = this;
    string text = toString(x);
    string text2 = text;
    return text2.ToLower();
}

.method public hidebysig virtual
    instance string ToString () cil managed
{
    .param [0]
        .custom instance void System.Runtime.CompilerServices.NullableAttribute::.ctor(uint8) = (
            01 00 00 00 00
        )
    // Method begins at RVA 0x9238
    // Header size: 12
    // Code size: 23 (0x17)
    .maxstack 3
    .locals init (
        [0] valuetype Pocof.Data/Matcher 'Pipe #1 input at line 235',
        [1] string 'Pipe #1 stage #1 at line 235',
        [2] string
    )

    IL_0000: ldarg.0
    IL_0001: ldobj Pocof.Data/Matcher
    IL_0006: stloc.0
    IL_0007: ldloc.0
    IL_0008: call string Pocof.Data::toString<valuetype Pocof.Data/Matcher>(!!0)
    IL_000d: stloc.1
    IL_000e: ldloc.1
    IL_000f: stloc.2
    IL_0010: ldloc.2
    IL_0011: callvirt instance string [netstandard]System.String::ToLower()
    IL_0016: ret
} // end of method Matcher::ToString

IL の命令数を極限まで減らしていこうと pocof はしてないのだけど、 _.Property shorthand は気軽に使える高速な方法ってことで良さそう(実際そうした)。逆にこれの結果に従うと C# like に書ける箇所は . で引きずり回す方が効率が良いのでそうしようとなってしまうが、 pipeline の方が好きなので当面は採用しないでおく。極限まで削らないといけないところが出たら局所的に採用するかも知れんけど。

最近プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するかを読んでるのもあって命令数に敏感になってるから気になってるだけって感じではある。もっと全体的に見直す価値ある箇所あるのではよそっちやれ、という自戒。

UnixStat のことはよく知らないが、PowerShell のコードにちらっと現れる。こいつを掘り下げて理解するのが今後の宿題かな ↩

F# で Cmdlet を書いてる pt.63

Sun, 26 Jan 2025 09:00:00 +0900

krymtkts/pocof 開発をした。

修正したい箇所の benchmark がなかったら作って、直して、修正後にまた benchmark を取って最適化の効果が出ているかを実践してみた。 #315

今回は単純に array に対して Seq module を使ってた箇所を Array module を使うようにしてみたのだが、要素数が少なく遅延評価が必要ない箇所ばかりでやはり array のまま扱った方が処理速度が良い。

Seq.filter を Array.filter にする前。

| Method              |      Mean |     Error |    StdDev |    Median |    Gen0 |   Gen1 | Allocated |
| ------------------- | --------: | --------: | --------: | --------: | ------: | -----: | --------: |
| Action_fromString   | 642.77 us | 12.622 us | 27.171 us | 635.54 us | 89.8438 | 1.9531 | 369.12 KB |
| Operator_fromString |  12.78 us |  0.430 us |  1.241 us |  13.18 us |  0.9766 |      - |   4.11 KB |

修正後の方が良い。 Operator_fromString の方は共通化の影響で使わない Array.filter が 1 箇所噛んでるから余計に array を作ってしまったのかメモリ増えたけど。こういうのも今後は削って切り詰めていくのがやっぱ妥当かな。

| Method              |      Mean |     Error |    StdDev |    Gen0 | Allocated |
| ------------------- | --------: | --------: | --------: | ------: | --------: |
| Action_fromString   | 635.84 us | 12.393 us | 15.220 us | 89.8438 | 368.22 KB |
| Operator_fromString |  12.10 us |  0.215 us |  0.328 us |  1.0986 |   4.56 KB |

あとこれは元のコードが拙かっただけだが、不必要に seq を list にしてたところを seq のママ取り扱ったり、 seq に index access してたところを infinite sequence を実装して次の要素を取るだけにしてみたり。

修正前。

| Method                                 |       Mean |    Error |    StdDev |     Median |   Gen0 | Allocated |
| -------------------------------------- | ---------: | -------: | --------: | ---------: | -----: | --------: |
| invokeAction_CompleteProperty_NoSearch |   131.2 ns |  2.64 ns |   2.82 ns |   130.8 ns | 0.0286 |     120 B |
| invokeAction_CompleteProperty_Search   | 1,173.7 ns | 51.83 ns | 152.82 ns | 1,099.7 ns | 0.3319 |    1392 B |
| invokeAction_CompleteProperty_Rotate   |   535.5 ns | 10.69 ns |  15.68 ns |   534.7 ns | 0.1869 |     784 B |

List.ofSeq 取り除きで高速化＆メモリ減。 (invokeAction_CompleteProperty_NoSearch は影響受けないはずだが何でかメモリ消費が減ってる)

| Method                                 |     Mean |    Error |   StdDev |   Median |   Gen0 | Allocated |
| -------------------------------------- | -------: | -------: | -------: | -------: | -----: | --------: |
| invokeAction_CompleteProperty_NoSearch | 131.5 ns |  2.53 ns |  3.63 ns | 130.2 ns | 0.0229 |      96 B |
| invokeAction_CompleteProperty_Search   | 714.5 ns | 28.08 ns | 82.79 ns | 684.4 ns | 0.2041 |     856 B |
| invokeAction_CompleteProperty_Rotate   | 476.3 ns |  9.31 ns | 13.05 ns | 470.9 ns | 0.1564 |     656 B |

infinite sequence にした版。 infinite sequence の実装自体は再帰的な seq 。

    module Seq =
        let rec cycle source =
            seq {
                yield! source
                yield! cycle source
            }

PropertySearch.Rotate という DU が元々 Rotate of keyword: string * candidates: string seq だったのが Rotate of keyword: string * candidates: string seq になって tuple が 4 byte 縮んでると思うのだけどそれよりも infinite sequence によるオーバヘッドの方がメモリに乗ってるのか？処理速度もメモリもパフォは良くないけど、次の index を算出するあたりが煩雑だったしわかりやすさとのトレードオフということで。再帰的な seq を作る際に Seq.cache で計算済みにしたら速くなるかなと思ったけどむしろ遅くメモリ使用量も多くなったのでやめた。

| Method                                 |     Mean |    Error |   StdDev |   Median |   Gen0 | Allocated |
| -------------------------------------- | -------: | -------: | -------: | -------: | -----: | --------: |
| invokeAction_CompleteProperty_NoSearch | 124.0 ns |  2.57 ns |  3.77 ns | 123.1 ns | 0.0210 |      88 B |
| invokeAction_CompleteProperty_Search   | 717.5 ns | 26.57 ns | 77.50 ns | 749.7 ns | 0.2232 |     936 B |
| invokeAction_CompleteProperty_Rotate   | 534.7 ns | 10.66 ns | 17.21 ns | 529.6 ns | 0.2060 |     864 B |

こうやって、速くなっているのかメモリ消費が減っているのか、特に速度に関しては実行事のブレが大きいのもあれど、定量的に測れるというのは良い。この手でダメなら次の手で、の試行錯誤をするのに明確な理由付けができる。今は開発時に local で走らせてるだけだが、理想は CI で benchmark testing して時間・空間計算量が悪化してたら job をこけさせれたら良いけど、 GitHub Actions だと中々ブレが大きいようなので当面は様子見か。

良いな～と思っているけど良くないところも当然ある。いちいち benchmark を取るから開発に時間がかかる。今はまだ慣れてないから枝葉の部分でうまく使えるか練習してるような状態だが、ほんとはもっと中核の部分だけ開発時に benchmark を組み込むとかにした方が作業効率はいいんやろな。

今月ちまちまいじった分をそろそろリリースするか。

おまけで、 benchmark の改善とは関係ないけど Seq.last を Array.last に変えた箇所の coverage が悪化することがあった。理由は Array.last が inline 展開されると要素数 0 の場合にエラーを発生させる分岐が埋め込まれるから(Seq.last は inline じゃない)。要素数が 1 以上であることを保証できるケースであれば単純に array[array.Length - 1] して不要な分岐の発生を回避するしかない感じ。

F# で Cmdlet を書いてる pt.62 - BenchmarkDotnet と ObjectLayoutInspector

Sun, 19 Jan 2025 09:00:00 +0900

krymtkts/pocof 開発をした。

BenchmarkDotnet や ObjectLayoutInspector で pocof の benchmark や memory layout を可視化できるようになったので、局所的ではあるが定量化された改善をはじめた。何故局所的かというと、結局一部の module で改善されたとて全体的に見れば負荷を他所に避けているだけのこともあり、そういう意味で局所的だからだ。

ひとまず着手したのは内部状態を管理する型 InternalState のダイエットだ。 #305 元々可変状態のみを保存していくつもりの型だったが、幾度の機能開発を経て起動後変わらんだろうという field まで含まれるようになっていた。理想的には更新頻度も高めで取り回されることも多いし GC を避ける目的で struct にしたいのだが、サイズが大きくなり struct にしようものなら爆発的にコピーコストが嵩むという状態だった。本当に struct にするかは benchmark との相談だが、やるやらない関係なくとも fat なので、ひとまず減量する必要があるなと考えた。

まず InternalState でプログラム実行中に変わらない fields を整理して半分ほど取り除いたりしてみた。結果 memory layout は以下のようになった。削られた fields はカリー化された関数の引数だったりの起動時以降変更されない値に移行した。

減量前 (15b6fe4)

Type layout for 'InternalState'
Size: 88 bytes. Paddings: 7 bytes (%7 of empty space)
|=====================================================|
| Object Header (8 bytes)                             |
|-----------------------------------------------------|
| Method Table Ptr (8 bytes)                          |
|=====================================================|
|   0-7: QueryState QueryState@ (8 bytes)             |
|-----------------------------------------------------|
|  8-15: QueryCondition QueryCondition@ (8 bytes)     |
|-----------------------------------------------------|
| 16-23: PropertySearch PropertySearch@ (8 bytes)     |
|-----------------------------------------------------|
| 24-31: FSharpOption`1 Notification@ (8 bytes)       |
|-----------------------------------------------------|
| 32-39: IReadOnlyCollection`1 Properties@ (8 bytes)  |
|-----------------------------------------------------|
| 40-47: IReadOnlyDictionary`2 PropertyMap@ (8 bytes) |
|-----------------------------------------------------|
| 48-55: String Prompt@ (8 bytes)                     |
|-----------------------------------------------------|
| 56-63: String WordDelimiters@ (8 bytes)             |
|-----------------------------------------------------|
| 64-71: Refresh Refresh@ (8 bytes)                   |
|-----------------------------------------------------|
| 72-75: Int32 PromptLength@ (4 bytes)                |
|-----------------------------------------------------|
| 76-79: Int32 ConsoleWidth@ (4 bytes)                |
|-----------------------------------------------------|
|    80: Boolean SuppressProperties@ (1 byte)         |
|-----------------------------------------------------|
| 81-87: padding (7 bytes)                            |
|=====================================================|

減量後 (9ab37b0)

Type layout for 'InternalState'
Size: 40 bytes. Paddings: 7 bytes (%17 of empty space)
|=================================================|
| Object Header (8 bytes)                         |
|-------------------------------------------------|
| Method Table Ptr (8 bytes)                      |
|=================================================|
|   0-7: QueryState QueryState@ (8 bytes)         |
|-------------------------------------------------|
|  8-15: QueryCondition QueryCondition@ (8 bytes) |
|-------------------------------------------------|
| 16-23: PropertySearch PropertySearch@ (8 bytes) |
|-------------------------------------------------|
| 24-31: Refresh Refresh@ (8 bytes)               |
|-------------------------------------------------|
|    32: Boolean SuppressProperties@ (1 byte)     |
|-------------------------------------------------|
| 33-39: padding (7 bytes)                        |
|=================================================|

これにより、キー入力で内部状態を書き換える処理の benchmark は良い方向に差分が出た。そこそこ速くメモリも軽くなった。多分取り除いた fields より、それらを更新する関数が取り除かれたことによる影響が大きそう。

減量前 (15b6fe4)

| Method                          | Mean       | Error    | StdDev   | Gen0   | Allocated |
|-------------------------------- |-----------:|---------:|---------:|-------:|----------:|
| invokeAction_Noop               |   131.6 ns |  2.39 ns |  2.35 ns | 0.0401 |     168 B |
| invokeAction_AddQuery           | 1,690.6 ns | 32.05 ns | 63.26 ns | 0.8106 |    3392 B |
| invokeAction_BackwardChar       |   530.5 ns | 10.64 ns | 19.98 ns | 0.1030 |     432 B |
| invokeAction_DeleteBackwardChar |   220.1 ns |  4.31 ns |  3.36 ns | 0.0401 |     168 B |
| invokeAction_SelectBackwardChar |   444.8 ns |  8.78 ns | 13.41 ns | 0.1183 |     496 B |
| invokeAction_RotateMatcher      |   202.4 ns |  4.44 ns | 11.86 ns | 0.1070 |     448 B |
| invokeAction_CompleteProperty   |   249.8 ns | 21.63 ns | 63.77 ns | 0.0496 |     208 B |

減量後 (9ab37b0)

| Method                          | Mean     | Error    | StdDev   | Gen0   | Allocated |
|-------------------------------- |---------:|---------:|---------:|-------:|----------:|
| invokeAction_Noop               | 113.9 ns |  2.29 ns |  3.90 ns | 0.0210 |      88 B |
| invokeAction_AddQuery           | 964.6 ns | 19.28 ns | 20.63 ns | 0.4406 |    1848 B |
| invokeAction_BackwardChar       | 285.4 ns |  5.79 ns | 10.58 ns | 0.0591 |     248 B |
| invokeAction_DeleteBackwardChar | 125.3 ns |  2.58 ns |  3.70 ns | 0.0210 |      88 B |
| invokeAction_SelectBackwardChar | 308.2 ns |  6.22 ns | 11.06 ns | 0.0744 |     312 B |
| invokeAction_RotateMatcher      | 131.5 ns |  2.67 ns |  2.74 ns | 0.0381 |     160 B |
| invokeAction_CompleteProperty   | 125.3 ns |  2.57 ns |  3.43 ns | 0.0286 |     120 B |

が、これは局所最適なだけで、全体的に見れば他所に寄せられた負荷(特に正規表現パターンのエラー表示)があるので、全体で見てどこまで効果があるかはちょっと微妙。そんで全体的な benchmark を取る術がないのが現状。 pocof は event loop を末尾再帰で実装してて、そこで InternalState の受け渡しが延々と発生してるので、そのへんの benchmark も見ておきたいのだけどまだ作れてない。

とりあえず InternalState の減量の第 1 ステップは完了、次のステップを進めるのに先述の通り今の benchmark では心許ないなと感じている。たまにメチャクチャ簡単に部分的な高速化が全体に好影響をもたらすケースもあるが、他に影響ないのを確認するにはやはり全体を見るものがないと確証を得にくい。必要は感じているが全体を見る benchmark 作るのちょっとしんどいな...と思ってしまいまだ着手できておらず、結果的に局所的な改善な改善からちまちまやってしまっているのは essential ではないなーと感じる。はよ autopilot のアイデアを実現しろという自身からの圧。

F# で Cmdlet を書いてる pt.61 - ObjectLayoutInspector

Sun, 12 Jan 2025 09:00:00 +0900

krymtkts/pocof 開発をした。

BenchmarkDotnet に続き ObjectLayoutInspector で pocof の record とか DU の memory layout を可視化し始めた。#300 benchmark とるのや memory layout の考え方は以下の blog が詳しく、参考にさせてもらっている。

Writing high performance F# code

半年ほど前にもこの blog を見てたのだけど、 .NET 力と F# 力が低かったから手を付けれずにいた。今もレベル低いが前よりは高まったので、ようやく手を動かす気になったので試しているところだ。 pocof に取り込むに当たり練習しておくための repo krymtkts/fsharp-bench も作った。以下は pocof の型を分析した例で、 record と DU の memory layout を印刷できて便利。

Type layout for 'Refresh'
Size: 8 bytes. Paddings: 4 bytes (%50 of empty space)
|=============================|
| Object Header (8 bytes)     |
|-----------------------------|
| Method Table Ptr (8 bytes)  |
|=============================|
|   0-3: Int32 _tag (4 bytes) |
|-----------------------------|
|   4-7: padding (4 bytes)    |
|=============================|

この Refresh DU は独自の field を持たず、 tag (DU のケース分け)しかないのでこういうのは構造体とすることで、Object header と vtable(method table) pointer を削減できる分パフォ改善できるケースが多い。 tag だけなら int32 _tag の 4 bytes しか使わないから、参照ポインタの 8 bytes の半分になる。コピーコスト以外にも利用する側でも padding が発生しなければ効率が良くなる。

ただ DU を構造体として扱うときの難しいところは、各 tag の filed 全ての memory を確保するところ。

Type layout for 'Key'
Size: 32 bytes. Paddings: 10 bytes (%31 of empty space)
|====================================|
|   0-3: ConsoleKey _key (4 bytes)   |
| |================================| |
| |   0-3: Int32 value__ (4 bytes) | |
| |================================| |
|------------------------------------|
|   4-7: Int32 _tag (4 bytes)        |
|------------------------------------|
|   8-9: Char _c (2 bytes)           |
|------------------------------------|
| 10-15: padding (6 bytes)           |
|------------------------------------|
| 16-31: Action _action (16 bytes)   |
| |================================| |
| |   0-7: String _query (8 bytes) | |
| |--------------------------------| |
| |  8-11: Int32 _tag (4 bytes)    | |
| |--------------------------------| |
| | 12-15: padding (4 bytes)       | |
| |================================| |
|====================================|

この Key DU は StructAttribute 付与してて、内包する Action も構造体なので、以下のように大きめになる。 Key DU に限れば、内包する Action DU を使ってる箇所で String query を使うケースは除外されてるので、別の Struct DU を作って置き換えるべきだろう。前に軽率に Struct を付与したのが裏目に出てる。

Type layout for 'InternalState'
Size: 88 bytes. Paddings: 7 bytes (%7 of empty space)
|=====================================================|
| Object Header (8 bytes)                             |
|-----------------------------------------------------|
| Method Table Ptr (8 bytes)                          |
|=====================================================|
|   0-7: QueryState QueryState@ (8 bytes)             |
|-----------------------------------------------------|
|  8-15: QueryCondition QueryCondition@ (8 bytes)     |
|-----------------------------------------------------|
| 16-23: PropertySearch PropertySearch@ (8 bytes)     |
|-----------------------------------------------------|
| 24-31: FSharpOption`1 Notification@ (8 bytes)       |
|-----------------------------------------------------|
| 32-39: IReadOnlyCollection`1 Properties@ (8 bytes)  |
|-----------------------------------------------------|
| 40-47: IReadOnlyDictionary`2 PropertyMap@ (8 bytes) |
|-----------------------------------------------------|
| 48-55: String Prompt@ (8 bytes)                     |
|-----------------------------------------------------|
| 56-63: String WordDelimiters@ (8 bytes)             |
|-----------------------------------------------------|
| 64-71: Refresh Refresh@ (8 bytes)                   |
|-----------------------------------------------------|
| 72-75: Int32 PromptLength@ (4 bytes)                |
|-----------------------------------------------------|
| 76-79: Int32 ConsoleWidth@ (4 bytes)                |
|-----------------------------------------------------|
|    80: Boolean SuppressProperties@ (1 byte)         |
|-----------------------------------------------------|
| 81-87: padding (7 bytes)                            |
|=====================================================|

こちらはデカすぎる InternalState record。こういうのは構造体にするとコピーコストかさむため重くなる。先に挙げたような単純な DU を構造体にすれば参照ポインタよりサイズを小さくできるのでメモリを節約できるか。他にも最近の改善で Prompt は切り分けられるようになったし、改善できるかな。 benchmark 調べた感じだとデカい record 一発で取り回すより細かい record に分けて取り回した方が速いから、分けるべきなのかも。

ちなみに、 ObjectLayoutInspector の fsproj は実行形式(OutputType Exe) にしておかないと標準出力できないので、 TargetFramework は net9 にしている。 pocof は PowerShell の各 version との互換性のために netstandard2.0 を対象にしてて、 ProjectReference で pocof.fsproj を参照してるから、 pocof 側の record や DU は netstandard2.0 準拠で compile され、実際に利用されるときと同じ memory layout が出力される(はず)。

一通り record や DU の memory layout は見れるようにしたのだけど、 benchmark は簡単なのだけがある状態なので、 pocof のパフォで気になる部分の benchmark を作って計測してみないことには最適化に着手できない。これ、どういう風に実際と同じような benchmark を作るか考えるのも中々難しいよな。 pocof は module 毎に公開されてる関数が概ねその module の entrypoint になってて、そこは benchmark を作りやすい。けど組み合わせたパターンになると、 PowerShell の E2E testing 改善の文脈と同じような autopilot mode みたいなの作り込むってところにつながってく気がするな。いま unit test でやってる ICommandRuntime のテスト用実装で PSHostUserInterface テスト用派生クラスをもう少し作れたらかのうせいがあるのかも(今は空っぽ)。キー入力と仮想スクリーンをうまく作れるか次第よな～。

まあ何にせよ benchmark が取れて memory layout を可視化できるようになって、準備は揃っている。このあたりの知識は .NET の内部的な話で、先に挙げた blog のような解析をしてる人の記事以外は文書が見当たらないし、先人の通った道を自分も通ることでしか習熟しないと思うねんよな。何より ChatGPT や Copilot ｻﾝも全然詳しくなくて当てにならないところ。尚更自分でやるしかない。

続く。

F# で Cmdlet を書いてる pt.60 - xUnit v3 と FsUnit と FsCheck

Sun, 05 Jan 2025 09:00:00 +0900

年末年始は結局 krymtkts/pocof 開発をした。 command-line predictor の開発は始めず。

0.18.1 のリリースで小綺麗にできるようになったのもあって、基本コード最適化みたいなやつをやった。 #285 #293 #295 #296 #297 #298 ずっとやらずに置かれていたページめくり #16 や行選択 #17 などで行を選択するやつを not planned で閉じたりもした。 PowerShell の Format.ps1xml で変わる見た目を今のところ尊重してるから使えんなという判断でだ。

他に新たな試みとしては、成果物のサイズを減らしてみたり #284 、 BenchmarkDotnet でベンチマーク測定できるようにしたり #294 。

ベンチマークはまだ GitHub Actions workflow に組み込んでない。どうも実行のたびにスペックが固定されてないらしくて、安定したベンチマーク測定に向かないらしいという情報をいくつか見かけた。ただ相対値を測るくらいなら問題ないので、ベンチマークテストも追加できたら良さそう。これは今後に託す。

あと取り組んだけどうまくいかなかったものもある。 FsUnit と FsCheck が依存する xUnit の major update だ。

FsUnit が 7.0.0 で xUnit 3 系に対応したので試したら、 .nupkg に dll と exe が含まれてて依存関係が解決できずそのままでは使えなかった。報告して workaround を教えてもらったり対応してもらった fsprojects/FsUnit#298 ので、いざ pocof でそれを使いだしたら PBT が動かなくなってしまった。すっかり忘れてたのだけど、 FsUnit だけじゃなく FsCheck も xUnit 依存してたのだった。

xUnit は v3 から NuGet package name が xunit から xunit.v3 に変わるという変更だけでも大きいのだけど、 xUnit の extension に提供されてる interface が大幅に変更されてた。 Migrating from v2 to v3 [Unit test authors] > xUnit.net 以降に詳しく書かれてる。 FsUnit の方はほぼコードが xUnit に依存してなくて package 変更くらいしか影響なかったけど、 FsCheck の方は interface 変更のあおりを受けてかなり変更しないといけない fscheck/FsCheck#690感じ。 (他の人もそう考えてたみたいだが)わたしもサクッと変更できるならコントリした方が速いなと考えて試しにやってみたが、この interface 変更やらがやたらメンドくていったん諦めた(ｵｲ)。多分先述の xUnit の文書をガッツリ読み込めて、 xUnit の extension に詳しい人なら難しくないのだろうけど、ちょっと xUnit 素人がパパっと終えれるものではなかった。

FsCheck はいま v3 の release candidate の段階だし、ここでこのクソデカ変更を入れるのか？みたいなのも判断難しいと思う。 xUnit は v2, v3 別々にメンテしていくつもりで NuGet package name 分けちゃってるしな。どえらいこっちゃなという印象を受けたが、こういうの一般的なんだろうか。 FsUnit が採用した v2 との後方互換性を落として v3 一択にする方針が、コミュニティベースで開発する OSS には向いてると思うけど、 FsCheck がどうするかはまだ動きが見えてない。メンテナの人が昔別の OSS で xUnit v1 → xUnit v2 の経験があるらしくて、そのときは NuGet package name を分ける対応をしたらしい。 xUnit 流のやり方に寄せるのかなー。複数パッケージをひとつの repo から提供した経験ないから興味深く観察する。

年末年始で xUnit v3 に上げれなかったのはちょっと惜しかったなと思うものの、その過程で package に含まれる任意のファイルを消し去る技を知れたり、 xUnit のように package name を変えて複数バージョンサポートするスタイルがあるのを知れたのはいい経験になった。

2025

Wed, 01 Jan 2025 09:00:00 +0900

例年通り目標をたてる。

テーマ: 不惑

2023 年から続くテーマ、不惑。

2025 年の目標

継続目標だが、強度を上げれるものは上げていく。

積読消化 1 冊/月を超える
- 読書習慣構築後は 2 ヵ月で 1 冊いけたので、次は月 1 冊
F# の開発
- pocof と blog-fable をやりつつ、 Command-line predictor plugin 作ってみる
GitHub のストリークを継続する
- 今年前半で 1,000 達するので気を抜かず取り組んでく
毎週ブログを書く
ギター練習を 4 / week
深酒で怪我をしない
- 血中アルコール濃度にも気をつけたいな。測りようないかもだが
自分メンテナンス
- 読書の習慣化の次は、筋トレ習慣化。いま日記とかアプリに記録してるけどそれだと効力低めなので、もっとシステマティックな習慣化できないかな

2024 年後半は、仕事で所々迷いが生じたこともあったので、もう少し意思を堅固にしたいな。先々のことまで考えすぎて決断の数が多いのをエッセンシャルなところに絞るべきなんやろうか。とはいえ先のことを考える者が他にいなかったら誰かがやらないといけないから、そのジレンマとどう付き合うかよな。

振り返り 2024 年

Tue, 31 Dec 2024 09:00:00 +0900

2024 年を振り返る。

2024 年のテーマは 2 年連続の「不惑」だった。

2024 年の目標と成果

いい線いってるというのが率直な自己評価だ。

⭕️ 積読消化 0.5 冊/月を超える
- そういう機能を blog に作ったので習慣化に成功したし、定量的にも年間目標達成。ちょっと読み込み浅いかもなという懸念が浮かんできてるけど、まず息をするように数をこなせるようになるのに注力したい。現状は習慣化してるといってもなんだかんだ追われてる感が払拭できてない気がする
  - 読了
  - 途中
⭕️ F# の開発
- krymtkts/pocof
  - 2023 末に 0.7.0 だったのが 0.18.1 まできた
  - git log --since="2024-01-01" --until="2024-12-31" --date=short --pretty=format:"%ad %an %s" | ? {($_ -notmatch 'Merge pull') -and ($_ -notmatch 'dependabot\[bot\]')} | Set-Clipboard を GitHub Copilot(o1 preview) に食わせて出させた概要は以下の通り。微妙に説明足りてないけどそれは多分 commit message がしょぼいせい。 2024 年にできるようになったことって結構あるねんなというのが率直な感想
    - prompt
      - このコミット履歴から、機能開発の概要やバージョンアップの履歴を時系列で日本語の文章にまとめて。 2024-01-01 時点では 0.7.0 でした。
    - 回答
      - これらのコミットでは、2024-01-01 時点で 0.7.0 だったバージョンが、主に新機能の追加やバグ修正、リファクタリング、ドキュメント更新に合わせて段階的に引き上げられています。たとえば、2024-01-13 に 0.8.0、1 月末に 0.9.0、2 月末に 0.10.0、4 月初旬に 0.11.0、5 月に 0.12.x と 0.13.0、7 月に 0.14.x、9 月に 0.15.0、10 月に 0.16.x、11 月に 0.17.0、12 月下旬に 0.18.x とリリースを重ねています。コミット内容は、クエリウィンドウや非同期レンダリング、半分の高さウィンドウ、独自のワード区切り設定など機能拡張に加え、テストやドキュメントの整備が継続的に行われ、最終的には 0.18.1 までバージョンが進みました。
  - F# 的な初体験としてはコードクォートや遅延評価を実際に使ったくらい？ Cmdlet に非同期レンダリングを持ち込むのも個人的には挑戦的だったかもな。
- krymtkts/blog-fable
  - あんまやるつもり無かったが booklog 機能は作ってよかった。お陰？で定期的にちょいちょい弄りたい部分も出てきた
- 新しい取り組みは Command-line predictor を作るための調査を krymtkts/SamplePredictor でしたくらい、もうちょいやれたと思う。後は着手するだけなんやけどな～ 2025 入ってから alpha でもいいから作れないかな
⭕️ GitHub のストリークを継続する
- きょう含め 863 。もうまず途絶えることないやろなという自信は持てた。だけど今まで見かけた中の最強が 2,500(6.8 年！) 超えてる人なのでまだまだ先は長い。なんで続けてるか忘れるくらいに没頭してからが本番かな
⭕️ 毎週ブログを書く
- 良く書けてる
⭕️ ギター練習を 4 / week
- ちまちま 1 日 30 分くらいで。ただ相変わらず下手くそなので昔コピッた曲を練習し直したり。ライブもスタジオ練習もやってないから何曲も弾ける体力がなくなってきててすぐ息があがる
- Tremolo unit 変えたいな～と思い出して 1 年経った。 Tremoline の 7 string あったら絶対買いそうやけどんないねんよな
❌️ 深酒で怪我をしない
- 今年は花見で派手な擦り傷したり血中アルコール濃度高めすぎて長期記憶曖昧だったりよろしくなかった
🔺 自分メンテナンス
- 体重あんま変わらん。こなせる負荷は増えてるし筋力アップはしる。でも今年後半忙しい時は気持ちがアゲられず何も出来ない日もあったので、もっとシステマティックな習慣化を目指す
- 何も運動しないのに加齢のせいだと思うが膝が朝バキッ！っていってから毎日パキポキいって、痛むときもある。サポートのためスクワットとカーフレイズ足した。脚太くなっていい感じなんやが、未だ動いてる時はなんともないけど停止状態から動いたときとかポキパキなんよな。病院いかなあかんかな...

酒とか膝とか、加齢による劣化が見られるのでなんか改善したいが何したらいいんだか。

仕事に於いては、 2024 年は担う仕事のうち中長期(N ヶ月～最長起票から終わるまで 1 年 8 ヶ月)なものに取り組む中で所々判断に迷いが生じたこともあった。当然生じても遂行したが。後半にかけてこれってもしかしてミドルエイジクライシスか！(wktk)と思ったけど、キャリアや子育てが一段落したわけでもないから多分違うな。

単身で取り組むのが移行とか刷新とか構築とかのテックリ的案件で、自ら調整やら調査を経て決断することが多く、立て続けにそれらに取り組む中で疲労が溜まったからかなという見立て。こういう決断って誰かに決めてもらえたら楽だが、現状だと誰かに期待できるものでもないし、迷ったり悩んだりしててもマジで意味なかったなと思った。やるべきなのは、ただ自律駆動で目標を撃破すること。もちろん無印がそれに取り組んでるのも良くないので、そこは実態に沿うよう是正しよう(会社がどえらい儲かってたらなんぼでも請求したらいいけどそうじゃないのもこれまた気を遣わさせられる。我ながら優しい従業員)。

私生活に於いては、今年は子どもが習い事始めたりで結構生活に時間の制限が増えて変化あったかも。でもそれよりは 1 日 1 回の読書習慣付けとか自身に課した制約で時間に追われてる感じあったかも。使う筋肉を最小限にした省力化に注力したらいいんかな。過去の自分よりは絶対に充実してるけどまだまだ渇望してるので、もっと積んでいきたいところやねんよな～。

まとめ

新しい習慣も増えて良くできたなという気持ちはあれど、まだこなれてない感じはする。もうちょい慣れて先述の通り呼吸をするようにサクサクこなせるようになりたい。そうした後に更に目標の負荷も高めていきたいところ。

F# で Cmdlet を書いてる pt.59

Sun, 29 Dec 2024 09:00:00 +0900

krymtkts/pocof 開発をした。

年内になんとか 0.18.0 、その bug 修正版の 0.18.1 をリリースをできた。前回触れた以下の bug の対処が間に合って良かった。 #276

今のところただの query であれば問題ないのだけど、 property query だと指定した property が認識されてなくて絞り込めない bug がある。

対象の絞り込みと描画が非同期に行われるため、 -Query option を指定した pocof 起動直後の絞り込み時に選択可能な property の list が完成していないと property query が無効になる bug だった。なので絞り込みのタイミングをずらすために、 query の絞り込みと property name の候補の結果を遅延評価するようにした。 F# なら Lazy Expressions で簡単に導入できる。一点 Entry seq の引数に Entry pseq を取り回せていたところが、遅延評価にしたことで Entry pseq Lazy と明示的な型の指定が必要になったのでそこだけ想定外だったか(理解不足かもしれんが元の制約が緩かっただけかな)。

結果を得るタイミングを遅らせただけなので、実質的に根治策というよりある種の緩和策なところだけが懸念点か。仕組み的に、ものすごく膨大な検索対象に複数の object が含まれていた場合、登場するのが遅い object の property はこれまで同様に起動直後の property query として無効になるだろう。とはいえそんな膨大な検索対象の場合は ProcessRecord 中の定期描画で救われるだろうから、大きく問題になることはない多分(心配なので今度試す)。

遅延評価に切り替える過程で、 UI のリファクタも行った。これは従来のレイアウトである {prompt}>{query} {matcher} {operator} [{filter count}] だと遅延評価を組み込むのに支障があったためだ。 query window の幅を算出するのに {query} 前後の {prompt} と {matcher} {operator} [{filter count}] の文字数を知る必要があったが、絞り込み件数を正格評価しないと {filter count} の文字数を正しく算出できない。遅延評価されても query window の幅算出に影響ないレイアウトであればよいので、解決策として 1 行ずらして notification 等を表示する行に {matcher} {operator} {filter count} をずらした。 {filter count} が膨大な検索対象がある場合のパフォ劣化の原因でもあるので消してもいいけど、個人的に良く見てる項目なので置いておきたかったというのもある。

これが、

>:Name a                        match and [7]
note>xxxxxx

こうなった。

>:Name a
note>xxxxxx                     match and [7]

多少見た目悪い気もするがこれによって query window 幅の動的な計算が不要になり、今後の内部状態の設計もスッキリしそうなので、良いタイミングでの決定だったかなと。ただ残念ながらこの 0.18.0 のリリースで terminal 端っこにカーソルが位置したときに UI が崩壊する bug を仕込んしまったので、急遽直した。それが 0.18.1 になった。 #281

うわ～あったなこの挙動と bug の原因に気づいてから思い出したのだけど、 PSReadLine なのか Console なのか何に由来する挙動か知らないが、行末端までカーソルが進むと改行して次の行に移るやつがあって、その影響っぽかった(忘れる前にこの現象についても調べておかな)。行末にカーソル位置がなければ問題ではないので、現状 query window の幅を 1 文字縮めることで回避している。自動で次の行に進んでしまうので、進んでから戻すよりも、進ませないのが手数を少なくするのを優先した対応としては正しいはず...多分。

もうちょい事前にテスト出来てたら 100% 気づけた bug だが、現状手動テストしか出来ないところではあるし、中々難しおまんな。ただ debug build でのみ有効な autopilot mode みたいなの作り込めたら E2E testing 改善の可能性あるか。そうすれば理論的に PBT における stateful properties か state machine properties が書けるハズや。 FsCheck で Model-based Testing がそれに該当するはずやから試す価値はあるよな(まだ初歩的な generator しか使ってないし)。

来年も pocof の開発することありそうな感じやな～。やりたいことがいっぱいあるというのはいいことや。

F# で Cmdlet を書いてる pt.58

Sun, 22 Dec 2024 09:00:00 +0900

krymtkts/pocof 開発をした。

年末に次のリリースする。そのための修正をいくつかした。リリースするするフラグが折れないようにするためにも後何を解消しないといけないか書いておく。

1 つデカい破壊的な変更を入れた。それは Select-Pocof の parameter の position=0 を変えたことだ。修正は軽微だがこれはデカい。 #268

この変更により従来は $datasource | pocof -Query nanigashi としなければならなかったところを、 parameter name を省略して $datasource | pocof nanigashi とできるようにした。もし pocof ユーザの方がいて pocof の position=0 だった InputObject にフィルタリング対象のデータを渡している人がいたらすみません、以後 pipeline で渡してください。破壊的変更なのでテストに影響あるかなーと思ったが影響なかったので問題ない認識。

この変更は、絞りたいキーワードが分かりきっててパパッと確認したいときなんかはやはり type 数が少ない方が良いよなという判断だ。今のところただの query であれば問題ないのだけど、 property query だと指定した property が認識されてなくて絞り込めない bug がある。

# NG
# 多分 property の Map 構築が間に合ってないか構築後の再描画に問題がある
ll | pocof ':Name .github'

# 単純な query はOK
ll | pocof '.github'
# -NonInteractive は OK
ll | pocof '.github' -NonInteractive
ll | pocof ':Name .github' -NonInteractive

非同期で処理してるためなので、過去にも似たような bug を直したがまだ直さないといけない箇所があるんやろなというお気持ち。早く直してリリースしたい。調査が億劫なので、他の repo の開発をしてたりして着手してない。

また別の話ではあるが、喜ばしことに人生で初めて自分の repo にプルリクをいただいた。 #290 嬉しい限りである。ｳｪｰｲって投げつける側は割と誰でもなれると思うが、もらう側になったのは初めてだったので良い経験になった。

GitHub の README 仕様の知らないところを教えていただいたところもあってこれまたありがたい。みんな README.md から repo 内の別の文書へのリンクは相対パスで書くんやなと知った。

また external contributor から PR もらったときの GitHub Actions の挙動のチェック甘かったところもあぶり出され、ほんとありがたい限り。エラーを起こしてしまった申し訳ない感じではあるが。この機会に Codecov は token なしでも coverage を upload できる機能があるのを知った。そして Snyk は token なしだと単にエラーになる。

Uploading without a token - Codecov Tokens
snyk/actions: A set of GitHub actions for checking your projects for vulnerabilities
- Note that GitHub Actions will not pass on secrets set in the repository to forks being used in pull requests, and so the Snyk actions that require the token will fail to run.

今年も残すところわずかなので、件の課題に年末中に着手し、解決したい、というかしなければならない。来週には今年の振り返りをしたいし。

続く。

F# で Cmdlet を書いてる pt.57 - PlatyPS v1 preview の bug

Sun, 15 Dec 2024 09:00:00 +0900

krymtkts/pocof 開発をした。

PlatyPS についていくつか覚え書きしておくのと、 .NET 9 及び F# 9 対応に進展がありひとまず PR を merge できた。

PlatyPS の v1 の preview の挙動に関してメモしておく。

あと地味に Markdown の table が MAML 翻訳されない bug も直ってるようなので、コレを気に pocof の help も多少綺麗にできるかな。 Markdown tables not rendered properly in MAML · Issue #577 · PowerShell/platyPS

前回触れたこれ、直ってるっぽいけどその確認の過程で変なエラーに遭遇した。再現条件がイマイチ分からなかったが、Export-MamlCommandHelp で必ず壊れた MAML が出力されるようだった。壊れた MAML を Show-HelpPreview するとわかりやすくエラーになる。

> Show-HelpPreview -Path .\src\pocof\pocof-Help.xml
InvalidArgument: Cannot convert value "<?xml version="1.0" encoding="utf-8"?> <helpItems xmlns:maml="http://schemas.microsoft.com/maml
... </helpItems>" to type "System.Xml.XmlDocument". Error: "The specified node cannot be inserted as the valid child of this node, because the specified node is the wrong type."

pocof でこのエラーが発生した場面は、元々 Markdown の table が使えなかったので code block (```md ~ ```)で囲んでいた箇所を通常の Markdown に戻したあとだった。 pocof の Markdown command help は scheme 更新した関係で Locale: en-US や title: ... が生えてなかったのだけど、これらの不足した属性がエラーとは関係ないのは確認した(あってもなくてもエラーになる)。このとき MAML 最後尾の tag が重複して出力されていた。以下のような感じ。

   </command:command>
 </helpItems>
+  </command:command>
+</helpItems>

MAML command help を出力するコマンドは以下の通り。

Measure-PlatyPSMarkdown -Path ./docs/pocof/*.md | Where-Object Filetype -match CommandHelp | Import-MarkdownCommandHelp -Path {$_.FilePath} | Export-MamlCommandHelp -OutputFolder .\src\ -Force

1 つわかったのは、エラーを回避するには出力済みの MAML command help を物理的に削除して、再度出力し直す必要があったことだ。つまり -Force option 付きでの上書きの問題があるっぽい？何にせよ workaround があってよかった。どうにもよくわからんが Export-MamlCommandHelp が不正な XML を出力する issue もあるしその関連かなあ。 OPS13 Export-MamlCommandHelp creates invalid XML · Issue #692 · PowerShell/platyPS

他に、 INPUT OUTPUT の section は code を使ってると Markdig.Syntax.Inlines.CodeInline が出力されてしまう。そうなると繰り返し Update-MarkdownCommandHelp を実行したとき冪等性がないっぽくて、 section が無限増殖してしまう。 workaround としては code を section に使わなければ良い。

最後に、 pipeline で使いにくい件は Path に Alias なりついてりゃいいよなと思ってるのだけど、 Path parameter 周りでなんか改善の予定あるみたいだしそん時に前提的に見直されたりするのかも？様子見。 Make Path and LiteralPath parameters work like they do for Item cmdlets · Issue #696 · PowerShell/platyPS

あと .NET 9 及び F# 9 対応に進展があり、ついに PR を merge できた。やったね。

取り敢えず残された課題のうち、最低限 Fantomas が対応できたら merge しようと考えてた。でも format できないわ～参ったね... と思って issue を立てたのだけど、実は preview リリースで対応していましたという話だった。メンテナの人達は忙しかろうから一瞬 Issue を立てて迷惑やったな...と思ったが、立てるまでその preview リリースに気づいてなかったのもあり、結果的に解決に至れたのでヨシッ！とした。副次的に Fantomas の online で最新の preview が使える(Setting で変えれる)のも知ったし、 .NET 9 対応の流れも知れた。

もうそろそろ pocof の今年最後のリリースしても良さそうな感じになってきた。

続く。

F# で Cmdlet を書いてる pt.56 - PlatyPS v1 preview

Sun, 08 Dec 2024 09:00:00 +0900

krymtkts/pocof 開発をした。

まだ FsCheck を使った既存の事例テストを PBT で置き換えてる最中。なるべくシンプルなプロパティにして、ジェネレータでいろんなパターンを書くような感じで今は上手くハマっている。今はまだ簡単な関数に対するプロパティしか書いてないので、もうそろそろ難易度上げても良い頃合いかも。

.NET 9 のやつも放置状態。 FSharpLint の .NET 9 の問題は issue ができてた。 Latest version incompatible with .NET 9 · Issue #718 · fsprojects/FSharpLint

他に新しいネタとしては、 2024-10-30 に dev blog に出てた PlatyPS の v1 の preview へ移行始めてみた。調べた内容を整理する意味も込めてまとめておく。

Announcing Microsoft.PowerShell.PlatyPS 1.0.0-Preview1 - PowerShell Team

まだ preview なので PlatyPS のチュートリアルは更新されてない。 Create XML-based help using PlatyPS - PowerShell | Microsoft Learn install は先に挙げた dev blog に従ってやる。

Install-PSResource -Name Microsoft.PowerShell.PlatyPS -Prerelease -Scope AllUsers

> Get-PSResource -Name platyPS,Microsoft.PowerShell.PlatyPS -Scope AllUsers | select Name,Version,PublishedDate

Name                         Version PublishedDate
----                         ------- -------------
platyPS                      0.14.2  2021-07-02 22:53:28
Microsoft.PowerShell.PlatyPS 1.0.0   2024-10-29 22:38:53

実に 3 年ぶりの更新になる様子。 pocof を作り始めたときから v0.14.2 を使ってた。 module name も変わった。 PowerShellGet が PSResourceGet になったのと同じ命名規則なので、 PowerShell Team の module は将来皆こうなるんかな。

module に含まれる Function, Cmdlet は随分様変わりした。コレはなるほど使い方がわからん。

> Get-Command -Module platyPS

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Function        Get-HelpPreview                                    0.14.2     platyPS
Function        Get-MarkdownMetadata                               0.14.2     platyPS
Function        Merge-MarkdownHelp                                 0.14.2     platyPS
Function        New-ExternalHelp                                   0.14.2     platyPS
Function        New-ExternalHelpCab                                0.14.2     platyPS
Function        New-MarkdownAboutHelp                              0.14.2     platyPS
Function        New-MarkdownHelp                                   0.14.2     platyPS
Function        New-YamlHelp                                       0.14.2     platyPS
Function        Update-MarkdownHelp                                0.14.2     platyPS
Function        Update-MarkdownHelpModule                          0.14.2     platyPS

> Get-Command -Module Microsoft.PowerShell.PlatyPS

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Function        New-HelpCabinetFile                                1.0.0      Microsoft.PowerShell.PlatyPS
Function        Show-HelpPreview                                   1.0.0      Microsoft.PowerShell.PlatyPS
Cmdlet          Compare-CommandHelp                                1.0.0      Microsoft.PowerShell.PlatyPS
Cmdlet          Export-MamlCommandHelp                             1.0.0      Microsoft.PowerShell.PlatyPS
Cmdlet          Export-MarkdownCommandHelp                         1.0.0      Microsoft.PowerShell.PlatyPS
Cmdlet          Export-MarkdownModuleFile                          1.0.0      Microsoft.PowerShell.PlatyPS
Cmdlet          Export-YamlCommandHelp                             1.0.0      Microsoft.PowerShell.PlatyPS
Cmdlet          Export-YamlModuleFile                              1.0.0      Microsoft.PowerShell.PlatyPS
Cmdlet          Import-MamlHelp                                    1.0.0      Microsoft.PowerShell.PlatyPS
Cmdlet          Import-MarkdownCommandHelp                         1.0.0      Microsoft.PowerShell.PlatyPS
Cmdlet          Import-MarkdownModuleFile                          1.0.0      Microsoft.PowerShell.PlatyPS
Cmdlet          Import-YamlCommandHelp                             1.0.0      Microsoft.PowerShell.PlatyPS
Cmdlet          Import-YamlModuleFile                              1.0.0      Microsoft.PowerShell.PlatyPS
Cmdlet          Measure-PlatyPSMarkdown                            1.0.0      Microsoft.PowerShell.PlatyPS
Cmdlet          New-CommandHelp                                    1.0.0      Microsoft.PowerShell.PlatyPS
Cmdlet          New-MarkdownCommandHelp                            1.0.0      Microsoft.PowerShell.PlatyPS
Cmdlet          New-MarkdownModuleFile                             1.0.0      Microsoft.PowerShell.PlatyPS
Cmdlet          Test-MarkdownCommandHelp                           1.0.0      Microsoft.PowerShell.PlatyPS
Cmdlet          Update-CommandHelp                                 1.0.0      Microsoft.PowerShell.PlatyPS
Cmdlet          Update-MarkdownCommandHelp                         1.0.0      Microsoft.PowerShell.PlatyPS
Cmdlet          Update-MarkdownModuleFile                          1.0.0      Microsoft.PowerShell.PlatyPS

PlatyPS の reference は更新されてるので、そこを参考に手で試しながら理解するしかないか。 Microsoft.PowerShell.PlatyPS Module - PowerShell | Microsoft Learn

pocof の用途だと「既存の help をイイ感じに更新したい」ところなので、その周りの機能を確認する。

# https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.platyps/measure-platypsmarkdown?view=ps-modules
# Markdown help が含む content type と schema version を検証する
# Filetype が enum なので stringify された値に対して match しないと filter できない
# Output の path 属性が Filepath なので pipeline でそのまま渡しにくい
# 気が利いた機能だが出力が微妙に行けてなくて PlatyPS 内での取り回しが良くない
Measure-PlatyPSMarkdown .\docs\*.md
#
# Title   Filetype              Filepath
# -----   --------              --------
# unknown CommandHelp, V1Schema C:\Users\takatoshi\dev\github.com\krymtkts\pocof\docs\Select-Pocof.md

# https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.platyps/test-markdowncommandhelp?view=ps-modules
# Markdown command help の内容を検査する
Measure-PlatyPSMarkdown .\docs\*.md | ? Filetype -match CommandHelp | select -ExpandProperty FilePath | Test-MarkdownCommandHelp -DetailView
#
# Test-MarkdownCommandHelp
#   Valid: True
#   File: C:\Users\takatoshi\dev\github.com\krymtkts\pocof\docs\Select-Pocof.md
#
# Messages:
#   PASS: First element is a thematic break
#   PASS: SYNOPSIS found.
#   PASS: SYNOPSIS is in order.
#   PASS: SYNTAX found.
#   PASS: SYNTAX is in order.
#   PASS: DESCRIPTION found.
#   PASS: DESCRIPTION is in order.
#   PASS: EXAMPLES found.
#   PASS: EXAMPLES is in order.
#   PASS: PARAMETERS found.
#   PASS: PARAMETERS is in order.
#   PASS: INPUTS found.
#   PASS: INPUTS is in order.
#   PASS: OUTPUTS found.
#   PASS: OUTPUTS is in order.
#   PASS: NOTES found.
#   PASS: NOTES is in order.
#   PASS: RELATED LINKS found.
#   PASS: RELATED LINKS is in order.

# https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.platyps/import-markdowncommandhelp?view=ps-modules
# Markdown command help を読み込んで command help の object を作る
$before = Measure-PlatyPSMarkdown .\docs\*.md | ? Filetype -match CommandHelp | select -ExpandProperty FilePath | Import-MarkdownCommandHelp

# https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.platyps/update-commandhelp?view=ps-modules
# command help object を session に存在する同名 cmdlet の情報で更新する
$after = Measure-PlatyPSMarkdown .\docs\*.md | ? Filetype -match CommandHelp | select -ExpandProperty FilePath | Update-CommandHelp

# https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.platyps/compare-commandhelp?view=ps-modules
# command help object 同士を比較した text を出力する
# 出力される text が D=delete, M=modified, S=same ぽいので適宜 filter しないといけない
Compare-CommandHelp $before $after | ? {$_ -notlike 'S*'}
# M Inspecting dictionary CommandHelp.Metadata
# D   CommandHelp.Metadata: ms.date does not exist in reference
# M Inspecting list CommandHelp.Syntax
# D CommandHelp.Syntax lists are different sizes (1 vs 2)
# 省略

# https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.platyps/export-markdowncommandhelp?view=ps-modules
# command help object を Markdown command help に出力する
# OutputFolder 配下に module name で directory が作成されてその中に出力される
# module name の directory 作らず平置きしてる場合は注意
$after | Export-MarkdownCommandHelp -OutputFolder .\docs

# https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.platyps/update-markdowncommandhelp?view=ps-modules
# Markdown command help を session に存在する同名 cmdlet の情報で更新する
# デフォ *.bak ファイルを作ってくるので、 -NoBackup を指定すると作らなくなる
# description とか example に手で書いた内容は消えないので気軽に実行できる
Measure-PlatyPSMarkdown .\docs\*.md | ? Filetype -match CommandHelp | select -ExpandProperty FilePath | Update-MarkdownCommandHelp -NoBackup

# https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.platyps/export-mamlcommandhelp?view=ps-modules
# OutputFolder 配下に module name で directory が作成されてその中に `${moduleName}-Help.xml` 出力される
Measure-PlatyPSMarkdown .\docs\*.md | ? Filetype -match CommandHelp | select -ExpandProperty FilePath | Import-MarkdownCommandHelp | Export-MamlCommandHelp -OutputFolder ./src/

# https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.platyps/show-helppreview?view=ps-modules
# 出力した MAML を Markdown preview する。何故かこいつは Path が Position 0 じゃなく Named なので注意
Show-HelpPreview -Path .\src\pocof\pocof-Help.xml
# 省略

Measure-PlatyPSMarkdown の output の object が pipeline で使いにくいのだけ気に入らんが、他は良好な使用感そう。

pocof の古いドキュメントを更新するにあたってやるべきことも見えてきた。 Update-MarkdownCommandHelp を 0.14.2 で作った Markdown command help に対して実行すると scheme の version が 1 -> 2 になって結構変わるので、初回は scheme の更新のみで実行する方が良さそう。 OutputFolder 配下に module name の directory ができるのもあるし、出力されるファイル名が変わるのもあるし、まずは今の構造を変えるのが良さげやな。

あと地味に Markdown の table が MAML 翻訳されない bug も直ってるようなので、コレを気に pocof の help も多少綺麗にできるかな。 Markdown tables not rendered properly in MAML · Issue #577 · PowerShell/platyPS

続く。

F# で Cmdlet を書いてる pt.55 - FsCheck

Sun, 01 Dec 2024 09:00:00 +0900

krymtkts/pocof 開発をした。

.NET 9 への更新は Ionide が .NET 9 に対応して 1 つ課題が解消された。あと .NET 9 SDK の bug の影響で Fantomas が動かないやつが解消されたら最低限 OK かなと。 FSharpLint が動かなくなったやつはどうにもならなそうなので何かできることがないか長期的に模索しようと考えている。

さて、その間に他の開発が止まるのもイマイチなので、新しい取り組みとして FsCheck の利用を始めてみた。最近 PBT の本を読んでることで感覚が培われてきたような気がするので、多分機は熟している。初回の対応は従来のテストケースの置き換え。 #264 あまり PBT しても意味ないようなケースだが、欲しい型のジェネレータを自分で書く辺りは良い練習になるかなと思って試した。

リヨウしている FsCheck の version は 3.0.0-rc 。

open Xunit
open FsUnitTyped
open FsCheck.FSharp
open FsCheck.Xunit

module unwrap =
    open System.Collections
    open System.Management.Automation

    let psObjectGen =
        ArbMap.defaults
        |> ArbMap.generate<string>
        |> Gen.map (PSObject.AsPSObject >> Entry.Obj)

    let dictionaryEntryGen =
        ArbMap.defaults
        |> ArbMap.generate<string>
        |> Gen.two
        |> Gen.map (DictionaryEntry >> Entry.Dict)

    type EntryPSObject =
        static member Double() = psObjectGen |> Arb.fromGen

    [<Property(Arbitrary = [| typeof<EntryPSObject> |], EndSize = 1000)>]
    let ``should return PSObject sequence.`` (data: Entry list) =
        data
        |> unwrap
        |> List.ofSeq
        |> shouldEqual (
            data
            |> List.map (function
                | Entry.Obj x -> x
                | _ -> failwith "Dict is unreachable")
        )
        |> Prop.collect (List.length data)

    type EntryDictionaryEntry =
        static member Double() = dictionaryEntryGen |> Arb.fromGen

    // 略

    type MixedEntry =
        static member Generate() =
            Gen.oneof [ psObjectGen; dictionaryEntryGen ] |> Gen.listOf |> Arb.fromGen

    [<Property(Arbitrary = [| typeof<MixedEntry> |], EndSize = 1000)>]
    let ``should return mixed sequence.`` (data: Entry list) =
        data
        |> unwrap
        |> List.ofSeq
        |> shouldEqual (
            data
            |> List.map (function
                | Entry.Obj x -> x
                | Entry.Dict x -> x)
        )
        |> Prop.collect (
            List.length data,
            // TODO: use .Is* after bumping to F# 9.
            data
            |> List.filter (function
                | Entry.Obj _ -> true
                | _ -> false)
            |> List.length,
            data
            |> List.filter (function
                | Entry.Dict _ -> true
                | _ -> false)
            |> List.length
        )

Xunit, FsUnit, FsCheck が滑らかに統合されておりいい感じ。まだ解像度高くないから今後高まったときに気になる点とか出てくるかもしれんな。手を動かしてみていくつか覚えたことをまとめておく。概ね公式文書の焼き直しだが、動かしてみてわかった点もある。

Using FsCheck.Xunit - Running tests

xUnit を利用している場合は FsCheck.Xunit にある PropertyAttribute を使うと、従来のテストケースと FsCheck のテストケースが滑らかに繋がって良い
- Arbitrary instance の上書きを使うとケース、 class, module, assembly 毎にジェネレータを設定できる。ケース以外に設置する場合は PropertiesAttribute を使う
Arbitrary instance の Arbitrary<'Value> を返す static method の名前は何でもいいみたい
- 今回の実装では先 2 つのジェネレータがコピペ元のママ Double になってて、その後書き加えたジェネレータで Generate にしても問題なく動くいてるので reflection で拾ってきてるぽい(実装はまだ追えてない)
PBT 本で学んだ通り統計情報を出しておいた方がどのようなテストが行われたか可視化出来て良い(ただしログは汚れる)。 FsCheck では Prop.collect で出せる
PSObject DictionaryEntry を ArbMap.generate で直に生成できないので ArbMap.generate<string> で生成したデータを詰めれば良い

当面はステートレスプロパティでの置き換えを先にやってみて、次にステートフルプロパティ、多分 FsCheck で言うところの Model-based Testing に手を出そうかと考えている。

公式文書にもあるが、内容が 3.x に追随してないらしくて、唯一 API docs が最新を反映されてる状態らしい。 API docs 見て感覚つかめる人ならそれで学んで、わたしのようによくわからんなーとなってしまう人なら docs 見つつ直にコード書いて試すのが良さそう。

続く。

F# で Cmdlet を書いてる pt.54 - .NET 9

Sun, 24 Nov 2024 09:00:00 +0900

krymtkts/pocof 開発をした。

.NET 9 に更新してみた。結論から言うと 2024-11-24 時点ではなかなか厳しいなという感触だった。ということで一旦寝かせて状況を見る。

詰まってるのは以下の課題。

dotnet fsharplint lint が遂にどうにも動かなくなった。
.NET 9 SDK の bug の影響で fantomas がコケる
- dotnet list package --vulnerable throws ArgumentException: '' is not a valid version string [.NET 9] · Issue #44838 · dotnet/sdk
Ionide は .NET 9 未対応
- Update FSAC used in Ionide to the 9.0.100 version · Issue #2048 · ionide/ionide-vscode-fsharp

もともと fsharplint のやつは Execution fails when using dotnet 7.x or 8.x to target net6.0 project · Issue #687 · fsprojects/FSharpLint という課題にぶち当たってて、 0.24.2 を使えば回避できるのでそうしてた。ただ .NET 9 になってエラーが出るようになって遂にどうにもならなくなった。

> dotnet fsharplint lint pocof.sln
Lint failed to parse files. Failed with: Aborted type check.
Aborted type check.
Aborted type check.
(略)

最新の 0.24.2 とか 0.24.3 の preview に変えてみても issue と同じ既知のエラーが出るのみ。このエラーは fsharplint が .NET 6 を target framework にしてて、利用してるプロジェクトがそれより高い .NET 8 とかを利用してることに起因するらしいのだけど、よくわかってない。プロジェクトに dotnet tool を入れてるとそのプロジェクトの .NET SDK で動く仕組みに問題があるんじゃないのみたいな話もあるようだけど、恐らくその仕組み自体は変わらんだろうしツールの提供側で前方・後方互換性を維持するしかないような感じはするな。

.NET SDK と Ionide ののやつは時が経てばコミュニティが解決してくれそうやけど、 fsharplint のはどうやろな。 .NET 6 は EOL したし target framework が変わればなにか改善できるのかもしらんけど。他力本願じゃなくコントリして直せよって話かも知れんが。

話は変わって言語機能的なところでいうと、 pocof は以下を使えたので利用してみた。良さげ。

ただ先述の通り、まだ Ionide が対応してない。ビルドは成功するけど VS Code 上ではエラーになる状態で、これはちょっと開発しにくい。

続く。

F# で Cmdlet を書いてる pt.53

Sun, 17 Nov 2024 09:00:00 +0900

krymtkts/pocof 開発をした。

その前に、毎年恒例 .NET の新しい major が出ましたな。

What's new in F# 9 - F# Guide - .NET | Microsoft Learn

Nullable reference がでかいのかな。リリース後ブログになってたし。 Nullable Reference Types in F# 9 - .NET Blog

個人的には Enforce attribute targets はよく間違うのでありがたそう。

pocof 的には Optimized equality checks Field sharing for struct discriminated unions あたりの IL の改善が効果でたらうれしいな。 equality の最適化は半年ほど前ブログにもなってて、すご...と思ったやつだ。 F# developer stories: how we've finally fixed a 9-year-old performance issue - .NET Blog

Enhancing #help in F# Interactive - .NET Blog もブログになってたやつ。 Extended #help directive in fsi to show documentation in the REPL 早速使ってみてる。

先に .NET の最新リリースに触れたが、 pocof でも毎年恒例の .NET 更新をやりたいので、それに合わせて今着手中の開発を一区切りして 0.17.0 でリリースした。

含まれるのは、 word 操作。これは自分の日常使いで早速使い込む予定。あとはキーに対応づいた操作の、内部コードのリファクタリングをしてた。例えば、対称な処理が個別の実装になってるのを 1 つにまとめたり。クエリ文字列を操作するあたりはまだゴチャついてて、もっとよくできる直感があるけど、リリースのために後回し。

リリース自体は問題なくいったのだけど、リリース前に既存バグを見つけたので、リリース後にその対処をした。ずっと気づいてなかったが、 pocof のいくつかの option に $null を渡すと validation されてなくて NullReferenceError が出たりしてたので、カッコ悪かった。とりあえずこいつは直した。 #261

その過程で知ったのだけど、 pocof の switch parameter に $null を渡したら truthy な動作をするのよね。なんとなく $false が渡されたときみたいな挙動になるのかと思いきや、 $true を渡されたような挙動になる。

あんまり switch parameter に $null を渡すような変なことしないようなので、以下の辺りがわたしが探してることに近そうかな...という感じはしてるが、まだよくわかってない。

この件に関しては大した情報もなさそうやと思ってコード見に行ったのだけど、まだ追いきれなくてよくわからんかった。この辺は宿題としたい。一応 PowerShell で簡易的に switch parameter の挙動をチェックする PowerShell の関数を作ったのだけど、こいつだと falsy な挙動になる。なんでや...ひょっとしたら pocof のバグなんかも。あるいはバイナリ Cmdlet だと違うとか？めんど...宿題。

function test-switch ([switch]$Switch) {
    "is null=$($Switch -eq $null)"
    "is false=$($Switch -eq $false)"
    "is true=$($switch -eq $true)"
    "isPresent=$($Switch.IsPresent)"
}

# 狂気のワンライナー
Write-Host 'plain'; test-switch -Switch; Write-Host '$false'; test-switch -Switch:$false; Write-Host '$true'; test-switch -Switch:$true; Write-Host 'null'; test-switch -Switch:$null
# plain
# is null=False
# is false=False
# is true=True
# isPresent=True
# $false
# is null=False
# is false=True
# is true=False
# isPresent=False
# $true
# is null=False
# is false=False
# is true=True
# isPresent=True
# null
# is null=False
# is false=True
# is true=False
# isPresent=False

続く。

F# で command-line predictor を書いてる Part 1 - sample 実装を F# に翻訳する

Sun, 10 Nov 2024 09:00:00 +0900

ちょっと前触れた command-line predictor を書きたいというやつを試し始めた。

How to create a command-line predictor - PowerShell | Microsoft Learn

これ ↑ を参考にお試しする。記事によると command-line predictor は PSReadLine の 7.2 のときに登場した機能らしい。 7.4 でアナウンスされた feedback provider はなんか印象強かったが、 command-line predictor の方が先輩機能だった。日本語の方のドキュメントを見たら「コマンドライン予測器」というある意味カッコいいがなんとも伝わらなそうな名前になっているので、英語の command-line predictor の方を使うことにする。略記は記事の URL に含まれてる cmdline predictor に倣うとする。

command-line predictor の記事によれば、

A predictor is a PowerShell binary module.

とのことでバイナリモジュールじゃないとダメなようだ。確かに始め簡単に試したかったので sample code を AI と一緒に PowerShell に翻訳したものを作ってみたが、ダメだった。

諦めて真面目に F# で翻訳したやつを作ってみた。

krymtkts/SamplePredictor: A sample command-line predictor written in F#.

今回は素振りなので、次に本ちゃんを作る時用に手順を残した。

dotnet new classlib --name SamplePredictor --language F#
cd SamplePredictor
git init
git commit -m 'Initial commit.' --allow-empty
# translate code.
git add .\Library.fs .\SamplePredictor.fsproj
git commit -m 'Initialize F# project.'
touch .gitignore
git add .\.gitignore
git commit -m 'Add `.gitignore`.'

dotnet build

# confirm that PredictionSource is set to HistoryAndPlugin.
Get-PSReadLineOption | Select-Object PredictionSource

# PredictionSource
# ----------------
# HistoryAndPlugin

Import-Module .\bin\Debug\net6.0\SamplePredictor.dll

# confirm that SamplePredictor is added to Implementations.
Get-PSSubsystem -Kind CommandPredictor

# Kind              SubsystemType      IsRegistered Implementations
# ----              -------------      ------------ ---------------
# CommandPredictor  ICommandPredictor          True {Windows Package Manager - WinGet, SamplePredictor}

New-GitHubRepository -Name $(pwd | Split-Path -Leaf) -Description 'A sample command-line predictor written in F#.'
git remote add origin $(Get-GitHubRepository -OwnerName krymtkts -RepositoryName SamplePredictor | select -ExpandProperty ssh_url)
git push -u origin main

雑にこんな感じで作れる。

実装は元記事の sample を丸ごとコピペ翻訳しても良かったが、 .NET 素人のためプロジェクト構成の GenerateDependencyFile PublishDir ExcludeAssets PrivateAssets 辺りが何を意図して設定したものか理解してなかったので、部分ごとにちまちま確認しつつコピペ翻訳した。お陰で krymtkts/pocof でも試せそうやなというのが理解できた。あと挙動がわからんのでファイルにログ出力する雑実装を入れて追跡を容易にし、念の為 sample から GUID も変えてる。

使い方は README.md にも書いてるが、これによって Import-Module ~ 後に PSReadLine の suggestion に追加した command-line predictor のエントリが現れる。

> sss
<-/1>                                                       <SamplePredictor(1)>
> sss HELLO WORLD                                              [SamplePredictor]

この実装だと、 ICommandPredictor の CanAcceptFeedback GetSuggestion が呼ばれるタイミングはわかったが、他のメソッドが何するとき動くかは理解できてない。ドキュメント見てもぱっとせんので、手で試行錯誤するのが良さそう。あと既にコミュニティで作成されてる predictor の困りごとを探るとか、 PSReadLine の issue を漁って、今出来ないことを探ってくのが現実的な理解方法かも知れんな。ざっと見た感じ ICommandPredictor は 20ms 以内に response しないといけないやつが短過ぎるって意見があるから、重めの処理ができそうにないのは理解した。にしてもやで、 ICommandPredictor で検索してもあんま情報ないな command-line predictor 。調べ方が悪いんかな。或いはどんだけ人気ないねん。 GitHub で ICommandPredictor 検索して直に見ていくしかないか。

何も内容がない日記になったが、個人的な理解は進んでるはずなのでヨシッ！

booklog はじめた 4

Sun, 03 Nov 2024 09:00:00 +0900

8 月半ばにつけはじめた booklog もはや 3 ヶ月目。そろそろ streak を数値化したくなったので、そういう機能を krymtkts/blog-fable に追加してみた。 #259 #264

新機能によると、昨日時点で 76 日連続で読書できてるらしい。この週間を始めてから読み始めた本だと、読みかけも含めて 5 冊。つまみ読みや輪読会¹の課題図書も含めて 9 冊。少なく見ても月 1 冊以上は読めてるので、年初の目標 0.5 冊/月をさばけてて、いい感じ。

1 回あたりのページ数は、調子がいい時は 20 前後、ダメな時は数ページ。ダメな時は概ね忙しくて寝る前にざっと読んで記録をつけてる感じ。そういう時は 30 分以内で処理できてるのでちょっとは早くなったのか？あと仕事で自分で決める事が多く決断力を消費して疲弊することが多いのだけど、そういう頭がこんがらがってる時に数ページでも読書すると、頭がスーッとして休憩みたいになって良いのを知った。これは習慣化しないと見えなかった風景やな。

輪読会の日は課題図書と自分が読んでる本で 2 冊になるのでちょっと忙しい。けどそういう時はダメな時のような急いでなんかできる感じじゃなく、あらかじめどのタイミングで読んで～といった計画性が必要になってくるので、そういう点ではより強制力高くて良いなと感じている。

ただ今強度を高めると中折れしそうなので、とりあえず 1 年間続けられたらその先同じ用に繰り返せば何年でもできる感触がつかめるだろうから、そのときにページ数の縛りだとかの制約を追加しても良いかもしれない。

ところでこの booklog の streak 機能、 static site generator なため日付が変わっても streak が 0 にならないのよな。コンテンツ生成時に現在日付をもとに計算しても良かったが、なんかイマイチかもなと思って今のところ最後の streak が current streak になる「仕様」になってる。

これだと streak が止まった時のショックが小さくなってしまうから、なんか動的な仕組み考えたほうが良いのかもなー。 GitHub Actions を日次実行するような無駄な使い方になってしまうけど。

知人に付き合ってもらってる輪読会。ゆるく開催してて概ね月 0 ~ 4 回くらい。 ↩

F# で Cmdlet を書いてる pt.52

Sun, 27 Oct 2024 09:00:00 +0900

krymtkts/pocof 開発をした。

word 操作の実装中 #173 で、移動、選択、削除を雑に作った。

多分まだ日記でどういう方針で実装するかを書いてなかったので、備忘がてら実装開始前のメモを記しておく。

word 操作の実装は PSReadLine を参考にするつもり。

PSReadLine/PSReadLine/Movement.cs at e87a265ef8d2c6c5498500deb155bf6258b34629 · PowerShell/PSReadLine

_singleton.Options.WordDelimiters は Get-PSReadLineOption | Select-Object WordDelimiters のこと。

;:,.[]{}()/\|!?^&*-=+'"–—―

この文字列に対して独自の文字列一致関数を使って一致したか判定している。

PSReadLine/PSReadLine/StringBuilderCharacterExtensions.cs at e87a265ef8d2c6c5498500deb155bf6258b34629 · PowerShell/PSReadLine

また加えて、

PSReadLine/PSReadLine/StringBuilderCharacterExtensions.cs at e87a265ef8d2c6c5498500deb155bf6258b34629 · PowerShell/PSReadLine

を見てわかるように character が whitespace の場合は問答無用で区切る。

pocof も同様に Option で指定できるようにしてジャンプ位置を指定するようにしようかな。

PSReadLine の word の特徴？なのか bash とは別の動きするので PowerShell の流儀的に pocof もそれに倣うため実装を参考にしてる。ただ、 pocof では選択範囲ありの行頭・行末までの削除の挙動が独自なのだけど、今回の word 削除でも同じく独自にした。 PSReadLine では選択範囲を無視して word を削除するが、 pocof では選択範囲も削除する。

あと当初の予定の範囲で実装できてないのが、区切り文字の Option 指定。これは他の Option 同様に内部状態に加えるだけなので実装自体はたいしたことない。個人的には _ も区切りたいのだけど、これは自分でデフォルトパラメータを設定したらいいだけなので、足さない。

そこまでできたら最後にリファクタリングが必要だ。何故なら、今回の実装で痛感したが、文字の選択と削除の実装が結構バラバラで苦労したからだ。 1 文字消すのと複数文字消すのと行頭行末まで消すので実装マチマチなので、なんか統一的な操作に落とし込めるだろこれｗみたいな。過去の自分のツケが回ってきた。

あと特に認知的な負荷が高いと思ってるのが、選択範囲の実装。正負の整数でカーソルの前後にある選択範囲の文字数を示してるので、最近全然触ってなかったし結構混乱した。すでに discriminated union にくるまれた整数だが、更に DU を分けるべきなのか、 Units of measure で上手くできるもんなのか、検討する。実際選択範囲を正負の整数で表現することで、カーソル位置から選択範囲を加減算するだけで選択範囲のカーソル位置がわかる便利さはあるのだけど、案外リファクタリングの過程で別のわかりやすい実装が見つかるかも知れんし。

続く。

F# で Cmdlet を書いてる pt.51 - Windows PowerShell on GitHub Actions workflow

Sun, 20 Oct 2024 09:00:00 +0900

krymtkts/pocof 開発をした。

以前発見した .NET の挙動が文書と違うやつは .NET Framework に依存する Windows PowerShell だけで発生するエラーがあったためだが、それを自動的に検知する仕組みは作ってなかった(このときは手で見つけた)。今後も同じような事があると面倒なので、 pull request を作成したときに自動で検知できるよう GitHub Actions workflow の matrix に Windows PowerShell を追加した。

job の step で Windows PowerShell を利用するには、jobs.<job_id>.steps[*].shell に powershell と指定すればいい。 jobs.<job_id>.steps[*].shell を使うのは、 pocof の Github Actions workflow は処理を共通化するのに Composite action を使ってるからで、 step ごとに指定する必要があるから(確か)。当然コレを使えるのは platform が Windows の場合だけ。 job runner が Windows の場合だけ pwsh と powershell の 2 つの shell を Composite action に追加してやれば良い。

従来はすべての platform で pwsh を利用する matrix になってたので、 Windows の場合だけ拡張してやる必要がある。これには jobs.<job_id>.strategy.matrix.include が使えた。 matrix 定義の追加や上書きができるみたい。便利すぎ。

結果この様になった。 #246

composite action の inputs に shell を追加して、それで jobs.<job_id>.steps[*].shell を設定する。

inputs:
   codecov_token:
     description: "Codecov token"
     required: true
+  shell:
+    description: "Shell for the job. pwsh or powershell"
+    required: true
+    default: pwsh

       with:
         global-json-file: ./global.json
     - name: Install modules from PSGallery
-      shell: pwsh
+      shell: ${{ inputs.shell }}
       run: |
         Set-PSResourceRepository PSGallery -Trusted
         Install-PSResource Psake,Pester,PSScriptAnalyzer -Quiet -Reinstall -Scope CurrentUser
     - name: Execute All Tests
-      shell: pwsh
+      shell: ${{ inputs.shell }}
       run: Invoke-Psake -taskList TestAll
     - name: Upload coverage reports to Codecov
       uses: codecov/codecov-action@v4

include を使って Windows runner の matrix を拡張する。

     strategy:
       matrix:
         os:
           - windows-latest
           - ubuntu-latest
           - macos-latest
+        shell:
+          - pwsh
+        include:
+          - os: windows-latest
+            shell: pwsh
+          - os: windows-latest
+            shell: powershell
     runs-on: ${{ matrix.os }}
     steps:
       - name: Checkout

         uses: ./.github/actions/test
         with:
           codecov_token: ${{ secrets.CODECOV_TOKEN }}
+          shell: ${{ matrix.shell }}
       - name: Run Snyk to check for vulnerabilities
         uses: snyk/actions/dotnet@master
         # snyk/actions uses Container action that is only supported on Linux.

これで完成かと思いきや、 3 つ障害があった。まず Pester 用のテストスクリプトに Windows PowerShell 非互換の機能があったので取り除く必要があった。また GitHub Actions workflow で使える Windows Server 2022 の runner には PSResourceGet が入ってなかったので、 PowerShell Module の準備を pwsh 用と powershell 用に分けた。この 2 つはテストスクリプトと workflow を調整するだけで済んだ。

Split-Path -LeafBase は PowerShell 6.0 以降の機能で Windows PowerShell で使えなかったので Get-ChildItem で代用。

     if ($DryRun -eq $null) {
         $DryRun = $true
     }
-    $ModuleName = Resolve-Path ./src/*/*.psd1 | Split-Path -LeafBase
+    $ModuleName = Get-ChildItem ./src/*/*.psd1 | Select-Object -ExpandProperty BaseName
     $ModuleVersion = (Resolve-Path "./src/${ModuleName}/*.fsproj" | Select-Xml '//Version/text()').Node.Value
     $ModuleSrcPath = Resolve-Path "./src/${ModuleName}/"
     $ModulePublishPath = Resolve-Path "./publish/${ModuleName}/"

shell の内容に応じて Install-PSResource と Install-Module を使う step に分ける。

       uses: actions/setup-dotnet@v4
       with:
         global-json-file: ./global.json
-    - name: Install modules from PSGallery
+    - name: Install modules from PSGallery (pwsh)
       shell: ${{ inputs.shell }}
+      if: inputs.shell == 'pwsh'
       run: |
         Set-PSResourceRepository PSGallery -Trusted
         Install-PSResource Psake,Pester,PSScriptAnalyzer -Quiet -Reinstall -Scope CurrentUser
+    - name: Install modules from PSGallery (powershell)
+      shell: ${{ inputs.shell }}
+      if: inputs.shell == 'powershell'
+      run: |
+        Install-Module -Name Psake,Pester,PSScriptAnalyzer -Force -Scope CurrentUser -Repository PSGallery -SkipPublisherCheck
     - name: Execute All Tests
       shell: ${{ inputs.shell }}
       run: Invoke-Psake -taskList TestAll

最後の障害は解消できなかったので、暫定対応とした。解決できなかったのは、 [System.Threading.Thread]::CurrentThread.CurrentCulture に設定した DateTimeFormat.ShortDatePattern が pocof に伝播されない点だ。この DateTimeFormat.ShortDatePattern に 'yyyy-MM-dd' を設定したら、 DateTime.ToString() でそのパターンが参照されるはずだが、されなくてテストがコケる。自 PC であれば PowerShell でも Windows PowerShell でも上手くいくが、 GitHub Actions の Windows Server 2022 runner では反映されなかった。

culture を設定した thread と違う thread で動いたのか？とか考えられるが、となると解消方法は DateTime.ToString() に culture を直に渡す方法になる。これはやりたいものではない。現時点で恒久対応が難しかったので、 skip 判断で良かったと思う。 Pester で提供されてた Conditional skip 機能で条件付き skip を実現できた。便利すぎ。 $PSVersionTable.PSEdition -eq 'Desktop' で判断しているので Windows PowerShell だけこの test case が skip 対象となる。ついでに culture の変更は BeforeEach AfterEach を使うようにした(*All でいい気もするが)。

         Context 'with culture' -ForEach @(
             @{ Matcher = 'match'; Operator = 'or'; Query = '24-01' }
         ) {
+            BeforeEach {
+                $global:culture = [System.Threading.Thread]::CurrentThread.CurrentCulture
+                $global:testCulture = [System.Globalization.CultureInfo]::GetCultureInfo('en-US').Clone()
+                $global:testCulture.DateTimeFormat.ShortDatePattern = 'yyyy-MM-dd'
+                [System.Threading.Thread]::CurrentThread.CurrentCulture = $global:testCulture
+            }
+            AfterEach {
+                [System.Threading.Thread]::CurrentThread.CurrentCulture = $global:culture
+            }
             It "Given '<InputObject>', it keeps order as '<Expected>'." -TestCases @(
                 @{InputObject = 1..12 | ForEach-Object {
                         Get-Date ('2024-{0:D2}-01' -f $_)
                     }; Expected = @(
                         Get-Date '2024-01-01'
                     ) ; Params = $BaseParam + $_
                 }
-            ) {
-                $culture = [System.Threading.Thread]::CurrentThread.CurrentCulture
-                $testCulture = [System.Globalization.CultureInfo]::GetCultureInfo('en-US').Clone()
-                $testCulture.DateTimeFormat.ShortDatePattern = 'yyyy-MM-dd'
-                [System.Threading.Thread]::CurrentThread.CurrentCulture = $testCulture
+            ) -Skip:($PSVersionTable.PSEdition -eq 'Desktop' ) {
+                # TODO: This test is not working on Windows PowerShell on GitHub Actions. It works well locally.
+                # TODO: It seems that the culture is not changed.
                 $InputObject | Select-Pocof @Params | Should -BeExactly -ExpectedValue $Expected
-                [System.Threading.Thread]::CurrentThread.CurrentCulture = $culture
             }
         }

現状 skip してるが根治できたらしたいな。継続して調査する。

ひとまずこれで v0.16.0 のリリースしたあと Windows PowerShell 出だけ発生するエラーがあるとかは事前に気づける。あとやっぱ今の PowerShell は Windows PowerShell より大分速いんやなと実感できた。 Windows PowerShell の job は他よりも完了するのがめちゃくちゃ遅い。いい仕事をした。

F# で command-line predictor を書きたい

Sun, 13 Oct 2024 09:00:00 +0900

krymtkts/pocof はちょこちょこいじってるだけ、また前回発見した .NET の挙動が文書と違うやつも意図した挙動で長くドキュメント不備だっただけらしいので、特に進捗なし。 dotnet/dotnet-api-docs#10508

なので今日は今後やりたいなと思ってることをメモしておく。

ちょっと前にに Windows Terminal に Snippets Pane ていう機能が来てた。

Snippets Pane | Windows Terminal Preview 1.22 Release - Windows Command Line

Have you ever woken up at 3:00 AM after getting paged for a SEV1 and frantically struggled to remember what commands you need to revive a production cluster? Well, maybe the Snippets Pane can help with that…

意訳するとこう。

深夜 3:00 に緊急対応で起こされて本番クラスタを復活するためのコマンドを思い出すのに必死になったことはあらへんか？ Snippets Pane が助けてくれるかも知れへんで...

要はタダのスニペット挿入機能なんやけど、 Windows Terminal の複数プロファイルを束ねる特性と組み合わさることで、様々な環境に対して同じワンライナー(ここでいう snippets)を挿入できる素敵な機能になってる。登場以来わたしもよく使ってる。

ただ満足してるわけではないねんよな。何故かというとこの機能は個々のシェルの外側にいるので、そのシェルの中で滑らかにつながってない。郷に入っては郷に従えではないが、そのシェルの中、ここでは PowerShell のお作法に従って滑らかに繋がってるスニペット挿入機能があってほしい。日常使いする PowerShell は自分のローカル開発環境でしかほぼ使わないから、 PowerShell のスニペットを Windows Terminal に保存しても特に嬉しいことないねんよな。 PowerShell のような人少なめコミュニティでもスニペットみたいなみんなが欲しい機能は当然昔からあるようで、調べたらなんぼでも出てくるのよね。例えば新し目のだと mdowst/PSNotes とか良さそうよな。

ただ、わたしの場合スニペットに名前をつけて覚えといて、その名前で利用するときに呼び出すなんてことは面倒そうな気がしてる。 Windows Terminal の Snippets Pane を使うまでは履歴から目当てのコマンドを拾って実行したりしてたので、その利用感でスニペットを優先的に表示できたらなんか良さそうよな。だからやりたいのは PSReadLine の補完候補のところにスニペットを出したい。

少し調べたところ、 PowerShell 7.2 & PSReadLine 2.2.2 から使える command-line predictor という機能を使えばやりたいことができそう。

How to create a command-line predictor - PowerShell | Microsoft Learn

Microsoft 様公式ドキュメントもパッと見充実しており、というかコレ以外はあまりまともそうな資料が見つからないのだけど、これを使って意中の機能を実装できないかなーと検討している。 F# で。 command-line predictor と、追加・削除のための Cmdlet を提供できたら、いい感じに日常使いが回るかなと考えている。ひょっとしたら世界の何処かで誰かが既に実装してるかも知れないが、見つけられなかったので自作する。

それならまずサンプル実装をしてみようと思ってたのだけど、時間取れず着手できないまま 2 ヶ月近く経過してしまった。このままではまずい。ということで、とりあえず今日は日記に書くネタがなかったし、代わりにこの話を書くことで自身に対する実行の強制力を高めようという目論見だ。日記に書く暇あったら sample だけでもはよ作れよという感じではあるが。

続く。

F# で Cmdlet を書いてる pt.50

Sun, 06 Oct 2024 09:00:00 +0900

krymtkts/pocof 開発をした。 v0.16.0 と、そのバグ修正版の v0.16.1 をリリースしたのでその話を書く。

コードクォートでクエリの述語を実装してみた版を v0.16.0 でリリースした。 pocof は .NET Standard 2.0 を対象にしてるので PowerShell と Windows PowerShell の両方で動くのだけど、この版に含まれる変更に起因して Windows PowerShell でだけエラーになるバグ #235 が発生した。

> '' | pocof

# pocof : The startIndex argument must be greater than or equal to zero.
# Parameter name: startIndex
# At line:1 char:6
# + '' | pocof
# +      ~~~~~
#     + CategoryInfo          : NotSpecified: (:) [Select-Pocof], ArgumentOutOfRangeException
#     + FullyQualifiedErrorId : System.ArgumentOutOfRangeException,Pocof.SelectPocofCommand

Windows/Linux/MacOS の PowerShell ではエラーにならない。率直に Windows PowerShell になにか問題あるよなと考えた。

バグが入り込んだコミット krymtkts/pocof@2554092 は人力二分探索で特定した。該当のコミットでの変更差分は以下の通り。

         member __.Receive() =
-            match renderStack.Count with
-            | 0 -> RenderMessage.None
-            | c ->
-                let items = Array.zeroCreate<RenderEvent> c
-                renderStack.TryPopRange(items) |> ignore
-                items |> Array.toList |> getLatestEvent
+            let items = Array.zeroCreate<RenderEvent> renderStack.Count
+            renderStack.TryPopRange(items) |> ignore
+            items |> Array.toList |> getLatestEvent

コレ見て分かる通り、 0 のケースを ConcurrentStack<T>.TryPopRange に寄せたのが良くなかったみたい。 PowerShell 7.4 と Windows PowerShell 5.1 はそれぞれ .NET 8 と .NET Framework 4.5 に依存しててたまに挙動の違いがあるからこういうこともあるよなという感じ。今回はそこのテストが不十分だった。

このエラーは Windows PowerShell でも確認できる。依存する .NET/.NET Framework で動くからな。 (Windows PowerShell のほうが CLRVersion 4.0. ~ なのがよくわからんかったが CLRVersion は major version で一緒ということを知った)

# PowerShell の場合
> $PSVersionTable; $s = [System.Collections.Concurrent.ConcurrentStack[System.String]]::new(); $s.Count; $s.TryPopRange(@())

# Name                           Value
# ----                           -----
# PSVersion                      7.4.5
# PSEdition                      Core
# GitCommitId                    7.4.5
# OS                             Microsoft Windows 10.0.22631
# Platform                       Win32NT
# PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
# PSRemotingProtocolVersion      2.3
# SerializationVersion           1.1.0.1
# WSManStackVersion              3.0
# 0
# 0

# Windows PowerShell の場合
> $PSVersionTable; $s = [System.Collections.Concurrent.ConcurrentStack[System.String]]::new(); $s.Count; $s.TryPopRange(@())

# Name                           Value
# ----                           -----
# PSVersion                      5.1.22621.4249
# PSEdition                      Desktop
# PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
# BuildVersion                   10.0.22621.4249
# CLRVersion                     4.0.30319.42000
# WSManStackVersion              3.0
# PSRemotingProtocolVersion      2.3
# SerializationVersion           1.1.0.1
# 0
# Exception calling "TryPopRange" with "1" argument(s): "The startIndex argument must be greater than or equal to zero.
# Parameter name: startIndex"
# At line:1 char:104
# + ... ConcurrentStack[System.String]]::new(); $s.Count; $s.TryPopRange(@())
# +                                                       ~~~~~~~~~~~~~~~~~~~
#     + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
#     + FullyQualifiedErrorId : ArgumentOutOfRangeException

とここまで追い込んだら修正するだけだったので、 #237 で修正して v0.16.1 を出した。

ここからはタダの brain dump だ。

直し方がわかって修正したらあとはこの動作の差異が何なのかというのが気になる。コードを見に行った。 microsoft/referencesource dotnet/runtime/ どちらもライセンスが MIT なので snippet を貼る。以下は ConcurrentStack<T>.TryPopRange の引数の validation をしているメソッドだ。

.NET の方は runtime/src/libraries/System.Collections.Concurrent/src/System/Collections/Concurrent/ConcurrentStack.cs から runtime/src/libraries/System.Collections/src/System/Collections/ThrowHelper.cs を呼ぶ。

        private static void ValidatePushPopRangeInput(T[] items, int startIndex, int count)
        {
            ArgumentNullException.ThrowIfNull(items);

            ArgumentOutOfRangeException.ThrowIfNegative(count);

            int length = items.Length;
            ArgumentOutOfRangeException.ThrowIfGreaterThan(startIndex, length);
            ArgumentOutOfRangeException.ThrowIfNegative(startIndex);

            if (length - count < startIndex) //instead of (startIndex + count > items.Length) to prevent overflow
            {
                throw new ArgumentException(SR.ConcurrentStack_PushPopRange_InvalidCount);
            }
        }

        public static void ThrowIfGreaterThan<T>(T value, T other, [CallerArgumentExpression(nameof(value))] string? paramName = null)
            where T : IComparable<T>
        {
            if (value.CompareTo(other) > 0)
            {
                ThrowGreater(value, other, paramName);
            }
        }

.NET Framework の方は referencesource/mscorlib/system/collections/Concurrent/ConcurrentStack.cs

        private void ValidatePushPopRangeInput(T[] items, int startIndex, int count)
        {
            if (items == null)
            {
                throw new ArgumentNullException("items");
            }
            if (count < 0)
            {
                throw new ArgumentOutOfRangeException("count", Environment.GetResourceString("ConcurrentStack_PushPopRange_CountOutOfRange"));
            }
            int length = items.Length;
            if (startIndex >= length || startIndex < 0)
            {
                throw new ArgumentOutOfRangeException("startIndex", Environment.GetResourceString("ConcurrentStack_PushPopRange_StartOutOfRange"));
            }
            if (length - count < startIndex) //instead of (startIndex + count > items.Length) to prevent overflow
            {
                throw new ArgumentException(Environment.GetResourceString("ConcurrentStack_PushPopRange_InvalidCount"));
            }
        }

.NET の方で ArgumentOutOfRangeException.ThrowIfGreaterThan(startIndex, length) になったとき startIndex = length のケースがエラーの対象に含まれなくなってんのよね。

ドキュメントも見てきた。 .NET 8 が ConcurrentStack.TryPopRange Method (System.Collections.Concurrent) | Microsoft Learn 。 .NET Framework 4.5.2 が ConcurrentStack.TryPopRange Method (System.Collections.Concurrent) | Microsoft Learn 。

どっちも ArgumentOutOfRangeException にはこう書いてる。

ArgumentOutOfRangeException startIndex or count is negative. Or startIndex is greater than or equal to the length of items.

これって実装がドキュメントの挙動と違うねんけど、どっちが間違ってんの？となって理解進んでないのが現状。いやさっさと聞きに行ったら良いねんけど、どっちが妥当なんか自分の中で腑に落ちてなくて立ち止まってるところ。空の配列渡したら何の操作もなく戻る現状の挙動の方が使い良くて好きやけど、ちゃんとした裏付けしたいのでもうちょっと調べる。

例えばやで、仮にこう ↓ するとエラーにならんのよね。これは item.Length より大きい index を startIndex が指してるからやっぱおかしい気もするわ。 count = 0 の場合を特別扱いにするとかしないと辻褄あった API 仕様にならんのちゃうかなあ。

$s = [System.Collections.Concurrent.ConcurrentStack[System.String]]::new(); $s.Push("a"); $s.Count; $a = @($null); $s.TryPopRange(@('a'), 1, 0)
# 1
# 0

続く。

F# で Cmdlet を書いてる pt.49 - コードクォート

Sun, 29 Sep 2024 09:00:00 +0900

krymtkts/pocof 開発をした。最近のまとめ。

以前コードクォート¹でクエリの述語を実装してみるアイデアを記した。多重で lambda を入れ子にするよりもコードクォートで条件を平坦に繋いだ lambda にした方が速そうやなというやつ。

趣味プロなのでパフォーマンスの計測とかせずそのまま実装に移してしまっても良かったが、一応サンプルとして lambda 入れ子版とコードクォート版を作って比較してみた。

fsharp-cmdlet-sandbox/src/code-quote/Library.fs at main · krymtkts/fsharp-cmdlet-sandbox

コードはこんな感じ。

    let buildExpr conditions op =
        conditions
        |> List.rev
        |> List.reduce (fun acc x -> fun e -> op (acc e) (x e))


    (*
        or condition
        if expr1 x then true else xxx
        if expr2 x then true else xxx
        if expr3 x then true else xxx
        if expr4 x then true else xxx
        if expr5 x then true else false

        and condition
        if expr1 x then xxx else false
        if expr2 x then xxx else false
        if expr3 x then xxx else false
        if expr4 x then xxx else false
        if expr5 x then true else false
    *)
    let generateExpr conditions op =
        let xVar = Var("x", typeof<string>)
        let x = xVar |> Expr.Var |> Expr.Cast<string>

        let combination =
            match op with
            | Operator.And -> fun c acc -> Expr.IfThenElse(<@ c %x @>, acc, <@ false @>)
            | Operator.Or -> fun c acc -> Expr.IfThenElse(<@ c %x @>, <@ true @>, acc)

        let rec recBody acc conditions =
            match conditions with
            | [] -> acc
            | condition :: conditions ->
                let acc = combination condition acc
                recBody acc conditions

        let body =
            match conditions |> List.rev with
            | [] -> <@@ true @@>
            | condition :: conditions ->
                let term = Expr.IfThenElse(<@ condition %x @>, <@ true @>, <@ false @>)
                recBody term conditions

        let lambda = Expr.Lambda(xVar, body)

        lambda
        |> LeafExpressionConverter.EvaluateQuotation
        :?> string -> bool

コードクォートを使って組み合わせて作った lambda の AST を評価することで関数を動的に生成する。 body の組み立てに必要な (||) や (&&) は F# の repo を見てわかるように if ~ then ~ else の構文糖なので、 AST 組み立てでも ExprIfThenElse を利用して再現する。コードクォート同士の組み合わせは Splicing operator を使って、最後に Expr.Lambda に食わせることで lambda が出来上がるという仕組み。 AST の組み立ては型のサポートあれど、不正な文法だと実行時のエラーでしか気付けないのでちょっと面倒だった。しかし面倒さを払う価値ある強力な機能。

以降は 2017 Razer Blade Stealth RAM 16 GB で計測した結果の話をする。

結果の数値をコピってなかったが、件数が多いとコードクォートの方が明らかに速かった。デメリットとして、コードクォートから lambda を構築するのに 100ms 程度のオーバーヘッドが生じるようだった。 lambda の方は単純に組み合わせていくだけなので、構築するのに大して時間がかからない。

ただ lambda 版の方は入れ子の階層が深いほど lambda の呼び出し回数が増加してパフォ劣化が如実になるようだった。そのオーバヘッドを回収するのはそんなに難しいことではないなと判断し、 #224 で pocof へ実装した。コードはこんな感じでほぼサンプル実装と同じ。

pocof 実装の note にもあるが、条件を末尾から組み立てる必要があるので (Entry -> bool) list の並び順は事前に反転してある。また pocof では hashtable をサポートする関係で評価の対象が DictionaryEntry の場合の条件組み立てで key と value を評価した結果を (||) か (&&) で判定する必要があるのだけど、それは Entry -> bool の関数を構築する時点で解決しておりここには載ってない。パフォに関しては、 pocof の場合は動的にプロパティの値にアクセスするコードがあるのもあってか、サンプル実装よりも条件の組み合わせが増えた場合の lambda 版の速度劣化が著しかった。コードクォート版なら条件の数が多くてもさほど遅くならない。複数条件を入力することが多いし、大いにコードクォートを使う価値があったな～という感じ。

わずかでも pocof が速くなったし、コードクォートの実践もできたし、なかなか良かった。コードクォートはまだ簡単な使い方しかできないし、型情報有り無しの取り扱いもこなれてないので、 pocof とは別の形でもいいので更に掘り下げたいな。

プログラミング F# ではコード引用符と呼んでたがどうもコードクォートとカタカナ表記するのが一般的なようなのでこっちに寄せる。 ↩

booklog はじめた 3

Sun, 22 Sep 2024 09:00:00 +0900

先日はじめた booklog が 1 ヶ月を超えた。 krymtkts/pocof でコード引用符使ってみるのも結構うまくいってる(つもりや)けど、今日は booklog を続けてみて思ったことついて記す。

取り戻した読書習慣について触れるには未だ継続期間が短く、平日は特に追い立てられて読んでる感じが強い。読書習慣の再開で未だ次のステージに進んだ感じはなく、なんとか前いた地点に戻ろうとしてる感じかな。

なので主に booklog 機能について思うところに触れる。カレンダーによる streak の可視化の効果については前から触れてるので、それ以外について書いてみる。

notes は未記入可能にしてるのだけど、今のところ毎日記入することにしている。うっすい付け焼き刃のコメントでも毎回書かないといけないので、読んでる途中で頭の中を強制的にまとめる練習になっている。恥ずかしくて書かないよりも、多少恥ずかしくても書いて、また読み直して理解を深めてからまた書いたらいい。でもこればっかりは疲れ切ってるときに書けない可能性もあるので、 optional としておいておくつもり。

書籍の属性と booklog を切り分けたのも良かった。コピペする量が減っただけだが、モバイルでコピペして書き足すときに多少楽だと感じる。書籍ごとのまとめページを作った際に、書籍の URL を決めるための ID を付与する必要があったけど、これも書籍の属性を切り分けてたことですんなりできた。もしこれらの情報が booklog にベタのままだったらコピペ量爆発してクソダル案件になってたろうことは想像するに易い。

書籍のまとめページは現状シンプルなものだが、サクッと振り返る程度には役に立つ。未だ複数回読んだ書籍が booklog に出てきてないので、そういうのが現れたときに不便だったら更にグルーピングするのもいいかも知れない。

総じて良いと思ってるけど、機能的にイマイチな点もある。

まずリンクの位置がイマイチ。画面最下部までジャンプしないと使えないあたりがそう。書籍のまとめページは日々の booklog の書籍タイトルから飛べるようにしたので未だマシとして、年ごとのまとめが下部のリンクしかないので、カレンダーにそういう機能を足してもいいかも。

あと気になるのが年ごとのまとめページの高さが相当高くなりそうな点。 krymtkts/blog-fable で毎日記録したパターンのサンプルを作って使用に耐えるか見てみた方が良いかな。個人的に、ブログサービスでよくある月ごとに分かれてるようなのはページ内の検索性低くて好きじゃないので、文量が許すなら年ごとのままいきたい。

結局近い将来にまた機能追加しないと満足いかなさそうではあるが、現状は満足しており習慣化の促進にもなってるので良いよな、という自画自賛の感想であった。

F# で Cmdlet を書いてる pt.48 - コード引用符

Sun, 15 Sep 2024 09:00:00 +0900

krymtkts/pocof 開発をした。日記にするのは約 1 ヵ月ぶりか。

この 1 ヶ月の間、 #209 以降はちょうど盆、日本の夏休みということで、移動の車中や山に囲まれて細々とした修正を重ねてきた。 None operator を消して、それに伴うドキュメント修正し、プロパティ候補が case insensitive になってないバグ直したり、気になるコードをキレイにしてみたり...ほんと細々と。そういうのの対処をしたあと、 blog に booklog 機能を実装するのに注力してる間は、完全に放置してた。先週になって booklog が 100% ではないが概ね満足いくものになったので、全部ひっくるめて v0.15.0 としてリリース。めでたしめでたしさて次何やるかなというところだった。

pocof のクエリ改善にコード引用符が使えそうやなという閃きが頭に降りてきた。その頃ちょうど dmmf 本を読み終えたところで、本から特別な何かを得たわけじゃなかったが F# の本なんてそう日本語で読めるもんでもないので、刺激になったみたい。 dmmf 本には全然コード引用符書いてないけどｗ母国語で興味のあるトピックに触れたことでシナプスが発火したのかな。いい経験したわ。

そこでプログラミング F# のコード引用符の章とCode Quotations - F# | Microsoft Learn を読んでイメージを膨らませ、 #224 で実装はじめてみた。

クエリの箇所は元が気合の再帰で実装してるのもあって(それより前は List 処理でもっと遅かったけど)、軽く見た感じ結構速くなりそう。ところがうまくいかんのよね。昔のわたしが書いたテストをクリアできない。なんでかなーとなるわけやけど調査してみたら、ちょっと前に非同期レンダリングを入れたときに non-interactive mode のプロパティ検索がバグってたみたい。処理が遅いうちは気付かないが、速くなるとプロパティ読み替え用の Map の構築が追いつかなくて、プロパティ検索できなくなってるみたい。 #223 どうにもならんので準備がてらきょう直してみたらテスト通る様になったので、やっぱコイツが原因だったか... まあ直ってよかったわ。

いまは未だ、入力されたクエリを個別の条件式の lambda にして && か || でつなぐというところまでしかやってない。これだと個別の条件式の数だけ lambda が増殖する。

Implementation to replace with a lightweight predicate. by krymtkts · Pull Request #224 · krymtkts/pocof

        | QueryPart.End ->
            match acc with
            | [] -> alwaysTrue
            // TODO: should i use code quotation to remove redundant lambda?
            | _ -> acc |> List.rev |> List.reduce (fun acc x -> fun e -> combination (acc e) (x e))

この余分な lambda を取り除いて平坦な式にするのにコード引用符を使えたらなって考えている。 fsi で試す感じ <@ %acc && x e @> って感じにできそうやねんよな。

この対応で気になってるのはコード引用符の評価にどんくらいのオーバヘッドがあるかよくわかってないところ。デフォで使える LeafExpressionConverter.EvaluateQuotation を使うつもりなんやが、こいつのオーバヘッドが lambda を入れ子にしまくるオーバヘッドに勝れば、いい感じよな。

他にも難しく考えすぎてややこしく遅くなってる pocof のコードって意外にありそうなので、まだまだ楽しませてくれそうな気がする。続く。

booklog はじめた 2

Sun, 08 Sep 2024 09:00:00 +0900

先日はじめた booklog がきょうで 3 週間になった。仕組みを構築したことで明らかにい強制力働いてるあたり自身の単純さに笑える。

krymtkts/pocof も再開したが、次やりたいことは多少練習しないとできなそうなので、今日はまた当ブログの booklog 機能について記す。

booklog 機能のバグ修正と機能追加をちまちま行ってきた。雑多なリファクタリング #232 と Light テーマの対応漏れ #233 。

既読日のセルからログにジャンプするリンクは、元々手抜きでその日の最初のログ(${date}-1)に飛ぶようになってた。でも登録降順でログ表示しているから 1 番目に飛べても嬉しくない。なのでその日の最後のログに飛ぶようにした。これなら描画域先頭が最後になりその日のログをある程度一覧できて良い。

あと忘れがちというか忘れてたのだけど light & dark theme 対応しているので、 Solarized Light っぽいカレンダーの色も考えた。ゆーても未読の日のセルの色を調整しただけなので、多少 cyan が目立つかなーというのはある。また既読のセルの色を GitHub の Activity みたいに回数でグラデーションしたようなのは考えてないから、配色はコレで固まったかなという感じ。

あと足したい機能として考えてるのが、サマリ系の機能。 current streak & longest streak を表示しておきたいのと、あと書籍ごとにログをまとめたページを作りたい。

tag は要るかなと思って属性のみ設けていたけど、要らない気がしてきた。 tag のページから書籍のサマリの一覧があるといいかもなというのはあるが、そんなに既読の書籍が貯まるのは未だ先の話だと思う。その時になって tag で書籍を管理できたらいいなという感覚があれば対処するものとしたい。 streak はそんなに難しくないけど、書籍ごとまとめはちょっと難しいなと考えてる。何が難しいかというと URL どうするかというところ。なんかいい感じに ASCII だけの URL にしたいけど日本語の書籍ばっか読むのでどーにもならん。 Punycode だと URL を一見して何のページかわからなくなるし。

となるとやで、手動で書籍ごとに識別子を考えて付与してやるのがいいと思うが、 booklog の YAML に毎回書くのはちょっとなあという感じがする。なので現実的な解としては書籍の名前から識別子を引くための YAML を個別に作って、そこに登録されてたら書籍のサマリを生成するってのがいいかな。ちょっとめんどいけど。そうするとなればいま booklog の YAML に直に書いてる著者名や前読んだかの属性も本に寄せた方がログ追記も楽やろなとなる。

blog-fable/src/Booklog.fs at f4ee5cc9c3198596539d34588570619d7ba6e07a · krymtkts/blog-fable は以下のようになるはず。

    // これが
    type Booklog =
        abstract date: string
        abstract bookTitle: string
        abstract bookAuthor: string
        abstract readCount: int option
        abstract previouslyRead: bool option
        abstract pages: string
        abstract notes: string option

    // こうなるはず
    type Booklog =
        abstract date: string
        abstract bookTitle: string
        abstract readCount: int option
        abstract pages: string
        abstract notes: string option

    // NEW!
    type Book =
        abstract bookTitle: string
        abstract bookAuthor: string
        abstract previouslyRead: bool option

当初 1 ファイルにまとめたかったからそうしていたけど、結局ファイルを分けて正規化することになろうとはな。

ファーストクソコードは依然そのままだが、今やりたいことが実現できれば機能的に満足いくようになって、そこで一段落かなと考えている。あとは習慣を継続することのみに注力できそう。

booklog はじめた

Sun, 01 Sep 2024 09:00:00 +0900

先日 GitHub の Current Streak が 2 年に達したのを機に、新しい習慣 booklog をはじめた。

こちらが実装したモノで、

Merge pull request #220 from krymtkts:feature/booklogs · krymtkts/blog-fable@1e3c577 (この他にもちまちま修正を進めている)

それを使って出力したのが以下の Booklog ページだ。

krymtkts - Booklogs

正直なところ休みや空き時間でドバーッと書いたコードなので、まさにファーストクソコードと呼ぶに相応しき醜さだ。未だバグあるし、ない機能もあるし、 module 構成なんか後付感すごく元の奴らと調和してない。ただブツさえ生成できるようになればあとは改善やバグ修正は容易いので、まずはモノができたことを祝いたい。

わたしの booklog は今のところカレンダーの生成と 1 年毎のページに booklog がまとめられるのみだが、今後は tag やタイトルでまとめたページを作るのも良さそうだなと考えている。特に書籍ごとのグルーピングは工夫すれば書評になるよなと思っている。小言の羅列で連続性がないかも知れないけど、そこはまとめてみてのお楽しみ。

あといくつか実装前に想像していたことに対して実際どうなったのか書いていく。

あと自分に習慣を刻み込むにあたり、 GitHub の activity の heatmap みたいなの(calendar chart とかいうらしい)、日本で例えるなら夏休みに体操の判子押してくれるカレンダーみたいなのがあればめちゃくちゃ強制力があるのは、 Current streak の経験からわかっている。なのでそういう形式の book log を自分でこしらえようと思いついた。

この通りなので booklog のカレンダーを作るにあたって見た目 GitHub の Activity を参考にした。やはりアノ見た目は継続中毒者の心を鷲掴みにするので取り入れたかった。とはいえこちらは静的ページなので、あちらのような click した日のデータを動的に読み込む機能はない。代わりに 1 年間の booklog が日付降順で一覧されているので、その日付に飛べる。

このカレンダーの実装は GitHub Copilot や ChatGPT に投げつけたらすぐできるやろと高をくくっていたのだが、コイツラ全然満足なコードを出せなかった。細かい箇所では彼彼女らのコードが使われた箇所もあるが、結局大部分で自ら書いた。おかげで？愛着のあるものになった。早くゴチャついた部分のコードもキレイにしてあげたい。

この booklog のカレンダーだが、 Archives のページで post と page の記録日見れてもいいかもなと思ったが、週末しか書かないと悲しいカレンダーになるので今んところはナシかな。

そういう SaaS を使うのも良いが、やはりデータが自分の手元にないのは良くない。 plaintext に保存したデータから calendar chart が描けて、ついでに memo や読んだ回数、回数がわからなくても昔読んだことがあるかとかの属性も残せるやつ。

booklog のデータの保存形式は以下のような YAML 形式にした。いくつかの省略可能な属性を省いている。

- date: 2024-08-19
  bookTitle: Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう
  bookAuthor: Scott Wlaschin
  pages: vi ~ 5
  notes: |
    冒頭を読んだだけ。なんとなく丁寧な印象を受けた。

F# 側の厳密な型は以下のようにしている。 blog-fable/src/Booklog.fs at ea7bec057edd5f9ec1420318e4627bf42ecd965d · krymtkts/blog-fable

    type Booklog =
        abstract date: string
        abstract bookTitle: string
        abstract bookAuthor: string
        abstract readCount: int option
        abstract previouslyRead: bool option
        abstract pages: string
        abstract tags: string ResizeArray option
        abstract notes: string option

readCount を記録できるようにしてみて、かつ回数を覚えてないようなものは previouslyRead で前読んだことがあるのを意思表示する。 readCount はそのままの数字が印字されるが、 previouslyRead を入れてると n+1 のような印字になる。 notes は無駄に Markdown で書けるようにしてある。技術書を読んでると感想にも code を書きたくなるので、ほぼそのためだけ。あとあんまりにもおもんない本であれば notes を書くこともないかなと思い option とした。 tag は先述の通り未だ実装してないが事前に定義しておいた。

book log ができるまでは素朴に Markdown にでも記録していって、モノができたら変換して取り込むようにしてみようかな。

毎日更新するので気軽にかける形式が良いし、 krymtkts/blog-fable には既に front matter のデータを取り込むための YAML パーサ eemeli/yaml があったので、 YAML にした。 TOML も好きなのだけど、連続した要素の記述でカッコを書くのだるそうやなとか、複数行の文字列も面倒そうかなとか思い、やめた。実際 2 週間ほど booklog をつけてきたが YAML ならかなり楽に更新できる。まだ GistPad からの更新はしてない(commit sign がつかないのが潔癖症に引っかかる)けど、いつかやる日が来るはず。そうなればほぼメモ更新間隔で booklog をつけれるようになる。

理想的には bookTitle と bookAuthor は別のデータで管理してそれに参照するのが良いが、 1 ファイルに booklog を追記するだけで良いという利点を損なうので正規化していない。書くときは愚直に前の booklog をコピペし展開していく運用にしている。でもコピペと言っても毎回同じデータを書くのもダルいので、いつか省略できる仕組みは導入したい。

あと Fable のプログラミングが久しぶりだったので地味に Fable から Node.js の eemeli/yaml 使うのでハマった。 ResizeArray じゃないと array がマッピングされない点。これで無駄に時間を溶かしたが次忘れないように note を残せたからヨシとする。

    let parseBooklogs (str: string) =
        // NOTE: requires to define as ResizeArray to convert from raw JavaScript array.
        let bs: Booklog ResizeArray = Yaml.parse str

        bs |> List.ofSeq

モノがないとあんまり続けられる気がしないけど、習慣化の道筋はできたのでなんかいけそうな気がしてきた。

これについては booklog 機能をブログに実装すると決めたときから、書いておかないと booklog カレンダーを華やかすことができないという強制力が働いて、機能が出来上がるまでの間も習慣を続けられた。機能なくても良かったのかも知れんが、長期になったら続かなかっただろうし多分必要だった。これは必然やな。

ちまちま booklog の実装してた間は krymtkts/pocof を放置してたけど、今後はそんな集中していじることもないと思うので、まずリリースから再開しよう。と言いつつこの日記をしたためている間にバグを見つけた。実装してない機能もあるし、 pocof にはもう少し待ってもらうのが良いか、あるいは行ったり来たりが良いか。気分と相談してやること決めていく。

Terminal-Icons のよくわからないエラーを解決する

Sun, 25 Aug 2024 09:00:00 +0900

ちょっと前から、 pwsh 起動時の profile 読み込みでエラーが出るようになった。

どうも出どころは Terminal-Icons みたい。 $ErrorView = 'DetailedView' にして $Error で表示した内容は以下の通り。

Exception             :
    Type        : System.Management.Automation.RuntimeException
    ErrorRecord :
        Exception             :
            Type    : System.Management.Automation.ParentContainsErrorRecordException
            Message : Index operation failed; the array index evaluated to null.
            HResult : -2146233087
        CategoryInfo          : InvalidOperation: (:) [], ParentContainsErrorRecordException
        FullyQualifiedErrorId : NullArrayIndex
        InvocationInfo        :
            ScriptLineNumber : 3416
            OffsetInLine     : 5
            HistoryId        : 1
            ScriptName       : C:\Program Files\PowerShell\Modules\Terminal-Icons\0.11.0\Terminal-Icons.psm1
            Line             :     $userThemeData.Themes.Icon[$userIconTheme.Name] = $userIconTheme

            Statement        : $userThemeData.Themes.Icon[$userIconTheme.Name] = $userIconTheme
            PositionMessage  : At C:\Program Files\PowerShell\Modules\Terminal-Icons\0.11.0\Terminal-Icons.psm1:3416 char:5
                               +     $userThemeData.Themes.Icon[$userIconTheme.Name] = $userIconTheme
                               +     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            PSScriptRoot     : C:\Program Files\PowerShell\Modules\Terminal-Icons\0.11.0
            PSCommandPath    : C:\Program Files\PowerShell\Modules\Terminal-Icons\0.11.0\Terminal-Icons.psm1
            CommandOrigin    : Internal
        ScriptStackTrace      : at <ScriptBlock>, C:\Program Files\PowerShell\Modules\Terminal-Icons\0.11.0\Terminal-Icons.psm1: line 3416
                                at <ScriptBlock>, C:\Program Files\PowerShell\Modules\Terminal-Icons\0.11.0\Terminal-Icons.psm1: line 3414
                                at <ScriptBlock>, C:\Users\takatoshi\OneDrive\Documents\PowerShell\Scripts\PSResource\PSResource.psm1: line 27
                                at <ScriptBlock>, C:\Users\takatoshi\OneDrive\Documents\PowerShell\Microsoft.PowerShell_profile.ps1: line 18
                                at <ScriptBlock>, <No file>: line 1
    TargetSite  : System.Object CallSite.Target(System.Runtime.CompilerServices.Closure, System.Runtime.CompilerServices.CallSite, System.Object, System.Object, System.Object)
    Message     : Index operation failed; the array index evaluated to null.
    Data        : System.Collections.ListDictionaryInternal
    Source      : Anonymously Hosted DynamicMethods Assembly
    HResult     : -2146233087
    StackTrace  :
   at CallSite.Target(Closure, CallSite, Object, Object, Object)
   at System.Dynamic.UpdateDelegates.UpdateAndExecute3[T0,T1,T2,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2)
   at System.Management.Automation.Interpreter.DynamicInstruction`4.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
CategoryInfo          : InvalidOperation: (:) [], RuntimeException
FullyQualifiedErrorId : NullArrayIndex
InvocationInfo        :
    ScriptLineNumber : 3416
    OffsetInLine     : 5
    HistoryId        : 1
    ScriptName       : C:\Program Files\PowerShell\Modules\Terminal-Icons\0.11.0\Terminal-Icons.psm1
    Line             :     $userThemeData.Themes.Icon[$userIconTheme.Name] = $userIconTheme

    Statement        : $userThemeData.Themes.Icon[$userIconTheme.Name] = $userIconTheme
    PositionMessage  : At C:\Program Files\PowerShell\Modules\Terminal-Icons\0.11.0\Terminal-Icons.psm1:3416 char:5
                       +     $userThemeData.Themes.Icon[$userIconTheme.Name] = $userIconTheme
                       +     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    PSScriptRoot     : C:\Program Files\PowerShell\Modules\Terminal-Icons\0.11.0
    PSCommandPath    : C:\Program Files\PowerShell\Modules\Terminal-Icons\0.11.0\Terminal-Icons.psm1
    CommandOrigin    : Internal
ScriptStackTrace      : at <ScriptBlock>, C:\Program Files\PowerShell\Modules\Terminal-Icons\0.11.0\Terminal-Icons.psm1: line 3416
                        at <ScriptBlock>, C:\Program Files\PowerShell\Modules\Terminal-Icons\0.11.0\Terminal-Icons.psm1: line 3414
                        at <ScriptBlock>, C:\Users\takatoshi\OneDrive\Documents\PowerShell\Scripts\PSResource\PSResource.psm1: line 27
                        at <ScriptBlock>, C:\Users\takatoshi\OneDrive\Documents\PowerShell\Microsoft.PowerShell_profile.ps1: line 18
                        at <ScriptBlock>, <No file>: line 1

Terminal-Icons.psm1 のここでエラーが出てる。 the array index evaluated to null. とのことなので $userIconTheme.Name が $null であると。んなアホな。

# Load user icon and color themes
# We're ignoring the old 'theme.xml' from Terimal-Icons v0.3.1 and earlier
(Get-ChildItem $userThemePath -Filter '*_icon.xml').ForEach({
    $userIconTheme = Import-CliXml -Path $_.FullName
    $userThemeData.Themes.Icon[$userIconTheme.Name] = $userIconTheme
})

なんじゃー？と思ったら自分の icon テーマ krymtkts の名称が取れてないっぽい。なんでよ。更に追うと krymtkts.psd1 から生成される $env:APPDATA\powershell\Community\Terminal-Icons\krymtkts_icon.xml で Name 要素がダブってた。 krymtkts_icon.xml の場合は先頭と末尾にふたつ Name 要素のセクションができてた。以下再現イメージ。

<Objs Version="1.1.0.1" xmlns="http://schemas.microsoft.com/powershell/2004/04">
  <Obj RefId="0">
    <TN RefId="0">
      <T>Deserialized.System.Collections.Hashtable</T>
      <T>Deserialized.System.Object</T>
    </TN>
    <DCT>
      <En>
        <S N="Key">Name</S>
        <S N="Value">krymtkts</S>
      </En>
      <En>
        <!-- 省略 -->
      </En>
      <En>
        <S N="Key">Name</S>
        <S N="Value">krymtkts</S>
      </En>
    </DCT>
  </Obj>
</Objs>

このように Name 要素がダブってると値が $null になってだめみたい。

$x = Import-CliXml $env:APPDATA\powershell\Community\Terminal-Icons\krymtkts_icon.xml
$x

# Name                           Value
# ----                           -----
# Name                           krymtkts
# Name                           krymtkts
# Types                          {[Directories, System.Collections.Hashtable], [Files, System.Collections.Hashtable], [Directories, Sy…

$x.Name -eq $null
# True

なんでこれが発生して解消の仕方わからんので、とりあえず krymtkts_icon.xml 末尾の Name をコメントアウトし profile 再読み込みで Terminal-Icons を再度 import したら、ダブらずに生成されるようになった。起動時に正常な theme は Export-CliXml されてて、そこでコメントが消えてきれいになったみたい。

流れとしては、 Import-Preferences が prefs.xml に設定された CurrentIconTheme を読み込み、そのあと問題なければ Export-CliXml で保存される。はじめは途中で Terminal-Icons.psm1 がコケるため保存までいかなかったが、コメントアウトしてエラーが無くなり krymtkts_icon.xml が補正された結果が保存されたと。

解せんのは、何故このエラー原因となった Name の重複が発生したか、というところ。元ファイルが変わってないのと Module 自体も変わってないのを考えたら、壊したのは Export-CliXml よなー。 *_icon.xml が壊れるという意味で似たような Issue はあれど、今回のケースでは XML の syntax がが壊れることはなかったしなんかよくわからん。

Getting error on importing the terminal icons module · Issue #121 · devblackops/Terminal-Icons

ちょっとよくわからんので追いきれない感じがしたが、暫定的でも対処法がわかってよかった。

GitHub streak 2 years

Sun, 18 Aug 2024 09:00:00 +0900

夏休みという名の 1 週間の休みの内に krymtkts/pocof の細かな開発を結構できたのだけど、きょうはもうすぐ 2 年を迎える Github の Current streak について書く。

2022-08-22 から Current streak が続いてるので、来たる 2024-08-21 で 731(閏年を含む) 連続になって 2 年間続けたことになる。 365 に至るまでの 1 年目は、継続するためのちょっとした頑張りが今よりも必要だったように思う。でも 2 年目ともなると習慣が定着してきて、適切な言葉が見つからないが惰性のようなもので継続する心理的負担は減ったように思う。単純にサンクコストバイアスをポジティブな方向に使えてるってだけかも知れんけどな。積み上げを壊すのが怖い的な。しらんけど。

日常的ではない終日束縛されるようなイベント、例えば旅行だったり法事に行ったときでも、普通にプログラミングしたり日記を書いて普通にコミットできるようになった。何か他のことをやってるときに頭の中にあれやろこれやろが浮かんでて、それを移動中とか空いた時間で commit する(ただし両手が塞がっていない場合に限る)。事実、家事の合間に laptop のところに行って数分でまた料理作りに戻ってとか、毎週末よくやってる。以前は意識的にやっていたこと、例えば何を commit するか日記に何書こうかどうしよう等を考えるの自体は無くなってないけど、それらを浮かばせておく行動が生活に溶け込んでるから何とも思わなくなったと認識している。

でも未だたまに多忙だったりすると「あー、なんか commit しないと途切れるな」みたいな感じで継続することが意識に上がってくる状態なので、これが息をするように commit するようになってくれば、自分でも胸張ってある境地に達したと言えるかな。「面倒くさいけど今日も commit したわ」「気付いたら commit してたわ」みたいな。自分でも狂ってるなと思えるところまで行きたい。既に家族からはいつも laptop のところを行き来してて頭おかしいと思われてる可能性もあるけど。

思えば、昔から何かをずっと続けることが得意なのかも知れない。流行りが終わったゲームも延々 1 人でプレイし続けてたりしてた。気に入った映画は何度も観れるし、読んだ事がある本を何度も読める。太く短い瞬発力ある取り組みは苦手(疲れる)だが、薄く延々と続くようなの、そういうのが多分向いてる。エンジニアの知人だったりバンドメンバが「モチベーションが...」とか言うて活動を休止したりするのも理解できないことが殆どなので、多分わたしの脳みその中のブレーキが壊れてる。それはある意味走り出したら止まれない暴走特急なのかも。こういうのはもっと若い頃に気づきたかったな。年食って経験増えたから気づいたのかも知れんけど。

2 年間 GitHub の Current streak を続けたあと、 Current streak の次のマイルストンはやっぱ 4 桁突入の 1000 かなと思うが、そこまでの距離はもう遠くない。自分が死なない限り、毎日積み上げていったら 2025-05 には達成することになるので、歩いてきた道のりより短いねんよな。となると習慣化した Current streak がヌルゲーになってしまって張りがないので、他に狂気の取り組みを始められないかと考えている。 (今の Current streak を public なコントリのみに絞るというのもアリだろうがそれは普通に続かなそうｗなので時期尚早と見た)

今年の目標にあるものから選ぶなら、ずっと習慣化に失敗している読書がいいかな。これは何度も書いてる話ではあるが、通勤がなくなって読書への強制力がなくなり、読書習慣が失われてしまった。親切な知人エンジニアが月に数回輪読会を一緒にやってくれていて、そこでなんとか最低限の読書をしているが、理想はもっと狂ったように読書したい。

これは言い訳だが、最近は調べ物が多くて Web の文書とかを読みまくる¹ので文字で胃もたれして読めなくなってのはあるかも知れん。そもそもの食 ≒ 読書量が細ってるから自主的な読書が受け付けれなくなったんじゃないかと感じている。そういう状況だったのもあって最近は積読を増やさないような本の買い方になってたのだけど、また習慣化した暁には昔みたいに積極的に積読していきたい。 (増えるだけだと物理本の場合はほんと場所に困るので適切に陳腐化した書籍だったりを処分するのも含めてやりたい)

単に食が細ってるだけナノだったら、毎日少しずつリハビリしていけばまたモリモリ食べれる様になるかも知れんよな。とりあえず 1 日に数ページでいいから、読み始めてみようか。

あと自分に習慣を刻み込むにあたり、 GitHub の activity の heatmap みたいなの(calendar chart とかいうらしい)、日本で例えるなら夏休みに体操の判子押してくれるカレンダーみたいなのがあればめちゃくちゃ強制力があるのは、 Current streak の経験からわかっている。なのでそういう形式の book log を自分でこしらえようと思いついた。そういう SaaS を使うのも良いが、やはりデータが自分の手元にないのは良くない。 plaintext に保存したデータから calendar chart が描けて、ついでに memo や読んだ回数、回数がわからなくても昔読んだことがあるかとかの属性も残せるやつ。 book log ができるまでは素朴に Markdown にでも記録していって、モノができたら変換して取り込むようにしてみようかな。モノがないとあんまり続けられる気がしないけど、習慣化の道筋はできたのでなんかいけそうな気がしてきた。

毎日 commit し続けるとか、読書習慣を始めるのに記録方法から作ってまで読書を習慣付けたいとか、この行動が具体的な何かにつながるかはサッパリ想像もつかない。でもあんまり世間一般の人がやってなさそうなことほど楽しくなるし、その継続で磨き上げられた何かは一般のそれとは全く違うものになってるはずよ。

これが現職での仕事がそうなのか時代が変わったのかは検証してない ↩

F# で Cmdlet を書いてる pt.47

Sun, 11 Aug 2024 09:00:00 +0900

krymtkts/pocof 開発をした。

前回に引き続き Query.run 自体の最適化をしている。いつ終わるんだよ。

#208 、 #209 でコツコツ改善？してみた。わたしの laptop で 1 ~ 10 万までの数字から 1 つ選ぶのに 4 秒切りたかったがそこには達せず、伸びも見られなくなってきた。単純な検索についてはそうなんやけど、プロパティ検索時においては修正前後で null の扱いがめちゃくちゃ雑なママ放置してて例外処理に任せてた部分を適切に取り持ったことで爆発的に速くなった。他にもプロパティ検索周りはまだ改善の余地があるので、後ほど処置したい。

判別共用体を構造体に置き換える最適化は、適用しどころを間違ってたみたい。 Data.Entry を構造体にしても効果なかった。直感が外れたのは単純に理解が間違ってたからで、変更頻度が高い使い捨てのデータに対してこのアプローチをすべきだったからだ。 Data.Entry はオブジェクトの生成頻度こそ高けれど、一度生成されたあと変更されることがなく、アプリが終了するまで永続的に保持される。そのため構造体が適しておらず最適化に貢献しなかったという理解だ。代わりに processQueries 内でのみ利用される QueryResult に対して利用した。繰り返し生成されて関数内で利用されるのみでまさに使い捨て用途がハマってる。でもそんな爆発的な効果は出てなくて少し残念。

実は最近のこの最適化で結構バグってるみたいで、細かく見れていなかった箇所のテストケースを追加するなどもしている。その中で Operator.None もう要らんのちゃうかないう気が湧いてきたので、今後取り除いていくつもり。先述した最適化に伴うバグには、この Operator.None の挙動が変わってしまってるのも含まれる。 Operator.None を取り除いたことでロジックが簡略化されれば多少最適化にも貢献するだろう的なことも期待している。

元々空白を含めて検索したい場合に正規表現気にせず使えたらいいかなと思って準備したけど、キーワードの組み合わせで絞り込むことが多くてほぼ使わんし。作った本人が使いこなせていないというのは恥ずかしい話やが、不要だと思った時に機能を取り除けるのは作った本人しか無理なので、この際やってしまう。

結構この最適化周りで修正重ねてるけどいまいちリリースしていいかなって思える状態にならない。はよ出したいけど次の v0.15 を出すのはもう少し先になりそう。

F# で Cmdlet を書いてる pt.46

Sun, 04 Aug 2024 09:00:00 +0900

krymtkts/pocof 開発をした。

前回に引き続き Query.run 自体の最適化をしている。

ちまちまと変更を加えて、もとよりは多少速くなってそう。わたしのしょぼい 2017 年製 laptop で 1 ~ 100000 までの数字から 100000 を探し出すのに 5 秒前後かかっていたのが、 4.5 秒前後になったぽい。ほんまかー？という感じではあるが、実際に数を増やして 1 ~ 500000 までの数字から 500000 を探し出してみても修正後の方が 2 ~ 2.5 秒速いので、効果は確かなようだ。

前回の修正も含めて行った最適化は、 inline 化や List を末尾再帰に置き換えるといった簡単なものだけだ。それでも noob F# ninja のわたしには多くの気付きがあった。 inline をつけた関数であっても関数合成を使うと inline 化されないので pipeline を使う必要があるとか。

また特定のケースでは末尾再帰が List より速いようで、少し驚いた。 List は結構速いモノの認識だったが、更に突き詰めた局所最適化だと末尾再帰という primitive な形に落ち着くねんな...という気づきを獲た。まーでもどの言語でも配列やリスト構造をそれ用の関数でグルグル回すよりは単純なループのほうが速いこともあるし、そういうことなんやろなという認識(末尾再帰は loop に最適化されるため)。

判別共用体を構造体に置き換えるとかのより踏み込んだ最適化はまだやってない。まだただの直感だが、 Data.Entry を構造体にしたら、処理するデータ件数が大きいほど効果があるのかもなと思っている。この手法は確か bcarruthers/garnet を見つけたときに知ったのだったが、 pros. cons. あり検証を要するのでインスタントにできるものではそこに踏み込むにはまだやっていないことがあるので、計測・検証して順次試していくつもり。

他にも F# の最適化の手段は色々あるようで、 F# performance tips でググった上位 3 つを読むだけでもお腹いっぱいになってしまった。全部は消化しきれないので地道に .NET のプロファイリングから学んでいくか。ここ 1 月くらいで ILSpy を使い始めたのだけど、更にツールが増えるのかな...

因みに GitHub Copilot や ChatGPT に聞いても似たような回答をくれるが、(文脈理解してるはずなのに)一般的な話をされて pocof の文脈にそぐわないような回答をいただくばかり。なので、この件に関してはあまり使い物になってない(プロンプトが悪いのかも知れんが)。リスト処理を末尾再帰に変えてくれとか具体的な指示になったら元気に回答くれるけど(微妙に間違ってるけど)。

Writing high performance F# code
- これはレイヤが低めで .NET の理解度が求められ難しめ
Real life performance optimizations in F# - DEV Community
- これはかなり簡単な部類
performance - How to optimize F# programs generally - Stack Overflow
- まとめみたいなやつ。辿るのがダルい

まだやっていないことの 1 つは今対処中で、 Query.run が実行されるときに行われていたリストを取り除くことだ。これは検索条件を List に詰め込んでいたところを残していたので、そこを判別共用体で作った自作の連結リストに変えるものだ。これも多少速くなったようだ。教科書的な木構造の実装なんかで見た判別共用体の連鎖を普通に実用レベルで使えるねんなというのは気付きやな。

#209

     [<RequireQualifiedAccess>]
     [<NoComparison>]
+    [<NoEquality>]
     type QueryPart =
-        | Normal of value: string
-        | Property of lowerCaseName: string * value: string
+        | Normal of is: (string -> bool)
+        | Property of lowerCaseName: string * is: (string -> bool)
+
+    [<RequireQualifiedAccess>]
+    [<NoComparison>]
+    [<NoEquality>]
+    type QueryNode =
+        | Part of head: QueryPart * tail: QueryNode
+        | End

今はこんな風に変えてて、まだちょっとイマイチ。 QueryPart と QueryNode は分ける必要ないかなと思っているところ。元は検索条件の値だけを持った List を取り回して、 Query.processQueries 自体が引数に持つテスト関数で条件に一致しているか見ていた。これを検索条件の関数を持った連結リストにして、 Query.processQueries 自体はテスト関数を持たなくさせる。これは、今 Regex.IsMatch を使ってキャッシュされることを期待している部分を、事前にコンパイル済みのパターンを使うようにしてるための前準備でもある。これも効果あるかは試さないとわからない。現時点でキャッシュが効いてるのであれば多分変わらないのじゃないかなと思っている。

これまでの改善同様に爆発的な効果は出てないけど、地道に試行錯誤してく予定。

F# でコマンドレットを書いてる pt.45

Sun, 28 Jul 2024 09:00:00 +0900

krymtkts/pocof 開発をした。

前回のバグ対応を v0.14.1 としてリリースして以降、 pocof をパフォ改善する開発はあんまうまく進んでいない。そろそろ真面目に profiling すべきなんかも。 .NET 門外漢過ぎてわからん。

pocof の最適化については前にも触れてるが、当初 Trie や Suffix Tree を使って事前に検索しやすい形を構築しようかと考えていた。けど、これを全プロパティ + 文字列化されたオブジェクト分で構築すると空間計算量がかなり高く付くので、これはどうなんかな～と思って踏ん切りがつかなかった。同時に正規表現を捨てるのも覚悟が足りず。自身の利用シーンでは最低限として中間一致だけの検索モードを提供するってのはありかもなーと思ったが、これも踏ん切りがつかず。

他にできることとして PSObject を何度も toString している箇所が重いんかなと生成回数を減らすよう変えてみたが、効果は全くなかった。

もう CPU で殴るしかないかなということで、先達である fsprojects/FSharp.Collections.ParallelSeq のアプローチを便器ょした。そこから ParallelEnumerable を使って、 pocof に足る範囲の並列可能な F# 風 sequence (追加順維持)をこしらえてみた。 #207

pocof の用途に合わせて、必要な用途に絞った最小の実装にした。 ParallelEnumerable.Where Method で filter 、 ParallelEnumerable.Count Method で length を作った。 pocof では追加順を維持するのが重要なので、 ParallelEnumerable.AsOrdered を使ってる。

AsOrdered にしたので通常の ParallelEnumerable よりパフォ劣化するせいと思うが 100 万 ~ 1000 万件位のデータ量で確認した限り普通の seq と比べて速いわけでもなく、むしろ少し遅い。それでも CPU ゴリゴリに使って頑張ってくれるのはわかるが、そこまで速くなく更に CPU 使いすぎるのもどうかな～と思えてきた。大量データのときだけ CPU 頑張ってくれるだけなのでこれは main branch へ投入したけど、あまり良くなければ戻すかも。

CPU で殴っても効果がないとなるとあとやれることはロジック自体の改善。ということで、いまは Query module の対象 object か調べる処理自体を末尾再帰で書き直して速くならんか見ている。 #208

元々は 1 object 毎にクエリの list から filter 条件の list を作り、それに対して List.exists か List.forall する形だった。そこを末尾再帰で書き換えたことで、 list の生成処理が丸ごとなくなるのもあってちょっと効果出ている。ただ結構コードの循環的複雑度が高まったので、清書する必要がある。

この 1 objects あたりの処理量を減らす方向性は間違ってないっぽいので(爆発的な効果は出てないが)、他にもできることがないか検討してみる。機能維持しつつ爆発的に速くなる方法があればよかったけど現実的にそういうのはまず起こらないので、地道に改善重ねていくしかないかな。 AND 検索しかなかったらドンドン母数を絞り込めるからクソチョロなんやけど、 pocof は親切なことに OR 検索があるから...コツコツやるかデータ構造変更しかない。非同期描画のときは結局 alpha で出さなかったので、今回の並列＆最適化こそは prerelease するタイミングなのではないかと思っている(やるかはわからん)。

続く。

Chocolatey の chocolateyInstall.ps1 が壊れている場合の workaround

Sun, 21 Jul 2024 09:00:00 +0900

わたしは長らく Windows のパッケージ管理に Chocolatey を使ってるのだけど、壊れたパッケージを無理やり直してインストールする機会があった。これはもう直ってる問題に対して「こうしましたよ」という記録を残すものだ。

壊れたパッケージというのはわたしのお気に入りの PowerToys だ。

Update PowerToys script to newer tag by jaimecbernardo · Pull Request #253 · mkevenaar/chocolatey-packages

上記は PowerToys 開発チームの dev lead の人が chocolatey package の repo に作ってくれた PR だ。親切極まりない。 PR によれば次のようにして壊れたらしい。

先日 PowerToys 開発チームでリリース時に tag を v0.82.1 が正しいところ V0.82.1 とつけてしまったらしい(tag は v0.82.1 につけ直されてた)。その影響を受けて、 PowerToy の chocolatey package を作ってくれてる人の package が自動更新なのか知らんが壊れたっぽい。

どう壊れたかというと、 chocolateyInstall.ps1 が存在しなくなったタグ V0.82.1 を指したままになった。 chocolateyInstall.ps1 は choco upgrade powertoys -y で download されてくる。要は download したホヤホヤの chocolateyInstall.ps1 が存在しない URL からバイナリを download しようとするので、常に 404 でエラーするようになった。

これだと修正が merge されないと chocolatey package が更新できない。直し方はわかってるし、自力で力技の解決できないか試したら、できた。

事前に chocolateInstall.ps1 を新しいバージョンの URL と checksum に変えておき、クリップボードにコピーしておく。 checksum は GitHub の Release ページから取れる
- Release Release v0.82.1 · microsoft/PowerToys
chocolateInstall.ps1 をエディタで開きっぱなしにしておく
choco upgrade powertoys -y を実行する
chocolateInstall.ps1 がダウンロードされ次第(≒ エディタで表示してる内容が変わったら)変更内容をコピペして即座に保存する
うまくいったらコピペで変更されたファイルを使ってバイナリのダウンロードが始まる

はじめこれでうまくいくかわからんかったので手でやったけど、これなら FAKE の ChangeWatcher や素の FileSystemWatcher で自動化できそう。こんなもん自動化してどうすねんというのはあるけど。

今回は Chocolatey の正当な仕組み全く理解せずとも、ログを追ったらこのような力技ができた。ちゃんとした仕組みに乗ったもっとマシな patch 方法ないのかなとか、この仕組みはインジェクション可能ということで危なくないのかなと思ったりした。一度 Chocolatey の流儀を学んでちゃんとした方法を調べるかー？いい加減 Chocolatey にフリーライドし続けてきたのでちゃんと仕組みを理解して貢献できたらいい気もするしな。積みタスク行き。

PowerShell Gallery に関する備忘録

Sun, 14 Jul 2024 09:00:00 +0900

先日 krymtkts/pocof のメンテをしてるときに、 PSResourceGet で response status code 999 を受け取ってびっくりした。おおよその原因がわかれば大した話ではないが、また忘れてびっくりしないように備忘のメモを残す。

2024-07-12 06:00 JST 過ぎに Dependable version updates で自動作成された PR を処理しようとした。

Merge pull request #201 from krymtkts/dependabot/nuget/test-lib-8e312… · krymtkts/pocof@95be938

特に問題なかったので自動作成された PR を merge したらなんと GitHub Actions workflow がコケた。んなあほな。ログを見てみたら Install-PSResource で response status code 999 を受け取ってるようだった。銀河鉄道かよ。わたしの浅い経験では 999 を見たのはこのときが初めてだ。

Prepare all required actions
Getting action download info
Download action repository 'actions/setup-dotnet@v4' (SHA:6bd8b7f7774af54e05809fcc5431931b3eb1ddee)
Download action repository 'codecov/codecov-action@v4' (SHA:e28ff129e5465c2c0dcc6f003fc735cb6ae0c673)
Run ./.github/actions/test
Run actions/setup-dotnet@v4
/home/runner/work/_actions/actions/setup-dotnet/v4/externals/install-dotnet.sh --skip-non-versioned-files --runtime dotnet --channel LTS
dotnet-install: Attempting to download using aka.ms link https://dotnetcli.azureedge.net/dotnet/Runtime/8.0.7/dotnet-runtime-8.0.7-linux-x64.tar.gz
dotnet-install: Remote file https://dotnetcli.azureedge.net/dotnet/Runtime/8.0.7/dotnet-runtime-8.0.7-linux-x64.tar.gz size is 31272597 bytes.
dotnet-install: Extracting archive from https://dotnetcli.azureedge.net/dotnet/Runtime/8.0.7/dotnet-runtime-8.0.7-linux-x64.tar.gz
dotnet-install: Downloaded file size is 31272597 bytes.
dotnet-install: The remote and local file sizes are equal.
dotnet-install: Installed version is 8.0.7
dotnet-install: Adding to current process PATH: `/usr/share/dotnet`. Note: This change will be visible only when sourcing script.
dotnet-install: Note that the script does not resolve dependencies during installation.
dotnet-install: To check the list of dependencies, go to https://learn.microsoft.com/dotnet/core/install, select your operating system and check the "Dependencies" section.
dotnet-install: Installation finished successfully.
/home/runner/work/_actions/actions/setup-dotnet/v4/externals/install-dotnet.sh --skip-non-versioned-files --version 8.0.100
dotnet-install: Attempting to download using primary link https://dotnetcli.azureedge.net/dotnet/Sdk/8.0.100/dotnet-sdk-8.0.100-linux-x64.tar.gz
dotnet-install: Remote file https://dotnetcli.azureedge.net/dotnet/Sdk/8.0.100/dotnet-sdk-8.0.100-linux-x64.tar.gz size is 214395068 bytes.
dotnet-install: Extracting archive from https://dotnetcli.azureedge.net/dotnet/Sdk/8.0.100/dotnet-sdk-8.0.100-linux-x64.tar.gz
dotnet-install: Downloaded file size is 214395068 bytes.
dotnet-install: The remote and local file sizes are equal.
dotnet-install: Installed version is 8.0.100
dotnet-install: Adding to current process PATH: `/usr/share/dotnet`. Note: This change will be visible only when sourcing script.
dotnet-install: Note that the script does not resolve dependencies during installation.
dotnet-install: To check the list of dependencies, go to https://learn.microsoft.com/dotnet/core/install, select your operating system and check the "Dependencies" section.
dotnet-install: Installation finished successfully.
Run Set-PSResourceRepository PSGallery -Trusted
Install-PSResource: /home/runner/work/_temp/03b13c40-34d5-4152-b471-63d55ca095a9.ps1:3
Line |
   3 |  Install-PSResource Psake,Pester,PSScriptAnalyzer -Quiet -Reinstall -S …
     |  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | 'Response status code does not indicate success: 999.' Request sent:
     | 'https://www.powershellgallery.com/api/v2/FindPackagesById()?id='Psake'&$inlinecount=allpages&$filter=IsLatestVersion%20and%20Id%20eq%20'Psake''
Error: Process completed with exit code 1.

999 について調べてみても「一般的じゃない response code」くらいしか情報が見つからない(当然)。 999 は未定義のため、一般的には内部 status code が漏れ出てるパターンぽい。過去に LinkedIn をログインせず crawling しようとしたらが 999 返ったことがあるらしい。 python - 999 response when trying to crawl LinkedIn with Scrapy - Stack Overflow これは GitHub Actions だけじゃなさそうと思い、ローカルで試してみたら同じだった。

> Install-PSResource Psake
Install-PSResource: 'Response status code does not indicate success: 999.' Request sent: 'https://www.powershellgallery.com/api/v2/FindPackagesById()?id='Psake'&$inlinecount=allpages&$filter=IsLatestVersion%20and%20Id%20eq%20'Psake''
Install-PSResource: Package(s) 'Psake' could not be installed from repository 'PSGallery'.

Install-PSResource だけでなく Find-PSResource も挙動が変だった。 Find-PSResource -Name pocof で検索しても結果を取得できないけど Find-PSResource -Name poco* だと取得できたり。なんでだよ。

これ障害かなんかやなと漸くここで気づき PowerShell Gallery を見に行ったら、ページトップに ↓ の通りの記載があった。

Individual package statistics are temporarily unavailable. More info: https://aka.ms/psgallerystatus

https://aka.ms/psgallerystatus が ↓ に繋がってる

PowerShellGallery/psgallery_status.md at master · PowerShell/PowerShellGallery

July 11th, 2024 Individual package statistics will be temporarily unavailable.
Individual package statistics will be temporarily unavailable while we are making infrastructure changes. There will be no loss of information, however statistics numbers will temporarily not update.

Status: Ongoing

この文面からは PSResourceGet が影響を受けるような雰囲気は全く読み取れなかったのだけど、絶対これやろ。 2024-07-12 08:00 JST 時点でも 999 解消できなかったので、 PowerShell Gallery のインフラ変更中の間無理なんじゃないかなと不安になった。

2024-07-12 09:10 JST にはローカルで Install-PSResource が 999 することもなくなり、 Find-PSResource もちゃんと結果を返すようになった。その後 GitHub Actions を再実行したらうまくいった。きょうこの記事をしたためてる最中も、↓ ままやけど。

July 11th, 2024 Individual package statistics will be temporarily unavailable. Status: Ongoing

いつだったか PowerShell Gallery の更新計画を PowerShell の devblogs でみた気がするけど覚え違いかな？調べてみても、最近の PowerShell and OpenSSH team investments for 2024 - PowerShell Team で新しいタイプの PowerShell の repo に触れてる程度だった。ただこう、なんやろ。もうちょっと計画的なメンテとかは開発者がわかりやすく把握できるようにならんのかなという気はする。前から Markdown 直書きなのは知ってるけど、この更新を自動で受け取るのって PowerFighter(勝手に作った PowerShell ユーザの呼び名)のみんなは自前でシステム組んでるんかな？気になる所あるが、次回似たような記事を書くときまでにはなんか進展があるといいな。

F# でコマンドレットを書いてる pt.44

Sun, 07 Jul 2024 09:00:00 +0900

krymtkts/pocof 開発をした。

前回の対応で非同期のバグが云々言ってたやつは、普通に immutable なデータ構造に起因するバグだった。ショボ。 a9e5bab

Prerelease 出すにあたり最後に解消しておきたいのが、 -NonInteractive 時に結構な確率で Pester のテスト ≒ end-to-end テストがコケるところだ。いわゆる flaky test 化してしまった。

前に書いた ↑ は検討外れで、検索可能なプロパティの一覧を保持する際の内部データに F# の Map を利用していたので、非同期で要素が追加された際に結果が反映されないというものだった。要はただの凡ミスだったわけなので .NET の非同期コレクションで置き換えて解消した。他データ読み込み中に操作がない場合の描画間隔を調整したり #198 細々とした修正を入れている。

他にも試したいことがあったのだけど、うまくいかなくて頓挫した。以下に記すのは思考の整理のためのその記録。

まず code coverage の計測を coverlet から altcover に変えてみようと思い、試してみた。 coverlet は F# が生成する IL 向けにチューニングされてないので、コード上に現れない微妙な branches のせいで coverage を落とす。↓ これ。

Multiple branch points created for F# string slice · Issue #1208 · coverlet-coverage/coverlet

そのため F# らしく書けない事がある。 altcover でそれが解消せんかな的なことを考えて試してみた。また F# の OSS を使うという点でも良い。けどデフォルト設定で altcover で計測すると pocof 以外のバイナリも検査対象になり、そのせいか実行速度が 5 倍くらいになってしまった。なんてこった。対象のアセンブリを絞る設定が要るようだ。でも設定してみても速くなったり F# の IL に最適化される確証ないなーと思ったのでこれは今のところナシとした。 sandbox で試してみてから pocof に導入できるか検討するのがまともな判断かな。

次に pocof で大量データを操作すると遅い件に関する対応だ。この対応として非同期で描画して遅く感じさせない改良を入れてきたけど、肝心の検索自体は速くなってない。内部データの seq (実際は ConcurrentQueue) に対して正規表現で検索し、件数を数えるので、時間計算量が O(N) かかってる。もちろん件数を数えるときにも O(N) かかってる。

コレクションを分割して Task で並行処理したら速くならんかなと試してみたが更に遅くなった。元々 CPU bound な処理だから並列じゃない限り速くならんのよな。そもそも内部データの seq を分割する Seq.chunkBySize や処理後の Seq.concat で O(N) かかるし。ただこの過程で Array.Parallel や F# Parallel Sequences を知ったので、なんか参考にできるのかも知れない。

他の方法として内部データ構造の変更が思いつくので、 ChatGPT や GitHub Copilot に相談してみた。彼らは初め「Trie にしたらいいやん」って言ってきた。プロパティ毎に Trie 作成するってことかあ？と思ったので、でも「 1 億要素あって PSObject の任意のプロパティに対して正規表現の検索が可能でないとあかんねんけど...」と伝えたら「それはデータ構造だけやと理論的に難しいで」とのことだった。そら難しくなかったらお前に相談せんやろ...とりあえず検索パターンごとの最適化みたいなのを先に試してみるべきなのかも知れん。

例えば AND 検索であれば、クエリが追記されていく限りはそれより前の絞り込み結果に対して検索する方が少ない N 減で済むから速くなるとか。でもこの方針だと、 OR 検索の場合や非同期コレクションが更新された場合は常に全体を検索せねばならず、どうにもならんけど。 pocof は無駄にリッチに AND 検索と OR 検索ができて、正規表現とワイルドカードのどちらでも検索もできるため、打つべき手段も色々ややこしいことになってる。他に、検索機能を database なんかの外に出してみたらどうかとも思いつくが、なんか負けた気がするからそれは却下。自前の何かで解決したい。今のところ、全列に索引が貼られたテーブルみたいな如何にもメモリ食いそうな構造しか思いつかないので、なんか探求してみる。

そもそもの話、生の seq や ConcurrentQueue の件数を取ってみてもそんな爆発的に遅くないねんよな。つまり pocof で入れてる実装に起因して遅い可能性も微レ存だと。 PSObject を文字列にするあたりだとか、存在するかわからないプロパティに reflection でアクセスするあたりだとか、なんか PSObject の取り扱いが難しいんじゃないのこれ。前にプロパティ一覧取ってメモリ爆食いしてたやつを思い出した。

まだまだ伸びしろがあるということで一旦の締めとする。結構直してきたので、この初の非同期描画版になった pocof はもういい加減リリースしたいな(何度目)。

F# でコマンドレットを書いてる pt.43

Sun, 30 Jun 2024 09:00:00 +0900

krymtkts/pocof 開発をした。

前回の対応で非同期で読み込みながら即座に対話式 CLI を起動するようにはなったが、バグ・未対応や TODO が散見されるのでボチボチその対処をしていた。 Prerelease したいなといっていたが、自分で日常的に使うまでもなくなんかイマイチなところがあったので延期して、ちまちまと直している。やることが多いので pull request も小分けに切らず、このへん #191 #192 #195 で大雑把に対応をしている。 ProcessRecord 中に操作がなくても描画をリフレッシュする実装も雑だが仕込んだ。もうちょいで Prerelease 出せそうな気がする。

Prerelease 出すにあたり最後に解消しておきたいのが、 -NonInteractive 時に結構な確率で Pester のテスト ≒ end-to-end テストがコケるところだ。いわゆる flaky test 化してしまった。 pocof はクロスプラットフォームを謳っておるのもあり、テストランナーが Mac, Linux, Windows だが、コケるのは大体 Mac か Windows だ。なんでだよ。 interactive mode を模倣した unit test はコケないので、非同期の対応で -NonInteractive によるバグを生んでしまってるのはほぼ間違いないやろなとみている。ただ調べるのめんどくさい上位に君臨する非同期系バグの可能性もあり、対処を後回しにしてきた。だがついに対峙せなばならんときが来たのだろう。

他はコツコツ課題を解消できてきた。 #195 で StopUpstreamCommandsException を投げるあたりのコードを mock 可能にしてテストを通せるようにしたり。 xUnit でテストしてると StopUpstreamCommandsException を reflection で拾おうにも null になりエラーでテストできなかった。他にテストする方法がないか考えてたが、結局シンプルな挿げ替え方式を採用した。 StopUpstreamCommandsException の代わりに Exception を継承した mock に挿げ替えてテストを通せる。 pocof は依存関係なしの縛りプレイなため DI のライブラリを持ってないので、テスト時に手動で挿げ替える。

同様の方法で Console.ReadKey 等に依存していた箇所を挿げ替え方式にしたことで、 code coverage もステップレベルだと四捨五入 98 % まで引き上げた。良い感じ。いつか 100% 到達したいな。

余談だが、よくビジネスのシステム開発の文脈に於いては「code coverage は 8 割強に落ち着く」という人が多いけど、個人プロジェクトにおいては当てはまらない。好きでやってるから、コストとのバランスを度外視できる。 coverage も縛りプレイの追求ポイントなので、どこに落ち着くという概念は存在せず、ただ突き詰めるのみｗ

閑話休題、テスト可能な構造にするにあたり、 Cmdlet を継承した型に abstract method を追加した。元々使っていたテクニックだが、 default implementation を override で変えることで、テスト時に狙った挙動をさせられる。今回対応範囲を増やしたことで、ほぼ Cmdlet の動作パターンを模倣できるようになった。例えば以下は、 StopUpstreamCommandsException で Cmdlet の record processing のフローを抜けるパターンを模倣している。便利や。

    type SelectPocofCommandForTest() =
        inherit SelectPocofCommand()

        member val Host: PSHost = new Mock.Host()
        override __.Invoke(input: 'a seq) = input |> Seq.map string
        override __.PSHost() = __.Host

        override __.ConsoleInterface() = new MockConsoleInterface()

        override __.GetStopUpstreamCommandsExceptionType() = typeof<MockException>

        // NOTE: emulate the Cmdlet record precessing flow.
        member __.InvokeForTest2() =
            __.BeginProcessing()

            let mutable loop = true

            while loop do
                try
                    Thread.Sleep 50
                    __.ProcessRecord()
                with :? MockException as _ ->
                    loop <- false

いいことづくめのようだけど、これによって以前こしらえた interface が必要なくなったんじゃないかなとか、構造的に気になる点でてきたので、そこは新たな TODO として積まれた...

何にせよ、早々に Prerelease 出したい。

blog-fable に pagefind による検索を追加する

Sun, 23 Jun 2024 09:00:00 +0900

krymtkts/pocof 放置気味だが、今日も krymtkts/blog-fable の話を書く。

このブログは結構自身の備忘のために役立っている。例えば chocolatey で OpenSSH をインストールするオプションを確認するときのような、たまにしかやらないことを探すのにとても役立つ。ただ書くときは探しやすさに注意を払わずタイトルを書いてることもあって、どこに書いたか忘れて、あとからそういった情報を探すのにいちいち数記事読み返すときもある。そんなときは検索機能が欲しくなるのだけど、あんまり日本語がいい感じで、軽量な静的コンテンツの検索ってなさそうだったので放置していた。

でも最近 pagefind の日本語が良くなってきていると知り、また導入も簡単だということなのでやってみた。

blog-fable に pagefind を導入するのに以下を行った。

task runner に pagefind の実行を追加する
検索を最適化するための設定を作成し、 metadata を追加する
pagefind UI の初期化コードを仕込む
pagefind UI のスタイル調整する

task runner に `pagefind` の実行を追加する

まず pagefind の実行だが、やり方は至極簡単。概ね pagefind の文書に書いてあるとおりに index を構築して GitHub Pages に deploy したらいいだけ。

Running Pagefind | Pagefind — Static low-bandwidth search at scale

当然静的コンテンツの作成後出ないといけないので、コマンドの実行順にだけ気をつけたらいい。こんなふうにした。元々 build task に引数を渡して開発と本番を切り分けてたが、直接引数を渡すと最後尾の build-index に適用されてしまうため、仕方なく分割した。

  "scripts": {
    "postinstall": "dotnet tool restore",
    "build-fable": "dotnet fable src --test:MSBuildCracker --runScript",
    "build-md": "node ./src/App.fs.js",
    "build-css": "sass --style=compressed --no-source-map ./sass/style.scss ./docs/blog-fable/css/style.css",
    "build-index": "pagefind",
    "build": "npm run build-css && npm run build-fable && npm run build-index",
    "build-dev": "npm run build-css && npm run build-fable dev && npm run build-index",
    "serve": "dotnet fsi ./dev-server.fsx /blog-fable",
    "dev": "npm run build-dev && npm run serve"
  },

検索を最適化するための設定を作成し、 metadata を追加する

次は重要な点で、静的コンテンツからどう index 構築するかの設定する必要があった。デフォルトだと何もかも indexing してしまうので、どの要素で構築すべきか、どのパスで構築すべきかの設定しないと検索のノイズがすごかった。幸い pagefind は設定ファイルをサポートしているので、このような面倒な設定はすべてファイルにまとめられる。こんなふうにした。

site: ./docs/blog-fable
root_selector: .content
keep_index_url: true
glob: "{posts,pages}/*.html"

site は対象となる静的コンテンツのディレクトリ。 glob で指定するパターンと組み合わせて対象の静的コンテンツを指定できる。 blog-fable は posts/ pages/ 以外を対象にしたくない(404 だったり archives だったりは不要)のでこのオプションがなかったら終わってた。

blog-fable では root_selector を使ったが、文書では data-pagefind-body を使うべきで root_selector は余り使う必要ないと書いてあった。ただ blog-fable は Markdown から翻訳された HTML はすべて .content 配下に出力されるので、むしろこのオプションの方がハマっていた。一箇所だけ front matter なし page だと title 要素を拾えなかったので、しゃーなしで metadata data-pagefind-meta="title" を追加した。こんなふうに。

                let meta = if l = 2 then " data-pagefind-meta=\"title\" " else ""

                $"""<h%d{l} %s{meta}><a name="%s{escapedText}" href="#%s{escapedText}">%s{text}</a></h%d{l}>"""

keep_index_url は index.html を取り除くかどうか。 blog-fable では top page 以外にないので不要だが、万が一当てはまるパターンが増えたときに加工されるのはかなんのでつけた。

pagefind UI の初期化コードを仕込む

次はサイトで検索を使うための初期化コードを仕込む。オプションの指定で検索に表示される文言を変えたりするので、指定項目は多いが一通り指定するのが無難だろう。

ここで注意すべき設定項目は baseUrl の指定だ。 blog-fable のような GitHub アカウントの page じゃない場合 URL が https://${account}.github.io/${repo-name}/ となる。そのためそれに合わせて baseUrl を設定する必要がある。このブログなら GitHub アカウントの page なので "/" で、 blog-fable は "/blog-fable/" だ。

あと blog-fable 固有の対応として、初期化の JavaScript を F# に翻訳する必要がある。 Sample のコードをこんなふうにした。

type PagefindUI =
    [<Emit "new $0($1, $2)">]
    abstract Create: obj -> unit

[<Global>]
let PagefindUI: PagefindUI = jsNative

window.addEventListener (
    "DOMContentLoaded",
    (fun _ ->
        let elm = document.querySelector "#search"

        if isNull elm then
            ()
        else
            PagefindUI.Create(
                !!{| element = "#search"
                     baseUrl = "/blog-fable/"
                     pageSize = 5
                     translations =
                      !!{| placeholder = "Search"
                           clear_search = "Clear"
                           load_more = "More"
                           search_label = ""
                           zero_results = "\"[SEARCH_TERM]\" now found."
                           many_results = "\"[SEARCH_TERM]\" ([COUNT])"
                           one_result = "\"[SEARCH_TERM]\" ([COUNT])"
                           searching = "Searching \"[SEARCH_TERM]\"..." |} |}
            ))
)

new PagefindUI は pagefind-ui.js を読み込んでいれば global に展開されているので、 Fable の Emit で呼び出すのが多分いちばん楽。 new PagefindUI の引数は本来なら型をちゃんと書いた方が良いが、どのオプションを使うべきか定かでなかったのもあり横着して匿名レコードをぶち込んでいる。あと pagefind UI の埋め込み対象の要素は Archives ページにだけ作るようにしたので、その要素がない場合のエラー避けをした(これも横着)。

pagefind UI のスタイル調整する

最後に pagefind UI のスタイルを調整する。 CSS custom parameter が提供されているので基本それでスタイル調整する。 light と dark の 2 テーマあるのでこことここにで CSS custom parameter を上書きしている。当然、 pagefind-ui.css の読み込み後じゃないと上書きできないので、読み込み順も注意する。

ただ CSS custom parameter でできることが限定的で、あまり納得行く出来にならない。なので必要に応じて独自に CSS を書くのが妥当だろう。いまはまだやってないけど。検索結果の highlight が mark 要素で囲まれたり、検索フィールドにフォーカスすると枠が太くなるのとか、デザインの調和が取れてないと個人的に感じる点は今後いじっておきたい。

その他

あとこれ以外にも blog-fable 固有の問題があった。それは開発サーバとして使ってる Suave がデフォルトで未知の拡張子のファイルを配信できず 404 になるというものだ。一度知ってしまったら簡単だけど、これは結構調べるのに時間がかかった。

デフォの MIME type → suave/src/Suave/Combinators.fs

拡張はこうやる。 suave/examples/Example/Program.fs 拡張した MIME type の設定を Suave の startWebServer に渡したらいい。

pagefind は生成した Wasm に付与した 4 つ独自の拡張子を持っているので、それらを application/octet-stream で配信するものだと明示してやらないといけない。こんなふうにした。

let cfg =
    { defaultConfig with
        homeFolder = Some(home)
        compressedFilesFolder = Some(home)
        bindings = [ HttpBinding.create HTTP IPAddress.Loopback port ]
        listenTimeout = TimeSpan.FromMilliseconds 3000.
        mimeTypesMap =
            Writers.defaultMimeTypesMap
            // NOTE: Add custom mime types for pagefind to prevent 404 error.
            @@ ((function
            | ".pagefind"
            | ".pf_fragment"
            | ".pf_index"
            | ".pf_meta" -> Writers.createMimeType "application/octet-stream" false
            | _ -> None)) }

(ちなみに Suave のページが不安定みたい)

これで pagefind の設定は第 1 回戦終了って感じ。まだ気に入らない点あるし検索の使い勝手も検証してないけど、ないよりいいやろ。ちょくちょく改善入れていきたい。

blog-fable を Marked v13 に対応する

Sun, 16 Jun 2024 09:00:00 +0900

今日は krymtkts/blog-fable の話を書く。

このブログの基盤 krymtkts/blog-fable はコンテンツを Markdown で管理していて、 Markdown を HTML にコンパイルするのに markedjs/marked を使っている。

つい先日 marked が v13 になったらしく Dependabot が PR を投げてきたので merge したらブログ記事が壊れた 💥。ちゃんと調べてなかったのだけど、 v13 では parser に破壊的な変更があって、仕込んでいる Marked Extension が壊れたようだった。

Release v13.0.0 · markedjs/marked

Marked v13.0.0 のリリースノートから変更前後のコードを拝借すると以下の通り。

// v12 renderer extension

const extension = {
  renderer: {
    heading(text, level) {
      // increase level by 1
      return `<h${level + 1}>${text}</h${level + 1}>`;
    },
  },
};

// v13 renderer extension

const extension = {
  useNewRenderer: true,
  renderer: {
    heading(token) {
      // increase depth by 1
      const text = this.parser.parseInline(token.tokens);
      const level = token.depth;
      return `<h${level + 1}>${text}</h${level + 1}>`;
    },
  },
};

雑に言えば、 renderer の各要素に対応付く関数が parse 済み文字列を受け取っていたのが、 token を受け取って自身で parse するように変わった。

blog-fable では Markdown を HTML に変換する際 heading link listitem checkbox image の renderer を拡張している。ここが壊れたわけだったので、関数の引数を変えたらいいだけと簡単に考えていた。ただ結構手こずった。

Marked の新しい renderer は引数に destructuring assignment を使ってる。

この辺。 marked/src/Renderer.ts at 70bb55e0af5128a657a14b8b25d7d406661e6936 · markedjs/marked

型定義ファイルだとこの様になっていた。

/**
 * Renderer
 */
declare class _Renderer {
  options: MarkedOptions;
  parser: _Parser;
  constructor(options?: MarkedOptions);
  space(token: Tokens.Space): string;
  code({ text, lang, escaped }: Tokens.Code): string;
  blockquote({ tokens }: Tokens.Blockquote): string;
  html({ text }: Tokens.HTML | Tokens.Tag): string;
  heading({ tokens, depth }: Tokens.Heading): string;
  hr(token: Tokens.Hr): string;
  list(token: Tokens.List): string;
  listitem(item: Tokens.ListItem): string;
  checkbox({ checked }: Tokens.Checkbox): string;
  paragraph({ tokens }: Tokens.Paragraph): string;
  table(token: Tokens.Table): string;
  tablerow({ text }: Tokens.TableRow): string;
  tablecell(token: Tokens.TableCell): string;
  /**
   * span level renderer
   */
  strong({ tokens }: Tokens.Strong): string;
  em({ tokens }: Tokens.Em): string;
  codespan({ text }: Tokens.Codespan): string;
  br(token: Tokens.Br): string;
  del({ tokens }: Tokens.Del): string;
  link({ href, title, tokens }: Tokens.Link): string;
  image({ href, title, text }: Tokens.Image): string;
  text(token: Tokens.Text | Tokens.Escape | Tokens.Tag): string;
}

これらを Fable だとどうしたらいいのかわからなかった。分解後のパラメータを受け取るのか？的な。だが試しに動かして調べたら、結局のところ関数に渡ってくるのはすべて Token.Xxx だった。なので binding では destructuring assignment を無視したらいいみたい。以下のように Marked の binding を調整したらうまくいった。

    type Renderer = Renderer<obj>

    [<AllowNullLiteral>]
    type Renderer<'T> =
        abstract options: MarkedOptions with get, set

        abstract code: item: Tokens.Code -> string
        abstract blockquote:  item: Tokens.Blockquote -> string
        abstract html:  item: Tokens.HTML -> string
        abstract heading: item: Tokens.Heading -> string
        abstract hr:  item: Tokens.Hr -> string
        abstract list:  item: Tokens.List -> string
        abstract listitem: item: Tokens.ListItem -> string
        abstract checkbox:  item: Tokens.Checkbox -> string
        abstract paragraph:  item: Tokens.Paragraph -> string
        abstract table:  item: Tokens.Table -> string
        abstract tablerow:  item: Tokens.TableRow -> string
        abstract tablecell: item: Tokens.TableCell -> string
        abstract strong:  item: Tokens.Strong -> string
        abstract em:  item: Tokens.Em -> string
        abstract codespan:  item: Tokens.Codespan -> string
        abstract br:  item: Tokens.Br -> string
        abstract del:  item: Tokens.Del -> string
        abstract link: item: Tokens.Link -> string
        abstract image: item: Tokens.Image -> string
        abstract text:  item: Tokens.Text -> string

いま blog-fable で使ってる Marked の binding は使ってない型もいっぱい入ってるからわかりにくいし、いつか整理したい。今回はいくつかをコメントアウトするだけに留めた。なんならこういう破壊的な変更によるメンテ作業避ける名目で Markdown の parser & compiler を Fable で書くのもいいのかも。これはやりたいことに積んどこう。

あと renderer 内で parser を呼び出す際の注意点もあった。 block 要素と inline 要素で parser method を使い分ける必要があって、例えば block の token を parseInline に渡すとエラーになってしまう。エラーにしてるのはこの辺。

marked/src/Parser.ts at 70bb55e0af5128a657a14b8b25d7d406661e6936 · markedjs/marked

blog-fable とこのブログでは、今のところ listitem だけ block を含む可能性があるようだった。そういう要素は parseInline の代わりに parse を使うことで対処できるが、余計な p で囲まれるのは少し気になった。

これで多分ブログがそこそこ従来通りの表示をするようになったはずだ。ぶっ壊れたまま気づいてない点とかあるだろうけど、今後見つけたら直すという方針でいこう。

F# でコマンドレットを書いてる pt.42

Sun, 09 Jun 2024 09:00:00 +0900

krymtkts/pocof 開発をした。

前回考えた方針で基本実装できたので、諸々の TODO は残しているけど一旦 pull request を merge して区切りをつけた。とはいえ結構直さないといけないところがいっぱいなので、 #177 の issue に関連付ける形でいくつか pull request を積んでいっているところ。

実装に関しては思ったよりも制御が難しかったが、以下に示すような延々と WriteObject してくるような Cmdlet が上流にいても、即座に起動してユーザ入力を受け付けられるようになった。これはつまりとんでもなくデータ量が多くても即座に起動できることを意味する。

function Invoke-InfiniteLoop {
    [CmdletBinding()]
    param (
        [Parameter()]
        [scriptblock]
        $ScriptBlock
    )
    end {
        while ($true) {
            if ($ScriptBlock) {
                & $ScriptBlock
            }
        }
    }
}

# 100 ms 毎に WriteObject するので Select-Object 以外の通常の Cmdlet は止まれない
# pocof は Cancel action を使えば終了できる
Invoke-InfiniteLoop -ScriptBlock {$global:a += 1; $a; Start-Sleep -Milliseconds 100} | pocof

個人的に、ちょっとしたデータ量の通常利用時でも初回のレスポンス向上になった気がして、良いかもと感じている。ただ現状ユーザ入力がないと再描画しないので、ユーザ入力 ≒ 操作がないと定期的に再描画する仕組みが必要で、それは TODO として積んでいる。

最近の pocof 実装はそんなに悩むことなのだけど、今回の非同期レンダリングは比較的悩みごとが多かった。腕が不足してるんやろなと感じる。

非同期コレクションを生で PSCmdlet 継承クラスから使うのはいまいちかなと思って wrapped type を作ったのだけど、 F# 的にこのアプローチで良かったのかなと感じながらやってた。でも FSharp.Core/mailbox みたいな非同期処理 utility も同じアプローチでカプセル化してるし、多分そんなに変ではないはず。

他にも、 Cmdlet.EndProcessing を Option.iter や Pattern matching function の中で使おうとしてスコープが解決出来ないのを知ったり。 method 呼び出しの場合暗黙で第一引数に instance が渡されるから、スコープが違うと protected method は呼べないらしいな。初めて知った。仕方ないので EndProcessing を呼ぶだけの member method を作ってそれを Option.iter の引数の関数に渡した。

また先述の TODO 以外にもなんか怪しいところがチラホラある。まだあまりテストできていないが、もともと直列で動くことが前提だったこともありユーザ入力と描画がかち合ってたまにカーソル位置がおかしくなるような。内部状態の更新は直列で実行されるから問題ないと踏んでたけど、描画部分でなんかやらかしてるのか。他にも開発中はたまに入力が hang up することもあったし、アレがまだ発生しうるのかもチェックしないと。

あと、この変更によって Pester による E2E テストが flaky になってしまったぽいところ。今のところ開発環境では落ちたことがないが、 GitHub Actions の macOS の workflow がたまに落ちるのがわかっている。

これらは FsUnit や Pester でのテストでは拾いきれない部分なので、マニュアルテストを日常的に実施するために久しぶりの Prerelease をしてもいいかもなーと考えている。ただしバグが多いうちから出すのは流石に自身の日常使用に耐えないだろうから、 TODO はなるべく解消したうえで v0.14.0-alpha を出すのがいいかな。

Cmdlet の機能を使う非同期プログラミング、けっこう大変だったけどいい経験になった。まだ全くイケてるとは言い難い構造だし、もっとマシな実装ないんかとか、もう一度やりたいものではないなというのが本音だけど。やりようによってはできるなというのがわかっただけでも良い。

F# でコマンドレットを書いてる pt.41

Sun, 02 Jun 2024 09:00:00 +0900

最近の krymtkts/pocof 開発をまとめておく。

大量データを処理する場合、描画までめちゃくちゃ遅くなる課題 #177 の対処を試している。対処法としては単純に、① 描画、② ユーザによるクエリ入力、③ ProcessRecord からのデータ入力の 3 つが切り分けられて別々に動いたら良いだけ。 issue 起票したときから非同期にしたら余裕よな～という感触はあった。 ①、② を非同期にし、③ が終了した後 EndProcessing で ①② の終了を待ち受けるイメージ。これが実装できない場合、 3 つに切り分ける数を 2 つに減らすとか、最悪のケースは全部直列で処理する。最悪 ③ で特定の件数毎に ①、② は諦めて EndProcessing で起動する、というイメージだった。

ただこのアイデアを実装に移すにあたり、わたし自身事前に勉強しておく必要があった。 .NET や F# で並行/並列のような非同期プログラミングをほぼやったことなかった(意外とそういう機会なかった)し、 Cmdlet 内での非同期処理をどう扱えるか知らないのもあり。アイデアの実現可能性を探る必要があったということ。

krymtkts/fsharp-cmdlet-sandbox で、お試しコードを書きつつドキュメントを見つつで try & error して、漸く感触を掴んできた。

わかってきたのは以下の感じ。 PSCmdlet 内で普通の処理を非同期にするのは .NET と F# の POWER もあり簡単。でも PowerShell 由来の機能を使うのは出来ないという印象だった。なかなかハードル高い。

F# には async task computation 等の非同期のための準備が整っている
.NET には SynchronizationContext で特定の thread で処理を実行する下地があり、 task や async でそれが使える(Async.SwitchToContext)
- ただし SynchronizationContext.Current は Windows.Form や WPF 等では提供されていても CLI Application ひいては Cmdlet には提供されてない
PowerShell の Cmdlet 実装は single thread を前提にしている
- これちょっと裏付けのドキュメントが見つけれてないから探したい
- multi threading で操作したらこんな感じのエラーが出た
  - Select-Pocof: The WriteObject and WriteError methods cannot be called from outside the overrides of the BeginProcessing, ProcessRecord, and EndProcessing methods, and they can only be called from within the same thread. Validate that the cmdlet makes these calls correctly, or contact Microsoft Customer Support Services.
(余談だが) PowerShell では無限リストのような終わらないデータ構造をサポートしている Cmdlet はそんなにない。 Select-Object -First が代表格
- 基本 BeginProcessing → ProcessRecord → EndProcessing のフローを抜けることはできない
- Select-Object は StopUpstreamCommandsException という秘密の内部例外で以てフローを中断できる。 ProcessRecord を中断させる方法は公式に提供されないので、みんな reflection でこの方法を流用して中断している
  - Allow user code to stop a pipeline on demand / to terminate upstream cmdlets. · Issue #3821 · PowerShell/PowerShell
- pocof で非同期的に描画を始める場合、全部読み込み終わる前にキャンセルするケースを考えたらこれが必要だったので調べた

pocof では WriteObject 以外に PowerShell 由来の機能を使っている。 PSCmdlet.InvokeCommand.InvokeScript で描画のフォーマットをしているのがそれだ。 multi threading でも int とか PSCustomObject を流す程度なら問題なかったのだけど、 Get-ChildItem の結果を流すと描画後に処理が詰まるとわかった。深く追えてないけど FileInfo あたりがダメなんかな...？という感じ。回避できない。マジか。

WriteObject を main thread に置くのは造作もない。 pocof の場合は最後の EndProcessing で実行したらいいだけだからだ。けど、 PSCmdlet.InvokeCommand.InvokeScript を main thread に限定するのが難しい。常に描画する事があるためだ。

これを解消する実装パターン的にまさに UI で求められてるのと同じなので SynchronizationContext にハマるはずだった。ただし CLI Application には提供されていない。また自前でそれを作るとしても CLI Application に独自の SynchronizationContext 実装を組み込むのは困難が伴う。他の回避方法を探るために、例えば System.Collections.ObjectModel.ObservableCollection なんかを使ってイベント駆動で描画しようとも試した。けどコレクションに put した thread でイベントハンドラが実行されるので、先述の詰まりを回避できない。

結局のところ、 main thread に自前の event loop もどきを構築する形で実現することにした。 #186

ユーザ入力とクエリ結果生成を async に逃して、 PowerShell 由来の機能を使う描画は main thread で地道に event loop を組む。これには非同期コレクションを 2 つ用いた。 1 つは検索対象を保持する非同期コレクション ①、もう１つはクエリ結果を格納する描画イベントと終了イベントを保持する非同期コレクション ②。実装イメージはこうだ。

BeginProcessing
- ユーザ入力待受やユーザ入力によるクエリ更新を async で起動、ユーザ入力によるクエリ更新があれば非同期コレクション ② に描画イベントを発行する
- 画面の初期化はここで実行する
ProcessRecord
- 逐次受け渡される InputObject を非同期コレクション ① に追加する
- 非同期コレクション ② にから描画イベントを受け取ればそれで描画する
EndProcessing
- 描画の event loop を開始し、非同期コレクション ② から描画イベントを受け取れば描画、終了イベントを受け取れば event loop を終了する
- ユーザ入力の async が完了するのを待つ
- async から結果を受け取ったら WriteObject して終了する

もっとマシな方法ないんかコラという感じではあるが...少なくともうまく実装出来そうな気配はしてきた。まだ完成してなくて、上記の切り分けをしたうえで従来の処理フローを再現できた状態まできた。この後また詰まることあったら路線変更するかも。

もしうまくいったら、大規模にリファクタリングしたい。いま、先述の非同期コレクション ② に使ってる ConcurrentStack が生で露出してるので、そこは抽象化出来たらかっこいいよねという気持ち。それに既存のテストも結構モジュール構造に合わなくなってしまったので、新しい構造に寄り添わせないとカオスなテストがより手懐けられなくなる。カバレッジもなんか落としてしまってるので改善できないか見る。

あと今回 lazy は使わなかったが、クエリ結果とかまさにこのパターンにハマるような気配もするけど試せてない。

Cmdlet に独自の処理フローを実装しようとしたら出来なくはないけどけっこう大変なんやなというのを身を以て知れて良かった。うまく非同期レンダリング実装できたら pocof 良くなりそう。 (そんなクソデカデータや無限リストを PowerShell で扱うやつがどこにおるねんというオーバースペック感)

続く。

(なんか自ブログ執筆中の dev-server で websocket 通らなくなってるなんで)

PowerShell の profile を再構成する pt.2

Sun, 26 May 2024 09:00:00 +0900

前に PowerShell の profile を再構成し始めたことに触れた。

バグ修正の他に初期化の処理をカテゴリ毎に関数を分類してみたりしたが、これどこまでやるべきなんやろかというのは悩ましいところだ。 profile の処理を分類したかったら結局ファイルを分けることになって、ファイルを分けると profile のディレクトリ全体を履歴管理するのが定石。でもそのような profile 全体を git の管理下に置くのは個人的には好きでないので、どうしたもんかな。

結局関数に小分けしたとて 1 つのファイルんい書いてることから、使わない機能があっても丸ごとスクリプトに含まれてるし、スクリプトが長くなって見にくい。もうこれはファイル分割せざるを得ないなと諦めて、ひとまず自分で決めたカテゴリ毎に野良 psm1 二分割してモジュール化した。それらを Update-Profile という PowerShell の profile を GitHub から Download して読み込む関数に組み、最新化できるようにした。

個人的に、多少しょぼいモジュールであっても、PowerShell Gallery に公開できるようなものについてはそちらに publish すべきだと考えている。ニッチであれば世界のどこかの 10 人くらいは使ってくれるだろうってのは体感的に知っているし。であるが profile に含まれるものの大半が、自分の局所的用途にしか使われないので、ここでは野良モジュールがふさわしい。

まだ若干掃除しきれてないが、大体こんな構造になってる。 pwsh-profile/Microsoft.PowerShell_profile.ps1 at main · krymtkts/pwsh-profile

# ③profile 読み込み時に野良モジュールを読み込む
Get-ChildItem "$($PROFILE | Split-Path -Parent)/Scripts" -Recurse -File -Filter *.psm1 | Import-Module -Force

# ②野良モジュールを GitHub repo から download する
function Update-ProfileScripts {
    @(
        'Autocomplete'
        'AWS'
        'Functions'
        'Get-Hash'
        'Git'
        'Go'
        'Mod'
        'Nodejs'
        'OpenAI'
        'Pocof'
        'Psake'
        'PSResource'
        'Python'
        'StandardNotes'
        'Strings'
        'Windows'
    ) | ForEach-Object {
        $modulePath = "${_}/${_}.psm1"
        $scriptPath = "${ProfileHome}/Scripts/${modulePath}"
        if (-not (Split-Path $scriptPath -Parent | Test-Path)) {
            New-Item -ItemType Directory -Path (Split-Path $scriptPath -Parent) -Force
        }
        $params = @{
            Uri = "${baseUrl}/Scripts/${modulePath}"
            OutFile = $scriptPath
        }
        Invoke-WebRequest @params | Out-Null
    }
}

# ① PowerShell profile を GitHub repo から download する
function Update-Profile {
    $ProfileHome = ($PROFILE | Split-Path -Parent)
    $ProfilePath = "${ProfileHome}/Microsoft.PowerShell_profile.ps1"
    $baseUrl = 'https://raw.githubusercontent.com/krymtkts/pwsh-profile/main/'
    $params = @{
        Uri = "${baseUrl}/Microsoft.PowerShell_profile.ps1"
        OutFile = $ProfilePath
    }
    Invoke-WebRequest @params | Out-Null

    if (-not (Test-Path "${ProfileHome}/Microsoft.VSCode_profile.ps1")) {
        New-Item -ItemType HardLink -Path $ProfileHome -Name 'Microsoft.VSCode_profile.ps1' -Value $ProfilePath
    }
    # TODO: load the profile to prepare new psm1 files.
    . $ProfilePath

    Update-ProfileScripts

    # TODO: load the profile again to apply new psm1 files.
    . $ProfilePath
}

野良モジュールは $PROFILE と同じディレクトリの Scripts 配下へ配置するようにした。野良モジュールといえど Modules に配置するのが定石だろうが、パッと見だと見分けつかないし自分の用途だと Scripts は遊んでて空いてるので。

分割したモジュールを更新するのだけちょっとトリッキーになってる。 profile が更新されたときって Update-ProfileScripts の中も更新されてる可能性があるが、それは最新の profile を download するまでわからない。追加されたばかりの野良モジュールは、最新の profile を読み込んだ後の Update-ProfileScripts が実行されて初めて取得できる。どうにも解決法がわからなかったので、ここは力技で Update-ProfileScripts 前に一度 profile を読み込んでいる。

最初に Update-Profile を実行して profile を download する(①) そして最新化された Update-ProfileScripts を実行して最新の野良モジュールを download (②)したら、最後に再度 profile を読み込めば最新化が完了する(③)。

とはいえなんかもっといい方法ないのかという気もする。あと、今見たら Update-ProfileScripts が Update-Profile で定義した global 変数を参照して dynamic scope もどきの挙動してるから危ない気もするけど、一旦このままかな。

この profile を細かく野良モジュールに分解するスタイルは最初小さくいくつかのモジュールから導入した。いまではほぼ profile の更新機能以外は野良モジュールに分割した。まだ使ってみて 1,2 週くらい？だが、モジュール分割さえ済んでしまえば GistPad から更新も容易だし不都合はなさそう。 (モジュール分割は GistPad でやるには面倒なので repository を clone してやることが多い)

今は野良モジュールとして腐らせてるけど、今後いい感じのやつが育って熟成したら正規のモジュールとして publish してやるのもありか。

F# でコマンドレットを書いてる pt.40

Sun, 19 May 2024 09:00:00 +0900

krymtkts/pocof の開発をした。

はじめメモリ浪費に気付いたときの使い方は pocof の起動までにめちゃくちゃ時間がかかる。

    function global:Show-ReadLineHistory() {
        Get-Content -Path (Get-PSReadLineOption).HistorySavePath | Select-Object -Unique | Select-Pocof -CaseSensitive -Layout TopDown
    }
    Set-Alias pghy Show-ReadLineHistory -Option ReadOnly -Force -Scope Global

こういう使い方をしてるのだけど、 Select-Object -Unique がめちゃくちゃ遅い。どういう実装をしてるかまでおってないが、順不同の要素中の他の重複を取り除くから遅いっぽい。ここを Get-Unique にしたら爆発的に速くなるのだけど、まず Sort-Object で並び替えておく必要があり、それは期待した動作じゃない。元の順そのままで重複だけなくしたい。

そこまできたらもう面倒なので pocof に -Unique オプションつけた方が楽やろなということで、そういう機能を実装した。 #181

PowerShell で言うところのこういうコードにしたら、とても速く重複が取り除ける。

Get-Content -Path (Get-PSReadLineOption).HistorySavePath | % -begin {$a=[ordered]@{}} -process {if ($a.Contains($_)) {} else {$a.Add($_, $null)}} -end {$a.Keys}

[ordered] は pocof のコードだと System.Collections.Specialized.OrderedDictionary になる。 pocof のInputObject の並び順を維持しつつとなるとこいつを使うのが定石だろう。

System.Collections.Specialized.OrderedDictionary では key の等価性を判定するのに Equals と GetHashCode が使われる。なので PSCustomObject の場合だと重複が取り除けない。 PSCustomObject は Object.Equals の再定義とかしてないから参照等価性しかチェックしてないみたい。ちょっと残念だが、でも PowerShell の環境では大体の object はそれらを実装してるし、いったん PSCustomObject 用の特別な比較関数を書かないでやった。

-Unique オプション対応してみてわかったのだけど、 hashtable の key-value の組み合わせが一致するエントリも除外できるし、こりゃなかなか便利な機能な気がしている。ぱぱっと思いついて作った割には。

pocof の設計思想的に、 pocof の呼び出し前後で他の Cmdlet でできることはあまり実装しないことにしてる。それが PowerShell らしいかなと(勝手に)と考えて -Unique オプションは考えてこなかった。でも今回の件は学びになった。既存の Cmdlet で出来たとしても、長々とパイプラインを書かないといけないとかで複雑になったり、パフォーマンスが振るわないようであれば、機能に取り込んでも良さそうやなという感覚。

この -Unique は早速 0.13.0 でリリースして、自分の PowerShell profile で新しいオプション使うように直した。

F# でコマンドレットを書いてる pt.39

Sun, 12 May 2024 09:00:00 +0900

krymtkts/pocof の開発をした。

前にメモリ浪費について触れ、それがどうも PSObject.Properties によるものだと書いた。

ひとまず Discriminated Union で wrap するときしないときのメモリ消費量を計測するためのサンプル Cmdlet でも書いてみて検証するしかないかな。

多少はメモリ食うがだいぶ的外れっぽい。ヤバいのは PSObject.properties にアクセスして補完候補を集めてるところみたい...うーん。

これイマイチ挙動がわからないのだが、 ProcessRecord の中で PSObject.Properties にアクセスしたとき条件が揃うと、症状が悪化するぽいとわかった。浪費する量は Discriminated Unions に包むことで増えるメモリ量の比でない。まさに爆増。

あまりにわからなかったので宣言通り検証用モジュールを作り、こねくった。

100 万個の int を流し込むパターンと 100 万個の PSCustomObject を流し込むパターンを作ってみた。そのそれぞれで、生か DUs でくるんで追加、プロパティアクセスの有無などの組み合わせでパターン分けして検証してみた。なるべく pocof の利用パターンに近い形で。

わかったのは、100 万回 ProcessRecord が呼ばれても、その中でただ PSObject.Properties だけアクセスするのであればメモリを浪費しない。 ProcessRecord の中で、 PSObject 本体をコレクション (今の pocof では System.Collection.Generic.List) に格納し、かつ PSObject.Properties にアクセスすると延々メモリを浪費するのがわかった。「アクセスする」と書いてるのは、言葉通り PSObject.Properties を参照するだけでメモリ消費につながるからだ。↓ これもダメ。

    let throughProps (io: PSObject) =
        match io.BaseObject with
        | _ ->
            for p in io.Properties do
                // p.Name |> ignore
                ()

なんだこれ。

ProcessRecord の中で PSObject 本体を保存しない選択肢はないので、ならば PSObject.Properties に都度アクセスしなければ良いと仮定し、 PSObject.BaseObject で読み込み済み or not を判定してプロパティを収集するように変えたら、メモリ浪費を抑えられる事がわかった。なので pocof では一旦それに倣ってメモリを消費しない形を実現できた。でも PSCustomObject の場合は依然メモリを食いまくることがわかり、これはどうすりゃいんだとなった。が、これは Out-ConsoleGridView でも浪費するのがわかった(し pocof の方が多少メモリ消費も低い)ので一旦放置した。

これで一旦 pocof のメモリ浪費対策はそこそこに対応できたかなと。あと今書いてて hashtable のパターン見忘れてるの気づいたので、やっておこう。

ただし当然のごとく、この PSObject.Properties の挙動は不可解なので PowerShell の実装を見てみた。が、残念ながらよくわからなかった。

PowerShell/src/System.Management.Automation/engine/MshObject.cs at d564d0fff95b6251dfb9e79d8243b319a7c0aecf · PowerShell/PowerShell

        /// <summary>
        /// Gets the Property collection, or the members that are actually properties.
        /// </summary>
        public PSMemberInfoCollection<PSPropertyInfo> Properties
        {
            get
            {
                if (_properties == null)
                {
                    lock (_lockObject)
                    {
                        _properties ??= new PSMemberInfoIntegratingCollection<PSPropertyInfo>(this, s_propertyCollection);
                    }
                }

                return _properties;
            }
        }

一度プロパティが読み込まれたら生成したコレクションをキャッシュをするようになってた。同一 PSObject から連続で読む限りはキャッシュが保持されるが、 ProcessRecord のなかで呼ばれるのはそれぞれ別の PSObject なので、 pocof の利用ケースではそもそもキャッシュは使われない。別の PSObject であれば lock も関係ないし。 new PSMemberInfoIntegratingCollection<PSPropertyInfo>(this, s_propertyCollection) の部分がメモリ消費しまくってると考えれば、アクセスするだけでダメなのも頷ける。逆に何故 PSObject.Properties だけアクセスする方のメモリ消費が低くなるのか気になってきた。キャッシュが使われているとしか思えんが、最適化で暗黙的な使いまわしが発生してんのか...？この挙動を追い詰めるのに今回は時間を使いたくなかったので、そのまま放置。これは将来の宿題とする。

ひとまず pocof の patch version up でこの修正を release しておくかー。

F# でコマンドレットを書いてる pt.38

Sun, 05 May 2024 09:00:00 +0900

krymtkts/pocof 0.12.0 をリリースした。

前に触れてた Active patterns の適用、あと key mapping の名称と割当の変更などのリファクタリング。それと CPU 使用率が高くなるバグへの対応だ。これは速く対処して出したかった(それでも面倒で間が空いたが)。

先日 KeyAvailable になるまで ReadKey しなくしたことでイベントループが回りまくって CPU 上げてた。実はこれ pocof の初期実装では CPU load 下げるための Thread.Sleep が仕込まれており、要は考慮済みだった。だけどその後紆余曲折で await 使ったりして KeyAvailable がなくなり、その後また復活して～ってなってその部分だけ忘れ去られてたという形。情けない。

あと最近気づいたお困りポイントが、 pocof に大量のデータを食わせたときの応答の遅さ #177 とメモリ使用量が多すぎる #176 問題だ。単純に 1..1000000 | pocof のようなコマンドを実行してみたら起動も遅いし、キータイプごとに秒かかるし、 2GB 超メモリを食う。やばすぎ。キャンセルして終了したあと [GC]::Collect() でもしないと確保したメモリが解放されない始末(それも全部が解放されないという)。

これに気づいたのは以下のような関数を書いてるとめちゃくちゃ遅いので、その理由を調べたときのことだった。この関数自体は pocof の遅さに由来して遅いのではなく、単に Select-Object -Unique が脅威の遅さだったためだが。 12,000 件程度しかなかったので大して pocof は遅くなかった。

    function global:Show-ReadLineHistory() {
        Get-Content -Path (Get-PSReadLineOption).HistorySavePath | Select-Object -Unique | Select-Pocof -CaseSensitive -Layout TopDown
    }
    Set-Alias pghy Show-ReadLineHistory -Option ReadOnly -Force -Scope Global

応答が遅いのは 2 種類ある。

まずは、都度 O(N) かけて要素を絞り込んだり件数を算出したりしてたため、フィルタリングが遅い。内部でデータを保持するのに list を使ってたのもあり、ひとまず seq に変更した。 seq は要素が必要なタイミングまで遅延評価される。今のところ件数の表示がある限り遅延評価を活かせず速くならないが、件数の表示をなくせば表示範囲の件数だけ取れたら処理を終われる構造になった。そういうオプションにすればいいのかもしれないが、とはいえこれも全件走査が必要な場合に効果がない。根本的に内部のデータ構造を変えないと速くならんのではーと見ている。でも pocof は依存関係基本なしの縛りがあるので、自前で効率化する方法やデータ構造の見直しを色々手探りしてみるしかないか。

もう 1 つは EndProcessing で描画を開始するので、 PowerShell の Cmdlet の仕組み上データ量が多いと ProcessRecord が終わるまでの時間も長くなり、初動が遅い。アイデアベースではこれの解決案は考えついていて、単に ProcessRecord 中に画面描画開始できる件数が溜まったら描画し始めたらいいかなと考えている。ただその際にキー入力を受け付け始めれるのか？とか、単に実装力の問題でアイデアをモノに落とし込めてない。なのでこれも小さなサンプル Cmdlet でも作って手探りする必要がある。

最後にメモリ使用量が多い件。まだ一番でかい原因を追いきれてないが、おそらく Discriminated Unions を各要素を wrap するのに使ってるからかと推測している。というのも、まず ProcessRecord 毎に list が生成されるような構造だったので、試しに mutable な List を使って for で追加していく形に最適化してみた。ところがそんなに爆発的には効果がなかった(ゆーても 2.3GB 超 RAM 消費する状態で 1.9 GB にはなったが)。であれば Discriminated Unions が濃厚かなと考えるが、 pocof のままだとちょっと試すのも色々変えないといけないので億劫だ。ひとまず Discriminated Union で wrap するときしないときのメモリ消費量を計測するためのサンプル Cmdlet でも書いてみて検証するしかないかな。

ちなみにこれらの点いずれも、 PowerShell/ConsoleGuiTools のフィルタは初期ロードが死ぬほど遅いのを除けば¹、省メモリで高速にキビキビと動く。なんか参考になる要素あるかもな。

2 年超の間のらりくらり F# で PowerShell の Cmdlet 書いてきてるが、(体系的な学習してないのもあって)知らないことに毎度のようにぶち当たる。知るべきことを知ってない怠惰なのかも知れんが、ここは広範な知識の海で新たな発見が尽きないのだと、ポジティブに考えていきましょ。

今日は気になっている課題を書いたが、他にも pocof でやりたいことがちらほら残っている。 Ctrl+LeftArrow, Ctrl+RightArrow あたりで単語区切りの移動 #173 したい気分になってきた。また、よく考えると選択範囲がある状態でのプロパティ補完時の挙動も未定義なままだった。パフォ系の問題を処置する前にするか、処置したあとにするか...思いつき駆動なのでちょっと悩ましい。

追記 2024-05-05

ひとまず Discriminated Union で wrap するときしないときのメモリ消費量を計測するためのサンプル Cmdlet でも書いてみて検証するしかないかな。

多少はメモリ食うがだいぶ的外れっぽい。ヤバいのは PSObject.properties にアクセスして補完候補を集めてるところみたい...うーん。

わたしのいまや貧弱になった Razer Blade Stealth 2017 だと 1..1000000 | Out-ConsoleGridView でもしようものなら起動までに 7 分かかる。 ↩

PowerShell の profile を再構成する

Sun, 28 Apr 2024 09:00:00 +0900

長らく自作 PowerShell の profile を使ってる。長年継ぎ足ししてきた謂わば秘伝のタレのようなもので、全体はかなりごちゃついている。これを整理して再構成する必要が出てきたので、今日はそれを記す。

再構成が必要だと思ったのは、毎週行う PowerShell module はじめとした諸々のモジュールの更新のときだった。 PowerShell module の更新は以下の関数で行うのだけど、違和感わかってもらえるだろうか？

function Update-InstalledModules {
    [CmdletBinding(SupportsShouldProcess)]
    param()

    Get-InstalledPSResource -Scope AllUsers | Where-Object -Property Repository -EQ 'PSGallery' | ForEach-Object {
        $Prerelease = $_.Name -notin $pinStable
        $_.Name | Update-PSResource -Prerelease:$Prerelease -Scope AllUsers
    }
}

更新後にたまたま PowerShell Gallery を見たら妙に krymtkts/pocof の download 数が増えてたのでなんでや？と思って見てみたら、犯人はこいつだった。 Installed-PSResource は module name x version の組み合わせを返すので、インストールされている pocof の数だけ download が増えるという... このバグが入り込んだタイミングは PowerShellGet -> Microsoft.PowerShell.PSResourceGet に変わったタイミングだろう。

function global:Update-InstalledModules {
    [CmdletBinding(SupportsShouldProcess)]
    param()

    Uninstall-OutdatedPSResources
    Get-InstalledPSResource -Scope AllUsers | Where-Object -Property Repository -EQ 'PSGallery' | Group-Object -Property Name | ForEach-Object {
        $Prerelease = $_.Name -notin $global:pinStable
        Write-Host "Update $($_.Name) $(if ($Prerelease) {'Prerelease'} else {''})"
        # NOTE: -WhatIf is not work with Update-PSResource in some cases.
        Update-PSResource -Name $_.Name -Prerelease:$Prerelease -Scope AllUsers
    }
}

なのでこんな感じで Group-Object で複数バージョンあっても折りたたむ形にした。

余談だが、 Update-PSResource を WhatIf で動作確認してたら妙なエラーになってよくわからなかった。

> Update-PSResource pocof -Prerelease -WhatIf -Scope AllUsers
What if: Performing the operation "Update-PSResource" on target "Package to install: 'pocof', version: '0.11.0'".
What if: Performing the operation "Update-PSResource" on target "Exit ShouldProcess".

Exception             :
    Type    : Microsoft.PowerShell.PSResourceGet.UtilClasses.ResourceNotFoundException
    Message : Package(s) 'pocof' could not be installed from repository 'PSGallery'.
    HResult : -2146233088
TargetObject          : Microsoft.PowerShell.PSResourceGet.Cmdlets.UpdatePSResource
CategoryInfo          : InvalidData: (Microsoft.PowerShel…ts.UpdatePSResource:UpdatePSResource) [Update-PSResource], ResourceNotFoundException
FullyQualifiedErrorId : InstallPackageFailure,Microsoft.PowerShell.PSResourceGet.Cmdlets.UpdatePSResource
InvocationInfo        :
    MyCommand        : Update-PSResource
    ScriptLineNumber : 1
    OffsetInLine     : 1
    HistoryId        : 13
    Line             : Update-PSResource pocof -Prerelease -WhatIf -Scope AllUsers
    Statement        : Update-PSResource pocof -Prerelease -WhatIf -Scope AllUsers
    PositionMessage  : At line:1 char:1
                       + Update-PSResource pocof -Prerelease -WhatIf -Scope AllUsers
                       + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    InvocationName   : Update-PSResource
    CommandOrigin    : Internal
ScriptStackTrace      : at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo :
      0
      1

-WhatIf results in extra, unwanted output and a spurious error · Issue #1541 · PowerShell/PSResourceGet

Cmdlet は違うがこれと同じっぽい。アップデートできるモジュールがある場合に起こる。パッと見の挙動は -WhatIf 付きのときにインストール済み module 名を消せてないから「インストールできなかった」エラー判定されるようだった。焦らすなや～。コード追ってみたがエラー発生箇所はわかったけどどうやったら解決するのかは追いきれなかった。

PSResourceGet/src/code/InstallHelper.cs at bb4c0d0402a43cb561b33c681024ec6312a8474d · PowerShell/PSResourceGet

あと Gist でずっと管理してたやつを GitHub repo に移した。 krymtkts/pwsh-profile

Gist で最新版を管理するのが手軽であるのと、 snippet に対して直にコメントもらったりのコミュニケーションを取りやすいのが利点だと認識している。ただわたしの PowerShell profile の場合そういう化学反応起こらないので、履歴管理の面倒さからも Gist をやめたくなった次第。どうせ履歴の更新に関しては従来通り GistPad を使ってコピペしていくだけなので、何も変わらない。移行は以下の手順で行った。びみょーに実際の手順と違って間違いあるかもしれんが大体こんな感じなはず。

# new repo.
New-GitHubRepository -RepositoryName pwsh-profile -Private
# mistake.
$r = Get-GitHubRepository -OwnerName krymtkts -RepositoryName pwsh-profile

# clone gist.
ghq get https://gist.github.com/krymtkts/f8af667c32b16fc28a815243b316c5be
# move to gist repo.
gcd
git remote add github $r.ssh_url
# change master to main.
git switch --create main
# push to the GitHub repo.
git push -u github main
$remove = pwd

# clone new repo.
ghq get -p $r.ssh_url
# move to new repo.
gcd
# publish repo.
Set-GitHubRepository -OwnerName krymtkts -RepositoryName pwsh-profile -Private:$false

# remove gist repo.
rm -Recurse $remove -Force
Remove-GitHubGist -Gist f8af667c32b16fc28a815243b316c5be -Force

はじめ Remove-GitHubGist が 404 Not Found で返ってきて何ぞ？と思ったが、 Access Token の権限足りないようだった。 403 とかじゃないんだ。

バグ修正の他に初期化の処理をカテゴリ毎に関数を分類してみたりしたが、これどこまでやるべきなんやろかというのは悩ましいところだ。 profile の処理を分類したかったら結局ファイルを分けることになって、ファイルを分けると profile のディレクトリ全体を履歴管理するのが定石。でもそのような profile 全体を git の管理下に置くのは個人的には好きでないので、どうしたもんかな。

つづく。

F# でコマンドレットを書いてる pt.37

Sun, 21 Apr 2024 09:00:00 +0900

krymtkts/pocof ではあまり Active Patterns を使ってなかった。特に理由があって避けてたわけじゃなく、わたしの F# 力が低いのもあるけどなんか大げさな感じがして使ってなかった。

でもこの辺を読んでもっと気軽に使っても良さそうやな～という気になってきた。

そこで可読性高めるのと汎用化を期待して使いはじめてみた。 Partial Active Patterns やら Complete Active Patterns やらあるけど、気に入ってるのは Single-case Active Pattern だ。値を変換するパターンがこれに相当する。

こんな感じでタプルを照準に並び替えて返すものを作ってみたが、良さそう。

    let (|Ascending|) (x, y) = if x < y then (x, y) else (y, x)

pocof は範囲選択の実装の都合上、数値を並び替える場面がいくつかあった。あるいは 2 つの数値のうち小さい方、大きい方を取るとか。そういったケースにこれがバッチリハマる。

並び替えるだけならこう。

    match x, y with Ascending xy -> xy

大小どちらかを取る場合、例えば小さい方はこう。

    match x, y with Ascending (x, _) -> x

既に 2 値のタプルがあるなら、こうするのがシンプルか。

    xy |> function Ascending xy -> xy

この状態だと単に関数呼び出しでしかないけど、他のパターンと組み合わせていい塩梅にできる。

let xy = (0, -1)
match xy with
| x, y when x < 0 || y < 0 -> None
| Ascending xy -> Some(xy)

いいやん。ボトムアッププログラミングが捗るな(ゆーても既にモノ出来てるからボトムアップしようがないけど)。

あとは多少複雑なコードの人まとまりに意図を示すのにも向いてる。こことか

    let (|Found|_|) aType excludes name =
        FSharpType.GetUnionCases aType
        |> Seq.filter (fun u -> Set.contains u.Name excludes |> not)
        |> Seq.tryFind (fun u -> u.Name |> String.lower = name)


    let private fromString<'a> s =
        let name = String.lower s
        let aType = typeof<'a>

        match name with
        | Found aType (set []) u -> FSharpValue.MakeUnion(u, [||]) :?> 'a
        | _ -> failwithf $"Unknown %s{aType.Name} '%s{s}'."

Discriminated Union を文字列から作るとき(pocof のパラメータ変換で使う)にハマる。元は match ~ with のところに Found active pattern 相当のコードを置いてたので、なおさら読みやすくなってる。関数でもいいのだけど、 Match expression と組み合わせることでより文脈読みやすくなると、個人的に感じた。

まだ引数のパターンを示すのに使うような尖った？使い方は出来てないが、徐々になじませていくか。

F# の Inline Functions のカバレッジを計測する

Sun, 14 Apr 2024 09:00:00 +0900

最近あんま週末時間取れず開発できてないので小ネタ。

CI test coverage of F# unit tests · Issue #3579 · dotnet/fsharp

この中で触れられてるのだけど、 F# の Inline Functions は code coverage を計測できない。コンパイル時点で使われてる箇所に inline 展開され、展開前の情報を捨て去るので追えないみたい。 krymtkts/pocof の開発でも Inline を使ってる箇所があって、そこは長らく code coverage 取れないので網羅率がちょっと低くなるという状態だった。

ただ計測のためのちょっとした hack はある。ここで触れられてる #if ディレクティブを使って Debug モードのビルドのときだけ inline を外す方法だ。静的にジェネリック型が解決されるようなパターンだと使えないようだが、 pocof では使えた。こんな感じ。

    let
#if !DEBUG
        inline
#endif
        private (?->)
            (x: PSObject)
            (prop: string)
            =
        try
            Some (x.Properties.Item prop).Value
        with _ ->
            None

ただやっぱコード見た目意味わかんなくなるし Fantomas もフォーマットに困るみたい(ガタガタ)なので、あんま良くないなと。仕方なくやってる。

F# は coverlet とあまり相性いい感じしない。個人的には以下が相性良くないと感じてる点だ。他にもあるんかな。

match expression は可読性高くてあまり複雑にならないのだけど、コンパイル後の中間言語の循環的複雑度が高い
string の slicing を使うと循環的複雑度が上がる
- Multiple branch points created for F# string slice · Issue #1208 · coverlet-coverage/coverlet
先述の Inline functions

ここまで来ると F# では code coverage や複雑度などのメトリクスはあまり意識しない方がいいのか？と思えてくる。

FSharplint の issue でも「みんな使ってないし手続き型ほど重要じゃない」という意見で、過去に循環的複雑度の計測をなくしたことがあるみたいだし(復活したようだが)。 cyclomatic complexity removed? · Issue #195 · fsprojects/FSharpLint

code coverage も、テスト書くならどのコードがテストされたかを計測したいのは当然だと思ったが...

pocof の場合で考えたら、毎日連続的に開発してるわけじゃないし、品質を維持できる指標があると、すっぱり忘れてしまってても安心して取り組めるのであった方が良い。

興味は尽きませんな。

F# でコマンドレットを書いてる pt.36

Sun, 07 Apr 2024 09:00:00 +0900

最近の krymtkts/pocof の開発をまとめる。

主だったものでいうと、クエリ文字列選択のプロトタイプを実装した。それと Windows Terminal で Ctrl+S して出力を停止しているときに type すると pocof がエラーで落ちる様になってたので、その修正をした。 #160

これらとカバレッジの改善などを含む 0.11.0 をリリースした。

クエリ文字列選択は、以下の新しいショートカットで実装している。

Ctrl+A 全選択
Shift+Home カーソル以前全ての文字列を選択
Shift+End カーソル以降全ての文字列を選択
Shift+LeftArrow カーソル前方の 1 文字を選択
Shift+RightArrow カーソル後方の 1 文字を選択

あと削除系の操作に選択範囲がある場合の振る舞いを追加した。

Backspace 選択範囲を削除
Delete 選択範囲を削除
Alt+K 選択範囲とカーソル以前全ての文字列を削除
Alt+U 選択範囲とカーソル以降全ての文字列を削除

選択範囲がある場合のカーソル前後すべてを消すやつは、 PSReadLine でも見ない挙動だろうからちょっと変わり種だ。 (PSReadLine の BackwardDeleteInput ForwardDeleteInput は選択範囲を消さない) ただ自分の感覚だと削除系の挙動が統一されてないと感じるので、選択範囲を消すような実装とした。 (余談だがショートカット割当を雑に決めてしまってるので、そこもそのうちデフォ設定を変えたい)

あとプロトタイプと書いてるのは、選択モードでもプロパティ補完候補の振る舞いを決めてないからだ。いまのところ通常のカーソル位置にあるプロパティ補完候補の表示が働いている。

選択範囲があるときに Tab 補完したら、選択範囲を消して補完候補を出したらそれなりに便利な気がするが...そうしたら補完候補は常に表示しておきたいか。逆に選択中で補完候補を出したくないときってどんなとき？まだちょっと利用想定を詰めるのが甘いか。もうちょっと煮詰まったら実装したい。

あと #160 のバグ修正は、 Windows Terminal で Ctrl+S したあとで何か type したときに発生してたエラーを防ぐものだ。この年まで知らなかったのだけど、昔は標準出力の印字を紙にしてたから、それを一時停止するための Ctrl+S と再開するための Ctrl+Q があったそうだ。そのため伝統的に terminal emulator でも同機能を実装しており、しかも割と現代でもそれを使う人もいるということだった。 (なんか tail -f で流しているようなとき気になる箇所で止めたりする使い方らしい)

Windows Terminal でもその実装があるみたいで、 Ctrl+S で出力停止、何らかのキー押下で再開するらしい。この振る舞いに詳しく触れている文書を見つけられなくて、以下で触れられてるのくらいしかなかった。 Windows Terminal の repo に PR があるからどっかで触れられてていいと思うが。 Re-investigate Ctrl+S pausing · Issue #809 · microsoft/terminal

何にせよ Ctrl+S 押下したあと Console.ReadKey が呼ばれると InvalidOperationException が発生する。ドキュメントにも書いてある。

Console.ReadKey Method (System) | Microsoft Learn

InvalidOperationException The In property is redirected from some stream other than the console.

これどうやったら防げるんや？と調べてたら、単純に pocof の実装がバグってるだけだったんがわかった ↓ Fix Screen.read function to prevent an unhandled error when output is… · krymtkts/pocof@60843b9

        [<TailCall>]
         let rec read (acc: ConsoleKeyInfo list) =
-            let acc = rui.ReadKey true :: acc
-
-            match rui.KeyAvailable() with
-            | true -> read acc
-            | _ -> List.rev acc
+            rui.KeyAvailable()
+            |> function
+                | true ->
+                    let acc = rui.ReadKey true :: acc
+                    read acc
+                | _ -> List.rev acc

rui.ReadKey は Console.ReadKey 、 rui.KeyAvailable() は内部で Console.KeyAvailable を呼んでる。元のコードだと、初回は必ず Console.KeyAvailable を見ずに Console.ReadKey を呼んでしまうので、そこでエラーになってた。修正したコードでは必ず Console.KeyAvailable のチェックのあとで呼ばれるので、エラーにならない。

Console.KeyAvailable を改めてみてみたら、ちゃんと標準入力でキーが有効かチェックしてて、そらそうやなという感じ...ただの実装ミスやったと。 Console.KeyAvailable Property (System) | Microsoft Learn

Gets a value indicating whether a key press is available in the input stream.

しょぼバグを直せて良かった。

次にやるのは、ひとまず選択中のプロパティ補完の振る舞いを詰める。その次は起票済みの機能よりも、 PSReadLine の Word 単位の移動や削除を模してみるか。自分で起票したけど行選択やページ移動はあまり気乗りしない。

Bulma 1.0.0 の automatic Dark mode を制御する

Sun, 31 Mar 2024 09:00:00 +0900

今回も引き続き Bulma 1.0.0 ネタだ。

前回 Bulma 1.0.0 に合わせてスタイル調整した話を書いた。加えて Bulma 1.0.0 で automatic Dark mode が導入されたのにも触れたが、これをうまく制御するのに多少のコツが必要だっので記しておく。

ドキュメントにも記載あるが、 Bulma の automatic Dark mode は prefers-color-scheme の media query を使ってる。これが automatic Dark mode の automatic の正体だ。手動で light/dark mode を使い分けるには data-theme を指定する。この data-theme="light data-theme="dark" 属性を HTML に差し込んだり、ユーザごとに設定を保存するのは、 JavaScript を書かないといけない。

そういう仕組みなので light/dark mode に関する style は以下のようにするのが多分 Bulma の推奨パターンのはず。

blog-fable/sass/style.scss at aa668a3e991a46e9b3b3d0302bdbc717d146665e · krymtkts/blog-fable

@media (prefers-color-scheme: light) {
  :root {
    @include light-theme();
  }

  [data-theme="dark"] {
    @include dark-theme();
  }
}

@media (prefers-color-scheme: dark) {
  :root {
    @include dark-theme();
  }

  [data-theme="light"] {
    @include light-theme();
  }
}

このように prefers-color-scheme の内側に逆の色の [data-theme="*"] を仕込むことで、システムのテーマ設定に関わらず指定のカラーテーマにできる。システムにテーマを表明されないときは prefers-color-scheme が light になるらしい。確認したことはないが、古い OS でカラーテーマが取れないときとか？ prefers-color-scheme - CSS: Cascading Style Sheets | MDN

ただ、この仕組みにしていると多少問題がある。 prefers-color-scheme が取れるタイミングと [data-theme="*"] が取れるタイミングに差がある実装だと、ページ遷移時にスタイルの切り替わりで画面がちらつく。「prefers-color-scheme のカラースキーマ反映 -> JavaScript で data-theme 設定される -> data-theme のカラースキーマ反映」となるとダメ。このチラつきは Bulma の official page でも起こってる。

これを解消するには、HTML 文書で JavaScript → CSS の読み込み順になるよう調整し、かつ JavaScript 読み込み時にユーザ設定値を復元して data-theme に設定する。ただし注意点としては、 data-theme の設定は JavaScript 読み込み時にやりたくても、テーマ切り替えのボタンに event を binding するのは後回しの方が良さそう。 blog-fable ではあまりに早過ぎて event を bind したい要素が準備されてなかったようで bind できなかったので、 load event で binding するようにした。

以下 blog-fable の例。 blog-fable/src/Handler.fs

module Handler

open Browser.Dom
open Browser.WebStorage

// NOTE: Don't use Fable library in this file because it is directly bundled int HTML files.
//       This includes, discriminated union, List, etc.

let private themeKey = "theme-mode"
let private themeAttributeName = "data-theme"

let private setThemeMode (t: string) =
    match t with
    | "light"
    | "dark" ->
        localStorage.setItem (themeKey, t)
        document.documentElement.setAttribute (themeAttributeName, t)
    | _ ->
        localStorage.removeItem themeKey
        document.documentElement.removeAttribute themeAttributeName

localStorage.getItem "theme-mode" |> setThemeMode

let private init _ =
    let els = document.querySelectorAll (".theme-toggle")

    for i = 0 to els.length - 1 do
        let el = els.item (i)
        let themeMode = el.getAttribute "data-theme"
        el.addEventListener ("click", (fun _ -> setThemeMode themeMode))

window.addEventListener ("load", init)

blog-fable は F# からトランスパイルした JavaScript を成果物にコピっているだけなので、 Fable のライブラリのインポートを必要とするコードは書けないという縛りがある。なので discriminated union や List.* といったものも使わない質素な実装になっている。ここまでやったら、 blog-fable のページ遷移に限ってかも知れないがチラつきは一切起こらなくなり、マニュアルでのテーマ切り替えも動作するようになった。

他にもちまちまとスタイルの補正をしている箇所はあるが、これにて大体 Bulma 1.0.0 対応ができたもといえそう。前より自作スタイルの CSS のサイズが 2 倍超デカくなってるのは気になるが、これも少しずつ改善重ねていけれたらよいか。

blog-fable を Bulma 1.0.0 に対応する

Sun, 24 Mar 2024 09:00:00 +0900

krymtkts/pocof に query string selection を実装するのはそれなりに進んだ。一段落ついたらまた日記にまとめたいが、その前に krymtkts/blog-fable(このブログ) へデカ目の変更が降りてきたので、今日はそっちを書く。

デカ目の変更というのは、 Bulma の 1.0.0 のリリースだ。捕捉してなかったから、これには正直驚いた。どうも 2024-01 頃から準備が進んでたらしい。 v1 release date? · Issue #3708 · jgthms/bulma

正直どこも賑わってなさそうなんやけど、 Hacker News にスレは立ってた。The Bulma CSS framework reaches 1.0 | Hacker News

blog-fable を作った(このブログを Fable で作り直した)のは 2023 で、当時の Bulma の最新は 0.9.4 だった。 0.9.4 が 2022-05 頃にBuild 0.9.4 · jgthms/bulma@3e00a8eリリースされて以降の Bulma は、リリースがなかったわけだ。 GitHub にアクティビティはあったけど、スポンサーのロゴを差し替えたりって変更とかが多くて、割と Issue, Pull Request も積んでた感じ。

今どきはみんな Tailwind CSS を使うのだろうけど、 blog-fable では CSS を書く労力を減らしたかったから Bulma を使った。 Bulma なら class 指定しなくてもそこそこ default で style が利くので、構造自体に集中しやすい。かつ JS 不要な CSS framework で、 Sass を使ってある程度 bundle を小さくできる余地があった。 Fable の Bulma wrapper である Fulma もあるけど、これは当時フィーリングが合わなかったみたいで採用しなかった。

昔話はこの程度にして、 Bulma 1.0.0 での変更点を見ていく。

Migrating to Bulma v1 | Bulma: Free, open source, and modern CSS framework based on Flexbox

Bulma 1.0.0 は全面的に Dart Sass で書き直されたらしい。 @import も非推奨となり、 @use がちゃんと使えるようになったのは喜ばしい。

blog-fable ではカラースキームの変更と bundle 最小化のために、以下のように Sass を使ってスタイルを自作している。カラースキームは Solarized で light/dark のモード切替なしで dark 固定だ。 Bulma 0.9.4 だと @use を使った場合、必要な *.sass だけインポートする方法だとエラーで使えなくて、古き良き @import を使っていた。

blog-fable/sass/style.scss at b51df81f0ef32e3065c18a43248c6599f15d9da8 · krymtkts/blog-fable

@charset "utf-8";

// NOTE: based on https://ethanschoonover.com/solarized/
$base03: #002b36;
$base02: #073642;
$base01: #586e75;
$base00: #657b83;
$base0: #839496;
$base1: #93a1a1;
$base2: #eee8d5;
$base3: #fdf6e3;
$yellow: #b58900;
$orange: #cb4b16;
$red: #dc322f;
$magenta: #d33682;
$violet: #6c71c4;
$blue: #268bd2;
$cyan: #2aa198;
$green: #859900;

// // NOTE: Solarized Light.
// $black: $base03,
// $black-bis: $base02,
// $black-ter: $base02,
// $grey-darker: $base00,
// $grey-dark: $base00,
// $grey: $base01,
// $grey-light: $base0,
// $grey-lighter: $base1,
// $grey-lightest: $base1,
// $white-ter: $base2,
// $white-bis: $base2,
// $white: $base3,
// $background: $base3,
// $code: $base01,
// $tag-background-color: $base3,
// NOTE: Solarized Dark.
$black: $base3;
$black-bis: $base2;
$black-ter: $base2;
$grey-darker: $base1;
$grey-dark: $base1;
$grey: $base0;
$grey-light: $base00;
$grey-lighter: $base01;
$grey-lightest: $base01;
$white-ter: $base02;
$white-bis: $base02;
$white: $base03;
$background: $base03;
$code: $base0;
$tag-background-color: $base03;
$hr-background-color: $base01;

$orange: $orange;
$yellow: $yellow;
$green: $green;
$turquoise: $cyan;
$cyan: $cyan;
$blue: $blue;
$purple: $violet;
$red: $red;

$code-size: 1em;
$link-hover: $violet;
$section-padding: 1.5rem;
$section-padding-desktop: 1.5rem;
$body-line-height: 1.7;

@import "../node_modules/bulma/sass/utilities/_all.sass";
@import "../node_modules/bulma/sass/base/_all.sass";
@import "../node_modules/bulma/sass/components/navbar.sass";
@import "../node_modules/bulma/sass/components/tabs.sass";
@import "../node_modules/bulma/sass/elements/button.sass";
@import "../node_modules/bulma/sass/elements/container.sass";
@import "../node_modules/bulma/sass/elements/content.sass";
@import "../node_modules/bulma/sass/elements/image.sass";
@import "../node_modules/bulma/sass/elements/tag.sass";
@import "../node_modules/bulma/sass/elements/title.sass";
@import "../node_modules/bulma/sass/form/shared.sass";
@import "../node_modules/bulma/sass/form/checkbox-radio.sass";
@import "../node_modules/bulma/sass/layout/footer.sass";
@import "../node_modules/bulma/sass/layout/section.sass";

// NOTE: adjust non-parameterized styles.
.content a {
  text-decoration: underline;
}
a:visited {
  color: $purple;
}
.checkbox {
  margin-right: 0.5em;
}
main {
  padding-bottom: 1.5em;
}
code {
  word-wrap: break-word;
}
code,
pre,
.tag:not(body) {
  border: 1px solid $grey-lighter;
  border-radius: $radius;
}
pre code {
  border: none;
  line-height: 1.5;
}
.content {
  li:first-child {
    margin-top: 0.25em;
  }
}
.date {
  color: $base01;
}
.prev a:before {
  content: "\2190";
}
.next a:after {
  content: "\2192";
}

Bulma 1.0.0 になったことで普通に使う分には非推奨のコンポーネントが出たくらいだろうが、昨日試してみた感じだと、先述したような独自のスタイルを構築している場合に結構影響を受ける感じだった。なんか従来通りカラースキームを指定しても背景に使われないのよね。

試行錯誤して、 automatic Dark Mode と CSS variables の仕組みを理解してうまく使えば、ひとまずいい感じにできそうとわかってきた。

automatic Dark Mode の場合、 light ↔ dark の色を hsl, hsla で計算して出してる。そのベースとなる CSS variable に色を指定する必要があるみたい。 0.9.4 のときは単純に $black とかの色の Sass の変数を変えるだけでいけた。けど、 1.0.0 からは --bulma-scheme-h, --bulma-scheme-s, --bulma-scheme-l 等で色相、彩度、輝度を指定しないといけないみたい。

button や tag などのコンポーネントはそれで背景色が決まるので、ここを攻略しないとどうにもならん。最悪彩度と輝度に無効な値を指定すれば無視できるのはわかったが、きちんと指定しておきたい。でもまだドキュメント読んでもあんまわからん。ドキュメントではの変数を参照してるとか調べるのが難しい。

ということで、開発者ツールで手探りして以下を設定してみたら、今のところほぼ同じにできた。ほぼと書いたのは、箇条書きの line height が微妙に違いそうだからだ。また、 button の border の色が hsl で勝手に定まるのだけ対処法わからなかったので style を上書きした。 light/dark の style を 2 箇所ずつ書かないといけないので、コピペしなくていいよう @mixin にまとめてある。

blog-fable/sass/style.scss at aa668a3e991a46e9b3b3d0302bdbc717d146665e · krymtkts/blog-fable

@charset "utf-8";

// NOTE: based on https://ethanschoonover.com/solarized/
$sl-base03: #002b36;
$sl-base02: #073642;
$sl-base01: #586e75;
$sl-base00: #657b83;
$sl-base0: #839496;
$sl-base1: #93a1a1;
$sl-base2: #eee8d5;
$sl-base3: #fdf6e3;
$sl-yellow: #b58900;
$sl-orange: #cb4b16;
$sl-red: #dc322f;
$sl-magenta: #d33682;
$sl-violet: #6c71c4;
$sl-blue: #268bd2;
$sl-cyan: #2aa198;
$sl-green: #859900;

@use "../node_modules/bulma/sass" as * with (
  $orange: $sl-orange,
  $yellow: $sl-yellow,
  $green: $sl-green,
  $turquoise: $sl-cyan,
  $cyan: $sl-cyan,
  $blue: $sl-blue,
  $purple: $sl-violet,
  $red: $sl-red,

  $code-size: 1em,

  $body-line-height: 1.7,

  $section-padding: 1.5rem,
  $section-padding-desktop: 1.5rem
);

@mixin light-theme {
  // NOTE: Solarized Light.
  --bulma-black: #{$sl-base03};
  --bulma-black-bis: #{$sl-base02};
  --bulma-black-ter: #{$sl-base02};
  --bulma-grey-darker: #{$sl-base00};
  --bulma-grey-dark: #{$sl-base00};
  --bulma-grey: #{$sl-base01};
  --bulma-grey-light: #{$sl-base0};
  --bulma-grey-lighter: #{$sl-base1};
  --bulma-grey-lightest: #{$sl-base1};
  --bulma-white-ter: #{$sl-base2};
  --bulma-white-bis: #{$sl-base2};
  --bulma-white: #{$sl-base3};

  --bulma-text: #{$sl-base01};
  --bulma-text-strong: #{$sl-base01};

  --bulma-scheme-main: #{$sl-base3};
  --bulma-scheme-main-bis: #{$sl-base2};
  --bulma-scheme-main-ter: #{$sl-base2};

  --bulma-scheme-h: 44;
  --bulma-scheme-s: 87%;
  --bulma-scheme-l: 94%;

  --bulma-background-l: 94%;

  --bulma-scheme-main-s: 87%;
  --bulma-scheme-main-bis-s: 87%;
  --bulma-scheme-main-ter-s: 87%;
  --bulma-scheme-main-l: 94%;
  --bulma-scheme-main-bis-l: 94%;
  --bulma-scheme-main-ter-l: 94%;

  --bulma-code: #{$sl-base00};

  --bulma-hr-background-color: #{$sl-base1};

  --bulma-border: #{$sl-base1};
}

@mixin dark-theme {
  // NOTE: Solarized Dark.
  --bulma-black: #{$sl-base3};
  --bulma-black-bis: #{$sl-base2};
  --bulma-black-ter: #{$sl-base2};
  --bulma-grey-darker: #{$sl-base1};
  --bulma-grey-dark: #{$sl-base1};
  --bulma-grey: #{$sl-base0};
  --bulma-grey-light: #{$sl-base00};
  --bulma-grey-lighter: #{$sl-base01};
  --bulma-grey-lightest: #{$sl-base01};
  --bulma-white-ter: #{$sl-base02};
  --bulma-white-bis: #{$sl-base02};
  --bulma-white: #{$sl-base03};

  --bulma-text: #{$sl-base1};
  --bulma-text-strong: #{$sl-base1};

  --bulma-scheme-main: #{$sl-base03};
  --bulma-scheme-main-bis: #{$sl-base02};
  --bulma-scheme-main-ter: #{$sl-base02};

  --bulma-scheme-h: 192;
  --bulma-scheme-s: 100%;
  --bulma-scheme-l: 11%;

  --bulma-background-l: 11%;

  --bulma-scheme-main-s: 100%;
  --bulma-scheme-main-bis-s: 100%;
  --bulma-scheme-main-ter-s: 100%;
  --bulma-scheme-main-l: 11%;
  --bulma-scheme-main-bis-l: 11%;
  --bulma-scheme-main-ter-l: 11%;

  --bulma-code: #{$sl-base0};

  --bulma-hr-background-color: #{$sl-base01};

  --bulma-border: #{$sl-base01};
}

@media (prefers-color-scheme: light) {
  :root {
    @include light-theme();
  }

  [data-theme="dark"] {
    @include dark-theme();
  }
}

@media (prefers-color-scheme: dark) {
  :root {
    @include dark-theme();
  }

  [data-theme="light"] {
    @include light-theme();
  }
}

// NOTE: adjust non-parameterized styles.
.content a {
  text-decoration: underline;
}
a:visited {
  color: $purple;
}
.checkbox {
  margin-right: 0.5em;
}
main {
  padding-bottom: 1.5em;
}
code {
  word-wrap: break-word;
}
code,
pre,
.tag:not(body),
a.button {
  border: 1px solid $sl-base01;
  border-radius: $radius;
}
pre code {
  border: none;
  line-height: 1.5;
}
.content {
  li:first-child {
    margin-top: 0.25em;
  }
}
.date {
  color: $sl-base01;
}
.prev a:before {
  content: "\2190";
}
.next a:after {
  content: "\2192";
}

とりまこっから個々の *.scss を @use するように変えてみて、 bundle を縮小したい。いま 68.7kb もあってやっぱデカいなと思わせるものがある。

あと手動で light/dark mode を切り替える実装について。

ドキュメントにも記載あるが、 Bulma の automatic dark mode は prefers-color-scheme の media query を使ってる。そこで利用者自身が light/dark mode を使い分けるには data-theme="dark" を指定するようにしないとダメっぽい。先に挙げた SCSS で [data-theme="dark"] { ~ } 等としているのはそのためだ。システムのカラースキームに合わせて反対の色を定義しないといけないのが、わかるまでちょっとつまづいた。

このあと、 HTML に data-theme="dark" や data-theme="light" を差し込む機能を、画面のどっかに設ける必要がある。 ↓ こういうのを Fable で作らないといけない。

document.documentElement.setAttribute("data-theme", "dark");

はじめはどうなるかと不安に思ったが、気合い入れたら終わり見えて良かった。

Bulma も 1.0.0 が出たばかりだしちょっとの間は更新リリースが続くんじゃないかな。テクノロジー的に「枯れる」というのは確かにあるが、取り巻く環境の変化に合わせて rewrite されていくのは良いことやな。素直に尊敬するわ。 blog-fable でも自力での対応を放置してた light/dark mode に棚ぼたであやかれて嬉しい限り。

つづく。

Coverlet の XPlat て何だよ

Sun, 17 Mar 2024 09:00:00 +0900

久しぶりに大酒を飲んでボロボロの二日酔いになってしまったので、 krymtkts/pocof の開発をできなかった。

代わりに、ずっと気になってた coverlet のキーワードの正体を調べた。 Coverlet を起動する dotnet test --collect:"XPlat Code Coverage" の "XPlat Code Coverage" が何なのかを知りたかった。世の中は広いので、同じことを考えた人が先にいた。ありがたい。

What is "XPlat Code Coverage" · Issue #1065 · coverlet-coverage/coverlet

vstest/src/vstest.console/Processors/CollectArgumentProcessor.cs at 724f79b5f4fb4ad33c5c6411ea74b31aea6e8776 · microsoft/vstest

    internal static class CoverletConstants
    {
        /// <summary>
        /// Coverlet in-proc data collector friendly name
        /// </summary>
        public const string CoverletDataCollectorFriendlyName = "XPlat Code Coverage";

        /// <summary>
        /// Coverlet in-proc data collector assembly qualified name
        /// </summary>
        public const string CoverletDataCollectorAssemblyQualifiedName = "Coverlet.Collector.DataCollection.CoverletInProcDataCollector, coverlet.collector, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null";

        /// <summary>
        /// Coverlet in-proc data collector code base
        /// </summary>
        public const string CoverletDataCollectorCodebase = "coverlet.collector.dll";
    }

ふーむ、 VSTest が決め打ちしている coverlet.collector を起動するキーワードなのはわかったが、結局 XPlat て何？

Use code coverage for unit testing - .NET | Microsoft Learn

The "XPlat Code Coverage" argument is a friendly name that corresponds to the data collectors from Coverlet. This name is required but is case insensitive. To use .NET's built-in Code Coverage data collector, use "Code Coverage".

フレンドリーな名前とは...

それはおそらくこちらが答えなんだろうなと思っている。

vstest/docs/contribute.md at 724f79b5f4fb4ad33c5c6411ea74b31aea6e8776 · microsoft/vstest

- A portable `vstest.console` for desktop (net46 target) and xplat (netcoreapp)
  target

.NET の Desktop と NETCoreApp の対比から考えて、結局 XPlat て cross platform てことやねんな。そう思って検索してみたら cross platform て意味で使ってる例がいくつか見つかる。一般的なキーワードなんだろうか。こんなん不惑超えるまで知らんかったわ...

おわり。

F# でコマンドレットを書いてる pt.35

Sun, 10 Mar 2024 09:00:00 +0900

krymtkts/pocof の開発をした。

ちょっと今週末は忙しかったのでクエリ文字列選択の開発をあまりできてない。

時間が取れなかったので車の後部座席に乗りながら pocof 開発を 2 時間ほどやってみたのだけど、それなりに準備しないといけないが、思ったよりできるなという感触を得た。助手席のヘッドレストにリュックの背中の部分が上になるようリュックを片方かける。そこに laptop を置き、下から膝でサポートすれば割りと安定する。ケチってテザリングしなかったので GitHub Copilot の支援は受けれなかったが、支援なくなったてもまだ割と書けるなという感じも得た。

ただし高速に乗ってるときくらいじゃないと揺れでとてもタイピングできないし、あと夜間はわたしの目が悪いのもあって、結構しんどい感じだった。

という感じで進捗あまりないが、 ANSI escape sequences 対応の前準備として、手軽にできるレンダリングの改善だけしたのでそれに触れる。 #149

PSReadLine/PSReadLine/ReadLine.cs を見てて気づいたのだけど、描画中は Console.CursorVisible を false にしてる。

            var console = _singleton._console;
            console.CursorVisible = false;

            // 略
            _singleton.Render();
            console.CursorVisible = true;
        }

GUI アプリケーションなんかでもよくある手法で、描画の状態が決定するまで描画停止するアレと同じ手法だこれ。 CUI アプリケーションの場合だと、カーソルのチラつき(flicking と表現するぽい)を抑えるために同じ手法が使えるみたい。 CPU 負荷が高い時にノロノロとカーソルが移動することでチラつき(flicking)が目に付きやすくなるので、カーソルを見えなくすることでチラつき(flicking)をなくす効果があると。なるほどなー、すっかり忘れてたわ。

実際に pocof の CPU 高負荷時のもっさり挙動でチラつきが目立つので、 IDisposable 実装を使って以下の様に対処した。目立つチラつき(flicking)は抑えれそう。

    type RawUI(rui) =
        // Console.CursorVisible を一時的に無効にする
        interface IRawUI with
            member __.HideCursorWhileRendering() =
                Console.CursorVisible <- false

                { new IDisposable with
                    member _.Dispose() = Console.CursorVisible <- true }

    type Buff(r, i, layout) =
        let rui: IRawUI = r

        // 使う方はこうする
        member __.WriteScreen
            (layout: Data.Layout)
            (state: Data.InternalState)
            (entries: Data.Entry list)
            (props: Result<string list, string>)
            =
            use _ = rui.HideCursorWhileRendering()

ちなみに実際のパフォに違いがあるのかというと、調べてみた感じだと微妙だった。以下のようなテスト関数を作成しまして、 1 行ずつ書くパターン、 1 文字ずつ書くパターンを比較した。

function test-rendering {
    param (
        [switch]
        $HideCursor,
        [switch]
        $HardMode
    )
    if ($HideCursor) {
        [Console]::CursorVisible = $false
    }
    [Console]::SetCursorPosition(0, 0)
    $start = Get-Date
    0..30 | % {
        [Console]::SetCursorPosition($_, $_)
        if ($HardMode) {
            # 1 文字ずつ描画する激遅モード
            $_ .. ([Console]::WindowWidth - 1) | % { [Console]::Write('x') }
        }
        else {
            # 1 行ずつ描画する普通モード
            [Console]::Write(('x' * ([Console]::WindowWidth - $_)))
        }
    }
    ((Get-Date) - $start).Milliseconds
    if ($HideCursor) {
        [Console]::CursorVisible = $true
    }
}

# それぞれを無風状態のときに実行
$a1 = 1 .. 100 | % { test-rendering } | measure -AllStats
$a2 = 1 .. 100 | % { test-rendering -HideCursor} | measure -AllStats
$b1 = 1 .. 100 | % { test-rendering -HardMode } | measure -AllStats
$b2 = 1 .. 100 | % { test-rendering -HardMode -HideCursor} | measure -AllStats

$a1;$a2;$b1;$b2;

# Count             : 100
# Average           : 5.05
# Sum               : 505
# Maximum           : 10
# Minimum           : 3
# StandardDeviation : 1.50671895859912
# Property          :

# Count             : 100
# Average           : 4.96
# Sum               : 496
# Maximum           : 10
# Minimum           : 3
# StandardDeviation : 1.43491808093351
# Property          :

# Count             : 100
# Average           : 216.31
# Sum               : 21631
# Maximum           : 283
# Minimum           : 196
# StandardDeviation : 19.5596446023361
# Property          :

# Count             : 100
# Average           : 221.2
# Sum               : 22120
# Maximum           : 297
# Minimum           : 196
# StandardDeviation : 20.8810967628667
# Property          :

結果、カーソル非表示の有無で誤差レベルの差しかない。実行したときの CPU 利用状況の影響のほうがでかい。なので体感の改善って面が大きい。

おわり。

F# でコマンドレットを書いてる pt.34

Sun, 03 Mar 2024 09:00:00 +0900

krymtkts/pocof の 0.10.0 をリリースした。

pocof 史上初の全画面スタイルを廃止する Half モード(TopDownHalf, BottomUpHalf) の導入は、自分自身使ってみてやっぱいいなという感じがしてる。挙動が PSReadLine チック過ぎて、わたしがやりたかったのは Feedback Providers¹ やったんかも...というのはあるかも。

あと FSharpLint, Fantomas, PSScriptAnalyzer 諸々チェックするようにしたので開発の安心感も高まった。

次に着手している開発は #44 Support query string selection だ。わたしのタイピングだと、変えたい箇所を選択して backspace, delete, あるいはそのままタイプして変えることが多い(あと Ctrl + Arrow で移動するのも多いけどこれは保留)。いま pocof には文字列を選択する機能がないから、通常のエディタと pocof で編集の仕方が違うのでめんどい。これも個人的に期待度の高い機能となっている(放置してたけど)。

この機能を作るに当たり、 CUI の前景色と背景色を反転する必要がある。そして PowerShell で CUI の色を操作する方法が 2 つあるのは理解している。具体的なコードとかは雑な理解だったので今回見てみた。あと他の方法があるかも知れないが、それは調べてない。

1 つは Console.ForegroundColor Console.BackgroundColor を直にいじる方法。変えた色を戻すのに Console.ResetColor を使う。

# Powerline を使ってると動作確認困難なので繋げて実行する
$tmp = [Console]::BackgroundColor; `
[Console]::BackgroundColor = [Console]::ForegroundColor; `
[Console]::ForegroundColor = $tmp; `
[Console]::Write("こんちはーっ!!`n"); `
[Console]::ResetColor(); `
[Console]::Write('ザバーッ');

もう 1 つは ANSI escape sequences を直に使う方法。 PowerShell 直で使うと `e が ANSI escape sequence 。 [Escape (`e) | about Special Characters - PowerShell | Microsoft Learn](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_special_characters?view=powershell-7.4#escape-e)

`e7m で反転、 `e[27m で元に戻すらしい。 Using ANSI Escape Sequences in PowerShell :: — duffney.io

1 つ目と完全に同じではないが、よりできることが多い。その代わり先に挙げた個々の ANSI Escape Sequence を理解して使う必要があり、~~めんどさ~~制御の煩雑さが伴う。

[Console]::Write("`e[7mこんちはーっ!!`e[27m`nザバーッ")

2 つ目の利点は ANSI Escape Sequence を組み込んだ文字列さえ組み立ててしまえば、一発で印字できるところ。 pocof での用途を鑑みると、クエリ文字列の部分選択をした箇所だけ前景背景を反転させる必要があるので、そのためだけに印字を分割しなければならない前者は採用できないかなーというのがでかい。

( 現に今の pocof のもっさりレンダリングは書き込み回数が小分けされてることに因る... PSReadLine パイセンは一気に印字スタイルぽいので、ふつーそっちに寄せるのが一般的なんやろな PSReadLine/PSReadLine/Render.cs )

ちょいと前例というか PSReadLine パイセンを調べたところ、こちらも ANSI Escape Sequence を使っていた。なので方向性は合ってる。 PSReadLine は VSColorUtils というクラスにその辺こ ANSI escape sequences をまとめて使ってる。 pocof でもそんな多機能はいらんにしてもまとめる必要はあるかな。

F# で書く場合、 ANSI Escape Sequence は PowerShell と違って C# と同じように \x1b を送るのが一般的ぽい。 C# では \e を ANSI escape sequence に使える機能が増えてる様子。だが機能が新し過ぎるのもあってか、昔からやってる PSReadLine では直に ANSI escape sequence を送る \x1b を使ってるようだ。

[Proposal]: String/Character escape sequence \e as a short-hand for \u001b (<ESCAPE>) · Issue #7400 · dotnet/csharplang

これらを踏まえて F# でやるなら以下の形式の出力を、なんかの抽象化層を通してやる感じか。

Console.Write("\x1b[7mこんちはーっ!!\x1b[27m\nザバーッ");;

あとはどっからどこまでを反転するかの選択範囲を pocof 内部の状態に追加して、 Handle.fs でキーに応じてよしなに更新操作するってところかー。

とりま方針は定まったな。ついでにレンダリング効率悪いのも解決できたらなんか使い勝手良さそう(今クソ遅いし)。

続く。

What are Feedback Providers? - PowerShell Team ↩

F# でコマンドレットを書いてる pt.33

Sun, 25 Feb 2024 09:00:00 +0900

krymtkts/pocof の開発をした。

FSharpLint を入れたのでついでに Fantomas も入れてみた。 #145

これまで VS Code の Ionide での整形しかやってなかったが、それを機械的に CI でもチェックしようかなという考えだ。実際 fantomas 入れてみたことで Ionide でファイル保存したときの整形も変わったので、なんか進化したのかも知れん。 pocof での fantomas の設定は以下の通りほとんどない(以下もデフォルト値でほぼ要らんレベル)。

[*.{fs,fsx,fsi}]
indent_size = 4
end_of_line = lf

個人的にはあまりコードフォーマットに独自性をもたせることは興味がなく、誰が書いても同じになるのが考えることも減って楽でいいと思っている。なので標準的な何かにさえ準拠してそれが自動的に適用されていればよい。

F# のコードフォーマットに関しては以下のスタイルガイドのページがある。 F# code formatting guidelines - .NET | Microsoft Learn

The Fantomas code formatter is the F# community standard tool for automatic code formatting. The default settings correspond to this style guide.

とのことなので、スタイルダイドのお墨付きがある fantomas を使えばそれを簡単に手に入れることができる。

fantomas を導入したことで意外に「あ、そこの改行もなくなるわけ？」みたいな整形は結構あった。が、それは気づかないうちに自己流の何かを入れてたわけであり、ある意味導入によってデトックスできたなという気がする。

あと思わぬ収穫として Ionide の挙動が fantomas の有無で変わるのを確認できた。具体的には先述した fantomas 導入前後で改行がなくなるようフォーマットされたケースだ。 1 行あたりの文字数が上限未満なら改行を取り払っている様子。以前は Ionide 内臓の fantomas で整形されてると思ってたが、先述の通りインデントのサイズと改行コードの指定しかなくてそれが変わるのなら、なんかのエッセンスが入ってるのか？これはちょっと気持ちが悪いので、後追いでも調べたいところ。

F# のフォーマットを入れたのもあって、ついでに PSScriptAnalyzer で psake のファイルと Pester のファイルも整形する気になった。これらも普段は VS Code の PowerShell 拡張に任せっきりだったが、 CI で整形済みかチェックできるようにした。 #146

PSScriptAnalyzer でちょっと面倒だったのが、 PowerShell 拡張が PSScriptAnalyzer のどのルールでチェック・整形されているか分からなかったところだ。なんかのデフォルト + 追記した powershell.codeFormatting.* 拡張機能のオプションが反映されてるっぽい。あんまり真面目に使ったことなかった、すまん PSScriptAnalyzer ... でも今回色々調べたお陰でルールの作り方がわかった。

PSScriptAnalyzer は、設定を指定しないデフォルトで全ルールのチェックをしてくれるのでそれが一番楽だが、ルールを調整したいときは設定を自前で用意しないといけない。以下のドキュメントにルールの一覧があるが、その中から必要なものを 1 つずつコピるのは苦行すぎる。

List of PSScriptAnalyzer rules - PowerShell | Microsoft Learn

その場合に楽なのは、 PSScriptAnalyzer に見込みのデフォルトルールをコピって、必要な変更を加える方法だ。 pocof では v1.21.0 の CodeFormatting.psd1 ↓ を流用し、 AlignAssignmentStatement を無効化する等の調整をした。 PSScriptAnalyzer/Engine/Settings/CodeFormatting.psd1 at 1.21.0 · PowerShell/PSScriptAnalyzer

AlignAssignmentStatement を有効化していたら ASCII ならキレイにフォーマットされるが、マルチバイト文字があるとその途端ぐちゃぐちゃになる。これは PSScriptAnalyzer が悪いのではなく、 Go やその他の言語の alignment も同じなので、非英語圏の言語だけの問題なのかも知れない。というわけで好きじゃないオプションなので、基本無効化する。 pocof でもそうした。この件は昔ブログに書いた。 krymtkts - East Asian な全角文字をキーに使った場合のアラインメントについて考える

このように作成した設定を読み込ませる方法は、明示的な方法と暗黙的な方法の 2 つある。 PSScriptAnalyzer は Path オプションで検査対象のスクリプトを指定する。その指定した Path のディレクトリに PSScriptAnalyzerSettings.psd1 があれば暗黙的な設定として読み込まれる。

Using PSScriptAnalyzer - PowerShell | Microsoft Learn

If you place a settings file named PSScriptAnalyzerSettings.psd1 in your project root, PSScriptAnalyzer discovers it when you pass the project root as the Path parameter.

pocof では検査したいスクリプトは 2 つしかなく、しかも別の場所にあるので明示的に Settings で設定を読み込ませるようにした。

あと PSScriptAnalyzer の CI でのコケさせ方だが、チェック結果が 1 件以上あれば以上があると判定するようにした。これはほんとにこれでいいのかよくわからないが、失格したチェックがあってもエラーコードが変わらないし。少なくともチェックに失格したものがあれば結果が出力されるので、多分あってる。

Task Lint {
    dotnet fsharplint lint "${ModuleName}.sln"
    if (-not $?) {
        throw 'dotnet fsharplint failed.'
    }
    dotnet fantomas ./src --check
    if (-not $?) {
        throw 'dotnet fantomas failed.'
    }
    # これでいいのか...
    $warn = Invoke-ScriptAnalyzer -Path .\psakefile.ps1 -Settings .\PSScriptAnalyzerSettings.psd1
    if ($warn) {
        throw 'Invoke-ScriptAnalyzer for psakefile.ps1 failed.'
    }
    $warn = Invoke-ScriptAnalyzer -Path .\tests\pocof.Tests.ps1 -Settings .\PSScriptAnalyzerSettings.psd1
    if ($warn) {
        throw 'Invoke-ScriptAnalyzer for pocof.Tests.ps1 failed.'
    }
}

これでもう機能開発以外の逃げ道はなくなったし、ほんとに pocof 0.10.0 リリースしよう。あとはガチの未実装機能を実装していくだけ。もう寄り道はなしにしよう(どの口が言うか)。

F# でコマンドレットを書いてる pt.32

Sun, 18 Feb 2024 09:00:00 +0900

krymtkts/pocof の開発をした。

前回以降バグつぶしや更新漏れに対応した。 #138 で TopDownHalf の境界値バグ修正、 #139 で長らく放置してた日付のフィルタリングバグ修正をした。そんでこれまた放置気味だったドキュメント更新を #140 でやった。

#139 の原因は早い話ローカライズされるべきところがされてなかったことによる。あんまり理解してなかったことなので、ここに改めてメモを残すことにする。

事象としては、わたしの環境で Get-ChildItem | pocof したときに、日付を表記通り絞り込めないというバグだった。プロ .NETer なら多分コレだけで気づくのだろうけど、これは System.DateTime.ToString がカルチャの書式情報を利用するためだった。

F# の string で System.DateTime に対して使うとカルチャ情報に依存しない形で文字列に変換される。 fsharp/src/FSharp.Core/prim-types.fs · dotnet/fsharp

             when 'T : DateTime       = let x = (# "" value : DateTime #) in x.ToString(null, CultureInfo.InvariantCulture)

かたや PowerShell は通常カルチャ情報に依存した文字列を表示するので異なる結果になる。

わたしの環境はちょっとしたこだわりのせいでカルチャ情報をいじっており、 [System.Threading.Thread]::CurrentThread.CurrentCulture は "en-US" 相当で、 [System.Threading.Thread]::CurrentThread.CurrentCulture.DateTimeFormat.ShortDatePattern を yyyy-MM-dd に変えてある。 ([System.Threading.Thread]::CurrentThread.CurrentCulture.DateTimeFormat.DateSeparator も "-")

そのためわたしの環境では System.DateTime.ToString と F# の string System.DateTime はこんな感じで異なる結果になる。

> System.DateTime.Now.ToString();;
val it: string = "2024-02-12 17:15:15"

> string System.DateTime.Now;;
val it: string = "02/12/2024 17:15:22"

ふつーに理解してなかったので pocof では string System.DateTime してたから、 PowerShell で想定される出力と全然違ってたわけだ。コレを機にローカライズされた文字列でフィルタリングされるように直ったハズ。

無知は怖いね。

あと CI でも FSharpLint を使ってみたかったので試してみている。普段は Ionide で linting されるのを見てるがやはり自前でルールを用意した上で CI でも見たい。早速試してみたところ、最新の 0.24.0 だと .NET 8 で実行できない issue があるようだった。

Execution fails when using dotnet 7.x or 8.x to target net6.0 project · Issue #687 · fsprojects/FSharpLint

issue にあるように prerelease の 0.24.1--date20240212-1103.git-08ceae7 どっちも試したがダメ。これは導入諦めて様子見しかないか？と思ったが Ionide の方はなんでうまくいってんのかなと調べてみた。どうも FsAutoComplete で使ってる FSharpLint.Core の version がちょいと古い 0.21.2 なら大丈夫みたい。 packet の lockfile がそんな感じだった。 FsAutoComplete/paket.lock · fsharp/FsAutoComplete

0.21.x 系なら行けるのかと思いきや 0.21.3 と 0.21.10 試してもエラー。 System.Runtime 云々出ているので先述の issue に関連するんやろか。ひとまず linter 導入が先なので、深追いせず一旦ここで留めておく。宿題ということで。

0.24.0 で出るエラー。

Module: pocof ver0.9.0 root=C:\Users\takatoshi\dev\github.com\krymtkts\pocof\src\pocof\ publish=C:\Users\takatoshi\dev\github.com\krymtkts\pocof\publish\pocof\
Executing Lint
Unhandled exception. System.TypeInitializationException: The type initializer for 'FSharpLint.Console.Program' threw an exception.
 ---> System.TypeInitializationException: The type initializer for '<StartupCode$dotnet-fsharplint>.$FSharpLint.Console.Program' threw an exception.
 ---> System.TypeInitializationException: The type initializer for '<StartupCode$Ionide-ProjInfo>.$Library' threw an exception.
 ---> System.ComponentModel.Win32Exception (2): An error occurred trying to start process 'C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe' with working directory 'C:\Program Files (x86)\Microsoft Visual Studio\Installer'. The system cannot find the file specified.
...

0.24.1--date20240212-1103.git-08ceae7 で出るエラー。

Module: pocof ver0.9.0 root=C:\Users\takatoshi\dev\github.com\krymtkts\pocof\src\pocof\ publish=C:\Users\takatoshi\dev\github.com\krymtkts\pocof\publish\pocof\
Executing Lint
Lint failed while analysing pocof.sln.
Failed with: Could not load file or assembly 'System.Runtime, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
Stack trace:    at Ionide.ProjInfo.ProjectLoader.loadProject(String path, BinaryLogGeneration binaryLogs, FSharpList`1 globalProperties)
...

0.21.3 で出るエラー。

Failed to parse file C:\Users\takatoshi\dev\github.com\krymtkts\pocof\src\pocof.Test\Pocof.fs
Exception Message:
The exception has been reported. This internal exception should now be caught at an error recovery point on the stack. Original message: A reference to the type 'System.Runtime.Serialization.ISerializable' in assembly 'System.Runtime' was found, but the type could not be found in that assembly)
Exception Stack Trace:
...

0.21.2 を使う workaround がうまくいったので、 dotnet fsharplint lint pocof.sln で実行してテストコード含めた全体をチェックすることにする。ドキュメントに書いてた通りディレクトリは対応してないみたいで、 pocof.sln を渡すことにした。間違った情報を渡してもエラーにならずサンプル的なのが出る。ちょっとわかりづらい。

> dotnet fsharplint lint ./src/pocof
========== Linting /home/user/Dog.Test.fsx ==========
========== Finished: 0 warnings ==========
========== Summary: 0 warnings ==========

warning があると return code が 0 じゃなくなるみたい。 $? = False になるみたいなのでそういう psakefile.ps1 にしといたら task runner への組み込みも容易そう。とりま GitHub Actions への組み込みまで目標にやってみるか。

F# でコマンドレットを書いてる pt.31

Sun, 11 Feb 2024 09:00:00 +0900

krymtkts/pocof の開発をした。

前回触れた PSReadLine スタイルのコンソールウィンドウ操作を実装したり、 query window の時間計算量を対数時間 O(logn) にしたり。それらを含む pocof version 0.9 をリリースした。

いまは高さ半分サイズの UI を実装して、その後の調整や coverage を改善したりしてる。高さ半分サイズの UI は TopDownHalf, BottomUpHalf という Layout オプションで使えるようにした。なかなか良いが、端末の高さが変わった場合のレンダリング崩れをどうするかが悩ましく、まだ 0.10.0 リリースはしてない。

端末の高さが変わった場合のレンダリング崩れは半ば諦めてる。 PSReadLine でも似たようなレンダリング崩れは起こるしな。ただ個人的に TopDownHalf, BottomUpHalf の実装してみて顕著に見えるようになったので気になりはじめた...

Layout オプションが TopDownHalf か BottomUpHalf の場合、コンソールウィンドウの高さの半分に相当する空行をカーソル位置から挿入し、 pocof 用の UI を用意する。この高さの半分というのが難しくて、初期表示から終了までにコンソールウィンドウのサイズが変更されて高さが違うこともある。そのためいずれも現在のコンソールウィンドウの高さを基準に操作する必要がある。例えば元々高さ 100 だった場合、コンソールウィンドウの高さを縮めて 50 にしたあと終了処理をしたら、残り 50 にはコンソールウィンドウを縮める前に描画したコンテンツが残っている可能性がある。

例えば Windows Terminal の場合だと、概ねカーソル位置を上端にして下方向に描画されたコンテンツが取り残される。また pane を上限分割してサイズ変更するなどで下端からカーソル位置までの高さより縮めた場合にカーソル位置が移動されることがあって、その場合はカーソル位置より前(コンソールウィンドウの外)にコンテンツが取り残されることもある。そうなると pocof は何も手出しできなくなる。下方向の残骸は終了処理で画面下端までを初期化すればよいのでなんとかカバーできるが、カーソル位置が強制移動された場合はもうどうにもならん。

長々と書いたが操作中にコンソールウィンドウのサイズ変更をそんなにするか？というのもあるし、いったんこのままかなあ。閃きが訪れるまで座して待つか。

coverage 改善についてはアプリケーションそれ自体の品質には寄与しないが、開発側の安心感やコンプ率欲求のような気持ちみたいなもんをアゲてくれる。なのでひとまず 90 % 超えときたいなと言うのが最近の目標だった。 pocof は branch coverage についてはそれほど高くないけど line coverage に関してはなるべく網羅したくて取り組んできた。でも PSCmdlet の実装部分は難しくて放置してきた。今回そこに手を入れようと考えた。

Cmdlet Class 実装の場合は、自前の ICommandRuntime 実装を渡せさえしたら手軽に実行できるようだった。

Unit Testing Powershell Cmdlets in C# - Fotsies Technology Blog

でも PSCmdlet はそう簡単にいかず、 Invoke すれば Cmdlets derived from PSCmdlet cannot be invoked directly. を返す。 PowerShell は一筋縄ではいかないんだ。

Invoking Cmdlets and Scripts Within a Cmdlet - PowerShell | Microsoft Learn

All cmdlets can invoke an existing cmdlet by calling the System.Management.Automation.Cmdlet.Invoke method from within an input processing method, such as System.Management.Automation.Cmdlet.BeginProcessing, that is overridden by the cmdlet. However, you can invoke only those cmdlets that derive directly from the System.Management.Automation.Cmdlet class. You cannot invoke a cmdlet that derives from the System.Management.Automation.PSCmdlet class.

であれば自前でテスト機構を作るしかないということで、考えてみた。

まず以下を継承・実装して mock を作る。これらを PSCmdlet 実装に差し込めばいい。これらの実装は利用する箇所以外重要でないので雑でいい。コードが長いし退屈なので省略する。

次に PSCmdlet 実装を継承してテスト用のメソッドを生やす。 Cmdlet の肝となる BeginProcessing, ProcessRecord, EndProcessing は public にアクセスできないので、テスト用のメソッドでまとめて呼び出すようにする。このやり方の場合 ICommandRuntime 実装から PSHost を PSCmdlet 実装の PSCmdlet.Host Property に渡せない。 PSCmdlet.Host は get のみのプロパティなので、あとから set もできない。なので自前でどうにかする術が必要になる。

pocof の場合は PSCmdlet.Host を PSCmdlet の実装箇所で参照しているのと、あと PowerShell の処理を呼び出している箇所もある。それらを mock できるようにするため abstract と default で再定義可能なメソッドに落とし込んでみた。

以下のようになる。

module SelectPocofCommand =
    open Xunit
    open FsUnitTyped
    open pocof
    open System.Management.Automation
    open System.Management.Automation.Host

    type SelectPocofCommandForTest() =
        inherit SelectPocofCommand()
        // SelectPocofCommand で以下を定義しておく
        // abstract member invoke: 'a list -> string seq
        // abstract member host: unit -> PSHost

        member val Host: PSHost = new Mock.MyHost()
        override __.invoke(input: 'a list) = input |> Seq.map string
        override __.host() = __.Host

        member __.InvokeForTest() =
            __.BeginProcessing()
            __.ProcessRecord()
            __.EndProcessing()

    [<Fact>]
    let ``invoke.`` () =
        let runtime = new Mock.CommandRuntime()
        let cmdlet = new SelectPocofCommandForTest()

        let a = PowerShell.Create()

        cmdlet.CommandRuntime <- runtime // ないと WriteObject 未実装のエラーになる
        cmdlet.InputObject <- [| PSObject.AsPSObject "a" |]
        cmdlet.NonInteractive <- true
        cmdlet.InvokeForTest()

        runtime.Output |> shouldEqual [ "a" ]

なんやややこしい感じの実装をして、なおかつ暴力的な解決方法ではあるが、これでなかなかうまくテストできる。結構手こずったが、 PSCmdlet 実装の理解も深まった。ずっと面倒で放置していた PSHostRawUserInterface の mock 実装もやればできなくないなとわかり、結構手応えのある学びになった。

そろそろ 0.10.0 リリースするかな。

Standard Notes を使いはじめた

Sun, 04 Feb 2024 09:00:00 +0900

去年末頃から Standard Notes を使いはじめた。

長らく Evernote を使ってたのだけど、 E2E Encryption 対応したメモサービスに乗り換えたいとずっと思ってた。思い立ったのは 2023 入った頃だったような記憶。

Evernote をずっと使ってたのは、汎用的なテキストエディタからアクセスできる拡張機能があったからだ。昔 SublimeText 2 ~ 3 を使ってた頃は Evernote の拡張機能があって(bordaigorl/sublime-evernote かな？)とても優秀な拡張機能だった。 VS Code ではそこまで優秀じゃないが michalyao/evermonkey があって、もうアクティブにメンテされてないが最近でもパッチを当てたら使えるので重宝してた。 Patched version of converterplus.js of evermonkey.

普段遣いするエディタからメモを探せたり書き足せたりできる体験は控えめに言っても最高で、とにかく便利なのだ。

でもいい加減サービス乗り換え時かなと感じて色々調べていた。 Obsidian は課金すれば E2E Encryption を得られるけど、 VS Code から利用できないので汎用的なエディタからのアクセスを諦める必要があった。他に Skiff は無課金で E2E Encryption が得られるが汎用的なエディタを持ってなかった。 OSS なので気合を入れたら CLI コマンド作ったり VS Code 拡張作れるかな？と思ったが結構重いタスクやなあと思って気が乗らず。あとメモを置きたいだけなのに対してサービスが多いのも気になった(メールのエイリアス機能は超便利なので調査とかで使ったりする)。

そうこうしているうちに 2023 後半頃、なんのきっかけか忘れたが Standard Notes を知った(スラドのコメントでかな？)。無課金で E2E Encryption が得られるのと、 OSS で CLI が既にあって、これはいけそうやなと確信した。 jonhadfield/sn-cli: a command line interface for standard notes

試しに sn-cli をちょっとの間使ってみたけど、結構いい感じがする。 CLI でデータが抜けさえすれば VS Code にそれを投げるのも容易いから、ひと手間増えるが便利なのには変わりない。もっとこなれてきたら sn-cli に依存した VS Code 拡張を書くなんかも考えられる。全部フルで作るよりは重くないだろう。

sn-cli の利用に際して、 README.md に書かれてるのとは違うインストール方法にしているのと、PowerShell で便利関数の提供をしている感じ。

インストールはバイナリをダウンロードするのがだるいので、 go install で latest をビルドしている。他にも Go 系のツールをまとめて install / update する関数を PowerShell にこさえていたので、そこにパスを足しただけ。

function Install-GoModules {
    $mods = @(
        'github.com/x-motemen/ghq@latest'
        'mvdan.cc/sh/v3/cmd/shfmt@latest'
        'github.com/jonhadfield/sn-cli/cmd/sncli@latest'
    )
    $mods | ForEach-Object {
        $start = $_.LastIndexOf('/') + 1
        $name = $_.Substring($start, $_.Length - '@latest'.Length - $start)
        if (-not (Get-Command "*$name*" -ErrorAction SilentlyContinue)) {
            go install $_
        }
    }
}

function Update-GoModules {
    if (-not (Get-Command go -ErrorAction SilentlyContinue)) {
        Write-Error "Install go with command below. 'choco install golang -y'"
        return
    }
    ll $env:GOPATH/bin | ForEach-Object {
        go version -m $_
    } | Where-Object {
        $_ -like '*path*'
    } | ConvertFrom-StringData -Delimiter "`t" | Select-Object -ExpandProperty Values | ForEach-Object {
        go install "${_}@latest"
    }
}

この方法だとビルド後のコマンドの名前が変わってしまうので、そこは Set-Alias で吸収する。あと autocomplete を作っておいたのと、まだ貧弱だが Standard Notes の note を開くための関数を作成した。

2023 末は bash の autocomplete しかなかった。依存パッケージの urfave/cli が古いものを使ってたからだ。 PowerShell の autocomplete は bash のものをそのまま使えるから自分で書いた。でも今日見たら PowerShell 版も提供されてた。 sn-cli/autocomplete/powershell_autocomplete.ps1

Set-Alias sn -Value sncli -Option AllScope
if (Get-Command -Name sn -ErrorAction SilentlyContinue) {
    Register-ArgumentCompleter -Native -Command sn -ScriptBlock {
        param($wordToComplete, $commandAst, $cursorPosition)
        Invoke-Expression "$commandAst --generate-bash-completion" | ForEach-Object {
            [System.Management.Automation.CompletionResult]::new($_, $_, 'ParameterValue', $_)
        }
    }

    # NOTE: require `sncli session --add` before use this.
    function Open-SnNotes {
        param (
            [Parameter(Mandatory,
                Position = 0,
                ValueFromPipeline = $true,
                ValueFromPipelineByPropertyName = $true)]
            [ValidateNotNullOrEmpty()]
            [String]
            $Title
        )
        $n = sn --use-session get note --title $Title
        if ($n -and ($n -notlike 'no matches*')) {
            $n | ConvertFrom-Json | Select-Object -ExpandProperty items | ForEach-Object {
                $_.content.text
            } | code -
        }
    }
}

この sn-cli の難点があるとしたら、それは検索ワードを入れないと全件ノートを取ってしまうところ。そのあたりは PowerShell の関数でカバーできるから、もうちょっと制限を入れていきたい。考えてみたら複数ノートから対象を選ぶのは krymtkts/pocof と相性良さそう。あとメモの追加と更新あたりの PowerShell 関数も書いていきたい。

今は Evernote のメモの中でも重要なやつだけを Standard Notes に移行した段階で、まだ両方とも利用している。移行ツールも OSS であるのでそれを使ってもいいのだけど、この際なのでメモの棚卸し兼ねていまは手動でちまちま移している感じ。全部終わった暁には先に上げた関数を実装して、 VS Code での利用もこなれてきたら更にその先へ、って感じかなー。

Oh My Posh のテーマを更新する 2024

Sun, 28 Jan 2024 09:00:00 +0900

Oh My Posh が PowerShell だけの v2 から multi shell な v3 になったあと、 PowerShell から JSON の設定に乗り換えた。 2 年ほど前に JSON の自分テーマを作って以降放置してた。 My own oh-my-posh v3 theme.

その後設定ファイルに JSON だけじゃなく YAML や TOML のサポートもされたのから随分時間が経った。 JSON もシンプルで良いのだけど、いかんせん最後の要素のカンマ調整がめんどくて。個人用途ならまず避けたい。この機会に設定が微妙な部分とか、 JSON を YAML か TOML のどっちかに変えようと思った次第。

PowerShell はデフォで ConvertFrom-Json, ConvertTo-Json がある。更に現時点の PowerShell Gallery には powershell-yaml 0.4.7 と PSToml 0.1.0 がある。 JSON を YAML や TOML に変換するのは容易い。

Oh My Posh の設定ファイルを変換するには以下のようにする。

# JSON to YAML.
Get-Content "$env:USERPROFILE/.oh-my-posh.omp.json" | ConvertFrom-Json | ConvertTo-Yaml | Set-Content -Path "$env:USERPROFILE/.oh-my-posh.omp.yaml"

# JSON to TOML. use Depth option to avoid truncated result.
Get-Content "$env:USERPROFILE/.oh-my-posh.omp.json" | ConvertFrom-Json | ConvertTo-Toml -Depth 10 | Set-Content -Path "$env:USERPROFILE/.oh-my-posh.omp.toml"

個人的に TOML は ini ライクで結構好きなのだけど、こと Oh My Posh の設定ファイルに使うと読みにくすぎる気がした。先に挙げた自作テーマ JSON は 150 行あるのだけど、 YAML だと 103 行、 TOML だと 134 行になった。これらはすべて最終行の改行含む。 TOML の場合はヘッダーの前に空行を入れたいので TOML だけ行数での比較は不利な感じだけど。

Oh My Posh の設定は Block Array と各 block に入れ子構造の Segment Array や更に入れ子になった properties がいる。これを TOML に置き換えたら Array of Tables が頻出して、個人的にこれが見にくいと感じるところかな。 TOML が階層と繰り返し構造の組み合わせだとこんなに読みにくくなるとは気づかなかった。新たな発見や。

比較として、以下に部分的に一覽してみる。 JSON で PUA に割り当てられた文字を直書きしてたところは、変換の際にキャラクターコードへと変換されてた。 (アイコングリフが同梱されたフォントを使ってなかったり、自分専用のコードポイントに当たってる箇所は豆腐で表示されるだろうがご了承いただきたい。)

{
  "$schema": "https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/main/themes/schema.json",
  "blocks": [
    {
      "alignment": "left",
      "newline": true,
      "segments": [
        {
          "foreground": "#839496",
          "style": "plain",
          "type": "text"
        }
      ],
      "type": "prompt"
    },
    {
      "alignment": "left",
      "segments": [
        {
          "background": "#002b36",
          "foreground": "#839496",
          "properties": {
            "home_icon": "🏠",
            "style": "mixed"
          },
          "style": "diamond",
          "template": "{{ .Path }} ",
          "type": "path"
        },
        {
          "background": "#859900",
          "foreground": "#002b36",
          "powerline_symbol": "\ue0bc",
          "properties": {
            "azure_devops_icon": "󿴄 ",
            "fetch_stash_count": true,
            "fetch_status": true,
            "fetch_upstream_icon": true,
            "fetch_worktree_count": true,
            "no_commits_icon": "󿖕 "
          },
          "style": "powerline",
          "template": " {{ .HEAD }} {{ .BranchStatus }}{{ if .Working.Changed }} \uf044 {{ .Working.String }}{{ end }}{{ if and (.Staging.Changed) (.Working.Changed) }} |{{ end }}{{ if .Staging.Changed }} \uf046 {{ .Staging.String }}{{ end }}{{ if gt .StashCount 0}}󿚓 {{ .StashCount }}{{ end }}{{ if gt .WorktreeCount 0}} \uf1bb {{ .WorktreeCount }}{{ end }} ",
          "type": "git"
        },
        {
          "background": "#002b36",
          "background_templates": [
            "{{ if gt .Code 0 }}red{{ end }}"
          ],
          "foreground": "#d33682",
          "powerline_symbol": "\ue0bc",
          "properties": {
            "always_enabled": true
          },
          "style": "powerline",
          "template": " {{ if gt .Code 0 }}󿮋  {{ .Meaning }}{{ else }}\uf004 {{ end }} ",
          "type": "exit"
        }
      ],
      "type": "prompt"
    },

$schema: https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/main/themes/schema.json
blocks:
  - alignment: left
    newline: true
    segments:
      - foreground: "#839496"
        style: plain
        type: text
    type: prompt
  - alignment: left
    segments:
      - background: "#002b36"
        foreground: "#839496"
        properties:
          home_icon: "\U0001F3E0"
          style: mixed
        style: diamond
        template: "{{ .Path }} "
        type: path
      - background: "#859900"
        foreground: "#002b36"
        powerline_symbol: 
        properties:
          azure_devops_icon: "\U000FFD04 "
          fetch_stash_count: true
          fetch_status: true
          fetch_upstream_icon: true
          fetch_worktree_count: true
          no_commits_icon: "\U000FF595 "
        style: powerline
        template: " {{ .HEAD }} {{ .BranchStatus }}{{ if .Working.Changed }}  {{ .Working.String }}{{ end }}{{ if and (.Staging.Changed) (.Working.Changed) }} |{{ end }}{{ if .Staging.Changed }}  {{ .Staging.String }}{{ end }}{{ if gt .StashCount 0}}\U000FF693 {{ .StashCount }}{{ end }}{{ if gt .WorktreeCount 0}}  {{ .WorktreeCount }}{{ end }} "
        type: git
      - background: "#002b36"
        background_templates:
          - "{{ if gt .Code 0 }}red{{ end }}"
        foreground: "#d33682"
        powerline_symbol: 
        properties:
          always_enabled: true
        style: powerline
        template: " {{ if gt .Code 0 }}\U000FFB8B  {{ .Meaning }}{{ else }} {{ end }} "
        type: exit
    type: prompt

"$schema" = "https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/main/themes/schema.json"
console_title_template = "{{if .Root}}Admin: {{end}} {{.Folder}}"
final_space = true
version = 2

[[blocks]]
alignment = "left"
newline = true
type = "prompt"

[[blocks.segments]]
foreground = "#839496"
style = "plain"
type = "text"

[[blocks]]
alignment = "left"
type = "prompt"

[[blocks.segments]]
background = "#002b36"
foreground = "#839496"
style = "diamond"
template = "{{ .Path }} "
type = "path"

[blocks.segments.properties]
home_icon = "🏠"
style = "mixed"

[[blocks.segments]]
background = "#859900"
foreground = "#002b36"
powerline_symbol = ""
style = "powerline"
template = " {{ .HEAD }} {{ .BranchStatus }}{{ if .Working.Changed }}  {{ .Working.String }}{{ end }}{{ if and (.Staging.Changed) (.Working.Changed) }} |{{ end }}{{ if .Staging.Changed }}  {{ .Staging.String }}{{ end }}{{ if gt .StashCount 0}}󿚓 {{ .StashCount }}{{ end }}{{ if gt .WorktreeCount 0}}  {{ .WorktreeCount }}{{ end }} "
type = "git"

[blocks.segments.properties]
azure_devops_icon = "󿴄 "
fetch_stash_count = true
fetch_status = true
fetch_upstream_icon = true
fetch_worktree_count = true
no_commits_icon = "󿖕 "

[[blocks.segments]]
background = "#002b36"
background_templates = ["{{ if gt .Code 0 }}red{{ end }}"]
foreground = "#d33682"
powerline_symbol = ""
style = "powerline"
template = " {{ if gt .Code 0 }}󿮋  {{ .Meaning }}{{ else }} {{ end }} "
type = "exit"

[blocks.segments.properties]
always_enabled = true

個人的にはこの中なら YAML が一番ましかな...ということで YAML でいくことにした。

インデントすれば TOML も見やすくなるだろうけど、 JSON や YAML で不要な table 名の繰り返しがきつい。

あと VS Code だと保存時の format で好きな項目順に並べられないしインデントも消失する。フォーマットなしで保存するようにしたらいいのかも知れんが、今どき自動フォーマットに従わないのもカッコ悪い。 YAML ならインデントが階層構造を示すし、保存時に項目が並び替わらなかったので、その点も良い。

Oh My Posh の JSON はコメント書けたけど、 VS Code で編集する時いちいち言語を JSONC に変えないとエラー表示されて面倒だったが、 YAML ならこの悩みはない。

ひとまず以下のようにした。

$schema: https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/main/themes/schema.json

version: 2
console_title_template: "{{ if .Root }}Admin: {{ end }} {{ .Folder }}"
final_space: true
blocks:
  # First line left.
  - type: prompt
    newline: true
    alignment: left
    segments:
      - type: text
        style: plain
  - type: prompt
    alignment: left
    segments:
      - type: os
        background: "#002b36"
        foreground: "#2aa198"
        style: diamond
        trailing_diamond: 
        template: "{{ if .WSL }}  at {{ end }}{{ .Icon }} "
      - type: root
        background: "#002b36"
        foreground: "#b58900"
        style: diamond
        trailing_diamond: 
        template: ""
      - type: session
        background: "#2aa198"
        foreground: "#073642"
        style: diamond
        trailing_diamond: 
        properties:
          display_host: false
        template: " {{ .UserName }} "
      - type: path
        background: "#002b36"
        foreground: "#839496"
        properties:
          style: mixed
        style: diamond
        template: "{{ .Path }} "
      - type: git
        background: "#859900"
        foreground: "#002b36"
        style: powerline
        powerline_symbol: 
        properties:
          fetch_stash_count: true
          fetch_status: true
          fetch_upstream_icon: true
          fetch_worktree_count: true
          github_icon: " "
          bitbucket_icon: " "
          no_commits_icon: "󿖕 "
        template: " {{ .UpstreamIcon }} {{ .HEAD }} {{ if .BranchStatus }}{{ .BranchStatus }}{{ end }}{{ if .Working.Changed }}  {{ .Working.String }}{{ end }}{{ if and (.Staging.Changed) (.Working.Changed) }} |{{ end }}{{ if .Staging.Changed }}  {{ .Staging.String }}{{ end }}{{ if gt .StashCount 0}}󿚓 {{ .StashCount }}{{ end }}{{ if gt .WorktreeCount 0}}  {{ .WorktreeCount }}{{ end }} "
      - type: text
        background: "#002b36"
        foreground: "#d33682"
        style: powerline
        powerline_symbol: 
        background_templates:
          - "{{ if gt .Code 0 }}#dc322f{{ end }}"
        foreground_templates:
          - "{{ if gt .Code 0 }}#002b36{{ end }}"
        properties:
          always_enabled: true
        template: " {{ if gt .Code 0 }}󿮋 {{ else }} {{ end }} "
  # First line right.
  - type: prompt
    alignment: right
    segments:
      - type: shell
        foreground: "#93a1a1"
        style: diamond
        template: "󿚍 {{ .Name }}"
      - type: time
        background: "#002b36"
        foreground: "#839496"
        style: diamond
        leading_diamond: 
        trailing_diamond: 
        properties:
          time_format: 15:04:05 MST
        template: "{{ .CurrentDate | date .Format }}"
      - type: executiontime
        background: "#073642"
        foreground: "#839496"
        style: diamond
        properties:
          always_enabled: true
        template: " {{ .FormattedMs }}"

  # Second line.
  - type: prompt
    newline: true
    alignment: left
    segments:
      - type: text
        foreground: "#b58900"
        style: plain
        template: ">"

要らない設定を削り、 2 行レイアウトの 1 行目に情報を詰め込んでみた。最近 Powerline じゃなくてもいいかもなと感じることあるのだけど、やはり視認性ではこちらに分があるので、情報表示する 1 行目は踏襲。 2 行目は限りなくシンプルに。

2 行目に慣れてきたら背景色なくして、文字色やアイコングリフだけでも視認性よく感じるかもなー。

F# でコマンドレットを書いてる pt.30

Sun, 21 Jan 2024 09:00:00 +0900

krymtkts/pocof の開発をした。

前回触れた PSHostRawUserInterface.LengthInBufferCells を使った full-width character の表示に対応した。なので、pocof version 0.8 をリリースした。

PSHostRawUserInterface.LengthInBufferCells で query window の表示域に収まる長さを求めるのに再帰させた。一発で長さを求められないあたり効率は良くない。時間計算量が線形時間 O(n) なので、今後せめて二分探索で対数時間 O(logn) にできないか考える。

pocof の積み Issues は今 4 つある。

#85 Linux support
#44 Support query string selection
#17 Selection support
#16 Page up/down support
- こいつはいらんかなと思いだした。 paging が必要なほど件数多いなら query 足して絞るし、なんか余計かなーと

今は #85 Linux support を進めてる。

pocof は .NET Standard 2.0 をターゲットにしてるので、 Windows PowerShell でも PowerShell (Core 6 以降) でも動くはず。現在の dotnet はほんとすごいな。でも PowerShell の ConsoleHost の実装で Windows 以外では NotImplementedException を投げる箇所がある。以下に、 Ubuntu on Docker で確認したエラーを Issue から転記する。

PS /src> Get-ChildItem | Select-Pocof
Select-Pocof: The method or operation is not implemented.

PS /src> $ErrorView = 'DetailedView'
PS /src> $Error

Exception             :
    Type       : System.NotImplementedException
    TargetSite :
        Name          : GetBufferContents
        DeclaringType : Microsoft.PowerShell.ConsoleHostRawUserInterface, Microsoft.PowerShell.ConsoleHost, Version=7.3.10.500, Culture=neutral, PublicKeyToken=31bf3856ad364e35
        MemberType    : Method
        Module        : Microsoft.PowerShell.ConsoleHost.dll
    Message    : The method or operation is not implemented.
    Source     : Microsoft.PowerShell.ConsoleHost
    HResult    : -2147467263
    StackTrace :
   at Microsoft.PowerShell.ConsoleHostRawUserInterface.GetBufferContents(Rectangle rectangle)
   at System.Management.Automation.Internal.Host.InternalHostRawUserInterface.GetBufferContents(Rectangle r)
   at pocof.PocofScreen.RawUI..ctor(PSHostRawUserInterface rui) in /src/src/pocof/UI.fs:line 55
   at pocof.PocofScreen.init(PSHostRawUserInterface rui, String prompt, FSharpFunc`2 invoke) in /src/src/pocof/UI.fs:line 173
   at pocof.SelectPocofCommand.interact(InternalConfig conf, InternalState state, Position pos, PSHostRawUserInterface rui, FSharpFunc`2 invoke) in /src/src/pocof/Library.fs:line 44
   at pocof.SelectPocofCommand.EndProcessing() in /src/src/pocof/Library.fs:line 191
CategoryInfo          : NotImplemented: (:) [Select-Pocof], NotImplementedException
FullyQualifiedErrorId : NotImplementedException,pocof.SelectPocofCommand
InvocationInfo        :
    MyCommand        : Select-Pocof
    ScriptLineNumber : 1
    OffsetInLine     : 17
    HistoryId        : 2
    Line             : Get-ChildItem | pocof
    PositionMessage  : At line:1 char:17
                       + Get-ChildItem | pocof
                       +                 ~~~~~
    InvocationName   : pocof
    CommandOrigin    : Internal
ScriptStackTrace      : at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo :

NotImplementedException の発生源はここかなと思ってる。 PowerShell/src/Microsoft.PowerShell.ConsoleHost/host/msh/ConsoleHostRawUserInterface.cs

        /// <summary>
        /// This API returns a rectangular region of the screen buffer. In
        /// this example this functionality is not needed so the method throws
        /// a NotImplementException exception.
        /// </summary>
        /// <param name="rectangle">Defines the size of the rectangle.</param>
        /// <returns>Throws a NotImplementedException exception.</returns>
        public override BufferCell[,] GetBufferContents(Rectangle rectangle)
        {
            throw new NotImplementedException("The method or operation is not implemented.");
        }

ConsoleHostRawUserInterface.cs の先頭に #if !UNIX てプリプロセッサディレクティブがあって、前半 Windows 後半その他になってる。これはその他の方。

そのため、 pocof では Linux の場合(厳密には Mac も含むが確認できない)に work around が必要だった。今は NotImplementedException を捕捉した場合は GetBufferContents 未対応の platform とみなし、エラーを回避する。この場合、コンソールに表示されているバッファのバックアップと復元はしない。

    type RawUI(rui) =
        let rui: PSHostRawUserInterface = rui

        // TODO: replace backup/restore buffer contents with scrolling contents for Linux support.
        let buf: BufferCell [,] option =
            try
                rui.GetBufferContents(Rectangle(0, 0, rui.WindowSize.Width, rui.CursorPosition.Y))
                |> Some
            with // NOTE: when running on Linux, this exception is thrown.
            | :? NotImplementedException -> None

元々 Windows で動いてるバッファのバックアップと復元も、可視範囲しか対応しないのと復元結果が微妙に壊れるので、イマイチではあるけど。

この課題を見つけて以降、 dotnet で cross-platform なコンソール操作どうなってんのやと調査を進めていた。 PowerShell で Windows 以外が未実装な機能もあれば、 dotnet 自体で Windows 以外の platform をサポートしないケースもある。 Support for Console.MoveBufferArea() on Linux & Mac · Issue #23073 · dotnet/runtime

コンソール周りの cross-platform は結構難しくて、 Windows でできることをそのまま他所ではできないのがわかった。

じゃあ pocof では描画域を確保したりバッファを復元したりの操作をどう変えていくべきか、悩ましいところだった。どう解消すべきかなと調査していたところ、先達の重要なコメントを見つけた。

PS-GuiCompletion does not work in PowerShell Core 7.0 on Linux · Issue #13 · cspotcode/PS-GuiCompletion

Similar functionality, such as the Menucomplete feature of PSReadLine, work around this limitation by writing several blank lines to the terminal, scolling everything upward and creating an empty region at the bottom of the screen. They draw their "gui" into this empty region, knowing they can erase it entirely when they're done.

PSReadLine の補完機能で表示されるアレをパクれば良いと。なるほどーって感じ。でも実装が大変なんでしょ？と思いコードを見に行ったところ、めちゃくちゃシンプルな仕組みだった。

PSReadLine/PSReadLine/DisplayBlockBase.cs at e57f7d691d8df8c1121fddf47084f96aea74a688 · PowerShell/PSReadLine

            protected void MoveCursorDown(int cnt)
            {
                IConsole console = Singleton._console;
                while (cnt-- > 0)
                {
                    console.Write("\n");
                }
            }

改行を印字したらカーソルが 1 行下に進むので、それを必要な高さ分行うだけで描画域を確保できると。この方法であれば、コンソールのバッファを破壊することもない。

一点マウススクロールを制限できないのがどうかなーと、はじめは思った。が、それは今までの pocof が「全画面モーダル」的なアプリだったからそう感じたわけで、これからは「全画面ウィンドウ」的なアプリと捉えればいいだけなのではと思えてきた。従来であれば可視範囲だけバッファをバックアップするのでスクロールを制限できる代わりに、見えない範囲のバッファを吹っ飛ばす制限があったし。これが全画面ウィンドウであれば、全画面をやめてバッファと共存するような下半分だけの UI もアリやなというアイデアにつなげることもできる。これは良さそうや。何ならタイリングレイアウト派なので、自分の用途だと半分 UI の方が向いてそう。

ということで、 PSReadLine スタイルの描画をプロトタイプしてみた。まず PowerShell で雑に書いてみて、次に F# で雑に書いてみた。これらは Gist に置いた。

以下は F# 版。

open System

[<TailCall>]
let rec readAndDisplay h w arr =
    let k = Console.ReadKey(true)
    let arr = k :: arr

    if k.Key = ConsoleKey.Enter then
        ()
    else
        let take =
            match List.length arr < h with
            | true -> List.length arr
            | _ -> h

        arr
        |> List.take take
        |> List.map (fun k -> $"[{k.Key} - {k.Modifiers}]")
        |> List.iteri (fun i s ->
            Console.SetCursorPosition(0, i)
            let s = $"{i} {s}"

            Console.Write(s + String.replicate (w - String.length s) " "))

        readAndDisplay h w arr

// test script for interactive console window.
// currently cannot prevent mouse scrolling.
let testConsoleWindowWithoutBufferCleaning () =
    // backup cursor x position.
    let x = Console.CursorLeft

    // add lines to the end of the screen for scrolling using the PSReadLine method.
    let h = Console.WindowHeight
    let w = Console.WindowWidth

    String.replicate (h - 1) "\n" |> Console.Write

    // write contents.
    let yy = Console.CursorTop

    Console.SetCursorPosition(0, 0)

    [ 0..yy ]
    |> List.map (fun i ->
        let s = $"Line: %d{i}"
        s + String.replicate (w - s.Length) " ")
    |> String.concat "\n"
    |> Console.Write
    // read and display.
    readAndDisplay h w []

    // clear contests.
    [ 0 .. (h - 1) ]
    |> List.iter (fun i ->
        Console.SetCursorPosition(0, i)
        Console.Write(String.replicate w " "))

    // restore cursor position.
    Console.SetCursorPosition(x, 0)

testConsoleWindowWithoutBufferCleaning ()

こんな感じに動く。

Windows の他に Ubuntu on WSL でも動かしてみた(disk カツカツで Docker やめた)が、良さそう。前方スクロールしてたとしても、入力をはじめたらカーソル位置の操作が行われて全画面位置に戻る。いい。これを pocof に組み込んでみて、まずは使ってみる。違和感なくいけそうなら 0.9 で出すかな。

Chocolatey で Portable OpenSSH を更新する 2024

Sun, 14 Jan 2024 09:00:00 +0900

少し前の話。 2024 を目前にして、久しぶりに Chocolatey に OpenSSH の β が降ってきてた。 Chocolatey Software | Win32 OpenSSH (Universal Installer) 9.5.0-beta1

前回は 2023-05 だった。 2023-05-20 - Chocolatey で Portable OpenSSH を更新する 2023

2023-05 に自分で bump したとき、 /SSHServerFeature を使うって書いてた。でも、これ uninstall-sshd.ps1 で sshd service を消しておいたら /SSHAgentFeature でもエラーせずに更新できるわ、というのに今更気づいた。そも sshd が立つのも、自分の PowerShell profile で ssh-agent のサービスがいないときに install-sshd.ps1 してるからなので。

openssh · master · DarwinJS / ChocoPackages · GitLab

-params '"/SSHAgentFeature"'

Installs SSH Agent Service even if SSHD Server is not being installed. Requires admin rights to configure service. IMPORTANT: ssh-agent is no longer required for sshd after version openssh 1.0.0.0

ちゃんとドキュメント読んでいこうぜ。

# 一度 uninstall しておく
uninstall-sshd.ps1
choco uninstall openssh -y
# 消えたの確認
Get-Service ssh-agent | select -Property Name,ServiceHandle,DisplayName,ServiceType,StartType

# 入れ直す
choco install openssh -params '"/SSHAgentFeature"' -y
Get-Service ssh-agent | select -Property Name,ServiceHandle,DisplayName,ServiceType,StartType

# Name          : ssh-agent
# ServiceHandle : Microsoft.Win32.SafeHandles.SafeServiceHandle
# DisplayName   : ssh-agent
# ServiceType   : Win32OwnProcess
# StartType     : Automatic

install-sshd.ps1 で ssh-agent 入れると、 StartType: Manual になるから別途 Automatic に変更する必要があった。正しい手順ならそのひと手間もいらないぽい。

2019-03-31 - Windows10 の更新で OpenSSH が逝ったではちゃんと /SSHAgentFeature 使ってた。なのにその後 2019-06-29 - また OpenSSH が動かなくなる季節がやってきたでそれを忘れて install-sshd.ps1 でサービス起動するように変えてた。これがことの発端ぽいな。

その後 Chocolatey で Portable OpenSSH を更新する 2023 で判断を誤る。 /SSHAgentFeature じゃなく /SSHServerFeature を使うようになってしまった。期間が開くと色々ノウハウが失われていく教科書的なパターン。

今後はちゃんと /SSHAgentService 使ってやるようにせなあかんな。ひとまず profile で ssh-agent サービス立ち上がってなかったら install-sshd.ps1 流すような記述してたのを消した。

にしてもわたしの profile も継ぎ足し守られた秘伝のタレ化して、管理が難しくなってきてる。もう利用してないやつは消したり、必要な初期化は関数小分けにするとかして改善せなあかん時がきたか...

Gist で 1 ファイルだけ管理してるのも download のやりやすさや更新のしやすさがあっていいけど、なんか他の方法考えなあかんかもな。古くは VS Code の Gist 、最近は GistPad で編集してる。楽に編集できて便利やからなー、他の方法としたら git repo があるけどやっぱ手軽さは劣るよな。

F# でコマンドレットを書いてる pt.29

Sun, 07 Jan 2024 09:00:00 +0900

krymtkts/pocof の開発をした。

2023 年末に pocof version 0.7 をリリースした。

その流れというか冬休みの宿題的に、 2024 年初は積んでた TODO から「長いクエリの場合は描画範囲に収まるよう部分表示する機能」を作ってみた。 #105 言うなれば、クエリ入力がテキストボックスに長ーいテキストを入れたときと同じ挙動になる機能なのだけど、 query window と名付けてひとまず実装してみた。まだ PSHostRawUserInterface.LengthInBufferCells を使ってないから full-width character の場合に表示が崩れるのだけど、いい感じぽい。

#105 でざっくり query window を実装したあと、コードを小綺麗にすべく #109 でかなり書き換えた。他にも諸々のコミットを積んだ。それもあって詳細な変更に関してまとめることはダルくてできないが、備忘のために要所をまとめておく。

query window の実現のために最低限必要と判断した要素は以下で、いくつかは新しく追加する必要があった。

クエリ文字列の全長
- クエリの長さを取るだけ
クエリ文字列中のカーソル位置
- 従来のコンソール上の X 座標を拡張する
コンソールの幅
- 持ってなかったから追加する
クエリ文字列の描画開始インデックス
- 持ってなかったから追加する

描画域は、コンソールの幅からクエリの状態だとかのシステム情報表示の幅を減算して求める必要がある。

クエリ文字列の描画開始インデックスは、クエリ文字列の全長から描画域を引いて求める。なのでクエリ文字列の全長が描画行の幅を超えない限りは 0 のままだ。

クエリ文字列のうち描画するのが、描画開始インデックスから描画域の幅に収まる文字数だけとなる。

画面上の X 座標は、クエリ文字列中のカーソル位置からクエリ文字列の描画開始インデックスを引いて求める。

描画域はウィンドウサイズを変更したときのことを考えたらイベントで更新されるようにするのがベストだろうけど、今の pocof ではそのような機構がないので、キー入力後に幅を更新するようにした。

描画域の変更が必要なのは、ウィンドウサイズの変更以外にもある。それはクエリの一致方法やら case sensitive にしたりとかの条件を切り替えたとか、クエリを打ち込んで絞り込まれた件数の桁が変わったとか、多岐に渡る。ほぼ全ての入力操作でそれが起こるので、こまめに描画域の調整をする必要があった。

そんな感じに玉突きで状態の変更が発生しまくるので、レコードを書き換えて新しいレコードにするコードが大量発生した。

なのでシンプルに実装したとはとても言えない感じがするけど、ややこしいレコード操作をまとめるためにこまめに module 分けしたので、あとから自分で見てもそこそこ困らなくなったはず。

あと諸々のリファクタリングのついでに、計測していたコードカバレッジを Codecov へ登録するようにしてみた。 #111

codecov/codecov-action で cobertura の XML を送りつけるだけでいいので楽だ。ただし composite action の中から secrets にアクセスできないため、以下のように composite action の input にしてやる必要だけあった。

index 01c3b6d..e75a80e 100644
--- a/.github/actions/test/action.yml
+++ b/.github/actions/test/action.yml
@@ -1,6 +1,11 @@
 name: Test
 description: Setup .NET, install PowerShell modules and run all tests.

+inputs:
+  codecov_token:
+    description: "Codecov token"
+    required: true
+
 runs:
   using: composite
   steps:
@@ -16,3 +21,9 @@ runs:
     - name: Execute All Tests
       shell: pwsh
       run: Invoke-Psake -taskList TestAll
+    - name: Upload coverage reports to Codecov
+      uses: codecov/codecov-action@v3
+      with:
+        file: ./src/pocof.Test/TestResults/coverage.cobertura.xml
+      env:
+        CODECOV_TOKEN: ${{ inputs.codecov_token }}
diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index be56145..06f2b91 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -22,3 +22,5 @@ jobs:
         uses: actions/checkout@v4
       - name: Test
         uses: ./.github/actions/test
+        with:
+          codecov_token: ${{ secrets.CODECOV_TOKEN }}

他にも勉強がてら Snyk に登録して脆弱性を検査するようにしてみた。 #112 Codecov のような送りつけるだけに比べると、思ったよりも Snyk はサービスの理解が難しく感じた。

めちゃくちゃ細かいところだと、例えば対応する package manager 的には dotnet は大丈夫だが、 badge は dotnet に対応してないとか。

まず krymtkts/blog-fable の方を実験台にしてたので、 dotnet と Node.js の複合プロジェクトだったから気づかなかった。

あと言語別に分かれた snyk/actions がなにやってるかもはじめは分からなかった。 snyk/actions は、どの言語の action も単に言語の環境を準備してから Snyk CLI を実行するだけ。それがわかったら、あとは Snyk CLI のドキュメントを見るだけなのでやりやすかった。この仕組みは snyk/actions/dotnet/action.yml を見て理解した。

特に blog-fable のような複数 package manager で構成される project なら --all-projects と --exclude を使うのが良さそう。 pocof でも --all-projects を使った。 pocof は Linux での動作確認用の Dockerfile を置いてたのもあって、意外に検査対象があったんも勉強になった。

Snyk は GitHub の code scanning に upload する SARIF ファイルを --sarif-file-output で出力できる。 main branch への push でアップロードするようにしてみた。

ほぼ Snyk の文書通りのコピーで良いが、 security-events: write の permission を足さないといけない。それは GitHub 側の文書でわかった。めんど。

pull request 時に脆弱性があったら snyk/actions はエラーにしたい。でも main branch の push で SARIF ファイルをアップロードする方がエラーになっては困る。なのでそういったケースでは別々に定義するのが良さそう。ココまでで Snyk の面倒さが伝わるはずだ。

あとコレは Snyk に関係ないけど xunit が依存してる NetStandard.Library 1.6 の依存関係にある脆弱性のおかげで High な脆弱性が検知される。

xunit.runner.utility is still referencing NetStandard.Library 1.6.0 · Issue #2778 · xunit/xunit

これを避けるには、 xunit を含む test project の検査をしないか、脆弱性を報告されている package の最新版への依存を追加するかの、どちらかしかない。検査しないのもどうかなーと思ったので後者で対処した。

結果は以下の通りになった。 (コメントで snyk を synk に typo してるのは後で直す)

 .github/workflows/main.yml | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index 06f2b91..deed645 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -7,6 +7,7 @@ on:

 permissions:
   contents: read
+  security-events: write

 jobs:
   test:
@@ -24,3 +25,18 @@ jobs:
         uses: ./.github/actions/test
         with:
           codecov_token: ${{ secrets.CODECOV_TOKEN }}
+      - name: Run Snyk to check for vulnerabilities
+        uses: snyk/actions/dotnet@master
+        # synk/actions uses Container action that is only supported on Linux.
+        if: runner.os == 'Linux'
+        continue-on-error: true # To make sure that SARIF upload gets called
+        env:
+          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
+        with:
+          command: test
+          args: --all-projects --sarif-file-output=snyk.sarif
+      - name: Upload result to GitHub Code Scanning
+        if: runner.os == 'Linux'
+        uses: github/codeql-action/upload-sarif@v2
+        with:
+          sarif_file: snyk.sarif
 .github/workflows/pr.yml | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/.github/workflows/pr.yml b/.github/workflows/pr.yml
index 8fe46f9..e3305a1 100644
--- a/.github/workflows/pr.yml
+++ b/.github/workflows/pr.yml
@@ -23,3 +23,12 @@ jobs:
         uses: ./.github/actions/test
         with:
           codecov_token: ${{ secrets.CODECOV_TOKEN }}
+      - name: Run Snyk to check for vulnerabilities
+        # synk/actions uses Container action that is only supported on Linux.
+        if: runner.os == 'Linux'
+        uses: snyk/actions/dotnet@master
+        env:
+          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
+        with:
+          command: test
+          args: --all-projects
 src/pocof.Test/pocof.Test.fsproj | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/pocof.Test/pocof.Test.fsproj b/src/pocof.Test/pocof.Test.fsproj
index 8b56bb8..d7316ae 100644
--- a/src/pocof.Test/pocof.Test.fsproj
+++ b/src/pocof.Test/pocof.Test.fsproj
@@ -31,6 +31,9 @@
     </PackageReference>
     <!-- NOTE: for creating mock PSObject -->
     <PackageReference Include="Microsoft.PowerShell.SDK" Version="7.4.0" />
+    <!-- NOTE: NOTE: for suppressing vulnerability report the transient dependencies from xunit that depends .NET Standard 1.6. -->
+    <PackageReference Include="System.Net.Http" Version="4.3.4" />
+    <PackageReference Include="System.Text.RegularExpressions" Version="4.3.1" />
   </ItemGroup>

Codecov と Snyk を使うことで 3rd party の token を secrets に保存して使う様になった。わたしは全然知らなかったが、 pull_request イベントだと Dependabot は secrets へアクセスできないらしい。この Dependabot が secrets を読めなくなった変更は結構なインパクトあったぽいな。

Dependabot triggered Actions cant access secrets or use a writable token · Issue #3253 · dependabot/dependabot-core

pocof のケースだと Dependabot secrets に secrets と同じ内容を定義するだけで済んだ。この Dependabot が作成した PR で Dependabot secrets にアクセスできるのは文書に書いてないぽい。

Configuring access to private registries for Dependabot - GitHub Docs

唯一？この文書がそれっぽいか。でも dependabot.yml で使えるとは書いてるけど GitHub Actions で使えるとは書いてない。ただ Dependabot secrets のところには以下のような記載があり、使えそうな雰囲気に見える。いつ GitHub の気が変わって使えなくなるかわからないけど。

Dependabot secrets Secrets are credentials that are encrypted. Anyone with collaborator access to this repository can use these secrets for Dependabot.

Secrets are not passed to forks.

こういう面倒なところを忌避して Renovate を使う勢があるというのも理解した。

なんか色々書いたが、冬休みに色々仕込んだものを早く 0.8 release にしたいところ。 PSHostRawUserInterface.LengthInBufferCells を使って full-width character の表示に対応したら、 release するようにしようか。

2024

Mon, 01 Jan 2024 09:00:00 +0900

例年通り目標をたてる。週末まで待っても良かったが、 2024-01-01 の commit なかったのもありコレでまかなう。

テーマ: 不惑

2023 年のテーマは不惑だった。 2024 年もそれでいく。今後はこのテーマを継続していき、なんかピンポイントで攻略せねばならん障害が発生したら適宜変更することにする。

2024 年の目標

テーマも継続することにしたので、基本的に目標も継続する。

積読消化 0.5 冊/月を超える
- 今年こそやる
F# の開発
- メインは pocof 。クロスプラットフォーム対応はじめとして今ある Issues を回収したい。今 #27 に着手してるが、クエリ全体の長さに対して表示域という今まで実装してなかった概念を導入することになり重めの修正となる。他の issues も同様に未実装の概念を導入するのでやっかいで、地道に取り組む
- blog-fable はやることがあったらスポットでやる
- なんか他にも継続できるネタが有っていいかなと思っている。パッと思いつくネタないけど。もっと F# に突っ込んだなんかやりたいよな
GitHub のストリークを継続する
- 継続できたら 2024 年早々 500 達成できるから、そこの先をさらに狙う。 500 超えたら次の大きなゴールは 1000 よな。ベストを尽くしても達成できるのは来年 2025 年になるけどコツコツ取り組む
毎週ブログを書く
- 2024 も継続する
ギター練習を 4 / week
- 頻度下げてゆるく継続する
深酒で怪我をしない
- 2023 に続き 0 を目指す
自分メンテナンス
- reps 多い筋トレメニューは強度マシで。体重には全然反映されないから強度が高いメニューをこなせるかに注目して取り組む

振り返り 2023 年

Sun, 31 Dec 2023 09:00:00 +0900

2023 年を振り返る。

2023 年のテーマは「不惑」だった。

2023 年の目標と成果

完全達成とは行かなかったがそこそこいい。

❌ 転居先を決める
- この話題に触れる回数は増えたけど、わたしは田舎に住んで薪ストーブやりたいのだけど、妻は交通の利便性を確保したいらしくて折り合い付かない。田舎で交通の便いいとこないかな。タイミング的にももう気軽な転居しにくくなってきてるから、今後は目標たてなくて、機会とその必要に応じてやることにする。
❌ 積読消化 0.5 冊/月を超える
- 年初の早い段階から、仕事で必要になった検索システムの知識を得るために小冊子含めて 2 冊読んだ。だけど、その後携わるテーマが所謂生成 AI に関するものになり読む本がなくなり(Web の文書は読むけど)機会も損失した
- あいかわらず自分の読みたいものを積読していくのはほそぼそと続いているので、自分時間をうまく確保してそれを消化すればよいのだけど、できなかった
- 継続的・強制的な読書習慣の構築には着手した。友人の協力の下、輪読会をはじめた。まだはじめの一冊を終えられてないけど。来年 2024 年の早いうちには終わりそうなので着実に進める
⭕ F# を学ぶ
- pocof と Fable を使った blog-fable に半分ずつ取り組めた感じ。なにか新しいチャンレンジしたいってのはこの Fable を使った自ブログの再構築でできたんじゃなかろうか
- 今年出た F# 8 の更新をすぐ試してみたり、 F# で開発される repo の動向を追ったりとかはできるようになってきた。コードクォートやコンピュテーション式で自前の DSL を書くようなシーンはまだ体験してない。単にまだあんま理解が染み込んでなくて機会を見逃してるのかな
⭕ GitHub のストリークを継続する
- 今年は 365 ストリークを迎えて、きょうで 497 まできた。完全に習慣化されたといって良いだろう
⭕ 毎週ブログを書く
- これも完全に習慣化されたと言える。書く頻度をもっと増やす努力をしてもいいかも知れんけど、今の感触だと日々のやることに追われ過ぎて疲れていきそうなので、ゆるく継続する
❌ ギター練習を 30 分/毎日
- 毎日となると気が向かなくてできないことがあった。でも Oura Ring の実績抜きにしても、週に数回仕事が行き詰まったとき頭を切り替えるために弾く習慣にはなった。こういうゆるい継続でいい気がする
- だいぶ前にもらった 2000 年はじめ頃の Squire のストラトをちょっとだけレストアしてコーティング弦を張ったところ、他のいかにもメタルギターなラインナップに新鮮味を吹き込んでくれた感ある
- ゴツいピックを使うようになってピッキングノイズを避けたくてブリッジ寄りで弾くようになり、 Floyd Rose のファインチューナーが邪魔になってきた(フォームの変更でカバーできるのかもだが)。最近出回ってる Non-Fine Tuner の Floyd Rose 搭載にカスタムしたいな...と思い出す程度には弾いてる
⭕ 深酒で怪我をしない
- 外飲みの機会がそれほどなく、今年は無事故だった。一応 Oura Ring 効果もあるのかな。二日酔いだとスコアすこぶる悪くなるし抑制効果がある
⭕ 自分メンテナンス開始
- 肌のメンテはやらなかった。単に忙しくて外出しなかっただけ。やっぱやりたいかも
- 歯のメンテは上の親知らず 2 本を抜いた。抜いてしばらくして歯が減ると認知能力が下がるという話を聞き背筋が凍る思いをしたが...親知らず周りを怪我して口内炎になる機会はめちゃくちゃ減った。昔深酒してぶつけて神経抜いた歯がうずく気がするのでそろそろメンテの時期なのかも。
- 自重トレーニングは習慣化できて、メニュー偏ってるけど以下のメニューを週に 1,2 回ずつできる感じになった
  - フルプッシュアップ 40 reps x 3
  - フルプルアップ 15 reps x 3
  - シシースクワット 15 reps x 2
  - 腹筋ローラー立ちコロ 5 reps x 2
- いくつかは reps 多いからもっと強度の高いトレーニングに移していい気がする。長い在宅勤務歴によって膝が弱ってるからあまり足を追い込めてなくて、そこも改善したい

将来への投資、習慣化、無事故あたりが今年の目標の分類で、特に習慣化に関しては何か知らんがうまくなってる。何故それができるようになりつつあるのか言語化できてないけど、いい傾向と捉える(あるいはマンネリ化なのかも知れんけど)。

まとめ

それといってビッグイベントなかったから淡々と進んだ感じ。この凪いでる感じがいいのよ。運が良かったのもあろうけど、昨年からのテーマである「自分の人生は自分で決める」を実現できた上で今年のテーマに注力できたってことだろうから良かったわ。

F# でコマンドレットを書いてる pt.28

Sun, 24 Dec 2023 09:00:00 +0900

krymtkts/pocof の開発をした。

今年最後の version 0.7 を release に向けて、これまでの TODOs を回収している最中。 #98 全部の TODOs を解消できるわけではないけど、前から直したかった 2 点を修正している。

不正なキーマップの検査
キー入力ごとのクエリ構築を毎回無から構築するのでなくて、入力されたキーに合わせた差分更新をする

結構大幅な内部設計の変更を #98 で行う感じ。これを終えたら version 0.7 を来週の年末休み中にリリースする。

不正なキーマップの検査は単に EndProcessing から BeginProcessing にオプションからのキーマップ構築を移すだけだったけど面倒で放置してた。これを今回サクッと書けそうだったので対応した。

失敗の可能性があるところは Results を用いて失敗の可能性を示すのが一般的だが、従来は手抜きで failWith していたので、定石どおり関数の戻り値を Results に変えた。これを BeginProcessing で Error を捕捉したら ArgumentException を投げてパラメータの検査としている。

恥ずかしながら理解してなかったのだけど Seq.map や Seq.fold は順序を保証しない。 Hashtable を Seq.cast<DictionaryEntry> して以降は seq で取り回していたので、エラーメッセージのユニットテスト段階でそれに気づいた。順序が変わったとて使用に問題はないけど、テストの都度エラーメッセージの順序が変わるのは気持ちが悪いしユニットテストで検査のしようがないから、 Seq.toList して順序を固定化するようにしている。

@@ -81,25 +81,34 @@ module PocofAction =

     let convertKeymaps (h: Hashtable) =
         match h with
-        | null -> defaultKeymap
+        | null -> defaultKeymap |> Ok
         | x ->
-            let source = defaultKeymap |> Map.toSeq
-
-            let custom =
+            let ok, ng =
                 x
                 |> Seq.cast<DictionaryEntry>
-                |> Seq.map (fun e ->
+                |> Seq.toList
+                |> List.map (fun e ->
                     let k = string e.Key |> toKeyPattern
                     let v = string e.Value |> PocofData.Action.fromString

                     match (k, v) with
-                    | (Ok kv, Ok av) -> (kv, av)
-                    // TODO: enhance error handling.
-                    | (Error e1, Error e2) -> failwith <| e1 + e2
+                    | (Ok kv, Ok av) -> Ok(kv, av)
+                    | (Error e1, Error e2) -> e1 + e2 |> Error
                     | (Error e, _)
-                    | (_, Error e) -> failwith e)
+                    | (_, Error e) -> Error e)
+                |> List.fold
+                    (fun (fst, snd) o ->
+                        match o with
+                        | Ok (o) -> (o :: fst, snd)
+                        | Error e -> (fst, e :: snd))
+                    ([], [])
+
+            match ok, ng with
+            | c, [] ->
+                let source = defaultKeymap |> Map.toList
+                List.append source c |> Map.ofSeq |> Ok
+            | _, e -> e |> List.rev |> String.concat "\n" |> Error

-            Seq.append source custom |> Map.ofSeq

パフォ的にキーマップの入力が尋常に多いエントリ数を持つことも無いだろうし、 List で問題ないかな。

キー入力に合わせたクエリの差分更新は結構大改修になってる。 module の分割と関数シグネチャの変更、あと既存のユニットテストの大幅な書き換えが必要になってる。 QueryContext という型を作って、そこに元々 PocofQuery.run が内包していた関数などをパーツとして持たせておく。それを PocofAction から切り出した PocofHandle.invokeAction の各入力キーに合わせた処理中で差分更新する。 PocofQuery.run は渡ってきた QueryContext を組み立てて実行するだけにした。これで例えばカーソル移動の場合ならクエリ(Queries)を初めとした大部分の再構築が不要なので、処理の軽量化になる。

他の箇所は差分が多くて貼りきれない。あとから詳細を見るときは #98 を参照するものとして、ここでは部分的にコードを抜粋しておく。レコードはこんな感じ。

    type TesterType<'a> = ('a -> bool) -> list<'a> -> bool

    type QueryContext =
        { Queries: Query list
          Test: TesterType<string * string>
          Is: string -> string -> bool
          Answer: bool -> bool
          Notification: string }

処理的には良くなってるのだけど、ユニットテストは QueryContext レコードに関数を持ってる関係でテストしにくい点があって、一部ザルになってる。 before/after でレコードが持つ関数の実行結果を比較したらいいけど、これまただるいな...という感じ。そこを頑張るよりも PocofQuery.run から個々に分解した関数自体のユニットテストをまだ書いてないから、そこで頑張る方がいいか。

あと ↑ に貼って思ったけど、 QueryContext.Notification て此処にあるべきではないな。これは InternalState に直に書き込んでやったら良さそう。早速直さな。

この対応によって、 PocofHandle.invokeAction の戻り値が 3-tuple から 4-tuple になって、 loop 関数の呼び出しがゴツくなってしまった。

@@ -52,8 +53,10 @@ module Pocof =
         |> function
             | Cancel -> []
             | Finish -> unwrap l
-            | Noop -> loop args l s pos NotRequired
-            | a -> invokeAction s pos args.props a |||> loop args l
+            | Noop -> loop args l s pos context NotRequired
+            | a ->
+                invokeAction s pos context a
+                |> fun (a, b, c, d) -> loop args l a b c d

これは流石にカッコ悪いので、 4-tuple 用のパイプライン演算子を定義してもいいのだけど...

let inline (||||>) (arg1, arg2, arg3, arg4) func = func arg1 arg2 arg3 arg4

素直に戻り値の構成を見直すのが良さそうと思ってる。独自に演算子を作るよりは、元々 InternalState にいても良さそうな refresh を loop の引数から削って InternalState に移動する感じ。

     let rec loop
         (args: LoopFixedArguments)
         (results: Entry list)
         (state: InternalState)
         (pos: Position)
         (context: QueryContext)
-        (refresh: Refresh)
         =

     type InternalState =
         { Query: string
           QueryState: QueryState
           PropertySearch: PropertySearch
           Notification: string
           SuppressProperties: bool
-          Properties: string list }
+          Properties: string list
+          Refresh: Refresh }

どうかな。

この他にもクエリに利用可能なプロパティ一覧を InternalState に移動して invokeAction の引数をスリムにするとかやってる。なるべく年内納得いく形にまとめて version 0.7 出したいのだけど、アレもコレもとなったら手に負えられないのでどっかで区切りをつけてリリース作業しよう。

F# でコマンドレットを書いてる pt.27

Sun, 17 Dec 2023 09:00:00 +0900

krymtkts/pocof の開発をした。

ずっと積んでた property の入力補完機能を作った。 #93

まだあんま使えてないが結構お気に入りの機能になった。だけど、今の実装は引数の取り回しだったり煩雑さが気に入ってなくて、どうにかリファクタリングできないものかと今も思ってる。

pocof では以下の流れでキー入力から実行コマンドを得て処理を行う。

入力キーを取得する
入力キーを文字入力・ショートカット・制御キーに選り分ける
選り分けたキーを実行コマンドに変換する
実行コマンドに引数を与えて実行する

今回の対応では、 4 のところでプロパティの一覧から候補のプロパティを導出するようにした。なので ↓ のように 4 の関数にはプロパティ一覧の引数を持つのだけど、この引数を使うのがプロパティ補完コマンドのみのため、そこがモヤっている。このへん

    let invokeAction (state: InternalState) (pos: Position) (props: string list) =

この最後の引数がなあ...

3 の実行コマンドへ変換するときに bind してもいいんじゃないかという気がせんでもない。でも今度はそこにプロパティ一覧の引数が増えるだけで、問題を別の場所に押し付けただけになってしまう。結局どっかのタイミングでプロパティ一覧を bind しないといけないし、 pocof 起動後はプロパティ一覧が変わることはないから起動したタイミングで bind すべきだったのかも... bind したとて引数の数減らんけどな。

悩みは多いが、プロパティ補完自体は上記でクリアした。

プロパティを補完したあとは、補完前の入力キーワードにマッチする候補を TAB とかで切り替えられるのが一般的なので、その実装もしている。

プロパティ補完の仕組み自体は大したことなくて、以下のような判別共用体を用意してそれぞれの状況に応じた処理を match で行うだけにしている。非補完時は NonSearch ¹ 、プロパティ検索時は Search 、候補切り替え用に Rotate がある。

Search にはキーワードを保持していて、そのキーワードで始まるプロパティに絞り込んだ結果をクエリ入力の下の行に表示している。これは既存の実装。 Rotate にはキーワード、選択中の index 、候補のリストを保持していて、これらを使えばマッチする候補を TAB 押下時に順繰り出力できる。これが今回追加した実装。

    type PropertySearch =
        | NonSearch
        | Search of string
        | Rotate of string * int * string list

文で書いたらシンプルだけど、この補完機能を担う関数がちょっとデカくて(これ)見た目にも分かりづらいかもなと思ってたりする。なんかスリムにしたい... debug log を仕込んだ事もあって余計に見にくい。

前回 Linux 用ビルドができたら alpha 外したリリースしたいな～といってたけどもうあんま年内時間残ってないし、この補完機能が組めたのもあるから、今の状態でリリースしたいお気持ちに変わった。コピペ時の動作が改善されておりかつ補完機能があるから、はよ自分の他の PC でも使いたい、という欲望に駆られての判断。

ひとまず #95 でリファクタリングはじめて、こまいバグも見つかってるから、いい感じに進めて 2023 年末リリースしよ。

この名前も今思えばイマイチで Noop か Normal でいいんじゃないかな。 ↩

F# でコマンドレットを書いてる pt.26

Sun, 10 Dec 2023 09:00:00 +0900

krymtkts/pocof の開発をした。

.NET 8 へ更新して、 F# 8 の機能を使ってみた。

SDK の更新ちょっといい手順がよくわからんのよな。 pocof の場合は以下でやった。 #88

dotnet new globaljson --sdk-version 8.0.100 --roll-forward latestFeature --force
dotnet add ./src/pocof.Test package Microsoft.PowerShell.SDK --version 7.4.0

test project の方は TargetFramework も net8.0 にしたのだけど、本体の方はやめておいた。なぜかというと netstandard2.0 にして Windows PowerShell もサポートしてみたいなという気持ちが突如湧き、そのようにしたからだ。

参考までに、 lockfile を生成している blog-fable の場合だと以下の手順になった。 krymtkts/blog-fable#120

```powershell
dotnet new globaljson --sdk-version 8.0.100 --roll-forward latestFeature --force
```

remove these from `App.fsproj`.

```xml
    <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
    <RestoreLockedMode>true</RestoreLockedMode>
```

```powershell
dotnet clean
fable clean
npm run build
# build success.
```

restore `App.fsproj` configuration.

```powershell
npm run build
# lockfile regenerated successfully.
```

このように、まず fsproj でロックしない設定にしてからビルドしないと、 F# の DLL の lockfile が期待のとおりにならなくてエラーを解消できなかった。

さて、ここまで来てようやく F# 8 の機能が使えるようになった。

Announcing F# 8 - .NET Blog

上記のアナウンスを参考にして、 Nested record field update 、 _.Property shorthand と `TailCall`` attribute を導入してみた。 #90

     let private switchMatcher (state: InternalState) =
         { state with
-            QueryState =
-                { state.QueryState with
-                    Matcher =
-                        match state.QueryState.Matcher with
-                        | EQ -> LIKE
-                        | LIKE -> MATCH
-                        | MATCH -> EQ } }
+            InternalState.QueryState.Matcher =
+                match state.QueryState.Matcher with
+                | EQ -> LIKE
+                | LIKE -> MATCH
+                | MATCH -> EQ }

書き換えるときに良さは感じなかったけど、これ実際に書くときに良さを感じるはず。

                         |> Seq.head
                         |> PSObject.AsPSObject
-                        |> (fun o -> o.Properties)
+                        |> _.Properties
                 | _ -> o.Properties)
-            |> Seq.map (fun p -> p.Name)
+            |> Seq.map _.Name
             |> Seq.fold (fun acc n -> acc.Add n) properties

もうこれは書き換えるときでも読みやすくなったなって感じがするわな。

TailCall attribute に関しては、 module 直下の関数かメソッドしか使えないみたい。関数内の関数に付与した場合、それが末尾再帰になってなくても警告されない。どっかで文書を見かけた気がするのだけど今探したら見つけられなかった。なんしか自分で動作確認をしてそうなってるというのは確認している。だからこれを使うためだけに関数内の関数を外に出した。

やっぱこういう検査機構は、ミスってないお墨付きがつくから気持ちが良い。もちろん今回付与した部分も大丈夫だった。

あとこの流れの中で PowerShell Gallery へ up してる配布物が pdb を含んだままになってると気づいたので、 DL サイズ下げたいしなくすことにした。

以下の文書を参考に設定した。

Common MSBuild Project Properties - MSBuild | Microsoft Learn

  <PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
    <DebugType>none</DebugType>
    <DebugSymbols>false</DebugSymbols>
  </PropertyGroup>

これでちょっとだけ配信サイズが縮んだ。

もうそろそろ次のリリースをしていい加減 alpha 外したい気持ちがしてきた。でもせめて Linux 用ビルドができからやりたいなーという気持ちもあり、年内どう最後を締めるか悩んでる。目標届かなくても改善点は細々あるし、なんなら .NET Standard 2.0 まで下げたのもあるから、出していいと思うけどなー。気持ちの面が邪魔してくる。

Fable でブログを再構築する pt.20

Sun, 03 Dec 2023 09:00:00 +0900

Fable で作った krymtkts/blog-fable の手直し。

細かすぎる修正は置いといて主だったものだけ記す。

もう 2 週前になるのだけど、 highlight.js の Solarized dark の CSS を CDN から引っ張ってきてたけど、 blog-fable の生成物へ同梱するようにした。 #112

CDN に分かれてたら package.json のバージョン更新に追随し忘れることもあるし、試した感じどうも GitHub Pages だとまとめて配信するほうが速いっぽいし。

node_modules 配下の highlight.js には minified な CSS が用意されてるのでそれをそのままコピった。 SCSS もあったので、試しに自前で sass --style=compressed --no-source-map 指定してビルドしてみたけど、ビミョーにデカくなったのでやめた。これは highlight.js をチラ見した感じ sass は使ってないから。スタイルを編集してること無いしそのまま利用で OK 。

これで外部への依存がリンクくらいしかなくなったはず。随分とスッキリしたな。

あと Markdown の脚注を有効にするの忘れてたので、追加した。過去の記事で数カ所脚注を使ってて、今後もたまに使うだろうしあった方がいいかなあと思ってのこと。

marked は Markdown の標準に脚注がないから対応してない。 GitHub Flavored Markdown(gfm) みたいに脚注をサポートしたいなら Extension を使うのが筋らしい。

Is "footnote" supported in marked.js? · Issue #714 · markedjs/marked

ちょうど最近 marked-footnote といういいのを作った人がいて、それをそのまま採用させてもらった。デフォだと脚注にでかいタイトルが付くのだけど、これは accessibility のためっぽい。でもあまりにもでかいし見出しは不要かなと思って水平ラインに置き換えた。スマン。

あと脚注に Markdown の link 記法 [nanigashi](https://example.com) を含むと正常に脚注を出力できないバグがあった。対象の脚注が [ を含む場合に正規表現で捕まえたい対象を逃してしまうというやつなのだけど、長めのパターンを直して PR するの面倒かもなと思って Issue を送ってみた。 Issue #23 · bent10/marked-extensions そしたらすぐに対応してもらえて、とても助かった。

使う node module はそんな感じで、次は Fable でどう使うかってところ。これに関しては、 Marked Extension に限定する限りは fable binding 書くメリットあんまないと感じてて、 obj をそのまま使った。

一点 marked-highlight.js と違って extension を作成する関数が export default になってた。この場合は対応する importDefault で取り込んであげないと対象が見つからない。 (この点 marked-highlight.js は大量に export されてるうちの 1 つだったから importMemberを使ってる)

以下のように obj をパラメータにして MarkedExtension を返す定義する。 option の指定は型ありのときと変わらず匿名レコードで行って、

        let markedFootnote: obj -> Marked.MarkedExtension = importDefault "marked-footnote"

        // 使うとき
        let footNote = markedFootnote !!{| description = "<hr />" |}

ただし間違ってても検査できないのが玉に瑕。でも局所的だしいちいち書くほどでもないかなと思って。その内気が変わるかもだけど

だいぶ npm module を Fable で使うときの取り回しに慣れてきた気がする～嬉しい。

F# でコマンドレットを書いてる pt.25

Sun, 26 Nov 2023 09:00:00 +0900

krymtkts/pocof の開発をした。

デバッグモードがほしいなと言っていたやつ #81
あと Linux で pocof を動作確認するための container image を作るやつ #84

デバッグモードに関しては、バグレポートをもらうときとかに -Verbose スイッチみたいに有効化したいシーンが想定される(pocof の場合 console に情報を出力できないからログファイル出力)。けど今のところ開発時に確認できる程度で良くて、 compiler directive で良さそうかなと思ってそうした。

Compiler Directives - F# | Microsoft Learn

これでサクッとログのファイル出力がされるようにしたのだけど、ちょっと弊害もあった。 dotnet test で実行されるテストってマルチプロセスかマルチスレッドで実行されるみたいで、単一のファイルへの書き込みだと System.IO.Exception する。回避のために、パフォ影響考えずにロックを掛けることで複数プロセスでの書き込みのエラーを発生しなくした。 MSBuild でプロセス数を絞れるみたいなので、それ使ったらいいのかも知れんけど。 MSBuild Command-Line Reference - MSBuild | Microsoft Learn

あくまで手軽にデバッグビルドで有効にするだけのログなのでこういう回避もアリかなと。

あと Caller information を使ってログを賑やかした。初めて試したみたけど DefaultParameterValue などは関数には使えなくてメソッドしかダメみたいね。 C# との相互運用が目的ならそらそうか。 Parameters and Arguments - F# 見る限り関数のサンプルないしな。

先述のドキュメントだけでわからない点は fslang-design を見るのが良さそう。今のところ IL の話まで理解する必要はないかも知れんけど、期待されるパターンが書いてあり、理解が深まる。 fslang-design/FSharp-4.1/FS-1027-complete-optional-defaultparametervalue.md at main · fsharp/fslang-design

Caller information 出してみた効果は使ってみて判断する。ただ RFC3339 形式の日時出力も足したしそれだけは使えそう。

次は Linux の container image を作るやつ。初めは以下の MS 謹製 PowerShell image に dotnet 足したらいいかなと思ってたが、結構面倒だった。

PowerShell by Microsoft | Docker Hub

何が面倒って dotnet 7 の最新バージョン(7.0.404 とか)が distro の repository にあるとは限らないこと。最新を使いたければ Microsoft の repository を引き込む必要がある。試しに Alpine Linux, Ubuntu で見てみたけど 7.0.1xx なので pocof の global.json の条件満たしてねえ。

自力で追加するなら Linux でのインストール方法 (.NET and Ubuntu overview - .NET | Microsoft Learn)を Dockerfile に焼き直すだけ。なのだけど、めんどしこんなん世界で誰かが既にやってるやろと思って container image を探した。

結局 dotnet の Linux container image が dotnet 完備で PowerShell も新しくて楽なので採用した。これサイコー。 .NET SDK by Microsoft | Docker Hub

ただサイズがデカイ... 1.5GB もあった。

ひとまず Linux の PowerShell 環境を手に入れたので、 pocof を対話モードで動かしてみたところ、以下のエラーを得た。

PS /src> Get-ChildItem | Select-Pocof
Select-Pocof: The method or operation is not implemented.

前から unit test と Pester による非対話モードのテストは Windows, Linux, Mac いずれも成功してる。 cross platform の対話モード依存のエラーってことかな。対応できてないやろなと想像はしてたけど、やっぱ動いてなかったので Issue を作成。#85

エラーの詳細を見たら Microsoft.PowerShell.ConsoleHostRawUserInterface.GetBufferContents がダメみたい。まじか。

PS /src> $ErrorView = 'DetailedView'
PS /src> $Error

Exception             :
    Type       : System.NotImplementedException
    TargetSite :
        Name          : GetBufferContents
        DeclaringType : Microsoft.PowerShell.ConsoleHostRawUserInterface, Microsoft.PowerShell.ConsoleHost, Version=7.3.10.500, Culture=neutral, PublicKeyToken=31bf3856ad364e35
        MemberType    : Method
        Module        : Microsoft.PowerShell.ConsoleHost.dll
    Message    : The method or operation is not implemented.
    Source     : Microsoft.PowerShell.ConsoleHost
    HResult    : -2147467263
    StackTrace :
   at Microsoft.PowerShell.ConsoleHostRawUserInterface.GetBufferContents(Rectangle rectangle)
   at System.Management.Automation.Internal.Host.InternalHostRawUserInterface.GetBufferContents(Rectangle r)
   at pocof.PocofScreen.RawUI..ctor(PSHostRawUserInterface rui) in /src/src/pocof/UI.fs:line 55
   at pocof.PocofScreen.init(PSHostRawUserInterface rui, String prompt, FSharpFunc`2 invoke) in /src/src/pocof/UI.fs:line 173
   at pocof.SelectPocofCommand.interact(InternalConfig conf, InternalState state, Position pos, PSHostRawUserInterface rui, FSharpFunc`2 invoke) in /src/src/pocof/Library.fs:line 44
   at pocof.SelectPocofCommand.EndProcessing() in /src/src/pocof/Library.fs:line 191
CategoryInfo          : NotImplemented: (:) [Select-Pocof], NotImplementedException
FullyQualifiedErrorId : NotImplementedException,pocof.SelectPocofCommand
InvocationInfo        :
    MyCommand        : Select-Pocof
    ScriptLineNumber : 1
    OffsetInLine     : 17
    HistoryId        : 2
    Line             : Get-ChildItem | pocof
    PositionMessage  : At line:1 char:17
                       + Get-ChildItem | pocof
                       +                 ~~~~~
    InvocationName   : pocof
    CommandOrigin    : Internal
ScriptStackTrace      : at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo :

似てそうな Issue みつけたけど transcript してないしな。

Unix system executables terminate with error if transcription enabled · Issue #1920 · PowerShell/PowerShell

今ん所は NotImplementedException を検知した場合の workaround として pocof 開く前のバッファの復元をしないようにして、最小限の Linux 対応とした。 #86

Linux でもバッファの復元したいし、もうちょっと調査する。 PowerShell/src/Microsoft.PowerShell.ConsoleHost/host/msh/ConsoleHostRawUserInterface.cs のこの箇所見るに単純に実装されてなかったりして...

この container iamge 試行錯誤の影響で、自機の 256 GB しかない記憶領域の残が 1 GB を切ってしまった。やば。直ちに container image の掃除と VHD を圧縮することにした。 Windows 11 Home だと Optimize-VHD が使えないので、以下のように diskpart というコマンドを使うらしい。

WSL 2 should automatically release disk space back to the host OS · Issue #4699 · microsoft/WSL

ここで attach, detach なくてもできるみたい。動的に拡張できる VHD なので readonly いらんのかな。

How to Shrink a WSL2 Virtual Disk – Stephen Rees-Carter

compact vdisk | Microsoft Learn

Remarks

A dynamically expanding VHD must be selected for this operation to succeed. Use the select vdisk command to select a VHD and shift the focus to it.
You can only use compact dynamically expanding VHDs that are detached or attached as read-only.

単純な手順を示すとこんな感じ。

docker system prune --all --force # 掃除しきる
wsl --shutdown
Resolve-Path  ~\AppData\Local\Docker\wsl\data\ext4.vhdx | Set-Clipboard
diskpart # 以降 diskpart との対話
# select vdisk file="paste here"
# compact vdisk
# exit

このように diskpart の窓の中でコマンド打たないといけないのは非常にだるい。ここは例に倣ってスクリプト化しておきたい。

diskpart scripts and examples | Microsoft Learn

以下に試作した手順を記す。

# Docker Desktop も dockerd も立ち上がってない前提
Start-Process "C:\Program Files\Docker\Docker\resources\dockerd.exe" -WindowStyle Hidden
# dockerd がいれば docker cli は動かせる
docker system prune --all --force
Get-Process "*dockerd*" | % {
    $_.Kill();
    $_.WaitForExit()
}
wsl --shutdown
$vdisk = Resolve-Path  ~\AppData\Local\Docker\wsl\data\ext4.vhdx
$tmp = "${env:Temp}/diskpart.txt"
@"
select vdisk file="$vdisk"
compact vdisk
"@ | Set-Content -Path $tmp
diskpart /s $tmp > ./log.txt
cat ./log.txt | Write-Host
Remove-Item $tmp,./log.txt

少なくとも docker ~ ってコマンドを打つだけなら dockerd.exe が立ち上がってさえいれば OK 。なので VHD の圧縮だけならこんな感じでいけそうなのだけど、 Docker Desktop の起動・終了の制御だけ全くわからんくて調査中。同時に Docker Desktop が立ち上がってるとどのみちこいつを graceful に殺さねば wsl --shutdown で Docker Desktop がエラーダイアログ出してくる。 com.docker.backend.exe が全てを司ってるのはわかったけど、こいつをどのように御せばいいのかわからん。

次、積み残し Issue やりたいなと思いつつも、 .NET 8 来たし更新するのが先かな。 F# 8 に新しく来た _.Property shorthand と nested record field copy and update は pocof でもすぐ取り入れたいしな。 Announcing F# 8 - .NET Blog

F# でコマンドレットを書いてる pt.24

Sun, 19 Nov 2023 09:00:00 +0900

pocof の開発をした。

描画部分で PSHostRawUserInterface をそのまま取り回してたところに一層別の型を噛まして、ちょっとだけ unit test を書けるようにした。 #73

PSHostRawUserInterface の mock をそのまま書こうものなら大量のメソッドを実装することになりそうだし、一層噛まして楽にできたと思う。まだ触り程度の test しか書いてないけど、あるとないでは天地の差よ。

この対応の中でおもしろかったのが、 platform 違いを体感できたこと。キー入力周りの .NET の cross platform の挙動の違いだったりバグについては .NET ブログかなんかで見たことがあったのだけど、今回初めてほんまに違うんやなと実感した。

PSHostRawUserInterface を wrap した型の mock を unit test で書いたのだけど、そこでたまたま既存コードのコピペで Console.TreatControlCAsInput を使ったところがあった。これ、 Windows でのみアクセス時に System.IO.IOException : The handle is invalid. が発生する。 Linux や Mac ではこの不正な handler は発生せずテストが成功していた。 Refactor PocofScreen. · krymtkts/pocof@3de1579

以下こけてた Windows のログを抜粋。 test (windows-latest) · krymtkts/pocof@3de1579

[xUnit.net 00:00:01.01]     PocofUI+Buff writeScreen.should render top down. [FAIL]
  Error Message:
   System.IO.IOException : The handle is invalid.
  Stack Trace:
     at System.ConsolePal.get_TreatControlCAsInput()
   at PocofUI.MockRawUI..ctor() in D:\a\pocof\pocof\src\pocof.Test\PocofUI.fs:line 19
   at PocofUI.Buff writeScreen.should render bottom up.() in D:\a\pocof\pocof\src\pocof.Test\PocofUI.fs:line 70
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
   at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)

CLI のハンドラのなんかが起こってるのは間違いなそうやけど何も解決策分からず。 unit test なので実際に CLI の in/out を司る者がいないからこうなるんやろけど。 mock やし単に true が欲しかっただけの箇所なので、 Console.TreatControlCAsInput を利用しないようにさえすれば起こらないのでそう直した。

あと別件で、 .NET 8 がリリースされ PowerShell 7.4 が出たことで Microsoft.PowerShell.SDK 7.4.0 が来てた。 dependabot.yml の設定がまずかったからその変更で PR を作られてしまった。 .NET 7 のままだからか Microsoft.PowerShell.SDK を利用してる箇所のテストコードが null reference でクラッシュするという事態に。 Bump the test-lib group with 2 updates · krymtkts/pocof@acf0c31 すまん dependabot-san 。

こういうインパクトの大きい更新は自分でやるから、 Microsoft.PowerShell.SDK と PowerShellStandard.Library の patch version しか受けないよう変更した。 .NET と PowerShell のバージョンが相互に関係し合うのは知ってるけど、他に利用してる NuGet module がどう影響受けるか把握してないので、ちょくちょく着手していきたい。ゆーても Chocolatey には 7.4 の更新きてるのを確認して自機の PowerShell 7.4 に上げたばっかりなので、ちょっと後で。

(余談やけど PowerShellStandard.Library 7.0.0-preview.1 が unlisted なの初めて知った。 Microsoft.PowerShell.Standard.Module.Template からは参照されたままなのだけど数年動き無いしどうなるんやろ。)

pocof/.github/dependabot.yml から NuGet module のところだけ抜粋。

- package-ecosystem: "nuget"
  directory: "/"
  schedule:
    interval: "weekly"
    day: "friday"
    time: "06:00"
    timezone: "Asia/Tokyo"
  groups:
    pwsh-std:
      patterns:
        - "PowerShellStandard.Library"
      update-types:
        - "patch"
    pwsh-sdk:
      patterns:
        - "Microsoft.PowerShell.SDK"
      update-types:
        - "patch"
    test-lib:
      patterns:
        - "*"
      exclude-patterns:
        - "PowerShellStandard.Library"
        - "Microsoft.PowerShell.SDK"
  ignore:
    - dependency-name: "PowerShellStandard.Library"
      update-types:
        - "version-update:semver-major"
        - "version-update:semver-minor"
    - dependency-name: "Microsoft.PowerShell.SDK"
      update-types:
        - "version-update:semver-major"
        - "version-update:semver-minor"
  assignees:
    - "krymtkts"
  reviewers:
    - "krymtkts"

このように特定のモジュールの major minor update を除外したいとなると、groups の指定だけではできない。明示的に ignore に該当モジュールを入れないと個別に PR 送る対象になってしまうので、なんか煩雑な感じの記述になった。

dependabot-san の設定変更できつかったのが、 main branch に dependabot.yml が反映されないと内容の検査ができないところ。まだ linter とかの検証方法無いよな？そういう Issue も開いたままだし。

Make it possible to validate Dependabot config before it lands on main · Issue #4605 · dependabot/dependabot-core

何度もやり直すのはまあ良しとしても、きついのは PR 作りまくったり Git の履歴が汚れるところ。なんかいい方法ないんかいな。

F# でコマンドレットを書いてる pt.23

Sun, 12 Nov 2023 09:00:00 +0900

pocof の開発をした。

作り始めた頃からずっと放置してた bottom up のレイアウトに対応した。 #72

自分で Issue 作っといてなんやけど、当初よりコレある意味あんのかな？という感じがしてて、やり始めるまで気乗りしなかった。しかしいざ手を動かしてみたら top down と部分的に違うだけでほぼ同じやし、長らく放置してた pocof の描画部分を思い出すのにもちょうどいいかもなと思えてきた。久しぶりに pocof の開発する通過儀礼としてはいい感じだった。あと逆さまに検索内容が表示されるのも案外面白かったので、あってもいいかなコレという気にはなれた。

描画部分を久しぶりに触ったので PSHostRawUserInterface をそのまま取り回してるから unit test 書けない(書きづらい)ねんよなというのも思い出した。でも今になって見た感じだと、PSHostRawUserInterface をくるんだ型を作っといて一層挟んであげればどうにかなるなと言う感触がする。

検索で絞り込んだ内容をデバッグログに出力する機能も長らく作ってなくて、開発時にはてきとーに開発用のコードを挟んでたりしたので、そのへんも合わせてリファクタリングしたいなーという気持ちになってきた。

今回 top down / bottom up に対応した描画ロジックは以下の通り。 pocof/src/pocof/UI.fs

        member __.writeScreen
            (layout: PocofData.Layout)
            (state: PocofData.InternalState)
            (x: int)
            (entries: PocofData.Entry list)
            (props: Result<string list, string>)
            =
            let basePosition, firstLine, toHeight = // NOTE: 主にいじったのここ。 layout に応じて作られた let binding を使うように全体調整しただけ
                match layout with
                | PocofData.TopDown -> 0, 1, (+) 2
                | PocofData.BottomUp ->
                    let basePosition = __.rui.WindowSize.Height - 1 // NOTE: こういう PSHostRawUserInterface に直接アクセスする部分を取り除く
                    basePosition, basePosition - 1, (-) (basePosition - 2)

            __.writeScreenLine basePosition
            <| __.prompt + ">" + state.Query

            __.writeRightInfo state entries.Length basePosition

            // NOTE: これオプションでどうにかする
            // PocofDebug.logFile "./debug.log" [ List.length entries ]

            __.writeScreenLine firstLine
            <| match state.Notification with
               | "" ->
                   match props with
                   | Ok (p) -> (String.concat " " p).[.. __.rui.WindowSize.Width - 1]
                   | Error (e) -> "note>" + e
               | _ -> "note>" + state.Notification

            let h = __.rui.WindowSize.Height - 3

            let out =
                match List.length entries < h with
                | true -> entries
                | _ -> List.take h entries
                |> PocofData.unwrap
                |> __.invoke
                |> Seq.fold
                    (fun acc s ->
                        s.Split Environment.NewLine
                        |> List.ofArray
                        |> (@) acc)
                    []

            seq { 0..h }
            |> Seq.iter (fun i ->
                __.writeScreenLine
                <| toHeight i
                <| match List.tryItem i out with
                   | Some s ->
                       // NOTE: これオプションでどうにかする
                       // logFile "./debug.log" [ s ]
                       s
                   | None -> String.Empty)

            __.setCursorPosition
            <| __.getCursorPositionX state.Query x
            <| basePosition

関数がでかいしゴチャついてる。デバッグログ出力がコメントアウトで残されており雑い。でも色々やれるイメージ湧いてきて、良い。ひとまず NOTE コメントのある箇所をどうにかしたい。

__.rui が PSHostRawUserInterface なのだけど、こいつをまず引き剥がしたいところ。その後デバッグモードの組み込みをしてデバッグログ出力を改善する。 page up / down のサポートをするときには、描画対象となるデータを取ってる let out のところを表示中のページと描画域の行の数で調整して～とか。

描画で Console.Write を使って茶を濁してるところはもうちょっと先。コンソールバッファの操作に関してわからないことが多いから調べないといけない。クロスプラットフォーム見据えたら .NET だけでできる範囲限られてそうやし。 Windows 以外ではインタラクティブな操作をテストしてないのもあって。

blog-fable の方を積極的にいじる熱落ち着いてるので、これから当面イメージが湧く限り pocof に集中していけそう。いつまで続くか知らんけど。

F# でコマンドレットを書いてる pt.22

Sat, 04 Nov 2023 09:00:00 +0900

pocof の開発をした。

krymtkts/blog-fable で素振りした dependabot の導入 #62 #63 #64 #69
キー入力に async expression を利用する #67

キー入力に async expression を利用する、がメイン。 krymtkts/blog-fable の開発で F# の async expression を触ったので、ちゃんと F# らしく pocof を改善してこうという気になった。

元々はキー入力されるまで Console.KeyAvailable でチェックして無限に再帰する形で実装してたのだけど、このコメントによれば、どうも継続を使ったら非同期にできるらしい。 asynchronous - Async to wait for a key in F#? - Stack Overflow

回答者が Invoke-Build の nightroman サンというのも渋い。ぜひ使いたい。

Async.FromContinuations でキー入力待ちを非同期にして Async.RunSynchronously で結果を待ち受ける。これによって無限ループで無駄に CPU 回していたやつが回避される、と。ひとまずこうした。

            let getKey () =
                Async.FromContinuations(fun (cont, _, _) -> Console.ReadKey true |> cont)
                |> Async.RunSynchronously

これでキー入力してないときの CPU 使用率はかなり改善された。

元々コピペした文字列を Console.ReadKey で 1 文字ずつ読み取って表示の処理まで回してるからパフォ良くない課題がある。今回の非同期化で幾分シンプルになったし、 Console.KeyAvailable と再帰を組み合わせて文字列丸ごと読み取ることで改善できそうな雰囲気も感じてきた。

因みに Async expressions - F# | Microsoft Learn にはこういう定石パターンみたいなの載ってなかったので、今回のように実例から学ぶのがいいのかな。

今回のキー入力を非同期にしたやつは、先にググったらそのまま良さそうな snippet が見つかったから GitHub Copilot には相談しなかった。でも次は聞いてみたらなんか良いコード出してもらえるかもな。

他に Lazy Expressions - F# | Microsoft Learn なんかも試したいけど pocof に活用できることないかもな...という直感。まずコードを漁って実例から学ぶとしよう。

Fable でブログを再構築する pt.19

Sun, 29 Oct 2023 09:00:00 +0900

Fable で作った krymtkts/blog-fable にブログ乗り換えたけど、まだ気になるとこをいじったりしている。

依存関係のメンテを楽にするため、 Dependabot version updates を使ってみることにした。以下を参考にして krymtkts/blog-fable で dependabot.yml を作成した。

使い始めて 1 週間くらいの利用期間を経て色々見えてきた感じ。

使ってみて早々、コレ結構設定(dependabot.yml)で調整してても Fable の project とは相性悪いなーと思った。 Fable の依存関係って .NET(NuGet) と npm 、 2 つの package system にまたがってるものがある。 krymtkts/blog-fable における具体例だと Feliz から react,react-dom に依存してるけど、これを dependabot.yml では複数 package-ecosystem をまとめた groups を書けないみたい。 JSON Schema の package-ecosystem が string やし。つまり dependabot サンが .NET で Feliz か npm で react* の PR を作ってきたら、自分で femto で更新して～みたいな流れを踏む必要がある。

結果的に npm 側の react* を検知しないようにして Fable.*,Feliz だけ dependabot サンに PR 作ってもらい、自分で femto で更新するように、今はしている。なんか、特定の依存関係の PR を dependabot サンが作ったのを引き金にして workflow で femto install して commit 的自動化ができたらカッコよさそう。でも実現可能性についてはまだ調べておらず、さっぱりわからん。

現状このような形での設定となった。 JST 金曜にチェックするのはだいたい週末に趣味プロするから。

version: 2
updates:
  # Maintain dependencies for GitHub Actions
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "friday"
      time: "09:00"
      timezone: "Asia/Tokyo"
    groups:
      workflow:
        patterns:
          - "*"
    assignees:
      - "krymtkts"
    reviewers:
      - "krymtkts"
  # Maintain dependencies for NuGet
  - package-ecosystem: "nuget"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "friday"
      time: "09:00"
      timezone: "Asia/Tokyo"
    groups:
      dotnet-tools:
        patterns:
          - "fable"
          - "femto"
      fable:
        patterns:
          - "Fable.*"
          - "Feliz"
    assignees:
      - "krymtkts"
    reviewers:
      - "krymtkts"
  # Maintain dependencies for npm
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "friday"
      time: "09:00"
      timezone: "Asia/Tokyo"
    groups:
      dependencies:
        dependency-type: "production"
        exclude-patterns:
          - "react*" # NOTE: react should be updated with Fable.
      dev-dependencies:
        dependency-type: "development"
    assignees:
      - "krymtkts"
    reviewers:
      - "krymtkts"

あと NuGet の lock file を使ってる場合とも相性が悪いぽくて、 dependabot サンは *.fsproj のバージョンは上げてくれるけどそこから lock file の作り直しはしてくれないみたい。 npm の package.lock.json はやってくれるのになんでだよと思ったが、やっぱ Issue 立ってるみたい ↓。

Support for NuGet package lock files · Issue #1303 · dependabot/dependabot-core コレみたい。間違ってたらスマン。

結局この場合も手でメンテしてやる必要があって、いまんところ以下が最も引っかかることなく作業できるかなって思ってる。ここまで来たら dependabot サンが対応するまでは bump 用に task runner 作っておいた方が良いよな...

rm .\src\packages.lock.json
# この辺を一掃しておかないとエラーになる
fable clean
femto install Fable.Core ./sr
# 動作確認ができて lock file が再生成される
npm run build

更に、 dependabot サンから PR を受け付けたら、端的にいうと動作確認が必要になる。お試し運用期間は動作確認スタイルで良いかなと始めてみたけど、依存関係の更新頻度 1 週間でも結構きついなという量だったので、テストの自動化は必須。でも krymtkts/blog-fable にはテスト無いから、単純に fable によるビルドと Markdown からの SSG がコケないのだけはチェックできたら良いかなと。

なので Pull request 受け付けたときにはビルドだけして、 main branch への merge 後に GitHub Pages へ deploy って形になる。そしたら追加した PR 用と元々ある deploy 用でビルド箇所の YAML は丸かぶりするわけ。コレもめんどい。

結局 composite action を作って使い回すのが良さそうだった。 Creating a composite action - GitHub Docs

試してみたら、 composite action で出力されたファイルはうまく後続の step でも使えた。こういう composite action を用意した。

name: "Build pages Action"
description: "Setup .NET and Node.js, install dependencies and build pages."

runs:
  using: "composite"
  steps:
    - name: Setup .NET
      uses: actions/setup-dotnet@v3
      with:
        global-json-file: ./global.json
        cache: true
        cache-dependency-path: src/packages.lock.json
    - name: Setup Node.js
      uses: actions/setup-node@v4
      with:
        node-version: 20
    - name: Install dependencies
      shell: bash
      run: npm install
    - name: Build pages
      shell: bash
      run: npm run build

使う方はこう。

name: Deploy GitHub Pages

on:
  push:
    branches: ["main"]
  workflow_dispatch:

permissions:
  contents: read
  pages: write
  id-token: write

concurrency:
  group: "pages"
  cancel-in-progress: true

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Build pages
        uses: ./.github/actions/build # ここが composite action で楽になっている
      - name: Setup Pages
        uses: actions/configure-pages@v3
      - name: Upload artifact
        uses: actions/upload-pages-artifact@v2
        with:
          path: docs/

  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v2

他にワークフローの再利用を使う手もあったけど、今回のケースでは docs/ に出力したファイル群を使いまわせるか不明だったので確認がとれてた composite action でやった。 Reusing workflows - GitHub Docs

いずれもドキュメントにはそういう記述なかった気がするけど案外いけるのかな。今度試してみたい。

Dependabot version updates を試してみたことで必要性に駆られて composite action にも手を出した。脇道それた感あるが、結果的に pocof にも適用できるものを得られたのでヨシ！😹

Fable でブログを再構築する pt.18

Sun, 22 Oct 2023 09:00:00 +0900

Fable で作ったブログに乗り換えたけど、まだ気になるとこをいじったりしている。

まず画像の Lazy loading をつけてみた。画像貼ることあんまりないけど。何ができるかなーと MDN を調べてみてすぐできそうだったので。

Lazy loading - Web performance | MDN

要は ![...](...) こういう画像リンクの場合に以下のように loading="lazy" をつけるだけ。

<img src="..." alt="..." loading="lazy" />

Marked の Renderer にオプションを渡して img タグ出力を担う image 関数を上書きしたら良いだけ。Using Pro - Marked Documentation

コード長いので該当のオプションの箇所だけを転記する。コレで可視範囲外の画像が遅延読み込みされるようになるらしい。実に単純な変更だ。

            let image (href: string) (title: string) (text: string) =
                // NOTE: add lazy loading attribute.
                $"""<img src="%s{href}" title="%s{title}" alt="%s{text}" loading="lazy" />"""

            let mops =
                !!{| heading = heading
                     link = link
                     listitem = listitem
                     checkbox = checkbox
                     image = image |}

試しにいっぱい画像があるページの昔 Planck を組み立てた記事なんかを開いてみたら、意外と画像読み込まれてて実際にコレで効果あんのか？という感じがした。でもスクロールダウンしていくと、確かに 1 枚だけ遅延読み込みされてきた。すご。 1 枚かーという気もしなくはないけど、いつか異常に大量の画像を貼る機会があったら効果を実感するだろう。機会なさそうやけど。

他に、 GitHub Pages へ deploy する workflow で NuGet package のキャッシュを試してみた。

Caching NuGet Packages | actions/setup-dotnet

初回は単にフラグオンでいけるかなと思ってやったが NuGet package の lock file を作ってなくて失敗した。これ当然の話しでドキュメントにも lock file 無いとエラーするって書いてた。けど読まずに体当たりしたため。

そも NuGet package の lock file のことあんまりわかってなかったので、ひとまず fsproj に出力するための設定をしてみたり。以下で勉強した限りオプション入れるだけっぽい。

lock file さえあればちゃんとエラーすることなく正常終了した。初回でキャッシュが無いから、ログにもそう出てた。

#72 のログを転記。

Run actions/setup-dotnet@v3
  with:
    global-json-file: ./global.json
    cache: true
    cache-dependency-path: src/packages.lock.json
  env:
    GITHUB_PAGES: true
/home/runner/work/_actions/actions/setup-dotnet/v3/externals/install-dotnet.sh --channel 7.0
dotnet-install: .NET Core SDK with version '7.0.402' is already installed.
Dotnet cache is not found

Actions タブの Caches を見たらキャシュが作成されてたので、キャッシュがなくなる前に次の workflow 実行したらキャッシュ有り版のログになるかな。

ちょうど bug があったので直したやつ #73 を merge したところ、キャッシュ使われてた。ただ workflow 全体を見て速くなった感じはなさそう。 Fable だからなのか。

#73 からログを転記。

Run actions/setup-dotnet@v3
  with:
    global-json-file: ./global.json
    cache: true
    cache-dependency-path: src/packages.lock.json
  env:
    GITHUB_PAGES: true
/home/runner/work/_actions/actions/setup-dotnet/v3/externals/install-dotnet.sh --channel 7.0
dotnet-install: .NET Core SDK with version '7.0.402' is already installed.
Received 131171387 of 131171387 (100.0%), 161.8 MBs/sec
Cache Size: ~125 MB (131171387 B)
/usr/bin/tar -xf /home/runner/work/_temp/bf7a4381-abc4-4d1d-90af-6c72251bb2dd/cache.tzst -P -C /home/runner/work/blog-fable/blog-fable --use-compress-program unzstd
Cache restored successfully
Cache restored from key: dotnet-cache-Linux-73204c40d9255ea97458df81ea64893c7b0c7130549819b8ae0fb308360b2d25

この方法で NuGet package のキャッシュできそうなので、同じ方法を krymtkts/pocof にもやってみたのだけど、そっちはまだ模索中。 platform が違うと生成される contentHash も違うらしく NU1403 というエラーで頓挫している。

NU1403 と cross-platform 周りで調べた内容。 NU1403 が出たら DisableImplicitNuGetFallbackFolder で大体解消するってのが定石らしいけど、 cross-platform なので話は別ぽい。調べたが理解が浅くてわからん。 cross-platform な lock file を置いても nektos/act でテストすると hash が合わないエラー NU1403 が解消できない。

なんで Fable の方は Windows で生成した lock file が ubuntu の runner でうまくいったんだろうか。 NuGet Package への理解が浅い。

あとやりたいこととしては、以前から気になってる Bulma の css 軽量化。

ただ前に書いたように Bulma がちゃんと SCSS 対応されてないことで @use を使った場合にスタイルを部分的にするとビルドエラーするから、それをなんとか解消できないと先がない。妥協案としては @use を諦めて @import にしたら良いのだろうけど、 SCSS で非推奨やからなあ...悩ましい。

続く。

Fable でブログを再構築する pt.17

Sun, 15 Oct 2023 09:00:00 +0900

Fable で作ったブログに乗り換えた。このブログは既に Powered by krymtkts/blog-fable だ。

前回検証したときの手順ベースでうまくできた。

# krymtkts/krymtkts.github.io の root directory にて
git switch --create feature/blog-fable

# 現行ブログのリソースを削除する
ll -Exclude content,contents | rm -Recurse

git add -u
git commit -m "Remove old resources."

# blog-fable repo を merge する
git remote add blog-fable ssh://git@github.com/krymtkts/blog-fable.git
git fetch blog-fable
git merge --allow-unrelated-histories blog-fable/main

# Sample を消す
rm contents/* -Recurse
git add -u
git commit -m "Remove sample posts and pages."

'posts','pages' | %{mv "./content/md/$_" "./contents/$_"}
'img' | %{mv "./content/$_" "./contents/$_"}

# 旧コンテンツを消す
rm content -Recurse

git commit -m "Move contents."

# エラーしないように Markdown を書き換える
# 自動でできる分
. .\scripts\convert-contents.ps1
# あと少しの手動書き換え
# App.fs の設定を書き換える

# 実行して動作確認する
npm ci
npm run dev

自動で書き換え可能と判断した以下は PowerShell でスクリプト化(scripts\convert-contents.ps1)した。今思えば F# スクリプトで書いても良かったなという感じもするけど。

posts の front matter を edn から YAML に変換
内部リンクに .html を付与
コードブロックの言語 typo とか非対応言語の置換

少し手で書き換えたのは以下。対処法ないものやめんどいもので止む無く。

言語なしのコードブロック(```)
- 閉じる方特別つかず、手動で ```plaintext に変更した
edn で書かれた front matter の tags リストにカンマがないやつ
- スクリプトでできる気がしたが数少なかったので
pages の書き換え
- 1 ページしかなかったので
相対リンクで書かれてたかしょ
- 1 箇所しかなかったので...

因みにこの手順だけでは終われなくて、 GitHub の repository の設定をイジる必要があった。具体的には、 branch から deploy される設定を GitHub Actions で deploy するように変更した。

Settings -> Pages -> Build and deployment の Source を GitHub Actions に変える

これを既存の Deploy from a branch から変えるのは公開中ページに影響ないか度胸がいったが、サクッと変えてもサイトが非公開化されたりしなかったので、安心してよい。

ちゃんと準備してきたこともあってすんなり終わった。

Markdown parser だったり highlighter は自分で書いてないけど、結構な部分自分で作った感じするので、愛着が湧いて良い。けっこう速くできてるけど、まだ高速化できる箇所もあったりなんかメンテの楽しみが増えて良いな。期間にして半年くらいの週末と休日の数時間を使って作ってきて、時間かかり過ぎな気もするが現時点で満足の行くものになった気がする。

Fable でブログを再構築する pt.16

Sun, 08 Oct 2023 09:00:00 +0900

krymtkts/blog-fable Fable でブログを再構築している。

こまい修正をして、その後現ブログの Markdown を元にどれくらいのパフォを望めるのか試してみた。

パフォ比較時点での記事数は今書いているこの記事を含めて、 posts が 151 pages が 1 画像が 25 。

# krymtkts/krymtkts.github.io の root directory にて
PS> 'md/posts', 'md/pages', 'img' | ForEach-Object { Get-ChildItem ./content/$_ -Recurse -File | Measure-Object | Select-Object -ExpandProperty Count }
151
1
25

この状態で lein run だと 3 度試行して概ね 26.174 , 27.144, 28.722 。 26~28 くらいか。

次に krymtkts/blog-fable の歴史を krymtkts/krymtkts.github.io に統合して測定する。統合する手法は前に Blog 用 Git repositories のマージでやったのと同じで慣れたもの。生成元の Markdown 配置だけ構造変わってるのでそこの置き換えだけは必要な感じだが、今回は検証なので symbolic link でやる。 Markdown と画像以外は全部消す。

# krymtkts/krymtkts.github.io の root directory にて
git switch --create feature/blog-fable

mkdir contents

# 現行ブログのリソースを削除する
ll -Exclude content,contents | rm -Recurse

git add -u
git commit -m "Remove old resources."

# blog-fable repo を merge する
git remote add blog-fable ssh://git@github.com/krymtkts/blog-fable.git
git fetch blog-fable
git merge --allow-unrelated-histories blog-fable/main

# Administrator access で検証のための symbolic link を作成する
rm contents/* -Recurse
'posts','pages' | %{New-Item -ItemType SymbolicLink -Path contents -Name $_ -Value "$(pwd)/content/md/$_"}
'img' | %{New-Item -ItemType SymbolicLink -Path contents -Name $_ -Value "$(pwd)/content/$_"}

# エラーしないように Markdown を書き換える ← 後述
# App.fs の設定を変える

npm install
npm run build

これで初回はビルドが発生するので 21.479 、若干速くなるけどキャッシュなしならあんま変わらんなという印象は否めない感じ。以降はキャッシュがあったら 6.424 , 7.597 という感じだった。

前回このように記した。

あと気になるのはパフォ面。 Fable のビルドは遅いけどそれ以外は結構速いから期待できんじゃないかな。 Cryogen での SSG は記事が多いともっさりしてて 151 記事で lein run の終了まで 25 秒くらかかる。 8 記事しかない状態で 4 秒未満のとこしか見てないから、 Cryogen と同じ記事数でどうなるか...

少なくともローカルで Markdown を書いて開発サーバで確認する分には速くなりそう。 GitHub Actions のワークフローで動かす分にはあんまり変わらないか。何なら npm と dotnet 両方の依存関係があるし遅くなったりして。

GitHub Actions でキャッシュするようにしたら良さそうか。でも GitHub Actions のキャッシュて 7 日間経過したら消えるらしいので、自分の使い方だと大体週一やからキャッシュの恩恵にあずかれなさげかな。ひとまずやるだけやろう。

あと一部先述しているように本格的な移行を進めるにあたり、以下の最低限対応が必要。

highlight.js 未対応言語の書き換え
- わかりやすいように新ブログでは謎言語をエラーで許容しなくしたので、言語の識別子の typo や空, textile log みたいな対応してないやつがエラーするようになった
front matter を edn から YAML 形式に書き換え
(念のため) サイト内 link に .html を足すようにする
- GitHub Pages だといい感じに処理してくれるが、新ブログで生成する *.html に合わせる

他に見落としあるかも？という気はせんでもないが、最低限これだけ処置すればいつでも現ブログを移行できるようになるはず。

front matter の書き換えだけちょっとめんどくさいな...というやる気ゼロモードだが、あえて edn を維持する必要がなくやらざるを得ない。量的に(150 あり)手作業はありえないので PowerShell でいい塩梅に処理できないか検討する。

ここまでくればあとは実施するのみだが、コレやってしまうと Feedly で見る限り少なくとも世界に 1 人は購読してくれている人がいるので、その人に影響あろうからちょっと気になるところではある。仕方ない点ではあるか。

あとアレな、 Fable と共に過ごすということは Node.js のエコシステムの上で生活するので、依存関係の更新が今後ずっとつきまとう。メンテの省力化のために dependabot 導入とか考えても良さそう。

Fable でブログを再構築する pt.15

Sun, 01 Oct 2023 09:00:00 +0900

krymtkts/blog-fable Fable でブログを再構築している。

TODO の回収と細々とした使い勝手の改善など #61 #62 #64 をした。内部のリファクタリングなり実装忘れの機能追加をしてきて、かなり移行への気持ちも高まってきた(毎回言ってる)。

その中でも自分でいい感じにできたんじゃないかなという所は、 #63 で Intl.DateTimeFormat のごく小さな binding を書いてみたところ。

調べた感じ、昔の Fable.Import.Browser にはあったけど、分割されたあとなくなってるぽい。

Import of 'intl' package fails in production mode · Issue #1925 · fable-compiler/Fable fable-import/Browser/Fable.Import.Browser.fs at a24f2c51bcfc79737427613e5c4aa5e99e114d40 · fable-compiler/fable-import

分割先のモジュールを調べるにはこの Issue を見る → Track repo splits · Issue #80 · fable-compiler/fable-import。

これを参考に足りない部分を補う形で以下のように記述した。自分が使いたい formatToParts DataTimeFormatPart はなかったから自前で書いて、 DateTimeFormatOptions は違いなし。この Create の書き方は学びになった。 MDN を参考にしたら簡単だったのでふつーにいけた。 Intl.DateTimeFormat.prototype.formatToParts() - JavaScript | MDN

// NOTE: minimum implementation for Intl.DateTimeFormat.formatToParts.
[<RequireQualifiedAccess>]
module Intl =
    [<Global>]
    let DateTimeFormat: DateTimeFormat = jsNative

    [<AllowNullLiteral>]
    type DateTimeFormatOptions =
        abstract weekday: string with get, set
        abstract year: string with get, set
        abstract month: string with get, set
        abstract day: string with get, set
        abstract hour: string with get, set
        abstract minute: string with get, set
        abstract second: string with get, set
        abstract hourCycle: string with get, set
        abstract timeZone: string with get, set
        abstract timeZoneName: string with get, set

    [<AllowNullLiteral>]
    type DateTimeFormatPart =
        abstract ``type``: string with get, set
        abstract value: string with get, set

    [<AllowNullLiteral>]
    type DateTimeFormat =
        [<Emit "new Intl.$0($1, $2)">]
        abstract Create: lang: string -> options: DateTimeFormatOptions -> DateTimeFormat

        abstract formatToParts: date: System.DateTime -> DateTimeFormatPart array

コレを書いたことでちょっとは安心感持って使えるかな？という感じやが、そもそも書き直すことあんまなさそうなのと結局戻り値はサイズ固定配列なので、そこまだなんとかしたい感じ。

ただ小さい binding でも書いてみることで Fable binding への理解度上がった感ある。

あと完全に忘れてたのが、画像ファイルがあった場合に出力先へコピる機能。初めは、 favicon とか画像類はスクリプトを手でいじって好きにやる想定にしてたけど途中で変えたから、まるっと忘れてた。機能的にはそんなもんちゃうかな？結構機能は削りまくってるのでなんか忘れてそうではあるが。

あと気になるのはパフォ面。 Fable のビルドは遅いけどそれ以外は結構速いから期待できんじゃないかな。 Cryogen での SSG は記事が多いともっさりしてて 151 記事で lein run の終了まで 25 秒くらかかる。 8 記事しかない状態で 4 秒未満のとこしか見てないから、 Cryogen と同じ記事数でどうなるか...

Fable でブログを再構築する pt.14

Sun, 24 Sep 2023 09:00:00 +0900

krymtkts/blog-fable Fable でブログを再構築している。もういい加減ブログ移行作業着手したいけど、ちまちま直してたら修正スべき箇所見つかってきてちまちまちした更新を続けている。

前のやつ ↓。

何が駄目かって、 Async.AwaitEvent するところで非同期ブロックが入るのだけど、その後クライアントから切断を受信して loop 変数の値を変更・ループ ② を止めても、ループ ① は非同期ブロックされてて次の変更イベント発火まで生き続けるのよね。なので画面遷移やリロードのたびに変更イベントの待ちが溜まっていって、変更イベントで一気にドバっと流れるというのになってる。

どう解決するかわかりまして、 CancellationToken でもって破棄してやれば良いとのことだったのでそうした。 #54

Async and Task Programming - F# | Microsoft Learn

ようやっと F# で非同期計算する入り口に立った気。

他に細々した更新やバグ修正してたのだけど、手間がかかったのだと依存関係の更新をしてた。特に Marked と Highlight.js の更新はちょっと気が重かった。ずっと古い ver に依存しておったことで型定義は @types/highlightjs @types/marked に依存してたのだけど、それを取り除いて純正の型を使う切り替えが必要だった。 Marked も Highlight.js もえらい前から型提供してたみたい。コピペ元が古いから自分での確認を怠っており全く気づかなかったか。

個別の型定義を取り除いたあとは ts2fable で Fable binding を生成する。

npx ts2fable node_modules\highlight.js\types\index.d.ts src/bindings/HighlightJs.fs
npx ts2fable node_modules\marked\lib\marked.d.ts src/bindings/Marked.fs

ぐいっと一気に引き上げたので極力型を fable binding を再生成したかったが、結構負担大きかった。結局生成した binding を手で補正する必要があった。

Highlight.js に関しては再生成した型定義をエラーが出ない範囲で削った。自分が使う極小範囲に留めた binding を作ったわけだ。

Marked はちょっとそう簡単にはいかなかった。びっくりするくらい上手くいかない。 ts2fable って Omit とか型の交差を理解しなくて、そのまま F# のコードに出力される。

Combined and Omit<> types · Issue #474 · fable-compiler/ts2fable

あとは Record とかも理解しない。これらに対する対処を手でやりつつ、非公開な型を削るのしんどかった。ので、 Marked は元々使ってた @types/marked で生成した型から、不要な部分や削除された部分を最小限で削ったものにした。恐らく利用してない範囲に非互換な型定義があるんじゃないかと思うが、利用範囲だけは手直しして使えるようにした感じ。

Fable の binding を用意する方法、結局 ts2fable を使うよりも自分で更地から書いた方がいいのでは...という気配薄っすら感じる。が、まったく ts2fable 開発されてないわけじゃないし今のところコミュニティの方向はどこに向いてんだろ。追々調べておく必要がありそう。そうそう binding て書く機会もないしな。とはいえよ、 module で API には快適変更があるときに binding 再生成だけで住むのが理想よな。ちょっと遠そう。

他、 Marked で使ってた headerIds という Extension が v8.0.0 からなくなってた。 Using Advanced - Marked Documentation

Removed in v8.0.0 use marked-gfm-heading-id to add a string to prefix the id attribute when emitting headings (h1, h2, h3, etc).

けどこれは h* 要素に anchor をつけるように作ってたから元々いらなくて、なくてもいけたのでコレを機に消した。 Using Advanced - Marked Documentation

あとこれは現在進行系で解決できてない困ってること。 Bulma が document で書かれてるような部分的な利用ができなくなってるってのがわかった。非推奨となった @import を使ってたら起こらないけど @use だと起こる。

With node-sass | Bulma: Free, open source, and modern CSS framework based on Flexbox

SCSS ビルド時にこういうエラーが出る。

Error: The target selector was not found.
Use "@extend %overlay !optional" to avoid this error.

Webpack @extend !optional error · Issue #3391 · jgthms/bulma

同じようなことに困ってる人いる。単純に Bulma 側が SCSS 対応がちゃんとできてないってことなんやろな。 @import ならいけるからな。

Dart 製の sass モジュールを使ってるせいか未だ調べてないけど、解決する予定もなさそうなので一旦全部入りでやり過ごす。できれば利用してるスタイルだけにとどめて高速・軽量化したいのやけどなー。 Bulma 自体今年はメンテ止まってるし、最悪自分でなんとかする感じかな。

Fable でブログを再構築する pt.13

Sun, 17 Sep 2023 09:00:00 +0900

krymtkts/blog-fable Fable でブログを再構築している。

開発サーバが重いので、諸々調整をしている。

既に対応済みのものとしては、ビルドの軽量化。 #52 #53

毎回全部ビルドし直す必要はないので、 *.fs, *.md と *.scss どれが変更されたかを判別して、実行するビルドタスクを切り替えるような実装にした。

特に今後ブログのコードをいじることはあまりないだろうから、 Markdown を変更したときのビルド待ちは極力抑えたかった。その場合 dotnet fable でビルド済みの JavaScript があるからそれを実行する形を採用した。

FAKE には npm コマンドを実行するモジュールがある。

Npm (Fake)

これを利用して直接 node を呼び出すことはできないが、 package.json に書いておいて npm run すれば FAKE から呼び出せる。こんな感じ ↓ で build-md と build-css を用意して FAKE から呼び出すだけ。 (ちょっとタスク名は整理した方がいいか)

  "scripts": {
    "postinstall": "dotnet tool restore",
    "build-css": "sass --style=compressed --no-source-map ./sass/style.scss ./docs/blog-fable/css/style.css",
    "serve": "dotnet fsi ./dev-server.fsx",
    "build-fable": "dotnet fable src --runScript",
    "build": "npm run build-css && npm run build-fable",
    "dev": "npm run build dev && npm run serve",
    "build-md": "node ./src/App.fs.js"
  },

// 実行は非常に簡素なインタフェース
Npm.run "build-md" id

Npm(FAKE) があれば、 dotnet fable に関しても npm run 経由で呼べばよいのだけど、 1 つ難点がありそのまま DotNet モジュールを利用している。それは実行結果を得られないところだ。コマンドの成否を以て何かしている訳では無いが、わざわざ情報を劣化させる理由もないのでそのままステイだ。

毎回 dotnet fable することがなくなったから、 Markdown の編集だけならかなり快適になったはず。

次に、適切に処理していなかった WebSocket 接続の手当をしている話。 #53

これちょっと難しくて、 WebSocket が難しいのでなくて Suave でクライアントからメッセージを受けつつサーバ起点で何かするのが厄介で、手こずってる。

ひとまずやりたかった「Suave でクライアントからメッセージを受けつつサーバ起点で何かする」に関しては 2 つのループで実現できるのがわかったのでそれを使った。これを参照した。 → How to implement server-push over websocket in suave? · Issue #307 · SuaveIO/suave

2 つのループを設けることで、クライアントが切断したときにサーバ側の WebSocket ハンドラを終了するのと、サーバ側の変更イベントでクライアントにプッシュする、が同時に実現できる。ただまだ駄目なところがあって完成ではない。現時点の Suave の WebSocket のハンドラは以下の通り。

    let socketHandler (ws: WebSocket) _ =
        let mutable loop = true

        Async.Start(
            async {
                while loop do // ループ①
                    do! refreshEvent.Publish |> Async.AwaitEvent

                    printfn "fire event."

                    let seg = ASCII.bytes "refreshed" |> ByteSegment
                    do! ws.send Text seg true |> Async.Ignore
            }
        )

        socket {
            while loop do // ループ②
                let! msg = ws.read ()

                match msg with
                | (Close, _, _) ->
                    let emptyResponse = [||] |> ByteSegment
                    do! ws.send Close emptyResponse true
                    printfn "WebSocket connection closed gracefully."
                    loop <- false
                | _ -> ()
        }

何が駄目かって、 Async.AwaitEvent するところで非同期ブロックが入るのだけど、その後クライアントから切断を受信して loop 変数の値を変更・ループ ② を止めても、ループ ① は非同期ブロックされてて次の変更イベント発火まで生き続けるのよね。なので画面遷移やリロードのたびに変更イベントの待ちが溜まっていって、変更イベントで一気にドバっと流れるというのになってる。

因みに Async.AwaitEvent のあとで if なり仕込んで抜けられるかなと試したけど、同じ周回だと loop 変数への変更が伝播してなくて止まらなかった。 ref をあえて使ったらまた違うのかな。

F# の async/await ちゃんと触ってないから手こずってるけど、これ上手く手なづけたら pocof へも良い影響出せそうなので、これを気にちゃんとやってこう。

Fable でブログを再構築する pt.12

Sun, 10 Sep 2023 09:00:00 +0900

krymtkts/blog-fable Fable でブログを再構築している。

色調整して Accessibility 上げたかったけど Solarized Dark を使おうとしたらどうにもならんので諦めた。

Elements must meet minimum color contrast ratio thresholds | Axe Rules | Deque University | Deque Systems

ここで Foreground と Background を色比較してコントラスト比を見ることができる。 AAA に合格する比率まで色を明るくしたらもう印象が違い過ぎるから、やめた。

コードブロックやリンクがあると、それだけで Accessibility のスコアが下がるのでどうにもならん。

あと以下にも抵触してるみたい。

Links must be distinguishable without relying on color | Axe Rules | Deque University | Deque Systems

今はリンクと本文の違いが色しかないから、これに下線を足したりすればましになる気配はある。

Accessibility て難しいなーと改めて思う。

他には、本格的な乗り換えに備えて以下を行った。

公開日や更新日の表示忘れ対応とドキュメント更新 #48
サンプルの更新 49

初めから乗り換えを目的にやってるけど、いざ手をつける段階になったらこれまた色々気になってくるので、なるべく処理してからやろうとしてる。やれ dev server が反応しなくなる時があるとか、 TODO は乗り換えまでに解消しておきたいなとか。

乗り換え時には krymtkts/blog-fable と krymtkts/krymtkts.github.io の歴史を合流するつもりやから、先にできるだけ課題を潰しておきたいというのがある。頻繁に両方メンテとかはやりたくなくて、なんか改善や変えたいことがあったら krymtkts/blog-fable の方で試してからブログの方に投入するみたいなフローでやりたい。

歴史を合流する方法以外にコードを統合するマトモな術は、 Fable Module とか dotnet のテンプレ化あたり。けどその辺に手を出すと注力するところが主目的から外れるので、やらないつもり。

npm package を含んだ Fable Module の作成は色々気を使うことがあり、ここに力割くのもどうかなって。 Fable · Author a Fable library

dotnet のテンプレ化に関しても、仮に誰か奇特な人が Fable でブログを作りたくて repo に辿り着いたとき便利だなとかその程度かな？ template repository になってても同じ感じか。

私的ブログの新しいコードを書いてるだけなので、機能を公開することに重きを置かず、一番楽にコードを統合できる歴史を合流する術で進めるという感じ。

まだやっときたいこと諸々あれど、ひとまず krymtkts/blog-fable を作り始めた当初の目標である年内乗り換えは現実味を帯びてきた気がする。 2023-10 末で期間としては半年になるから、その辺から年末の間でいい感じに移行したいなー。

Fable でブログを再構築する pt.11

Sun, 03 Sep 2023 09:00:00 +0900

krymtkts/blog-fable Fable でブログを再構築している。

ここ 1 ヶ月ほどでやりたかったことを 3 つ進められた。エライ(低ハードル)。

ややこしくなってた入出力パスの構築 #38 #39
PageSpeed Insights のスコア改善 #42
カラースキームの導入 #43

以下のとおり結果的に結構良いスコア叩き出すようになった。

platform	Performance	Accessibility	Best Practices	SEO
Mobile	99	93	100	100
Desktop	100	93	100	100

Solarized が好きなのだけど今回は Dark にしてみた。エディタやターミナルなんでも Solarized Dark にして 10 年近いのでついにブログも Dark に。まだいい感じに色調整できてないから Accessibility をちょい下げてしまってるが、後ほど調整する。

今回やった中には、初体験でちょっと調べる必要があるものもあった。これらはメモがてら以下に記しておく。全然 F# ネタではないけど。

いずれも上手く拡張できる様になっており楽だった。感心するわ。

Marked の Renderer を拡張する

The Renderer - Marked Documentation に示されるように Renderer オブジェクトにわたすオプションで拡張できる。

listitem(string text, boolean task, boolean checked) と checkbox(boolean checked) の組み合わせにちょっと癖があった。どっちも定義しているとどっちも呼ばれてチェックボックスが 2 個になってしまう。 checkbox(boolean checked) 側を無効化するような書き方をして checkbox 要素を label 要素で包み込んだ。シグネチャが checkbox(boolean checked) なもんで、こっち側は label 要素書こうにもテキスト不明でできないねんよな。ブログの場合 checkbox 要素が単独で使用されることまずないからこうしたけど、なんかもっと良い方法がないのかは気になるところ。

            let listitem =
                fun text task check ->
                    let checkState =
                        match check with
                        | true -> "checked"
                        | false -> ""

                    // NOTE: input を label で包んで関連を持たせる
                    match task with
                    | true ->
                        $"""<li><label class="checkbox"><input type="checkbox" class="checkbox" disabled {checkState} />{text}</label></li>"""
                    | false -> $"""<li>{text}</li>"""

            let checkbox =
                fun _ ->
                    // NOTE: checkbox は list と一緒に使われる前提と考えて何も返さない
                    ""

            let mops =
                !!{| heading = heading
                     link = link
                     listitem = listitem
                     checkbox = checkbox |}


            jsOptions<Marked.MarkedExtension> (fun o ->
                o.renderer <- Some <| U2.Case2 mops
                o.gfm <- Some true
                o.headerIds <- Some true)

Bulma の自前 style をビルドする

With node-sass | Bulma: Free, open source, and modern CSS framework based on Flexbox

概ねこの手順の通りにやればいい。

ただし以下の非推奨があって、それらは自前で最新のものに置き換える必要があった。

node-sass は非推奨、 Dart 製の sass に変える
Sass では @import は非推奨、 @use に書き換える
- 余談だが commit message には backquote で囲わずにこれらのキーワードを書いてたら GitHub 上でホバーしたときにその ID の方々がポップアップされて笑ってしまった

これらは Sass の最新仕様に追随するよう自前でこしらえた。

`node-sass` を `sass` に

変えるのは大したことないけど、 cli インタフェースのオプションも変わってるので、そこはケアする必要がある。ついでに出力される CSS を圧縮するオプション --style=compressed もつける。今回のケースでは空白が消えたことで 3KB くらい節約できた。

   "scripts": {
     "postinstall": "dotnet tool restore",
-    "css-build": "node-sass --omit-source-map-url ./sass/style.scss ./docs/blog-fable/css/style.css",
+    "css-build": "sass --style=compressed --no-source-map ./sass/style.scss ./docs/blog-fable/css/style.css",
     "serve": "dotnet fsi ./dev-server.fsx",
     "build": "dotnet fable src --runScript",
     "dev": "npm run build dev && npm run serve"

`@import` を `@use` に

@use を使う場合は、変数のデフォルト値を書き換えるには先述の手順のとおりにはできない。 Default Values | Sass: Variables の示す通り @use <url> with (<variable>: <value>, <variable>: <value>) を使う。以下書き換えイメージ。

 @charset "utf-8";

 // NOTE: based on https://ethanschoonover.com/solarized/
 $base03 :#002b36;
 $base02 :#073642;
 $base01 :#586e75;
 $base00 :#657b83;
 $base0 :#839496;
 $base1 :#93a1a1;
 $base2 :#eee8d5;
 $base3 :#fdf6e3;
 $yellow :#b58900;
 $orange :#cb4b16;
 $red :#dc322f;
 $magenta :#d33682;
 $violet :#6c71c4;
 $blue :#268bd2;
 $cyan :#2aa198;
 $green :#859900;

-@import "../node_modules/bulma/bulma.sass";
-// NOTE: Solarized Dark.
-$black: $base3;
-$black-bis: $base2;
-$black-ter: $base2;
-$grey-darker: $base1;
-$grey-dark: $base1;
-$grey: $base0;
-$grey-light: $base00;
-$grey-lighter: $base01;
-$grey-lightest: $base01;
-$white-ter: $base02;
-$white-bis: $base02;
-$white: $base03;
-// NOTE: set alternative colors.
-$turquoise: $cyan;
-$purple: $violet;
+@use "../node_modules/bulma/bulma.sass" with (
+    // NOTE: Solarized Dark.
+    $black: $base3,
+    $black-bis: $base2,
+    $black-ter: $base2,
+    $grey-darker: $base1,
+    $grey-dark: $base1,
+    $grey: $base0,
+    $grey-light: $base00,
+    $grey-lighter: $base01,
+    $grey-lightest: $base01,
+    $white-ter: $base02,
+    $white-bis: $base02,
+    $white: $base03,
+    // NOTE: set alternative colors.
+    $turquoise: $cyan,
+    $purple: $violet,
+);

もうちょっと PageSpeed Insights のスコア上げられる雰囲気はあるので、そこだけ粘ってみる。結構 Fable 製ブログも出来上がってきたし、いよいよ自ブログ移行に向けた試行をはじめられそう。

GitHub streak a year

Sun, 27 Aug 2023 09:00:00 +0900

5 月の日記で触れた GitHub Streak が 2023-08-21 ようやく 365 日に到達した。やったね。次は 730 日を目指すのだけど、マイルストンとしてまずキリよい 400 を置き、次に 500, 600 と目指していく。

Streak にこだわりだしたのは、生涯プログラマであろうとしたらやっぱり日々の鍛錬というか毎日コード書いて感覚を保ちたいよな、というのが根底にある。

とはいえコードを書いてない日、例えばにこの日記のような文章を書くだけのコミットもあるし、 GitHub Streak って Issue や review でも数えられるので厳密ではないのだけど。でもそのくらいの緩さじゃないと初めから続けられなかっただろうし、ちょうど良い落とし所であろう。

Streak が途絶えたとて何ら困ることないのだけど、途絶えると取り戻すのに同等の時間がかかるものは、続ける方向に適度にプレッシャーが発生して良い。特にゲーマー脳を少なからず持っていれば、トロコン感覚を持って臨める。積み重ねてきたものって割と簡単にやめる事ができるので、このような強制力を持って習慣を維持するのは良い案だと感じている。

しかしながら Streak を始めてから今に至るまで、仕事や私生活において日々の生活リズムが狂うようなインパクトの大きい出来事が一度も起こってない。つまるところそういったインパクトがあったときにも続けられるというサンプルが無いわけだから、もしものときに上手く続けられるかは定かではない。今の自分ならそういう状況でも淡々とこなせそうな気配は薄っすら感じるが、これも Streak を続けてきたことで得た感触だろう。ゆーても油断は禁物やけど。

次の目標 400 はもうすぐなので、堅実に次につなげていこう。

F# でコマンドレットを書いてる pt.21

Sun, 20 Aug 2023 09:00:00 +0900

pocof の開発をした。 pocof のコンパイルを .NET 7 にしたこともあってなんかテンション的に触りやすくなった(逆に Fable でブログ書き直す方を放置)。 PSResourceGet への乗り換えもできたのだけど、その時気になることがあった。

いつかはやらないといけないと考えていたが、配布 DLL が多すぎる。 PowerShell Gallery | pocof 0.5.0-alpha の FileList 見たらわかるけどめちゃくちゃ DLL がある。 pocof で使ってない DLL もいっぱい含まれている。

これは...解決したい。

.NET では実行可能ファイルであれば自己完結型と言われる単一バイナリの生成ができるのだけど、 DLL ではそういうのはない様子。 PowerShell モジュールの場合どういう手段が取れるのかちゃんと理解してなかったが、こういうこと ↓ で大量の DLL 全部ぶちまけられてた。

Microsoft.PowerShell.SDK を参照してる
F# の各言語に localize されたリソースの DLL が出力される

これらに対処してバンドルに含まれる DLL を減らしてみた。 #57

Microsoft.PowerShell.SDK

pocof のような PowerShell モジュールは PowerShell のランタイム内で動く。また pocof では PowerShell の機能をモリモリ使って出力結果を生成するようなことがない。このようなケースでは、 PowerShell/PowerShellStandard のリファレンスライブラリだけでいいみたい。

pocof で Microsoft.PowerShell.SDK を PowerShellStandard.Library に入れ替えて全テスト実行してみた。テストデータ作成のために PSObject を作成しているところだけ影響があった。つまり pocof 本体に影響はないので、テストプロジェクトで Microsoft.PowerShell.SDK を参照してれば OK ということ。

一番初めに pocof を書き始めたころの記事では PowerShellStandard.Library を参照してたのだけどなんか途中で変えてみたい。初回リリースでは既に Microsoft.PowerShell.SDK に変わってたのだけど、この頃は FsUnit 使ったテストなかった気がするし、違う理由かなんか分からず変えてそう。コミットログ追えばわかるかな。

F# の localize されたリソースの DLLs

pocof では localize されたリソースの DLL 要らない。なんか F# のリソースが使われるとしても英語でいいし。これらの各言語リソースの DLL を取り除くには SatelliteResourceLanguages という MSBuild プロパティを指定すれば良いようだ。言語を指定せずに空(null)だと全言語対象のママになるので、英語を指定しないといけない。

終わり

MUSBuild の世界は難しいなー。でもこれでかなり DDL が減った。ただ最後に System.Management.Automation.dll が残ってる。

これって PowerShell 環境ならかならずあるのでは...という気がするのだけど。 open してる名前空間の関係で消えないのかな？もうちょい検証してみないとわからん。

Publish-PSResource を試す

Sun, 13 Aug 2023 09:00:00 +0900

以前から気になってた PSResourceGet の Publish-PSResource を試す機会があったので試した。試したと書いてるけど、自分の利用ケースで問題なく使えるか見ただけ。

krymtkts/PSJobCanAttendance を修正する機会があったので、ついでに Publish-PSResource へ切り替えた。上手くいってた。 #9

(追記 2023-08-15) 試したバージョンは以下の通り。

PS> Get-Module *PSResourceGet; $PSVersionTable | Format-Table

ModuleType Version    PreRelease Name                                ExportedCommands
---------- -------    ---------- ----                                ----------------
Binary     0.5.23     beta23     Microsoft.PowerShell.PSResourceGet  {Find-PSResource, Get-InstalledPSResource, Get-PS…


Name                           Value
----                           -----
PSVersion                      7.3.6
PSEdition                      Core
GitCommitId                    7.3.6
OS                             Microsoft Windows 10.0.22621
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Publish-PSResource (Microsoft.PowerShell.PSResourceGet) - PowerShell | Microsoft Learn を参照して、 Path, ApiKey, Verbose, WhatIf を使った。 Verbose, WhatIf は確認用なのでなくても良い。 Repository も省略できて、省略した場合は優先度が高い repository に公開される。自分の場合は PowerShell Gallery 。

PSJobCanAttendance の場合は公開するファイルが少ないからか、実行したら一瞬で公開された。 PSResourceGet になったら公開まで高速化されるんや。

これでいけそうな感触を得たので、 pocof でも試す。 krymtkts/pocof#54

AllowPrerelease とか RequiredVersion とかのオプションで指定していたところがなくなって、 *.psd1 から読み取るように変わってるぽい。ただ ModuleName とかの指定どうなるんやと思ったけど、ディレクトリ名ぽいな。

ということなので、従来の pocof の公開方法である (Get-Module).Path を渡す方法は無理だってこと。これだと ddl のパスが得られるのだけどこれは弾かれたし、 *.psd1 のパスを渡す方法だと親ディレクトリがバージョン番号になってモジュール名にならない。 API Key にモジュール名の制限をかけてたから権限で弾かれて変な数字の名前をしたモジュールの公開を免れた。そこんところを公開用のディレクトリにモジュール類をコピーして、その中の pocof.psd1 を Publish-PSResource するようにしてみた。

+---.github
+---coverage
+---docs
+---publish
|   \---pocof <- ここへこぴる
|       \---pocof.psd1
+---src
|   \---pocof
        \---bin
            \---Release
                \---*
                    \---pocof.psd1 <- コピー元
\---tests

が、以下のようなエラーでまだ上手くいってない。

Error: 2023-08-13 18:59:25:
At C:\Users\takatoshi\dev\github.com\krymtkts\pocof\psakefile.ps1:108 char:5 +     Publish-PSResource @Params +     ~~~~~~~~~~~~~~~~~~~~~~~~~~ [<<==>>] Exception: Repository 'PSGallery': Response status code does not indicate success: 403 (The specified API key is invalid, has expired, or does not have permission to access the specified package.).

公開対象のディレクトリ名がモジュール名になるって判断が間違ってるのか...いけそうな感触を持ったけどあかんのかな、挑戦は続く。

追記 2023-08-14

その後、 PowerShell Gallery の API Key を作り直したり、 pocof のみ更新可能に絞っていた package を * にして全権与えてみたりしたがダメだった。 DDL の Module に対応してないような旨はどこにもなかった気がするけど。

Issue で気になるものとしては、 prerelease の依存関係を持つケースに対応してないというのがある。 PSResourceGet module prerelease version scheme issues · Issue #1251 · PowerShell/PSResourceGet けど pocof 自身はそういう依存関係を持ってないので該当しないはず。 ~~他の可能性があるとしたら、 prerelease のみのバージョン履歴を持つ場合に未知のバグがあるとかかな。~~ 普通に自家製バグ、見当外れ。

いかんせん条件が定かでないので、一通り他の PSResourceGet の Cmdlet も試してみるとかが妥当だろうけど、めんどくせえええ... ~~でも解決しないと pocof のプルリク永久に生き続けるし、事象を調べるか誰かが解決するのを待つか、面倒な選択しかない。~~ 自家製バグが原因なので時間かけてでも調査して当たり前。

~~なんかいい感じにサクッとできるつもりだったがそうならなかったのは、我ながら「持ってる」な。しらんけど。~~ 単に休みボケのケアレスミス発動しただけ。

追記 2023-08-16

昨日この件を調べるためのテストモジュールを書いた。 F# で空のモジュールをサクッと書いて PSResourceGet と PowerShellGet の両方で公開できるようなのを。でも PowerShellGet でも同じような権限のエラーになった。

それもそのはず普通に自分が書いた psake タスクのバグだったわ...恥ずかし。 API Key を string で取り出さなあかんとこ PSCredential がそのまま渡ってた...(SecureString じゃないんやというのは置いといて)

pocof/psakefile.ps1 at 83e3bf2691a8485a6b2595934845204d21b885a2 · krymtkts/pocof

間違いそのママの差分はこんな感じ。

     $Params = @{
-        Name = $ModuleName
-        NugetAPIKey = (Get-Credential API-key -Message 'Enter your API key as the password').GetNetworkCredential().Password
+        Path = $p.FullName
+        Repository = 'PSGallery'
+        ApiKey = (Get-Credential API-key -Message 'Enter your API key as the password') # ここが終わってる
         WhatIf = $DryRun
         Verbose = $true
-        AllowPrerelease = $true
-        RequiredVersion = $RequiredVersion
     }
-    Publish-Module @Params
+    Publish-PSResource @Params

正しいのはこう。

-        ApiKey = (Get-Credential API-key -Message 'Enter your API key as the password')
+        ApiKey = (Get-Credential API-key -Message 'Enter your API key as the password').GetNetworkCredential().Password

2 日浪費したけど解決してよかったわ。

キースイッチを分解して掃除する

Sun, 06 Aug 2023 09:00:00 +0900

ビルドログを書いた記憶ないけど、今は Keebio の Iris Rev. 3 を 3 年くらい使ってる。

キースイッチは Zealios Zilent 78g。買った当時はそこそこ高級品の部類に入ってた記憶で、そのスムースさとタクタイル感の強いタッチがとても気に入っている。

だけど 3 年もすると結構チャタリングを起こすようになってきてる。どうも利用環境のホコリがスイッチに混入してるのと、 Zilent のキースイッチ内で削りカスみたいなのが発生するぽくて、そいつが接点周りで悪さしてることに拠るみたい。

ホコリというのは一般的な毛ぼこりで、これが打鍵のときに軸の隙間から入り込んだり、 LED 用に開いている穴から侵入してるみたい。キースイッチを分解するとスプリングにホコリが付着していることがママある。

Zilent は軸の側面にスムースさと静音を目的としたシリコン的な緩衝材が埋め込まれてるのだけど、こいつがよく使うキーだとはみ出した部分が徐々に擦れて削りカスになる。あとこれは Zilent 以外でも起こると思うけど、打鍵が垂直でないことでボトムハウジングと軸が擦れることでプラスチックの粉？が発生する。こういった削りカスが接点の隙間に挟まって感度が悪くなってる様子。

これらはいずれも実際に自機を分解して目視確認したものだけど、現象が自分の利用環境によるのか一般的なものかはわからない。

こういう具合でなのでよくチャタリングしたキーを自分流で分解して掃除しているのだけど、なんか日記にでも残そうかなと思った次第だ。

分解掃除の道具は以下の通り。

Filco のキープラー
- キーキャップを取るのに使う
ダブルクリップの針金部分で自作したキースイッチオープナー
- ダブルクリップの針金部分を適度に曲げると MX Compatible キースイッチに適したオープナーができる。結構使いにくい
尼で買った先端の精度が甘い精密ピンセット
- 分解時の部品取扱とか、接点の掃除に使う
SuperMax っていうインド製の両刃カミソリの替刃についてた謎の樹脂製ヒゲブラシ
- これで顔を洗う気に離れなかったが、キーボードのような細かい隙間があるものの簡単な掃除に便利

自作キーオープナーは何処かで誰かのアイデアを見かけて試したら上手くいったので長らく使っている。キーキャップを外し、キースイッチのツメの部分の穴に合わせて左右にキーオープナーを差し込み、適度につまんで適度にひねりを入れるとトップハウジングがパカっと外せる。今日日みんなキースイッチは hot swappable だろうからこんな苦しんでキースイッチを分解掃除することないんじゃなかろうか。このように結構面倒なので、最適なキーオープナーあれば買いたい気持ち。

また、わたしは RSA プロファイルのキーキャップを好んで使っているので、キーオープナーでトップハウジングを外そうとしたら左右のキーキャップが干渉する。なので分解するキースイッチの左右のキーキャップも外しておく必要がある。

なんとかしてキースイッチを分解したら、ピンセットでトップハウジング、軸、スプリングを取り出して、先述のヒゲブラシでボトム含めささっと掃除する。スプリングやボトムのホコリはこれでほぼ取れる。

軸が擦れてできるホコリはピンセットで丁寧に取り除くのが良い(めんどい)。特に毛羽立って取れかかってるシリコン的緩衝材などはブラシで取れない。また接点部分も同様でにピンセットで丁寧に取り除く。取り除くと言ってもピンセットの先端で何回か接点部分を擦ってやる感じ。

この作業をスイッチの数だけ繰り返す。気が狂いそう。しかしこれで大体のスイッチは元通りの挙動に直せる。時が経てばまた再発するけど。

注意点すべきは、接点部分の掃除とトップをはめ込む際。あまり無理にピンセットでガシガシやると板バネ部分が曲がって死ぬ。特にトップをはめ込む向きを間違うと板バネが大変なことになる。わたしの 1 キーはそれでほぼ死んでる。キーマップ的に 1 の代替キーがあってそっちをメインで使ってるからそれほど困らないけど、普通は壊さない方がいい。板バネが死んだキーははんだを外してキースイッチ自体取り替えるしかない。

この様な作業には集中力を要するし、キースイッチ 1 つ調整するのに数分かかる。ド近眼の不惑ともなると老眼で細かいものも見にくいので、多少チャタっても打鍵角度や押し込む量を調整してなるべく作業しなくていいように誤魔化してしまうのが現状。

ぐだぐだ文句を書き連ねたけど、調整後のスイッチは概ね素晴らしいタイピング体験を提供してくれるから満足。単にだるくて何度もやりたくないのだ。つい先日左手側を 7 キーほど掃除した(最高)けど、右手側もまたやらないといけなくてほんとだるい。

もっと簡単にキースイッチのメンテナンスをできるようにキーボード自体や整備環境をアップグレードする方がいいかもと感じる。けど、次のキーボード何がいいかな～という最大の選択をクリアできないからなんとも進まない。やるならワイヤレスにしたいとか、 Iris よりキー少なくていいなとか、 lube したらホコリカバーできたりするかな？とか。そういった試行錯誤を色々考えるだけでも時間かかってるからいつかは着手するやろうけど。

Fable でブログを再構築する pt.10

Sun, 30 Jul 2023 09:00:00 +0900

krymtkts/blog-fable Fable でブログを再構築している。

最近日記には書いてなかったが諸々の Issue を解決してた。

#24 #27 #32 #34 RSS の実装。
#31 出力パス構築を整理するために、手始めとしてエントリポイントの設定を整理。
#37 生 JS の排除。
#25 #28 あと雑多な更新。

RSS はやっぱわたしがほぼ素人だったのもあってわからないことが多かった。はじめは普段遣いしている feedly で購読してみて目視で変なところを直した。最終的には Feed Validator Results: https://krymtkts.github.io/blog-fable/feed.xml でエラーを解消する形にした。こんな便利なものがあるとは。とても役に立った。

RSS 周りの実装で改めて Fable が割る言い訳じゃないけど Fable のツラみを感じた。それは JavaScript の API がモロに出てくるところだ。今回は feed の pubDate の表記を RFC 822 date format にする必要があって、 Intl.DateTimeFormat を使った。こういうとき素直に .NET が使えるととても楽やのに...と思わざるを得ない。

いったんこういう ↓ 激薄 binding を書いて、 obj を引き回すことで無理くり使っている。

module Intl =
    [<Emit "new Intl.DateTimeFormat([$0], $1)">]
    let DateTimeFormat lang options = jsNative

module DateTime =
    open System

    let options: obj =
        !!{| weekday = "short"
             year = "numeric"
             month = "short"
             day = "2-digit"
             hour = "numeric"
             minute = "numeric"
             second = "numeric"
             hourCycle = "h23"
             timeZone = "Asia/Tokyo" // TODO: parametarize it.
             timeZoneName = "short" |}

    // TODO: write binding.
    let formatter: obj = Intl.DateTimeFormat "en-US" options
    let zonePattern = new Regex(@"GMT([+-])(\d+)")

    let toRFC822DateTime (d: DateTime) =
        let parts: obj [] = formatter?formatToParts (d)
        let p: string [] = parts |> Array.map (fun x -> x?value)
        let d = $"{p.[0]}{p.[1]}{p.[4]} {p.[2]} {p.[6]}"
        let t = (p.[8..12] |> String.concat "")

        let z =
            match p.[14] with
            | "UTC" -> "+0000"
            | z ->
                let item = zonePattern.Matches(z)
                let group = item.Item 0
                let op = (group.Groups.Item 1).Value
                let offset = int (group.Groups.Item 2).Value

                $"{op}%02d{offset}00"

        $"{d} {t} {z}"

日付操作のための module 入れればいいってだけでもあるけど、このためだけに module いれるのもなあ...となるべく自力で解決する方向。

ただ TODO 残してるのもあるけど、それより Dynamic typing で危なっかしいしちゃんと binding を書きたいところ。あと添字でアクセスしまくるしか方法思いつかんかったけどもっとマシなのないのかな...

#37 で開発モードでの live reloading するために使ってた生 JavaScript を Fable が出力したやつを使うように変えた。

普通であれば webpack とかで bundling するんやろけど、開発モード以外で JavaScript を使う予定がないので、出力された js ファイルを出力先ディレクトリにコピることで実現している。他に方法あるかわからん。ただブラウザでもそのまま使える js ファイルを出力する豆知識は得られた。

open Browser.Dom
open Browser.WebSocket

let private init _ =
    let ws = WebSocket.Create $"ws://{window.location.host}/websocket"
    ws.onmessage <- fun _ -> window.location.reload ()

window.addEventListener ("load", init)

これ ↑ がこう ↓ なる。 private をつけておいたら export されない。

function init(_arg) {
  const ws = new WebSocket(`ws://${window.location.host}/websocket`);
  ws.onmessage = (_arg_1) => {
    window.location.reload();
  };
}

window.addEventListener("load", (arg00$0040) => {
  init(arg00$0040);
});

#31 でエントリポイントの render 関数で諸々の設定をするように変えた。元々好きに関数を組み合わせて出力を作れたらいいかなと思ってたけど、それぞれの関数で整合性を取らないといけない点があってめんどい、というのが設定を導入した理由。

ひとまずこれで外向きのインタフェースは固定して、あとは内側の重複したパス構築部分をまとめていけたら、楽に整合性取れるんじゃないかな。

8 月くらいにできるかなーって思ってたけど、使わない CSS を読んでるやつとかも使ってるやつだけビルドして出せるようにしたいとか、諸々考え出すと実際のところ無理かな。気長にいこ。

PSResourceGet メモ

Sun, 23 Jul 2023 09:00:00 +0900

PSResourceGet を使い始めてまだちょっとだが、明らかに変わったことがある。これ PowerShellGet v2 より圧倒的に速いな。 PowerShellGet v3 時代からインストールするようにはしてたけど日々使ってなかったから気づいてなかった。

ただ開発環境をプチ移行するにも追記したように、 v3 には Get-PSResource みたいなややこしい Cmdlet もいる。 PSResourceGet を入れてるなら v3 の方は消しとくのが無難。

なのでこの度普段定期的にしかやってなかった古いモジュールの整理をした。既に誰でもやってそうだが習慣的に行えるよう関数にした。なおこの関数、モジュール依存関係を壊すようなのがあればエラーになるだろう。それを回避したければ -SkipDependencyCheck 足してもいいかもだが、とりあえず壊れたときめんどいのでやめた(壊れたモジュール使うまで気づけなさそう)。

function Uninstall-OutdatedModules {
    [CmdletBinding(SupportsShouldProcess)]
    param()
    Get-InstalledPSResource -Scope AllUsers | Group-Object -Property Name | Where-Object -Property Count -GT 1 | ForEach-Object {
        $_.Group | Sort-Object -Property Version -Descending | Select-Object -Skip 1
    } | Uninstall-PSResource -Scope AllUsers
}

上記の関数の通り、 Get-InstalledPSResource は複数 ver 入ってるとそのままあるだけ返してくれる。 v2 時代は Get-Module しないとダメだったのは以前書いた PowerShell モジュールの大掃除日記でのこと。時代は変わったな。

また、こういう処理も v2 であれば Get-InstalledModule は結構遅かったのが、 PSResourceGet になってとても速くなった。

AllUsers の scope に 30 位のモジュールがある。実行するのは自環境、 Razer Blade Stealth 13 Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz 2.00 GHz, Windows 11 22H2, PowerShell 7.3.6 にて。初回の実行で v2 だと 1 秒くらい、 PSResourceGet だと 50ms 未満。ショボマシンでこの差は結構でかいな。何らかのローカルなデータストアにキャッシュでもしてんのかな PSResourceGet は。

MS の PowerShell Team の blog 読んだらここに書いたようなこと書いてたかもだが、改めて自分で試してみて新しいツールの利用が身体化されてる感じはするな。

あと pocof で気になってる Publish-PSResource のテストモジュール使った動作確認は未だやってない(めんどくて)。のでそろそろ手を付けないといけないけど、 web のどっかで情報出てきたらうれしいのだけど。

そういや勤怠スクリプト類などの他の PowerShell モジュールのこと忘れてた。今年の秋には PSResourceGet 対応しとかないとあかんか。

F# でコマンドレットを書いてる pt.20

Sun, 16 Jul 2023 09:00:00 +0900

久しぶりに pocof の開発をした。ゆーても .NET 6 → .NET 7 と、 PowerShellGet → PSResourceGet だけ。

.NET 6 → .NET 7 #53

ASP.NET じゃないけどこれがやることわかりやすくまとまってたので参考にした。 Migrate from ASP.NET Core 6.0 to 7.0 | Microsoft Learn

SDK を global.json で固定するようにした。

dotnet new globaljson --sdk-version 7.0.306 --roll-forward latestFeature

その後 *.fsproj の TargetFramework を net6.0 → net7.0 にする。 global.json の作成に先んじて TargetFramework を変更してビルドするとうまくいかなかったが、変えるとすんなりいった。キャッシュの影響？

NuGet Gallery | Microsoft.PowerShell.SDK 7.3.6 を見て .NET 7 と互換性がある Microsoft.PowerShell.SDK に変える。 7.2.4 → 7.3.6 にした。

これでビルドが通るようになる。

ビルド後に Regex 周りでエラーが出るようになった。 Regex.IsMatchメソッドで型推論できなくなった箇所があったので、型注釈して通るようにする。 IsMatch(ReadOnlySpan<Char>) が .NET 7 から増えたっぽいのでこの影響かなあ。 Regex.IsMatch Method (System.Text.RegularExpressions) | Microsoft Learn

また例外の文面も変わったらしくて、 1 つのテストケースで期待値を新しいものに合わせた。

GitHub Actions の job で actions/setup-dotnet@v3 に指定してるバージョンも 6.0.x → 7.0.x に変える。

この際 act 使った GitHub Actions の workflow テスト中に Docker が死んでしまった。最近 disk 容量少なくなってて、 Docker image が pull されたタイミングで枯渇したの原因(一時的に残 100KB くらいになってた。やば)。

解消するために以下を参考にしたが、 dockerd の再起動だけでは解決しなかった。 dockerfile - Docker error with read-only file system unknown - Stack Overflow

結果的に空き容量確保後に PC 再起動したら直った。

これにて .NET 7 化は完了。

PowerShellGet → PSResourceGet #54

変えたのは Publish-Module → Publish-PSResource だけ。前回の日記にも追記したが、 Get-Module は Microsoft.PowerShell.Core の持ち物だったので変える必要なかった。

WhatIf までの確認に留めている。というのも、結構パラメータが変わっておりホンマにうまく動くんかこれ...というのがあるため。 PSResourceGet の Issues 見て Publish-PSResource の状況をつかもうとしてるがまだまだあんまわからない。それに Publish-PSResource の前例を検索してもほぼない。

既存モジュールでいきなりやるのはちょい不安。やるならまずテスト用の module 作ってそれで試すが吉とみた。が、作るのめんどくせええええ、というのは否めない。

おわり

昔の日記で書いてた platyPS の prerelease 使うとエラーになる件忘れていてまた引っかかったが、久しぶりの pocof 開発なんとかできてよかった。

開発環境をプチ移行する

Sun, 09 Jul 2023 09:00:00 +0900

旧聞だが、 PowerShellGet が PSResourceGet に改名した。 2023 秋の PowerShell 7.4 リリース前には GA するらしいのでそれに移行することとした。

PSResourceGet Preview is Now Available - PowerShell Team

ついでに VS Code から VS Code Insiders にも移行したのでメモがてら残す。

VS Code Insiders

VS Code Insiders にする理由はまだ順番待ちの GitHub Copilot Chat が落ちてきたら即使えるようにするためだ。もうかなり待っていても来ないが、最新の VS Code じゃないと動かないとかなんとか。

わたしは chocolatey で入れる。これも以下のコマンドを打つだけだ。 Chocolatey Software | Visual Studio Code Insiders 1.80.0.20230704

choco install vscode-insiders -y

VS Code とは別に VS Code Insiders がインストールされる。

ここで code-insiders . を実行して VS Code Insiders を開くとまっさらになっている。はじめは Setting Sync が有効でないためだ。最も簡単に VS Code から VS Code Insiders へ設定を移行する方法は、一時的に VS Code Insiders で Stable の Setting Sync に繋ぐ方法だろう。わたしの場合は非公開になってしまった拡張機能以外はこれで問題なく移行できた。移行後は Setting Sync を off にして Stable から離脱、再度 Setting Sync を on にして Insiders へ接続するようにすれば良い。たまに Stable と Insiders で非互換があるらしいし、自身の利用端末全てで VS Code Insiders に移行するまではリスクがあると見て分けておくのが無難やろな。例外的に、認証情報の類は setting.json に token を書くような野蛮なもの以外すべてポチポチ再認証が必要だが、それでも随分楽なもんやな。

VS Code Insiders ではコマンドも code から code-insiders に変わるので、これまた PowerShell の profile で該当の箇所を変えてやる必要がある。普段から code を使う場面は ghq で一覧から選択した repo を開くときだけだ。面倒なので今回 current directory を開く関数を profile に新設した。さすがに code-insiders って長すぎるので許容できない。

# もとからあるやつ
function Set-SelectedRepository {
    ghq list | Select-Pocof | Select-Object -First 1 | ForEach-Object { Set-Location "$(ghq root)/$_" }
}
Set-Alias gcd Set-SelectedRepository -Option AllScope
# 新設
function Open-SelectedRepository {
    param(
        [Parameter()]
        [ValidateSet('Stable', 'Insider')]
        [string]
        $Channel = 'Insider'
    )
    $code = switch ($Channel) {
        'Stable' { 'code' }
        'Insider' { 'code-insiders' }
    }
    Set-SelectedRepository && & $code .
}
Set-Alias gcode Open-SelectedRepository -Option AllScope

これ gcd で選択肢がなかった場合の code-insiders が current directory になるのでなんか改善したほうが良いけど、いったんこれで。

PSResourceGet

PSResourceGet のインストールも大したことない。ブログに示されるコマンドでインストールすれば良い。わたしの場合は管理者権限で全ユーザ対象にインストールしてるので、追加でそのオプションだけつける。

Install-Module -Name Microsoft.PowerShell.PSResourceGet -AllowPrerelease -Scope AllUsers

インストールしたら PowerShell の profile で書いてる PowerShellGet のコマンドを PSResourceGet のものに置き換える。今回対象になったのは以下だ。基本 Module だった部分が PSResource になるだけだが、オプションも微妙に変わっているところもある。 profile で使ってるコマンドは以下の感じに置き換わる。意外に多かった。

Get-InstalledModule -> Get-InstalledPSResource
- -Scope の指定がいる
Install-Module -> Install-PSResource
- -AllowPrerelease -> -Prerelease
- -AllowClobber -> default 挙動に。従来の挙動は -NoClobber
Set-PSRepository -> Set-PSResourceRepository
- 追記: こいつもあったわ -InstallationPolicy Trusted -> -Trusted
Get-Module -> ~~Get-PSResource~~
- 追記:
  - Get-PSResource は PowerShellGet v3 にはあったけど PSResourceGet にはない。つまり何に変わったんだこれ？
  - Get-Module は Microsoft.PowerShell.Core が Source なのでそのまま使えば良いのか
Find-Module -> Find-PSResource
Update-Module -> Update-PSResource

これらの破壊的変更、どうも repo の CHANGELOG にまとまってないぽくて、すべてを一箇所で見つけることはできなかった。 PowerShell Team のブログとか追っていったら全貌わかるかもだが、面倒だ。 NoClobber の挙動とかは以下を参考にした。信頼の Ironman 。 What's new in PowerShellGet v3?

これらの変更を profile に施したあとうまく動いてるのが確認できたら仕事機にも反映する。

個人的にちょっとめんどいのが AWS Tools for PowerShell との今後の付き合い。 AWS Tools for PowerShell が PSResourceGet に移行するまで、当面は v2 v3 並行稼働という感じになるのだろうか。うまくいくのだろうか。互換モジュールが提供されてるから、そっちを使うのが良さげ。

PowerShell/CompatPowerShellGet: This module provide functions used with PowerShellGet v3 to provide compatibility with scripts expecting PowerShellGet v2

あと開発環境とは別に pocof の方でも PSResourceGet への移行を反映したい。具体的にはコマンドの名前が変わったこの辺。これらは Issue にしてればいいかな。未だ .NET 7 にも移行してないから、そういうのもやっていき。

Get-Module -> ~~Get-PSResource~~
- 追記: 先述の通り
Publish-Module -> Publish-PSResource

追記 1

Find-AWSToolsModule が Find-Module に依存してて、事前にダミーの Find-Module してないとエラーになるやつ未だ直ってないようだ。

Find-AWSToolsModule: The term 'PowerShellGet\Find-Module' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

自分用にはこれを回避するために関数を書いてたが、CompatPowerShellGet を使うとこの依存関係が永久に解決できないみたい。 module 違うからなあ...やはり v2 v3 の並行稼働しかなさそう...だいじょぶかな。

Get-PSResource も戻り値の property に変化があって、対処が必要だった。

Path -> InstalledLocation

追記 2

PowerShellGet に -AllowPrerelease つけて v3 をインストールしてたがややこしい。 PSResourceGet にない Cmdlet もあったりして危ない。おまえのことやぞ Get-PSResource 。 PowerShellGet は prerelease 版を入れないようにするのが無難。

Fable でブログを再構築する pt.9

Sun, 02 Jul 2023 09:00:00 +0900

krymtkts/blog-fable Fable でブログを再構築している。

細々とした修正だけやった。 #23

O'reilly の F# 本で勉強してたからか最近まで Interpolated strings - F# | Microsoft Learn わかってなかったのでそれに書き換えたり。あと Fable.Node の process 予約語で警告が出るやつも自前でかいた binding を使うことで解消した。利用する範囲そんなに多くなければ最小の範囲に絞り込んで Node.js の binding を書き Fable.Node 排除するのもよいが、なんとなく先延ばしにした。

RSS Feed に取り組み始めた。まずは RSS feed の構造を知らんかったので、自ブログの出力した feed.xml と RSS 2.0 specification RFC 4287 - The Atom Syndication Format を学んでる。自ブログは RSS 2.0 で書かれていて atom:link セクションを使うことで追加の機能を入れてるらしい。

RSS Validator なんてのも初めて知ったわ。試しに feed.xml を読ませてみたところ valid な RSS Feed と判定されてるが推奨事項がチラホラあった。 Fable でやるにあたってこういうのも丁寧に対応できると良いな。

feed.xml を作るにあたって sitemap.xml を書いたのと同じく自前で Fable.SimpleXml を使って書くのか、楽に Node.js のモジュールを使うのかがちょっと悩ましいところ。

この辺りが有名なモジュールのようだけど最後のコミットがちょっと古い。 feed の場合以下みたいにオブジェクトをもりもり書いていくだけっぽくて、 Fable.SimpleXml 使って自分で構築するのと変わらんのでは... という懸念があり、なんか自分でやったほうが良さそうに思っている。 RSS/Atom の知識乏しいけど、既存の焼き直しであればまあできるやろ的な。

// 以下はあくまでサンプルだがこれは書いてて楽しくなさそうな気配
// feed
const feed = new Feed({
  title: "krymtkts",
  description: "krymtktss blog",
  id: "http://krymtkts.github.io/",
  link: "http://krymtkts.github.io/",
  image: "http://krymtkts.github.io/image.png",
  favicon: "http://krymtkts.github.io/favicon.ico",
  copyright: "Copyright © 2019-2023 krymtkts",
  updated: new Date(2023, 7, 02),
  feedLinks: {
    json: "https://krymtkts.github.io/json",
    atom: "https://krymtkts.github.io/atom",
  },
});

// node-rss
var feed = new RSS({
  title: "krymtkts",
  description: "krymtktss blog",
  site_url: "http://krymtkts.github.io",
  image_url: "http://krymtkts.github.io/icon.png",
  copyright: "Copyright © 2019-2023 krymtkts",
  pubDate: "May 20, 2012 04:00:00 GMT",
  feed_url: "http://krymtkts.github.io/rss.xml",
});

let generateRssFeed (conf: RssFeed) =
    let items = ...

    let rss =
        {
            title = conf.title
            description = conf.description
            link = conf.link
            lastBuildDate = now.ToString("yyyy-MM-dd")
            generator = "blog-fable"
            items = items
        } |> convertToSimpleXml

    rss
    |> serializeXml
    |> (+) @"<?xml version=""1.0"" encoding=""UTF-8""?>"

イメージ雑いけどこんな感じにならんかな？自前でやることによって進捗が鈍化しそうやけど、しゃーないかという感じ。

Fable でブログを再構築する pt.8

Sun, 25 Jun 2023 09:00:00 +0900

krymtkts/blog-fable Fable でブログを再構築している。

先日の開発サーバ作成、 404 に生成済み HTML 表示するのもわかったので完了した。#20

再ビルドのパフォ改善は、今やらないと言うかできないと判断した。指定のファイル一覧だけを対象に HTML や関連する XML を再生成するって感じの機構を取り入れる必要があって、根本的に変えないとどうにもならんので、一通り必要と考える機能が揃ってから着手したい。

次に XML の類に取り掛かった。まずはデータ量少ない sitemap.xml のほう。 #22

sitemap.xml に関しては何の XML か知らなかったが検索エンジンのクローラにより正確な情報を与えるためのデータらしいのは理解した。今の Cryogen で生成されてる sitemap.xml がめちゃくちゃテキトーに作られてるのも含め。こちらを参考に知識を補った。 Build and Submit a Sitemap | Google Search Central | Documentation | Google for Developers

我がブログの運用に限れば、計測タグも設置してないし何 1 つ SEO 効果を期待してないけど、 wev.dev の PageSpeed Insights とかで良いスコアは出したい。ハイスコア狙いのゲーム感覚なのだ。だからこそいま全部同じ loc の全部同じ lastmod が出てるので、 loc を URL 毎にするとか lastmod に最終更新日を反映させるとかちょっとはマシにしたい。

折角なので priority も定めてみる。とりま index は 1.0 として Archives, Tags はカテゴリ系なので生成の度更新するし 0.9 としてみた。新しめのページは高い方が良いんか？結局全てが生成ファイルなので単純に post は投稿日付降順くらいしかできなそうやけど、ちょっとめんどいなあと思ったので今は控えて全部同じ 0.8 とした。代わりに投稿日付とは別に front matter に日付を持たせて、更新日付ぽい扱いができるよう悪あがきだけしておいた。

Fable で XML を操作するのには Zaid-Ajaj/Fable.SimpleXml を使う。 Feliz 作者の作品。使いたい機能は大体誰かが用意してくれていてありがたい限りである。

femto で足したらエラーになった。でも fsproj はちゃんと変更されてたから大丈夫ぽい。 npm モジュールが無いからエラーになる。 README には paket 使って足せと書いてあった(先に読め)。うちは使ってないから単純に dotnet add で足す。これでも十分シンプルに使えるし。

dotnet add .\src\App.fsproj package Fable.SimpleXml

Fable.SimpleXml は XML 宣言の読み込みは対応してるけど出力は対応してないみたいなので、手書き文字列を添えて出力してやる必要があった。それ以外に関しては Feliz で HTML を書くのと同じ感覚で書ける。参考として、以下に Fable.SimpleXml を使って sitemap.xml の文字列を作成する箇所を抜粋する。

    let generateSitemap root locs =
        let urls =
            locs
            |> Seq.map (fun loc ->
                node
                    "url"
                    []
                    [ node "loc" [] [ text $"{root}{loc.loc}" ]
                      node "lastmod" [] [ text loc.lastmod ]
                      //   node "changefreq" [] [ text "monthly" ]
                      node "priority" [] [ text loc.priority ] ])
            |> List.ofSeq

        let urlSet =
            node
                "urlset"
                [ attr.value ("xmlns", "http://www.sitemaps.org/schemas/sitemap/0.9")
                  attr.value ("xmlns:xsi", "http://www.w3.org/2001/XMLSchema-instance") ]
                urls

        urlSet
        |> serializeXml
        |> (+) @"<?xml version=""1.0"" encoding=""UTF-8""?>"

XML 宣言も文字列なんぞ使わずにサクッと書けるとカッコよいのだけど。

あとコメントアウトがあってダサいが、これは changefreq も足したいなーと思ってやらなかった残穢だ。 Index, Archives, Tags は post の投稿間隔から自動算出できるが、いま面倒でやらなかったので戒めとして残している。

これで次は RSS Feed の XML を作ったら最低限必要なものは揃う。スタイルや前後の post へのリンクみたいな細かな調整は必要だろうけど。 RSS Feed の仕組み、例えば既存の投稿に変更がある場合にどうなんの？とかもあんま知らんので、これを機に知識を補いたい。結構 post 周りのコード手を入れないと Markdown から抽出・生成したタイトル・公開日・ HTML 後続処理に回せんな... というのがあるので結構ダルそうではあるが、いい感じの手間がかかる点は最後に越える山としてふさわしい(と自分に言い聞かせる)。

場当たり的なコードも積もってきたし、細々とした気になってる点を補正する等も着手していこう。

Fable でブログを再構築する pt.7

Sun, 18 Jun 2023 09:00:00 +0900

krymtkts/blog-fable Fable でブログを再構築している。

当初開発サーバに使ってた tapio/live-server は npm の vulnerability 報告がずっと出てた。開発用なので構わないといえばそうだがやっぱいい気分ではないので、自力で開発サーバを立てるように変えていく(現在作業中)。 #20

F# Weekly の Sergey Tihon 氏がちょうどよい F# script を書いてるのを見つけたので、それをベースにする。 Web サーバに F# 製の SuaveIO/suave を使うようになる。

f# - Suave in watch mode (during development) - Stack Overflow

これに従うと、変更イベントで WebSocket のメッセージをページに送って、ページはメッセージを受け取ったらリロードする、という流れで live reload をすることになる。

ファイルの変更検知して変更イベントを発火する
変更イベントで WebSocket のメッセージ送信する
ページに差し込んだ JavaScript で WebSocket のメッセージを受け取ったら reload する

この開発サーバ用 F# スクリプトを開発するにあたり、 F# Interactive 特有の挙動とかあまりわかってなかったので、以下を参照に勉強した。 F# Interactive (dotnet) Reference | Microsoft Learn

今回ファイルの変更を監視するのと、 dotnet コマンド実行するのに FAKE のモジュールがいくつか必要だったので NuGet から取得する形にした。

FAKE はいつか勉強せなあかんなと思っていたが、タイミング良く使う機会が来た。その良さもなんとなく感じており、なんでも F# で書きたくなる気持ちがわかってくる。

先述の WebSocket でやり取りする JavaScript は、デプロイするブツには不要だ。なので今回開発モードをこしらえて、その場合のみ WebSocket 用の JavaScript をロードする script タグを差し込むようにした。開発モード自体は SSG 実行時のオプションで渡す形にしている。設定ファイルなしでスクリプトだけで完結する世界観にしたいので。

この開発用 JavaScript も、そのうち Fable.Browser.WebSocket で書いてトランスパイルしたものを使うようにしたい。

一通り作ってみて、いい感じに動いてるっぽい。ただし強烈に遅いのと、 Suave で 404 ページを表示する方法がわからないので、今後の課題かな。差分ビルドとかできるとかっこよい。

以下に今回のハマりどころを記載しておく。

ハマりどころ

Suave 、 Fable 共にそうだけどドキュメントに書いてないことがチラホラあるので、分からなくてコード読む必要があった。備忘のためいくつかメモを記録しておく。

Suave

Suave で以下のエラーが出たときは、権限じゃなくてサーバの設定が足りない。

System.UnauthorizedAccessException: Access to the path 'C:\Program Files\dotnet\sdk\7.0.302\FSharp\_temporary_compressed_files' is denied.

これを解消するには権限を与えるのではなく、 Sauve がデフォルトで使ってる圧縮ファイルのパスを config に指定しないといけない(デフォでなんかやってくれよめんどくせえ)。 suave/Web.fs at 8efe4b32ea0dc52f36c10c8d8fec8191c6ae901c · SuaveIO/suave

compressedFilesFolder = Some(home)

Fake.DotNet

Fake.DotNet の使い方は SAFE-Stack のテンプレが参考になる。 SAFE-template/Build.fs at db892ace1ecd1589a9a03a484e388a97f3b71718 · SAFE-Stack/SAFE-template

command と args どう分けるか謎だが、あんまきにしなくていいっぽい。現に ↓ のように cmd に引数が混ざっていても動くという。

let cmd = "fable src"
let args = "--runScript dev" // NOTE: run script with development mode.
let result = DotNet.exec (fun x -> { x with DotNetCliPath = "dotnet" }) cmd args

Fable

Fable に --runScript をつけて呼び出したときに引数を与えられるのかについては、ドキュメントの記載は見つけられなかったがソースコードを見る限り与えることができる。 Fable/src/Fable.Cli/Entry.fs at ac4d44997f69d5b1b7109730ccb45e354a4ec368 · fable-compiler/Fable

この形式なので、以下のようにコマンドを打てばよい。

dotnet fable src --runScript dev

--runScript で実行するスクリプトの方では、 Node.js の引数の取り方を使えば良い。つまり process.argv を使う。

Fable.Node を使ってたら process.argv が簡単に使える。でも process は F# の予約語で警告が出るので、気持ち悪いからそのうち自前で binding するように直すかも。

Fable でブログを再構築する pt.6

Sun, 11 Jun 2023 09:00:00 +0900

krymtkts/blog-fable Fable でブログを再構築しようとしている。

GitHub Actions で GitHub Pages のデプロイするようにした。あと個人プロジェクトの repo を deploy したときの root 間違ってたので手直しする必要があった。 #16, #18

GitHub Pages はこちら → Blog Title - February

GitHub Actions を使った GitHub Pages の deploy は現行ブログでもやりたかったネタで、長らく放置してた。ブログ再構築のタイミングなら導入するのにちょうどよいので以下の記事を参考に導入した。

注意点は先述の通り、個人プロジェクトの場合は {account}.github.io/{repo-name}/ がページの root になる点くらい。これは自動的に付与されるので、その前提でリンクやら調整する必要がある。ただし開発サーバでは自動で付与されないので、 root は docs にしつつ他は repo name のディレクトリを介すようにする。今回のケースでは以下を調整していい感じにした。

諸々のリンクに repo name のディレクトリを入れる
開発用サーバの index や 404 を repo name のディレクトリを介すよう調整する
actions/upload-pages-artifact の path は repo name のディレクトリにする ← 重要

いまの workflow と開発サーバの設定を転記しておく。

blog-fable/gh-pages.yml at 4cb5d81ac8099889dd55e50ae39ebb20935e96f5 · krymtkts/blog-fable · GitHub

name: Deploy GitHub Pages

on:
  push:
    branches: ["main"]
  workflow_dispatch:

permissions:
  contents: read
  pages: write
  id-token: write

concurrency:
  group: "pages"
  cancel-in-progress: true

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Setup Pages
        uses: actions/configure-pages@v2
      - name: Setup .NET
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: 7.0.x
      - uses: actions/setup-node@v3
        with:
          node-version: 18
      - name: Install dependencies
        run: npm install
      - name: Build pages
        run: npm run build
      - name: Upload artifact
        uses: actions/upload-pages-artifact@v1
        with:
          path: docs/blog-fable/ # ここ重要。 docs/ ではない

  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v1

開発サーバは今暫定的に live-server を使っているが、その場合以下のように index と 404 を指定して起動する。

live-server docs --open=blog-fable/index.html --entry-file=blog-fable/404.html

長々と書いたが、個人ページを作るなら {account}.github.io/ の repo を使うだろうから、そんなに心配することはない。

今回の GitHub Pages の対応でベタ書きだったパス類をエントリポイントへ全部まとめるようにしたので、幾分設定しやすくなった。これでサイトマップとフィードの XML 、開発サーバの置き換えあたりに着手できる。一段落までもうちょいかな。

Fable でブログを再構築する pt.5

Sun, 04 Jun 2023 09:00:00 +0900

krymtkts/blog-fable Fable でブログを再構築しようとしている。

雑多な更新 #11 #12 #13 。 favicon が出てなかったの直したり、 404 ページ作ったり、あとやりたかった module の整理。

ファイルは雑に共通系 -> 生成系 -> アプリの依存関係に切り分けて、それぞれのファイル内に雑多な module が詰まってるようにした。元は 2 ファイルだったのでこれでもだいぶマシかな。でも module の整理は今結構雑な感じで置いていて、もうちょいと関数を細切れにできるのでその後また見直す。互いに変な依存関係してたり、生成系関数のインタフェースが不一致だったりするのとか、気になるのが残ってる感じ。それより優先して細々した直したい部分があってわざと置いてる。

細々した直したい部分というのは navbar で、 Bulma (暫定的にこいつで行くことにしたから)の Navbar Component 見てみたのだけどこんな複雑に使い分けなあかんの？みたいな div div した感じになってて、これ導入したくないなあと感じてた。 nav -> ul -> li でだめなんか。 Tailwind の Navigation だと思ったようなシンプルな感じのものが得られるのだけど、あの大量の class をつけるのもなあという感じだった。世の中 Navbar はみんなグリグリ動いたり深ーい階層の div div したやつを、好きでやってんのかな。いやないはずだ。とりあえず自分のやつではやりたくないなって感じの奴らなことは確かな感触を持った。ちょうど Tabs Component というもっとシンプルで ul -> li に被せられるスタイルがあったので、これを適用する感じにし、諸々調整した。 #14 #15 Tailwind の Navigation で得られるシンプルなやつに近い感じ。モバイルなんかでもグリグリ UI が変わらず同じ見た目でスライドするだけなので、この方がいい。

とはいえこういう div div したくないというのは Feliz で HTML を直書きする方向性を選んだから書くのがだるいのも多少ある。もちろん生成物が div div してるとキモいなというのが一番だけど。ここにきてFulmaを導入したら楽になるのか？というのを Navbar のくだりで多少試したのだけど、なんか Feliz より書き味良くなかった(慣れの問題かも)ので今は据え置きにしている。仮に Fulma を導入するとなると、あの div div した生成物を受け入れるってことやからな。

div div 書きまくってどれだけあれが好きでないかというのが伝わっただろうが、仕事ではそういう div div した構造を目当てのレイアウトを得るために書くこともあるということは断っておきたい。必要な div なら仕方がない。でも自分の趣味プロで書くのであれば、仕事と同じことしても余白が狭すぎるし、極力簡素にしたいということでね。

もう最近やったことまとめと化してるけど、これも振り返りにちょうどよいので悪くない。ひとり(プラス GitHub Copilot サンと ChatGPT サン)で黙々とやってると、フィードバック得られるところも限られるからな。こういうことをダラダラと書き連ねるだけでも、次のアイデアにつながる。ちょうどこの記事をしたためいている中で、 footer 要素がないわ...というのに気づけた。とりあえずこの記事を push してから、それに取り掛かることとする。

Fable でブログを再構築する pt.4

Sun, 28 May 2023 09:00:00 +0900

krymtkts/blog-fable Fable でブログを再構築しようとしている。

YAML で書かれたメタデータ(Front Matter というらしい)の抽出を作った。 #5

またそれに伴って記事へのリンクのタイトルに front matter が使えるようになったので諸々手直しした。 #10

front matter 抽出については、まず最初に remark 使ってみた。けど、 ts2fable で binding を出力したところ unified 、 remark とその Plugin たちの間で型の整合性が取れなかった。整合取ろうとしたら自力で調整しないとどうにもならないので、とてもじゃないがすぐには使えないと判断して早々に諦めた。 remark のパーサを作る部分を JavaScript で書いて、それを import する形でやれば簡単にできるが、そこは F# で書いてこそ意味がある。

というわけで marked のまま、 front matter の抽出を古典的な方法、つまり正規表現を使って自力でやった。 front matter 自体は YAML で書くので、 eemeli/yaml を導入した。 yaml module は ts2fable で Fable の binding が生成されなかったので、雑なやつを手で書いた。

front matter 抽出ができるようになると、 Archives や Tags で作ってたページリンクにメタデータのタイトルを使えるようになる。タグ付けされたページにタグリンクもつけられるし。それに伴い諸々の手直しをし、ついでに参照元のコードのまま使ってた CSS とかを最新のものまで更新した。とりまいまは CDN のを借りてる。ついでに highlight.js の CSS を足した。 Index Archives Tags が出揃って、ページにタグが付き、 syntax highlighting も効くようになったから、結構ブログっぽくなってきたのでは？

諸々のスタイル調整はぜんぜんやってないけど。スタイル調整に対する欲求が低くて、どうしようか考えるとのがとてつもなくだるい。とりあえず色味だけは Solarized Dark でいこうと思ってるけど。ただ Solarized Dark のコンテンツに Solarized Dark の syntax highlighting だと境界ワカランのちゃうかな？というのはある。なので現にいまのブログでは Solarized Light をコンテンツに使ってるし。スタイルに関してはこのまま Bulma でいくか決めないといけないのだけど、こういう感じの自分であまり考えたくないケースに案外ハマってるかも、しらんけど。

最近の機能拡充に伴ってエントリーポイントである App.fs と Helpers.fs がむやみに肥大化しているので、そろそろ整理したいところ。いまは App.fs に色々書いてるけど、これ多分 render 関数以外はもう module に切り出した方がいいねんよな。

イメージ的には、 render 関数で用意した関数を組み合わせるだけにする。いま navbar に表示するページだったり index に最新のポストを表示するのが固定でやってるけど、こういうのも front matter に寄せたらスッキリするかな。設定ファイルとかはなしで、ディレクトリ構造とコンテンツの front matter だけで制御できたら楽かなあ。

道程は長い。

Chocolatey で Portable OpenSSH を更新する 2023

Sat, 20 May 2023 09:00:00 +0900

久しぶりに、 Chocolatey に OpenSSH の β が降ってきてた。

前回は 2019 年だった。 Windows10 の更新で OpenSSH が逝ったまた OpenSSH が動かなくなる季節がやってきた

Chocolatey Software | Win32 OpenSSH (Universal Installer) 9.2.2-beta1

ので更新してみたところ、以下のエラーログが。

ERROR: There is a configured instance of the SSHD service, please specify the /SSHServerFeature to confirm it is OK to shutdown and upgrade the SSHD service at this time.
The upgrade of openssh was NOT successful.
Error while running 'C:\ProgramData\chocolatey\lib\openssh\tools\chocolateyinstall.ps1'.
 See log for details.

はて？ sshd 入れてたっけ？と思ったが見たら入ってた。 chocolatey で自動で入ったんやっけ？

PS> get-service *ssh*

Status   Name               DisplayName
------   ----               -----------
Running  ssh-agent          ssh-agent
Running  sshd               sshd

いる！しかも実行中なのがなんかキモい。

こいつを停止させるのはあとにするとして、ひとまず choco upgrade を成功させるにはどうしたら良いか。こういうときはちゃんとマニュアルを読む。 Chocolatey の Package Source のリンクを辿れば良い。

openssh · master · DarwinJS / ChocoPackages · GitLab

-params '"/SSHServerFeature"' (Install and Uninstall)
Also install sshd Windows Service - including opening port 22. If this parameter is not included on an upgrade or uninstall and the sshd server is installed - an error is generated. You must use this switch to indicate you have made preparations for the sshd service to be interrupted or removed.

どう見てもこれ。以下を実行する。

choco upgrade openssh -params '"/SSHServerFeature"' -y

この後再起動をして Windows Terminal で PowerShell を開くと作業が完了した。すっかり忘れていが、わたしの $PROFILE は「 ssh-agent のサービスがいない ≒ Windows の OpenSSH が更新された」と判定し、インストールスクリプトを実行するのだった。ここ

# install ssh-agent service if not exists.
# it will be triggered after updating Windows OpenSSH.
if (! ($SshAgent = (Get-Service -Name 'ssh-agent' -ErrorAction SilentlyContinue))) {
    install-sshd.ps1
    Set-Service -Name 'ssh-agent' -StartupType Automatic
    Start-Service ssh-agent
}
elseif ($SshAgent.StartType -eq 'Disabled') {
    Set-Service -Name 'ssh-agent' -StartupType Automatic
    Start-Service ssh-agent
}
else {
    Start-Service ssh-agent
}

インストールスクリプトは Portable OpenSSH に提供されるもので ssh-agent と sshd が一緒くたにインストールされてたのね...なんか他にやりようないか考えても良いのかな。

とりあえずこれで事なきを得た。 sshd の起動タイプも手動になっておりヨシ。

PS> get-service *ssh* | select -Property Name,Status,StartType

Name       Status StartType
----       ------ ---------
ssh-agent Running Automatic
sshd      Stopped    Manual

Fable でブログを再構築する pt.3

Sun, 14 May 2023 09:00:00 +0900

krymtkts/blog-fable Fable でブログを再構築しようとしている。こちらに手をかけてることで最近 krymtkts/pocof 触っておらず多少不安になってきたが、もう少し Fable に慣れるまではお預け。

簡単に Index のページに最新ポストをコピるのと、投稿一式から Archive ページを作るのをやってみている。 #4 徐々にコード量が増えることでここは関数にしておいて～とか、コレコレをモジュールにしておいて～とか、楽しくなってきた。一緒に Tags のページを作りたかったのだけど、いま Markdown 内のタグはじめとしたメタデータをパースしてないから作れない。先に remark の導入やらないと投稿のメタデータであるタグは(自力で書かない限り)抜けないから、後回しにしておいた。

今回 Archive ページを作るにあたりコードを書いてると、設定で分ける想定をしてコードを汎化した方がスッキリする雰囲気になってきた。元は完全に自分用のイメージで作っているので、設定に基づいて出力をどうこうするというのは考えてなかった。現時点ではベタの部分と、設定(というか関数の引数)によって挙動を決める部分が混じり合っているので、徐々に後者に倒していく。

とはいえまだ Tags ページと RSS ができてないので、今後の予定としては以下かなと。

marked → remark へ移行する
Markdown ファイルのメタデータ(YAML)が読めるようになるので Tags ページが作れるようになる
RSS 機能を作成する
全体的な汎化で設定の切り出し
ブログのカラーテーマを作る(今は元コードから引き継いだ Bulma のスタイルが適用されてるだけ)
既存ブログとの互換性調整 etc

いまんとこ毎週末のスキマ時間で亀進捗出してるので、多少作業が多かろうが大丈夫な気がしてきたな。最後の互換性のやつだけあんま自信ないけど、リンク切れだけは起こらないように慎重に URL を調整する。 RSS フィードのは、わたしがリーダー側の仕組みがよくわかってなくて、どうなるかわからん。実際過去に自分が購読してるフィードも全部再配信みたいになってることがあった。せめてそういうのはなくしたいが、先述の通りどうなるかわからん。わたしの観測範囲ではわたし以外にも一人だけ RSS 購読者がいるっぽいし、たまーに記事が参照されてることもあるので、なるべき気をかけたい。

あと GitHub の streak 365 まで 100 日切ってた。残りも淡々と続けてこー。

Fable でブログを再構築する pt.2

Sun, 07 May 2023 09:00:00 +0900

krymtkts/blog-fable の話。 Fable でブログを再構築しようとしている。

repo 公開時点で README.md をレンダリングするだけに留めていたので、ブログらしく post と固定ページを出力できるように最低限手を加えた。 #2

あと node module に型を与える Fable bindings を利用しようと思い、 markedjs/marked, highlightjs/highlight.js でそれを試した。これが結構大変で、まだ慣れてない。

bindings は自動生成できる。それには fable-compiler/ts2fable を利用する。

# こんなん。型定義されてない module には使えない。
npx ts2fable node_modules\@types\marked\index.d.ts src/bindings/Marked.fs
npx ts2fable node_modules\@types\highlightjs\index.d.ts src/bindings/HighlightJs.fs

で出力された型を Fable の F# コードで利用するのだけど、うまく使うために色々覚えないといけない Fable 独自の型・関数・演算子がある。 ImportAttribute 、 Union Type の U2 その他大勢、動的キャスト演算子 !! と Anonymous record の組み合わせ、 jsOptions<'a> ... まだ勉強中だが、早い話 Fable · Call JS from Fable に載ってるの全部知っといた方というか知っとかないとキツイ雰囲気を感じている。何故なら Fable の真髄であろう JavaScript と F# の型で守られた相互運用がそこに詰まっており、知らないとうまくできないから。

寝かしつけ中にこのページ重要そうなの気づいて何度も読んだけど、実際に書いてみると全く活かせてない。また何度も読み直してる。何の気なく書かれてる一行のサンプルコードが重要だったり。 JavaScript の Module system に詳しいとピンとくるんかなー。このテーマに関しては GPT-4 に聞いたところでホラ吹いてくるので、自力で勉強せなあかん。

あと ts2fable で自動生成できない場合は自力で bindings を書く必要があるところも、パンチが効いてる。今の marked で Syntax Highlighting を使うにはmarkedjs/marked-highlight: Add code highlighting to marked を使う。けどこいつには Type Declarations .d.ts が提供されてないので、今回は Fable.Core.JsInterop の importMember で茶を濁した。 highlight.js の方も、実は Type Definitions が古くて新しいインタフェースになってない。

このように Fable の技術スタックは JavaScript のそれの上に乗っかって相互に混ざり合ってるので、両方に対して結構詳しくなるまで辛い気がする。ただその頂きを超えたところに Fable の楽しみがあるのかも、しらんけど。まあ書いていておもろいのは確かで、色々つまづきながら進めている。

あとここまでやって気づいたのだけど、 marked 自体には Markdown 中に書かれた title とか tag とかを読み取る機能ないっぽい。実現しようとしたらなんか自分で --- でファイルコンテンツ区切って YAML にパースするとかしないとだめみたい。そもそもこのメタ情報の部分 YAML だとこの機会に初めて知ったわ。自力で書いてもいいけど、この際 remarkjs/remark みたいなプラグインでそれが実現できるやつを使うのもいいかなと思った。 Markdown のレンダリング部分を換装するのは大変じゃなさそうなので、 navbar 作るとか RSS 作るとかの後に回す。

他にも、開発用途で問題ないとはいえ tapio/live-server にいちいち脆弱性の警告出るのも煩わしく、ここを F# のスクリプトに置き換えたい。

やりたいこと盛りだくさん。年内には SSG 乗り換え実施したいな...なんとなく。

Fable でブログを再構築する pt.1

Sun, 30 Apr 2023 09:00:00 +0900

Fable の練習を始めた。

Fable にしたのはフロントエンドのエコシステムと統合するのに良さそうだったから。いまの Clojure 製 Cryogen はフロントエンドとは切り離された感じで、一応 Bootstrap を使ってりはしてるが module 管理とかしてない。なのでフロントエンドの依存性の管理みたいのも一緒にしたいなーと考えていた。

今使ってる Clojure 製の Cryogen と同じ雰囲気を F# で再現するなら ionide/Fornax が正にそんな感じっぽかった。でも折角なので HTML, JavaScript, CSS 共に F# へ統合した感じにしたい。 Fable ならそれができそうに思えた。

実際のところ Fable は F# を他言語へ変換するトランスパイラなので、静的サイトジェネレーターとして使うにはオーバスペックな感じはある。けど、こんな機会でもないと一生触らないテクノロジなので、やるならこっちやろ！と考えた。

実現したいことは以下の通り。

Markdown で書いたコンテンツを静的サイトに変換する(Cryogen と同じ使用感)
RSS feed の XML を出す(Cryogen で出したのと同じやつ)

ここ 2, 3 週間ほど、子供の寝かしつけ中とかに片手間で Fable やその周辺ツール・モジュールのドキュメントとか諸々の repo を見ていた。けどあんまドキュメント充実しておらず、テンプレプロジェクトを生成して壊してを繰り返してようやく雰囲気がわかってきた。見た目は同じでも中身は違うわ、ってかんじ。

色々試行錯誤した成果として先述の 1 を最小限に実現できたので、一旦日記にまとめる。 krymtkts/blog-fable

実現手段はいくつか調査した。まず Fable 作者の Fable で静的サイトを作った例¹が既にある。でも激古なためかわたしが理解不足なのか、全くもって動かすことができなかった。また Bulma という CSS Framework の Fable wrapper である Fulma のテンプレ²もあったのだけど、これも同様に動かし方がわからなかった。

Fable の site で使われている MangelMaxime/Nacara を試してみたけど、これ RSS 以外をほぼ自分で組り込むところがなくて F# で書く楽しさなさそうったので却下。

ここまで来たら、自力で練習がてら Fable の無垢のテンプレに付け足ししていくしかあるまいなとなった。というか周辺ツールの不理解もあって 1 から自分でやらないと無理ゲーと化してた。

まず Fable · Start a new project で素朴なプロジェクトを作成しする。

次に fable-compiler/static-web-generator でやってることを移植していく。ここではエントリポイントで Markdown などのコンテンツを読み込んでテンプレに埋め込み、 HTML にレンダリングした結果をファイル出力している。なので、まずは素朴な手書きの HTML でいいからファイル出力できる状態にし、その後 React の wrapper を追加する形で進める。

RSS は、 Fable · .NET and F# compatibility を見るに .NET の機能はまあ使えないので、 Node.js で xml を出力するやつを移植することになるハズ。なんかハードな気配してきた。

何度も作っては消しを繰り返して得た確かな手順は以下の通り。

Fable のプロジェクト作成は Fable · Start a new project を参照
.NET 系ツールの取り回しは以下を参照
- How to manage .NET tools - .NET CLI | Microsoft Learn
- global.json overview - .NET CLI | Microsoft Learn
(後述する) Femto は Fable · Introducing Femto を参照

Paket を使うと依存関係の管理が楽になる(project ファイルから外に出せるから)のだけど、今回は導入しなかった。関係するツールが多すぎて腹いっぱいになってる。

# 無垢の Fable project 作成する。
dotnet new install Fable.template
dotnet new fable --name blog-fable
cd blog-fable
git init
git commit --allow-empty -m 'Initial commit.'
git add .
git commit -m 'Add minimal Fable template.'

# dotnet tool を更新する。
dotnet tool update fable
dotnet tool update femto

# 動くことを確認する。
npm install
npm run start

# global.json の更新方法わからないので力づくで書き換えて更新する。
dotnet new globaljson --sdk-version 7.0.203 --roll-forward latestFeature --force
dotnet tool restore

build target が .Net Core 2.0 なので .Net 7 にする。 src\App.fsproj を編集する。

 <Project Sdk="Microsoft.NET.Sdk">
   <PropertyGroup>
-    <TargetFramework>netstandard2.0</TargetFramework>
+    <TargetFramework>net7</TargetFramework>
   </PropertyGroup>
   <ItemGroup>
     <Compile Include="App.fs" />

Fable も最新版の 4 にする。これには Femto という tool を使うみたい。 Femto は packet と npm の仲介役のようなやつで、 Nuget から Fable のモジュールを持ってきたらついでに npm してくれるようなやつっぽい。さっぱりわからんが、コマンド打ったら確かに更新された。

femto install Fable.Core .\src
femto install Fable.Browser.Dom .\src

↓ こうなった。

   <ItemGroup>
-    <PackageReference Include="Fable.Browser.Dom" Version="2.2.0" />
-    <PackageReference Include="Fable.Core" Version="3.2.3" />
+    <PackageReference Include="Fable.Browser.Dom" Version="2.14.0" />
+    <PackageReference Include="Fable.Core" Version="4.0.0" />
   </ItemGroup>

npm run start npm run build あたりが動いてたら大丈夫だろう。 (dotnet tool restore が postinstall で走る記述になってる)

webpack も古かったのでとりあえず上げておいたが、 SSG したいだけなのでこれらは後ほど消した。

ついでに solution も作っとく。

dotnet new sln
dotnet sln add ./src

ここまでやってまだテンプレが最新化されただけ...

ここからが本番。無味乾燥したテンプレに fable-compiler/static-web-generator の要素を足していく。

以下の Fable の package が使われており、そのうちいくつかは deprecated されてる。分割されている package を追うのは直に repo でコードを追うしかなく、なかなかハードな道のりだった。そして調べた内容で書き換えをした。書き換えの内容は krymtkts/blog-fable を直に見るのが良い(書くのめんどい)。

Fable.PowerPack ← fable-compiler/fable-powerpack: Utilities for Fable apps
- Split Fable.PowerPack in multiple packages? · Issue #63 · fable-compiler/fable-powerpack 分割された
- そもそも使ってなくね？ということで移植しない
Fable.React ← Zaid-Ajaj/Feliz 使えと
Fable.Import 系はデカすぎて repo が分かれた Track repo splits · Issue #80 · fable-compiler/fable-import
- Fable.Import.Browser ← fable-browser
- Fable.Import.Node ← fable-compiler/fable-node: Bindings for node.js native modules めちゃ古だがまだ動くらしい？
Fulma ← 今回は使わなかった

これら新しい package を移植し多少のコードを変更することで、やっと Markdown(今は README.md のみ) → HTML とパースして表示できるようになった。

ひとまずここまで。

まだたった 1 ページを出力できただけで先は長いが、 Fable の雰囲気わかってきてできそうな感触を得ている。

やっぱ Node.js の変更周り全然わからんことだらけなので、そこは Nacara/Node.Extra.fs at master · MangelMaxime/Nacara のイケてる実装を参照するなどして組んでいけたら良さそう。

あとやっぱ F# は .NET へ重依存なので .NET を部分的にしか使わない Fable だとかなり書き味が違う。これに慣れるのはちょっとかかりそう。

続く。

pocof の 1 年間

Sun, 23 Apr 2023 09:00:00 +0900

krymtkts/pocof の話。

明日 2023-04-24 で pocof の開発を始めてから 1 年になるらしい。開発しない週があったり、そもそも進捗は亀だが、続けてきたのは我ながらエライ。折角なので Git の commit history を基に活動を振り返ってみる。

書き捨てのスクリプトは以下。案外役に立ったのでなんか小綺麗にして使える感じにしてもいいな。

# merge commit 除く。
$logs = git log --pretty=format:"%cd,%s" --date=iso-strict | ConvertFrom-Csv -Header CommitDate, Message | Where-Object -Property Message -NotLike 'Merge pull request*' | ForEach-Object { [PSCustomObject]@{
        CommitDate = Get-Date $_.CommitDate
        Message = $_.Message
    } }

# 年月ごとのコミット数。
$logs | ForEach-Object { $_.CommitDate.ToString('yyyy-MM') } | Group-Object | Select-Object -Property Name, Count

# 追加・削除行数。
$ret = @{}
$stats = git log --numstat --pretty="%cd" --date=iso-strict | ForEach-Object {
    switch ($_) {
        { $_ -match '\d{4}-\d{2}-\d{2}' } {
            $key = Get-Date $_
        }
        default {
            $values = $_ -split "`t"
            if ($values.Count -eq 3) {
                if ($ret.ContainsKey($key)) {
                    $entry = $ret[$key]
                    $ret[$key] = [PSCustomObject]@{
                        Add = [int]$values[0] + $entry.Add
                        Remove = [int]$values[1] + $entry.Remove
                    }
                }
                else {
                    $ret[$key] = [PSCustomObject]@{
                        Add = [int]$values[0]
                        Remove = [int]$values[1]
                    }
                }
            }
        }
    }
} -End { $ret }
$stats.GetEnumerator() | ForEach-Object { [PSCustomObject]@{Add = $_.Value.Add; Remove = $_.value.remove } } | Measure-Object -Property add, remove -Sum | Format-Table

# 年月ごとの追加・削除行数。
$ret = @{}
$monthly = $stats.GetEnumerator() | ForEach-Object { [PSCustomObject]@{YM = $_.Key.ToString('yyyy-MM'); Add = $_.Value.Add; remove = $_.value.Remove } } | ForEach-Object {
    if ($ret.ContainsKey($_.YM)) {
        $entry = $ret[$_.YM]
        $ret[$_.YM] = [PSCustomObject]@{
            Add = [int]$_.Add + $entry.Add
            Remove = [int]$_.Remove + $entry.Remove
        }
    }
    else {
        $ret[$_.YM] = [PSCustomObject]@{
            Add = [int]$_.Add
            Remove = [int]$_.Remove
        }
    }
} -End { $ret }
$monthly.GetEnumerator() | Sort-Object -Property Key | ForEach-Object { [PSCustomObject]@{YM = $_.Key; Add = $_.Value.Add; Remove = $_.value.remove } }

# ファイルごとの追加・削除行数。
$ret = @{}
$fileStats = git log --numstat --pretty="%cd" --date=iso-strict | ForEach-Object {
    $values = $_ -split "`t"
    if ($values.Count -eq 3) {
        $key = $values[2]
        if ($ret.ContainsKey($key)) {
            $entry = $ret[$key]
            $ret[$key] = [PSCustomObject]@{
                Add = [int]$values[0] + $entry.Add
                Remove = [int]$values[1] + $entry.Remove
            }
        }
        else {
            $ret[$key] = [PSCustomObject]@{
                Add = [int]$values[0]
                Remove = [int]$values[1]
            }
        }
    }
} -End { $ret }
$fileStats.GetEnumerator() | ForEach-Object { [PSCustomObject]@{File = $_.Key; Add = $_.Value.Add; Remove = $_.Value.Remove } } | Sort-Object -Property Add, Remove -Descending

# 年月・ファイルごとの追加・削除行数。
$ret = @{}
$fileStats = git log --numstat --pretty="%cd" --date=iso-strict | ForEach-Object {
    switch ($_) {
        { $_ -match '\d{4}-\d{2}-\d{2}' } {
            $date = Get-Date $_
        }
        default {
            $values = $_ -split "`t"
            if ($values.Count -eq 3) {
                $key = "$($date.ToString('yyyy-MM')) $($values[2])"
                if ($ret.ContainsKey($key)) {
                    $entry = $ret[$key]
                    $ret[$key] = [PSCustomObject]@{
                        Add = [int]$values[0] + $entry.Add
                        Remove = [int]$values[1] + $entry.Remove
                    }
                }
                else {
                    $ret[$key] = [PSCustomObject]@{
                        Add = [int]$values[0]
                        Remove = [int]$values[1]
                    }
                }
            }
        }
    }
} -End { $ret }
$fileStats.GetEnumerator() | ForEach-Object { [PSCustomObject]@{File = $_.Key; Add = $_.Value.Add; Remove = $_.Value.Remove } } | Sort-Object -Property File, Add, Remove

Merge commit を除いたコミット数が 113 。 2023 年に入ってからは前年より多少活発。

以下は年月ごとのコミット数。開発してない月あるんじゃないかって気がしてたが、ギリギリ毎月開発してた様子。

YM	Commit
2022-04	4
2022-05	16
2022-06	4
2022-07	2
2022-08	1
2022-09	11
2022-10	4
2022-11	7
2022-12	2
2023-01	7
2023-02	15
2023-03	24
2023-04	16

コードの変更を伴うコミットが今まで 109 あって、追加された行が 6312 、削除された行が 2821 。44% 位を書き直してるのが意外だった。時期的にはテストコード拡充とそれによるリファクタが大きい要因か。

以下が年月ごとの追加・削除行数。

YM	Add	Remove
2022-04	717	83
2022-05	1425	386
2022-06	83	26
2022-07	61	56
2022-08	30	17
2022-09	233	145
2022-10	69	27
2022-11	365	170
2022-12	57	19
2023-01	358	245
2023-02	214	143
2023-03	2163	1134
2023-04	537	370

ファイル別の分析はちょっと面倒で、 rename したものやドキュメント類も含まれてしまってる。が、目 grep した感じだと最近テストを頑張って書いてた Action.fs, Data.fs あたりの新陳代謝ができており、それにつられて依存関係の Library.fs の変更も多いと。 Query.fs はコア部分なので削除少ないのはおっかなびっくりいじってるからかな？ UI.fs なんかは全然いじれてないので削除行数少なめ。

以下がファイルごとの追加・削除行数。

File	Add	Remove
src/pocof.Test/Tests.fs	798	798
src/pocof.Test/PocofData.fs	705	145
src/pocof/Action.fs	569	179
src/pocof/Data.fs	517	451
src/pocof/Library.fs	470	282
src/pocof.Test/PocofQuery.fs	459	131
src/pocof/Query.fs	430	261
.gitignore	399	0
src/pocof/pocof.dll-Help.xml	382	60
tests/pocof.Tests.ps1	263	113
docs/Select-Pocof.md	260	31
src/pocof/UI.fs	238	112
src/pocof/pocof.psd1	231	99
src/pocof.Test/PocofAction.fs	171	23
psakefile.ps1	134	31
src/pocof/{Action.fs => Data.fs}	71	82
src/pocof/pocof.fsproj	38	17
pocof.sln	36	2
src/pocof.Test/pocof.Test.fsproj	36	1
README.md	33	2
.github/workflows/pr.yml	30	1
LICENSE	21	0
test/pocof.Tests.ps1	17	0
src/pocof.Test/Program.fs	4	0
{test => tests}/pocof.Tests.ps1	0	0

以下が年月・ファイルごとの追加・削除行数。

File	Add	Remove
2022-04 .gitignore	398	0
2022-04 pocof.sln	27	0
2022-04 src/pocof/Library.fs	57	3
2022-04 src/pocof/pocof.dll-Help.xml	1	0
2022-04 src/pocof/pocof.fsproj	22	0
2022-04 src/pocof/pocof.psd1	212	80
2022-05 {test => tests}/pocof.Tests.ps1	0	0
2022-05 docs/Select-Pocof.md	181	0
2022-05 LICENSE	21	0
2022-05 pocof.sln	1	1
2022-05 psakefile.ps1	90	13
2022-05 README.md	15	0
2022-05 src/pocof/{Action.fs => Data.fs}	71	82
2022-05 src/pocof/Action.fs	346	46
2022-05 src/pocof/Data.fs	89	107
2022-05 src/pocof/Library.fs	150	112
2022-05 src/pocof/pocof.dll-Help.xml	261	3
2022-05 src/pocof/pocof.fsproj	8	9
2022-05 src/pocof/pocof.psd1	1	1
2022-05 src/pocof/Query.fs	39	2
2022-05 src/pocof/UI.fs	128	10
2022-05 test/pocof.Tests.ps1	17	0
2022-05 tests/pocof.Tests.ps1	7	0
2022-06 src/pocof/Library.fs	3	3
2022-06 src/pocof/pocof.fsproj	3	3
2022-06 src/pocof/Query.fs	43	11
2022-06 src/pocof/UI.fs	34	9
2022-07 src/pocof/Data.fs	7	4
2022-07 src/pocof/Library.fs	4	11
2022-07 src/pocof/Query.fs	41	38
2022-07 src/pocof/UI.fs	9	3
2022-08 psakefile.ps1	3	3
2022-08 src/pocof/Library.fs	27	14
2022-09 psakefile.ps1	17	8
2022-09 README.md	18	2
2022-09 src/pocof/Action.fs	11	8
2022-09 src/pocof/Data.fs	18	18
2022-09 src/pocof/Library.fs	88	51
2022-09 src/pocof/pocof.fsproj	2	2
2022-09 src/pocof/pocof.psd1	15	15
2022-09 src/pocof/Query.fs	18	17
2022-09 src/pocof/UI.fs	8	12
2022-09 tests/pocof.Tests.ps1	38	12
2022-10 src/pocof/Library.fs	19	12
2022-10 src/pocof/pocof.fsproj	1	1
2022-10 src/pocof/pocof.psd1	1	1
2022-10 src/pocof/Query.fs	16	8
2022-10 src/pocof/UI.fs	6	4
2022-10 tests/pocof.Tests.ps1	26	1
2022-11 docs/Select-Pocof.md	58	26
2022-11 src/pocof/Action.fs	1	0
2022-11 src/pocof/Data.fs	29	0
2022-11 src/pocof/Library.fs	6	1
2022-11 src/pocof/pocof.dll-Help.xml	97	57
2022-11 src/pocof/pocof.fsproj	1	1
2022-11 src/pocof/pocof.psd1	1	1
2022-11 src/pocof/Query.fs	66	53
2022-11 src/pocof/UI.fs	0	1
2022-11 tests/pocof.Tests.ps1	106	30
2022-12 src/pocof/Data.fs	13	0
2022-12 src/pocof/Library.fs	23	9
2022-12 src/pocof/Query.fs	5	5
2022-12 src/pocof/UI.fs	16	5
2023-01 src/pocof/Action.fs	3	3
2023-01 src/pocof/Data.fs	204	154
2023-01 src/pocof/Library.fs	14	7
2023-01 src/pocof/Query.fs	124	50
2023-01 src/pocof/UI.fs	13	31
2023-02 docs/Select-Pocof.md	21	5
2023-02 src/pocof/Action.fs	9	4
2023-02 src/pocof/Data.fs	21	14
2023-02 src/pocof/Library.fs	22	11
2023-02 src/pocof/pocof.dll-Help.xml	23	0
2023-02 src/pocof/pocof.fsproj	1	1
2023-02 src/pocof/pocof.psd1	1	1
2023-02 src/pocof/Query.fs	18	12
2023-02 src/pocof/UI.fs	17	25
2023-02 tests/pocof.Tests.ps1	81	70
2023-03 .gitignore	1	0
2023-03 pocof.sln	8	1
2023-03 psakefile.ps1	17	7
2023-03 src/pocof.Test/pocof.Test.fsproj	36	1
2023-03 src/pocof.Test/PocofAction.fs	113	0
2023-03 src/pocof.Test/PocofData.fs	530	2
2023-03 src/pocof.Test/PocofQuery.fs	404	118
2023-03 src/pocof.Test/Program.fs	4	0
2023-03 src/pocof.Test/Tests.fs	798	798
2023-03 src/pocof/Action.fs	161	91
2023-03 src/pocof/Data.fs	81	112
2023-03 src/pocof/Library.fs	2	2
2023-03 src/pocof/Query.fs	7	2
2023-03 tests/pocof.Tests.ps1	1	0
2023-04 .github/workflows/pr.yml	30	1
2023-04 psakefile.ps1	7	0
2023-04 src/pocof.Test/PocofAction.fs	58	23
2023-04 src/pocof.Test/PocofData.fs	175	143
2023-04 src/pocof.Test/PocofQuery.fs	55	13
2023-04 src/pocof/Action.fs	38	27
2023-04 src/pocof/Data.fs	55	42
2023-04 src/pocof/Library.fs	55	46
2023-04 src/pocof/Query.fs	53	63
2023-04 src/pocof/UI.fs	7	12
2023-04 tests/pocof.Tests.ps1	4	0

2 年目も細々と開発を続けていく。他にやることで Fable でブログ再構築する際の調べ物あるけど、直感ではそんなに失速しないんじゃないかなという気がしている(気だけかも)。

F#でコマンドレットを書いてる pt.19

Sun, 16 Apr 2023 09:00:00 +0900

本当は Fable のメモを記録したかった。 Fable の練習を始めようと思って Fable · Start a new project を参考にプロジェクトを作成(以下)した。

dotnet new fable --name krymtkts.github.io

その後作成されたプロジェクトを VS Code で開いたら OOM で VS Code がお亡くなりになったので、また今度やるか...という気持ちに切り替わってしまった。

閑話休題。

また krymtkts/pocof の話。

もう 2023-04 も半ばを過ぎ、前回の pocof 0.4.0-alpha から 2 ヶ月経とうとしてるが、粛々とテスト追加と書き直しをしている。

以前 GitHub Actions の Workflow を作成した時に、 ubuntu_latest つまり非 Windows でも Pester のテストが問題なく緑になるんだなというのがわかった。これを機に OS の build matrix を組んで Windows, Linux, Mac の 3 つのプラットフォームのテストを有効にしてみた。 #48

すべてのプラットフォームでテストが成功したのを見て、 .NET 良く出来てるなあと思った(小並感)。とはいえ実際に PowerShell on Ubuntu でインタラクティブな動作テストしたわけじゃないし、 .NET はキー周りが大変だと聞く。わたしが持っているこの辺の知識はこれしかないけど → Console.ReadKey improvements in .NET 7 - .NET Blog

なので、いつか時間を取って人力で確認しないといけないのではと思っている。実際問題、例えば Ubuntu に PowerShell 入れるのって相当動機づけされてないとやらなそうなのだけど、機が熟しつつある。良いのか悪いのかは知らん。ただ面白そうではある。

pocof の機能追加はやってなくて、 CLI の UI をいじるところ以外はテストも揃ってきたので、リファクタリングと称して主に構造変換をそれほど伴わない書き直しをしている。 #49

pocof は PowerShell で書かれた poco を F# で写経するところから始まっているので、あまり F# ぽくない感じの箇所が多々ある。その環境の中にコードを足していってるので周りに引きづられて F# ぽくない部分も多かった。

それらは例えば string じゃなくて ToString メソッドを使ってるとか、一番気になってたのは conditional expression の if をいっぱい使ってた点。別に if の方が短く済むときもあるし使っても構わんのだけど、式としてじゃなくて制御構文として使ったときの else が必須じゃないのが気になってた。また match expression と違って網羅できてるか人目でわからないのが一番心配で、結局これらを match ... with で書き直すことにした。その結果、一部には active pattern も利用したりして、パッと見わかりやすくなった気がする。

if ... then を match ... with に書き換えたら以下のようになって、 true がなんか判然とせんなーという気は多少あるので、自前のロジックに関しては判別共用体に直すとか検討するとより良いのかも知れん。

// before
if nanigashi x then
    Some(x)
else
    None

// after
match nanigashi x with
| true -> Some(x) // この true ってのもなーんか気に食わん
| _ ->  None

こういうところにも active pattern を積極的に使っていったら良いのかもやけど、今回はまだ使わなかった。データの変換・分解を伴うようなパターンだとバッチリハマった感じだったが、単純なケースに使うと記述量だけ増えて表現力変わらないなとい感触だったため(書き方がまずいのか)。とはいえ積極的に使いたいものではあった。

コードの見通しも良くなってきて、そろそろ積み残しタスクにも着手しやすくなってきた感じがする。次やるとしたら #35 あたりかな。

でもテスト追加とリファクタリングはまだやりたいところが残っていて、悩ましい。 UI のテストを入れて置きたいのと、 PocofQuery をシンプルにするのと、 Library.fs から極力ロジックを引き剥がす点だ。なんかダルそうだなというのもあって手が出しにくいので、積み残しタスク減らしてからやると気分転換になるのかも知れん。

F#でコマンドレットを書いてる pt.18

Sun, 09 Apr 2023 09:00:00 +0900

krymtkts/pocof の話。

PocofQuery.run のテストをそれなりに足した。多少テストが増えてきたので CI が欲しくなってきた。ここで以前立てた Issue #34 を回収しておくとことにした。

Issue にも書いてたけど、基本 GitHub Docs に書いてたやつをなぞるだけ。

runner image は今の開発環境に合わせて windows-latest にしておく。 pocof 自体は今後他の OS でも動くことを保証してみたいけど、最初なのでシンプルにいく。この記事を書いた時点の windows-latest に含まれるツール類は以下を参照した。

runner-images/Windows2022-Readme.md at main · actions/runner-images · GitHub

dotnet のセットアップは必須のよう。 pocof はまだ 6 なのでそれを使う。

PowerShell はデフォで 7.2.10 が入ってるらしい。いろんなバージョンで動くことをチェックするのであれば PowerShell の version で matrix 組むのが妥当だが、これも最初なので簡単に。

pocof のテストに必要な PowerShell モジュール Pester, PSScriptAnalyzer あたりも入ってるが、肝心の psake が入ってない。ならば workflow で全部ひっくるめで force install するようにしておく。このへんも PSDepend を使うようにしておけば YAML にかき分ける必要もないし良さげか。

ここまでやれば psakefile.ps1 に書いた全テストタスクを実行すれば完了する。キャッシュあった方が速いだろうけど、そもそもそんなに時間かからんので対応しないでおく。

あと一番重要な GitHub Actions の YAML のファイル名と名前の部分、結構いろんな repo みても付け方がバラバラでイケてるパクリ元がない。ここは GitHub の Pull Request や Actions の画面で見られることを考えてない名称は避けたかった。最終的に、 FSharp.Formatting の命名規則が気に入ったのでそれを模した。ファイル名は pull-requests.yml を短縮して pr.yml で、名前は Build and Test on Pull Request だ。これなら GitHub の画面で見ても自然だ。

出来上がった素朴な YAML はこちら。 pocof/pr.yml

name: Build and Test on Pull Request

on:
  pull_request:
    branches: ["main"]

jobs:
  test:
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup .NET
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: 6.0.x
      - name: Install modules from PSGallery
        shell: pwsh
        run: |
          Set-PSRepository PSGallery -InstallationPolicy Trusted
          Install-Module Psake,Pester,PSScriptAnalyzer -Scope CurrentUser -Force
      - name: Execute All Tests
        shell: pwsh
        run: Invoke-Psake -taskList TestAll

GitHub Actions の難点としてテストしにくい点があるが、nektos/act を使えば ubuntu-* の runner に限ればテストできる。仕事では act を使ってるが自機には積んでなかったんで、この際に Chocolaty で入れた。

choco install act-cli

ではテストとばかりに windows-latest を ubuntu-latest に変えて実行する。

PS> act pull_request --verbose --platform windows-latest=catthehacker/ubuntu:act-latest
# ...省略
| OCI runtime exec failed: exec failed: unable to start container process: exec: "pwsh": executable file not found in $PATH: unknown
# ...省略
Error: Job 'test' failed

なん...だと... pwsh コマンドが無いと言われた... act のセットアップ時に MEDIUM 選んだらどうも入ってないっぽい。流石は minority の PowerShell 、参ったね。

しかし act が使うイメージを見てたら pwsh というキーワード付きの image があるじゃないの。 catthehacker/docker_images: Docker images

/linux/ubuntu/pwsh - ghcr.io/catthehacker/ubuntu:act-* but with pwsh tools and modules installed

こりゃきたな。試す。

PS> act pull_request --verbose --platform windows-latest=ghcr.io/catthehacker/ubuntu:pwsh-latest
# ...省略
[Build and Test on Pull Request/test] 🏁  Job succeeded

おーいけた。 6 分超かかったけど。これでなんとか PowerShell の場合でもローカルテストできそう。 Docker Hub に同じイメージ catthehacker/ubuntu:pwsh-latest あったので、これを使っていこう。

act pull_request --verbose --platform windows-latest=catthehacker/ubuntu:pwsh-latest

...でもいちいちこのクソながオプション書きたく無いなあ...設定ファイルとかはなさそう。関数にするか psake のタスクにするしかないか。なんか大げさな気がするけど。

そんなこんなで #45 を作れた。 matrix はまだ設定してないけど、少なくともテスト類は ubuntu でも動くことわかったし、追々対応していく。

おまけ。

DockerDesktop でログインしてると、 act 実行中にある DockerHub から catthehacker/ubuntu:act-latest を pull するのができなかった。ログアウトしてるといける。↓ このへんの関係ぽいが深く追ってない。

m1: act fails to pull with unauthorized: incorrect username or password · nektos/act · Discussion #1165

あとなんか知らんが act 実行後に [45;3R って謎キーワードが terminal の input に出てくる、必ず。 ansi escape sequences ぽいけどよくわからん。

PowerShell で OAuth して Google Sheet を CSV で DL する

Sun, 02 Apr 2023 09:00:00 +0900

最近役目を終えたスクリプトに、 Google Sheet を CSV でダウンロードするやつがいた。考慮不足等、諸々至らぬ点あろうが、スクリプトを供養するため日記にする。

モジュール導入したくないなーという事情があったので、下記を見てヒイヒイ言いながら実装した記憶がある。「Google Sheet から CSV をダウンロードする」には https://www.googleapis.com/auth/drive のスコープがいるみたい。てっきりスプシのスコープと勘違いして、無駄に時間かかった。

スクリプトは Gist に登録しておいた。それに伴い Comment-Based Help を書いたり、関数の名前を変えたりした。Google Sheets ってサービス名に対してスプシ自体は spreadsheet だったりしてマジでややこしい。

GoogleSpreadSheetOAuth.ps1

<#
.SYNOPSIS
Download Google Sheet as CSV.
.DESCRIPTION
Download Google Sheet as CSV using GCP OAuth Client.
.PARAMETER OAuthClientSecretsPath
The path to the JSON file for the OAuth 2.0 Client Secrets created on GCP.
.PARAMETER OAuthStorePath
The path to save authentication tokens.
.EXAMPLE
. ./GoogleSheetsOAuth.ps1 `
    -OAuthClientSecretsPath './client-secrets.json' `
    -OAuthStorePath './gss-credential'
Get-GoogleSpreadSheetAsCsv `
    -SpreadSheet 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' `
    -SheetId '000000000' `
    -OutFile './test.csv'
#>
[CmdletBinding()]
param (
    [Parameter(Mandatory)]
    [string]
    $OAuthClientSecretsPath,
    [Parameter(Mandatory)]
    [string]
    $OAuthStorePath
)

class OAuthCredentialStore {
    [SecureString] $AccessToken
    [SecureString] $RefreshToken
    OAuthCredentialStore(
        [SecureString] $AccessToken,
        [SecureString] $RefreshToken
    ) {
        $this.AccessToken = $AccessToken
        $this.RefreshToken = $RefreshToken
    }
}

$script:OAuthCredential = $null

function Get-GoogleSheetsAuthInitToken {
    [CmdletBinding(SupportsShouldProcess)]
    param ()

    if (-not (Split-Path $OAuthStorePath -Parent | Test-Path)) {
        throw "${OAuthStorePath} not found."
    }

    if (-not (Test-Path $OAuthClientSecretsPath)) {
        throw "${OAuthClientSecretsPath} not found."
    }
    $secrets = Get-Content $OAuthClientSecretsPath | ConvertFrom-Json | Select-Object -ExpandProperty installed

    $Scope = [System.Web.HttpUtility]::UrlEncode('https://www.googleapis.com/auth/drive')
    $ClientID = $secrets.client_id
    $ClientSecret = $secrets.client_secret
    $RedirectUri = $secrets.redirect_uris[0]
    $Uri = "https://accounts.google.com/o/oauth2/v2/auth?response_type=code&client_id=${ClientID}&redirect_uri=${RedirectUri}&scope=${Scope}&access_type=offline"

    Start-Process $Uri
    $AuthorizationCode = Read-Host 'paste auth code here!'

    $AuthData = @{
        code = $AuthorizationCode;
        client_id = $ClientID;
        client_secret = $ClientSecret;
        redirect_uri = $RedirectUri;
        grant_type = 'authorization_code';
        access_type = 'offline';
    }

    Write-Host 'try to get access token...'
    $TokenResponse = Invoke-RestMethod -Method Post -Uri 'https://www.googleapis.com/oauth2/v4/token' -Body $AuthData
    if (-not $?) {
        throw 'request failed.'
    }

    Write-Host 'done.'

    $script:OAuthCredential = [OAuthCredentialStore]::new(
        ($TokenResponse.access_token | ConvertTo-SecureString -AsPlainText),
        ($TokenResponse.refresh_token | ConvertTo-SecureString -AsPlainText)
    )

    $store = @{
        AccessToken = $OAuthCredential.AccessToken | ConvertFrom-SecureString;
        RefreshToken = $OAuthCredential.RefreshToken | ConvertFrom-SecureString;
    }

    if ($PSCmdlet.ShouldProcess($OAuthStorePath)) {
        New-Item -Path $OAuthStorePath -Force | Out-Null
        $store | ConvertTo-Json -Compress | Set-Content -Path $OAuthStorePath -Force
    }

    $OAuthCredential.AccessToken, $OAuthCredential.RefreshToken
}

function Get-GoogleSheetsAuthToken {
    [CmdletBinding(SupportsShouldProcess)]
    param ()
    Write-Verbose "$OAuthStorePath"
    $content = Get-Content -Path $OAuthStorePath -ErrorAction Ignore
    if ([String]::IsNullOrEmpty($content)) {
        $token, $_ = Get-GoogleSheetsAuthInitToken
        return $token
    }
    try {
        $cred = $content | ConvertFrom-Json
        $script:OAuthCredential = [OAuthCredentialStore]::new(
            ($cred.AccessToken | ConvertTo-SecureString),
            ($cred.RefreshToken | ConvertTo-SecureString)
        )
    }
    catch {
        throw 'Invalid SecureString stored for this module. Remove gs-credential and try again.'
    }
    $RefreshToken = $script:OAuthCredential.RefreshToken | ConvertFrom-SecureString -AsPlainText
    if (-not $RefreshToken) {
        $token, $_ = Get-GoogleSheetsAuthInitToken
        return $token
    }

    $secrets = Get-Content $OAuthClientSecretsPath | ConvertFrom-Json | Select-Object -ExpandProperty installed
    $RefreshData = @{
        refresh_token = $RefreshToken
        client_id = $secrets.client_id
        client_secret = $secrets.client_secret
        grant_type = 'refresh_token'
        access_type = 'offline'
    }

    $Response = Invoke-RestMethod -Method Post -Uri 'https://www.googleapis.com/oauth2/v4/token' -Body $RefreshData
    if (-not $?) {
        throw 'request failed.'
    }

    return $Response.access_token | ConvertTo-SecureString -AsPlainText
}

function Get-GoogleSpreadSheetAsCsv {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory)]
        [String]
        $SpreadSheet,
        [Parameter(Mandatory)]
        [String]
        $SheetId,
        [Parameter(Mandatory)]
        [String]
        $OutFile
    )

    $accessToken, $refreshToken = Get-GoogleSheetsAuthToken
    if (-not $?) {
        return
    }

    $Params = @{
        Uri = "https://docs.google.com/spreadsheets/d/$SpreadSheet/gviz/tq?tqx=out:csv&gid=$($_.SheetId)"
        Method = 'GET'
        Authentication = 'Bearer'
        Token = $accessToken
        OutFile = $ExecutionContext.SessionState.Path.GetUnresolvedProviderPathFromPSPath($OutFile)
    }
    Invoke-WebRequest @Params | Out-Null
}

このスクリプトでは認証コードを得るのに手でコピってる。これを System.Net.HttpListener で自鯖を立てて取る方式にしたかったけど、コピペするのは初回だけだし放置してたらそのままスクリプトの寿命が来てしまった。自動で認証コードを得る方式は以前ググってそれっぽいの見つけてたはずだが、 URL を失念してしまった。今なら ChatGPT サンにお願いしたら書いてくれそうな雰囲気するなと思い試したらそれっぽいのが出たが、 OAuth client の Redirect URL を変えるのが手間で検証しなかった。怠けてる。次にやる機会が来るその日まで、自鯖で認証コード取る方式は寝かせておく(やる日は来るのか)。

F#でコマンドレットを書いてる pt.17

Sun, 26 Mar 2023 09:00:00 +0900

krymtkts/pocof の話。

もう 4 月なのでそろそろ Fable Compiler を試してみたいと思ってるが、 pocof のテスト書くのと bugfix が落ち着かず、できていない。ちょっと今までのテストを小綺麗にする作業にも取り組んだ。

前回、 module を多層化することでテストケースをグルーピングしている話を書いた。その時はテストケースを 1 つのファイルにまとめて書いていたのだけど、 PocofQuery.run のテストを書き始めるにあたり、テストケースが爆増するのに備えてファイルを分割したいと思っていた。

はじめ F# ではどうテストプロジェクトのファイル分割をするのかわからなかったが、 F# の repo をいくつか参照してみて fsprojects/FSharp.Data.Adaptive が参考になりそうとわかった。それを pocof に提供したところ、上手く分割できた。要は普通の F# Project と同じようにするだけだった。コミットは krymtkts/pocof@dff10c8 。

FSharp.Data.Adaptive/src/Test/FSharp.Data.Adaptive.Tests がテストプロジェクトのディレクトリ。ここに分割されたテストコードのファイルが色々あるのと、テストプロジェクトのエントリポイントになる Program.fs が配置されている。プロジェクト FSharp.Data.Adaptive.Tests.fsproj を参照するとエントリポイント Program.fs が最後の読み込みなっているのがわかる。それ以前のファイルにモジュールを小分けにしたテストを書いたら良い。

ファイル分割の粒度はモジュール別に 1 ファイルした。あまり細かく分けると何処にテストを書くか悩みがちなので、シンプルにモジュールと対にしている。複雑なクエリのテストを書くとまた量が増えて更にファイルを分割したくなるだろうが、今ではない。

ひとまず満足な形に分解できたのでヨシ。

あとこの fsprojects/FSharp.Data.Adaptive を参考にしたとき気づいたのだけど、 FsCheck というモジュールを使ってるようだった。 Property-based Testing をするためのやつだ(今書いてるのは所謂「おなじみ」の Example-based Testing という)。 The 'Property Based Testing' series | F# for fun and profit が参考になった。

実際 pocof でもテストケースが貧弱で、テストは成功するがバグってたようなケースがもちらほらあるので、こういうより強力な方法を使うのが良いかもなーと興味深く思っている。とはいえ興味の範囲で無限にやること増えていく。かなりやってみたいのだけど、キャッチアップのほうが追いついてない感じ。

まずは所謂「おなじみ」の Example-based Testing である程度カバーしてから、 FsCheck で強化するってステップを踏むのが良さげ。徐々に... ひとまず今ある draft の pull request を merge してから、今後どう取り組んでいくか考えよかな(タスクを未来にブン投げる)。

F#でコマンドレットを書いてる pt.16

Sun, 19 Mar 2023 09:00:00 +0900

krymtkts/pocof の話。

FsUnit x xUnit を使ったテストコード追加とリファクタはまだ続けていて、前回から引き続きバグがもりもり見つかる。 PocofData.invokeAction はアクションに対応づいた各ロジックを呼び出して、内部状態を担うレコードを変更して返すだけの処理だけど、油断ならん。 #39, #40

まだ合計時間にしたら 10 時間も FsUnit(というか FsUnitTyped) 使ってないし、なんなら shouldEqual と shouldFail くらいしか使ってない。けど、手になじんできた気がする。

shouldEqual 使っていて良いのは、型間違うことがないところ(当たり前すぎるか)。

should の関数シグネチャがこう obj になってる。

let inline should (f: 'a -> ^b) x (actual: obj) =

片や shouldEqualはジェネリックになってる。

    let shouldEqual<'a> (expected: 'a) (actual: 'a) =

当然ながらその分テストを書くときに楽ができる。実際には以下のような一見して間違いがわかる派手な例はないだろうけど。テストコードのバグも有り得るので、とにかく安全な方に激ぶりしてかつ楽ができるのは、良い。

"a" |> should equal 1 // エラーじゃない。
"a" |> shouldEqual 1 // 型不一致のエラー。良い。

あとは、パイプ演算子のお陰で「英文ぽい」順番で記述できるのも良い。ただこの文脈でいえば、FsUnit の見た目に分がある。 should と equal 等分かち書きできるからな。

actual |> shouldEqual expected
actual |> should equal expected // <- 見た目とても良いけど型検査できなくて片手落ち。

OOP なんかでも test(actual).shouldEqual(expected) みたいな形式なら同じ感覚だろうけど、個人的にカッコがなくより自然(Lisper みたいに熟達すればカッコが透けて見える可能性もあろうが)。

とはいえ良いこと尽くめではない。ちょっと困ったのはテストのグループ化。例えば同じ関数に対するテストとか、関連あるグループをまとめたら平置きじゃない分だけ注力スべきコードが絞られて見やすくなるので、個人的には積極的にグループ化する。

FsUnit というか xUnit だと、 F# ではこんな感じに module を多層化するか module と type を使うか 2 通りの手法があるみたい。以下にその 2 通りのテストコードもどき。

module Tests

// module と type。
module ``PocofAction Tests`` =
    type ``toKeyPattern should returns`` () =
        [<Fact>]
        member x.``A without modifiers.`` () = // 以下略。

// module 多層化。
module ``PocofAction Tests`` =
    module ``toKeyPattern should returns`` =
        [<Fact>]
        let ``A without modifiers.`` () = // 以下略。

pocof ではまだテストで状態を持つことないのと、単にカッコや自己識別子を書く回数が減るってだけで module で多層化してる。

まあここまでは良い。これを dotnet test --list-tests したときにでるテストケースごとの名称のつなぎ方？が気に入らなくて、なんとかならんのかなと思ってる。先述の例の場合だと、 Tests+PocofAction Tests+toKeyPattern shoud returns.A without modifiers. のようなテストケース名になる。これ + とか . とかどうにかならんのかな。理想は whitespace で繋いでほしい。単に制御可能でその設定方法を知らないだけという可能性もあるので、追って調べたい。

多少気に入らないところを愚痴ったが、概ね満足している。今後もテストを足していってもりもりバグを洗い出す。かなーりテストコードに時間かかってる気がするけど、マイペースに。

F#でコマンドレットを書いてる pt.15

Sun, 12 Mar 2023 09:00:00 +0900

krymtkts/pocof の話。

前回困ってた Ionide 、理解が難しくあんまわかってないけどこれっぽい。 Test Explorer doesn't support tests with TestCaseAttribute · Issue #1756 · ionide/ionide-vscode-fsharp Subscribe して様子を見る。

FsUnit を使ったテストコード追加とリファクタをほそぼそと続けている。 #32, #37

テストをあとから書いてると、ケアレスミスの bug ポツポツ見つかる。わたしは練習不足なのかテストファーストどうしてもできないのであとがきでもいいかと思ってるが、こう bug が多いとちょっとドキッとする。 main branch へ merge する前にあとがきテストを添えるようにして減らそう。

いま簡単なところからテストを書いてるので、本丸である Query.fs のところを書けたらかなりいい感じ。 UI.fs に関してはどないしょ...という感じになってるけど。いま直で Console.Write へアクセスするような形になってるの、差し替え可能にしておいた方がいいんやろな。

また、 psakefile.ps1 にも unit test や coverage 用のタスクを追加した。というかそれ以外のタスクも見直す必要があった。というのも、 src ディレクトリ配下からビルド対象のプロジェクトを見つけるスクリプトが単一のプロジェクトしか想定してなかったので、そのまま使えなかったからだ。この度アプリとテストの 2 プロジェクトができたので、指定のプロジェクトのみ対象とするよう変更した。

まだ頻出ワードを変数にしておくとかの最適化してなかったり、タスクランナー自体小綺麗にできるんじゃないかなーというのはあるが、無闇に依存関係を増やすのもなと思って手を出せてない。 PowerShellBuild, PSDepend あたりの導入できれいになるかも知れんけど、なるべく依存関係をなくす方が結果的にシンプルなプロジェクトになるのを知ってるし。現時点でも psake PSScriptAnalyzer Pester PowerShellGet に依存してるから、四の五の言わずに PSDepend だけでもはよ入れろよという感じはある。だが、覚悟ができてからやる(先延ばし)。

おまけ

最近になって仕事でも AI チャットを使う流れがきており、練習がてら PowerShellAI と一緒に仕事し始めてみた。 VS Code Extension はちょっと種類が多すぎてどれが信頼できるかいちいち調べられてないし、やってない。上手く使えて、わたし・ Tabnine ・ OpenAI の三人力な感じを出せると良いが。ちょっと使ってみた感覚的に、仕事で使うような特定用途に特化した回答をさせたい時と普段遣いで雑に使う感じでは、 prompt に結構差がある感触。これほんま練習になるんかな。

にしても OpenAI の token がガリガリ消費されるのを見てると「ﾋｪｴ...」となる。

F#でコマンドレットを書いてる pt.14

Sun, 05 Mar 2023 09:00:00 +0900

krymtkts/pocof の話。

以下を参考に xUnit と FsUnit を導入した。

repo ルートを作業ディレクトリとする。

cd (mkdir pocof.Test)
dotnet new xunit -lang "F#"
dotnet add reference ../pocof/pocof.fsproj
dotnet sln ../../pocof.sln add .\pocof.Test.fsproj
cd ../../
dotnet build

一応ここでちゃんとテストできるか確認をする。Tests.fs のコードを単純なのに書き換える。

module Tests

open System
open Xunit

[<Fact>]
let ``My test`` () = Assert.True(true)

VS Code からでもよし、 CLI でなら repo のルートで以下の通り。

PS> dotnet test
  Determining projects to restore...
  All projects are up-to-date for restore.
  pocof -> C:\Users\takatoshi\dev\github.com\krymtkts\pocof\src\pocof\bin\Debug\net6.0\pocof.dll
C:\Users\takatoshi\dev\github.com\krymtkts\pocof\src\pocof.Test\Tests.fs(7,39): warning FS0988: Main module of program is empty: noth
ing will happen when it is run [C:\Users\takatoshi\dev\github.com\krymtkts\pocof\src\pocof.Test\pocof.Test.fsproj]
  pocof.Test -> C:\Users\takatoshi\dev\github.com\krymtkts\pocof\src\pocof.Test\bin\Debug\net6.0\pocof.Test.dll
Test run for C:\Users\takatoshi\dev\github.com\krymtkts\pocof\src\pocof.Test\bin\Debug\net6.0\pocof.Test.dll (.NETCoreApp,Version=v6.0)
Microsoft (R) Test Execution Command Line Tool Version 17.5.0 (x64)
Copyright (c) Microsoft Corporation.  All rights reserved.

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.

Passed!  - Failed:     0, Passed:     1, Skipped:     0, Total:     1, Duration: < 1 ms - pocof.Test.dll (net6.0)

あと dotnet new xunit -lang "F#" で生成された Program.fs は不要なので削除、 pocof.Text.fsproj からも削除する。

次に FsUnit を追加する。

dotnet add ./src/pocof.Test/pocof.Test.fsproj package FsUnit.xUnit

テストをこんな感じで書き換え、 dotnet test が成功したら完了。

 module Tests

-open System
 open Xunit
+open FsUnitTyped

-[<Fact>]
-let ``My test`` () = Assert.True(true)
+module ``Pocof Tests`` =
+
+    [<Fact>]
+    let ``Sample test should equals 1`` () = 1 |> shouldEqual 1
+
+[<EntryPoint>]
+let main argv = 0

"Main module of program is empty: nothing will happen when it is run" warning when running xunit tests on .net core. · Issue #2669 · dotnet/fsharp で知ったが、テストプロジェクトはコンソールアプリなので <EntryPoint> を必ず持たないと警告がでる。 xUnit 追加後シンプルにしたテストコードでは <EntryPoint> がなかったので警告が出てた。

ちょっとわからないのが VS Code からの実行だとハングしてるようだった。テストを実行するための DotNet CLI が後ろで実行されるみたいだが、そのプロセスは上手く行ってそうに見える。でも GUI がずっとくるくる止まる。どうも Inonide がエラーしてるっぽい。 xUnit の実行確認のときはいけたので FsUnit 起因か？ちょっと調べる必要ありだが、今回は先送りにする。

2023-03-04 15:50:47.005 [error] Error:
    at MapTreeModule_find (c:\Users\takatoshi\.vscode\extensions\ionide.ionide-fsharp-7.5.1\webpack:\out\fable_modules\fable-library.4.0.0-theta-018\Map.js:245:15)
    at FSharpMap__get_Item (c:\Users\takatoshi\.vscode\extensions\ionide.ionide-fsharp-7.5.1\webpack:\out\fable_modules\fable-library.4.0.0-theta-018\Map.js:1179:12)
    at f (c:\Users\takatoshi\.vscode\extensions\ionide.ionide-fsharp-7.5.1\webpack:\out\fable_modules\fable-library.4.0.0-theta-018\Map.js:1297:12)
    at Kt (c:\Users\takatoshi\.vscode\extensions\ionide.ionide-fsharp-7.5.1\webpack:\out\fable_modules\fable-library.4.0.0-theta-018\Array.js:70:21)
    at c:\Users\takatoshi\.vscode\extensions\ionide.ionide-fsharp-7.5.1\webpack:\out\Components\TestExplorer.js:138:27
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async Promise.all (index 0)

コードカバレッジは xUnit のテンプレなら初めから統合されてるらしくて、すぐ出せる。これはめちゃくちゃ楽。

dotnet test --collect:"XPlat Code Coverage"

こんな感じでレポート出力できる。出力しておいたら VS Code の Coverage Gutters で取り込めるしこりゃいいな。

reportgenerator -reports:".\src\pocof.Test\TestResults\*\coverage.cobertura.xml" -targetdir:"coverage" -reporttypes:Html

昔は Visual Studio からしか Solution とか作るしかなかったようなキヲクをがある(無能だっただけやも知れんが)。いまの DotNet CLI ある時代めちゃくちゃ便利でびっくりした。

あと FsUnit 非常によい。入力キーから処理を導くところのリファクタするのに役立っている。サクサク書けるし、バグってた状態で放置してるとこが見つかったり(#33)いまのところ良いことしか無い。

いい感じにテスト揃ってきたら、 GitHub Actions で FsUnit と Pester 実行するようにしよう。

F#でコマンドレットを書いてる pt.13

Sun, 26 Feb 2023 09:00:00 +0900

krymtkts/pocof の話。 pocof 0.4.0-alpha を公開した。

諸々の bugfix を主として行った。 #28 #25 #23 #21 #20 #18

修正自体は軽微だが、結構使っていてイヤーな感じをもたらす bug が多かったし、直して良かった。機能的なところでは入力中のプロパティ候補の表示非表示を切り替えるオプションを付与したのみに留まる。

正直なところプロパティの TAB 補完できてから公開したかったが、先送りにした。こいつをやるには内部的な状態を増やす必要があると思っていて、そのためにはリファクタリングをしてから着手する方が良い。要はリファクタリングしだすと、色々気になって手を入れてしまいズルズルとリリースを遅らせがちなので、切の良いタイミングで公開しておいたという算段だ。

増やす状態は、カーソルがクエリの分かち書きの何個目にいるか、単語の何文字目にいるとかを指す。 TAB 補完したときにクエリの書き換えとカーソル末尾への移動をするが、その計算にこれらの状態があると良い。今の実装だと単純にクエリ文字列と検索中のプロパティを保持しているだけなので、そこを小綺麗に整理した後にそれらを付与するようなイメージ。判別共用体を上手く使ってできる感覚を持っている。

ただしデータ構造の変更に伴いクエリ実行そのものも書き換える必要がある。前の日記でも触れてたように、やっぱこのタイミングで FsUnit 導入して動作保証しながらの開発は必須、避けられない。

話は逸れるが、FsUnit 使うに当たり .NET のテストライブラリを入れる必要があるのだけど、全然知らん。 What is FsUnit? を見るに xunit 、 nunit と MSTest がある。 FsUnit からはどれでも使えるけどそれぞれの推しどころわからず、どれを使えばいいかわからんというアレな状態。 GitHub の star 見るに xUnit が人気ぽいが、 fantomas は FsUnit と NUnit の組み合わせっぽかった。 FsUnit のドキュメント見てたら、強力な型付きの FsUnitTyped は NUnit か xUnit しかサポートしてないって書いてるし、なんとか二択までは絞れた...こっからがだるい。

話を戻して、クエリの内部状態以外にも判別共用体で書き直したい箇所があって、それは入力時のキー判定や今は文字列で保持しているキーマップだったりだ。キーマップの方は外部保存した設定ファイルを読み込む方式も検討したいのでハマるかわからんけど。入力時のキー判定の方は、いま if 式をこねくっているのもあって、パターンマッチング式に置き換えられるからハマるなという感覚がある。

また機能追加が滞りそうではあるが、あと 2 ヶ月ほどで pocof の initial commit から 1 年経つのもあり、掃除するにはちょうどいい頃合いではないかと。ちょっとは F# Ninja Level も上がったやろ。

AWS SSM Session Manager を PowerShell で

Sun, 19 Feb 2023 09:00:00 +0900

AWS SSM Session Manager を使って EC2 Instance とかに接続するやつがある。 AWS CLI であれば Session Mangger plugin¹ を入れておけば aws ssm start-session で SSH 感覚でつなげる。 Security Group に自分とこの外部 IP を含めなくていいし、最高のやつだ。

だが AWS Tools for PowerShell で対になる Start-SSMSessionは StartSession API の戻り値を返すだけ。 (公式回答なのか？) AWS dev サポの方が AWS Tools for PowerShell の Issue² にて Session Manager plugin に対応してなさそうなコメントしてる。また Session Manager plugin 自体、その本丸である WebSocket の URL やらをどのようにこねくり回して渡せばいいかが文書化されてない。

PowerShell では Session Manager 無理かな...半ば諦めていたところに、なんと Remote Desktop で繋げられたという記事を発見した。これはマジですごい。 Linux 上で aws ssm start-session を strace して解析したらしい。鬼テク。

Remote Access to Windows EC2 instances, the easy (and secure) way

解析結果から作成され接続確認された PowerShell モジュールが GitHub に公開されている。

EC2Access/EC2Access.psm1 at v1.0.0 · cloudsoft/EC2Access

元記事は RemoteDesktop を対象としているが、ぱっと見 SSH でも同様のことができそう。コミットが 1 年半くらい前なので Session Manager の API に変更がなければ、やけど。 Session Manager plugin にパラメータを渡す部分を参考に、接続を試行してみる。ライセンスは Apache License 2 なので無償利用・改変もヨシ。

試してみる。

まず AWS CLI の場合だが以下のような感じで使ってた。見やすさのために改行成分多く含んでいる。

Get-EC2Instance -Filter @{
    Name = 'tag:Name'
    Values = 'instance-name'
} | Select-Object -ExpandProperty Instances -First 1 | ForEach-Object {
    aws ssm start-session --target $_.InstanceId # ここを変えたいんや
}

これを一先ずこんな風に使えるような関数を作成してみてはどうか？(ForEach-Object 要らんが SSH は単発でつなぎたいし一先ず)。

Get-EC2Instance -Filter @{
    Name = 'tag:Name'
    Values = 'instance-name'
} | Select-Object -ExpandProperty Instances -First 1 | ForEach-Object {
    Start-SSMSshSession -Instance $_.InstanceId # こういう関数がほしい
}

先述の EC2Access.psm1 からコードを拝借する。 Start-SSMSession の戻り値をこねくる部分と、 Session Manager plugin を取り扱う箇所が対象だ。コメントも処理の解析に有用なのでそのまま残させていただく。

元コードは RemoteDesktop を対象にしているので、認証情報の作成、 port forwarding 、あと最後の接続の箇所だけ SSH 用に書き換える。

function Start-SSMSshSession {
    [CmdletBinding(SupportsShouldProcess)]
    param (
        [Parameter(Mandatory)]
        [ValidateNotNullOrEmpty()]
        [string]
        $InstanceId,
        [Parameter()]
        [ValidateNotNullOrEmpty()]
        [string]
        $Region = 'ap-northeast-1',
        [Parameter()]
        [ValidateNotNullOrEmpty()]
        [string]
        $SshUser = 'ec2-user',
        [Parameter(Mandatory)]
        [ValidateNotNullOrEmpty()]
        [string]
        $CertPath,
        [Parameter()]
        [int]
        $LocalPort = 10022
    )

    $PortForwardParams = @{ portNumber = (, '22'); localPortNumber = (, $LocalPort.ToString()) }
    $session = Start-SSMSession -Target $InstanceId -DocumentName 'AWS-StartPortForwardingSession' -Parameters $PortForwardParams

    # We now need to emulate awscli - it invokes session-manager-plugin with the new session information.
    # AWS Tools for PowerShell don't do this. Also some of the objects seem to look a bit different, and the
    # plugin is pernickety, so we have to jump through some hoops to get all the objects matching up as close
    # as we can.

    $SessionData = @{
        SessionId = $session.SessionID;
        StreamUrl = $session.StreamUrl;
        TokenValue = $session.TokenValue;
        ResponseMetadata = @{
            RequestId = $session.ResponseMetadata.RequestId;
            HTTPStatusCode = $session.HttpStatusCode;
            RetryAttempts = 0;
            HTTPHeaders = @{
                server = 'server';
                'content-type' = 'application/x-amz-json-1.1';
                'content-length' = $session.ContentLength;
                connection = 'keep-alive';
                'x-amzn-requestid' = $session.ResponseMetadata.RequestId;
            }
        }
    }

    $RequestData = @{
        Target = $InstanceId;
        DocumentName = 'AWS-StartPortForwardingSession';
        Parameters = $PortForwardParams
    }

    $Arguments = (
        (ConvertTo-Json $SessionData -Compress),
        $Region,
        'StartSession',
        '',
        (ConvertTo-Json $RequestData -Compress),
        "https://ssm.$($Region).amazonaws.com"
    )

    # Now we have to do some PowerShell hacking. Start-Process takes an array of arguments, which is great,
    # but it doesn't actually do what we expect it to - see https://github.com/PowerShell/PowerShell/issues/5576.
    # So instead we have to turn it into an escaped string ourselves...
    $EscapedArguments = $Arguments | ForEach-Object { $escaped = $_ -replace "`"", "\`""; "`"$($escaped)`"" }
    $ArgumentString = $EscapedArguments -join ' '

    # Start the Session Manager plugin:
    if ($PSCmdlet.ShouldProcess($session.SessionId, 'Start Session Manager plugin')) {
        try {
            $Process = Start-Process -FilePath 'session-manager-plugin.exe' -ArgumentList $ArgumentString -NoNewWindow -PassThru
        }
        catch {
            Write-Error 'Unable to start the process session-manager-plugin.exe. Have you installed the Session Manager Plugin as described in https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html#install-plugin-windows ?'
            exit
        }

        # Wait a moment for it to connect to the session and open up the local ports
        Start-Sleep -Seconds 1

        # The port should be open now - let's connect
        if ($PSCmdlet.ShouldProcess($InstanceId, 'Start SSH client')) {
            ssh "${SshUser}@127.0.0.1" -p $LocalPort -i $CertPath
        }

        # Once the ssh session has finished, kill the session manager plugin
        $Process.Kill()
    }
}

aws ssm start-session だと ssm-user でつなぐことになるが、自前で接続する場合このユーザの認証情報がわからなかった。代わりに ec2-user を使い、合わせて鍵も渡すようにした。結果、当初の想定よりパラメータが増えてしまうが、致し方なし。

できたら試す。 IP 等の一部の情報は伏せ字とする。

PS> Get-EC2Instance -Filter @{
>     Name = 'tag:Name'
>     Values = 'instance-name'
> } | Select-Object -ExpandProperty Instances -First 1 | ForEach-Object {
>     Start-SSMSshSession -InstanceId $_.InstanceId -CertPath ~/.ssh/instance-name.pem
> }

Starting session with SessionId: krymtkts-031e957031cdcb25c
Port 10022 opened for sessionId krymtkts-031e957031cdcb25c.
Waiting for connections...

Connection accepted for session [krymtkts-031e957031cdcb25c]
Last login: Sun Feb 19 06:09:45 2023 from localhost

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/
22 package(s) needed for security, out of 22 available
Run "sudo yum update" to apply all updates.
[ec2-user@ip-xxx-xxx-xxx-xxx ~]$ exit
logout
Connection to 127.0.0.1 closed.

見事つなげる事ができた。すーご。

非公式とはいえ、 AWS CLI だけでしかできかなったことが PowerShell でもできるというのがわかるのは、一ユーザとして喜ばしいこっちゃな。元記事の Great work に感謝やな。

(Optional) Install the Session Manager plugin for the AWS CLI - AWS Systems Manager 入れておけばというか入れてないと無理 ↩
Support for interactive Start-SSMSession · Issue #283 · aws/aws-tools-for-powershell で(AWS Tools for PowerShell は)外部プログラムに依存できないし、 Session Manager plugin は AWS CLI 専用て言ってる ↩

Windows 11 の表示言語を完全に英語にする

Sun, 12 Feb 2023 09:00:00 +0900

Windows 10 からデフォルト言語が日本の状態の PC でも表示言語を変えられる。極力英語 UI を使うようにしているのもあって、今の Razer Blade Stealth を買ったころから英語表示で利用している。 Windows 11 にアップグレードしてからも同じだ。

設定自体は、ここに書いてる方法で表示言語を日本語から英語に変えられる。 Manage the input and display language settings in Windows - Microsoft Support

あと重要なのが、 Time & Language → Language & region のところの Preferred languages の順番。ここでちゃんと先頭を英語にしておかないといけない。例えば PowerToys や Windows Terminal といったツール。これらは最優先される言語でコマンドパレットや UI を表示したりする仕組みになってるようで¹、日本語を最優先にしていると部分的に表示言語が日本語になり、使いにくいことこの上なくなる。これに従うとデフォルトのキーボードが英語になるデメリットがあるが、インスタントに切り替えられない UI の方を尊重して、起動後は毎回 Win + Space で英語 → 日本語に切り替えている。

こんな感じでちまちま英語 UI を使えるように調整していたのだけど、最近困った事が起こった。ここ数ヶ月のどっかの Windows Update のタイミング以降、ログイン画面やシャットダウン・再起動時の表示言語が日本語になる事象が発生した。先述の表示言語の設定で、英語 → 日本語としたあとで再起動後また英語にするとか、色々やっても解消しないので何なんや...と思っていた。

ついに先日、その解消方法を見つけた。しかも身近な Time & Language → Language & region の中にある。たまたまポチっては画面を眺めてを繰り返していたときに見つけた。

Administrative language settings だ。

キーワードさえわかればこのように類似ケースを探すのも容易い。でも Microsoft の文書がヒットしないのはなんでや... How to change system language on Windows 11 | Windows Central

ここ 2 つのセクションがあって、両方を英語に変えた。

Welcome screen and new user accounts
Language for non-Unicode programs

1 では Current user から Welcome screen, New user accounts の 2 つの言語設定に設定をコピーできて、その内の Welcome screen の言語設定がログイン画面に効いた様子。また英語表示が戻ってきて、うれしい。更に、 Windows Update 後に足した覚えのないキーボードが復活する現象にも悩まされていた。 New user accounts にその足した覚えのないキーボードが割あたってたので、多分犯人はこいつ。これも解消できそう。

2 の方は何に効いてるのかわからん。 non-Unicode なアプリがあったらわかるんかな。

手順がわかってしまえば、もしまた表示言語が日本語に戻ったとしても、この設定をやり直せば良いので安心できる。理想はスクリプト化しておきたいが、まだ Registry の該当箇所を調べてない。

という具体で久しぶりのフル英語表示にできて満足した。

要出典。昔 Windows Terminal にコマンドパレットが導入されたときにそんな Issue を見たが忘れた。 ↩

F#でコマンドレットを書いてる pt.12

Sun, 05 Feb 2023 09:00:00 +0900

krymtkts/pocof の話。

プロパティ指定検索をおおむね実装できて、バグ取りに勤しんでいる。バグ取りしたので割とまともに動いてるな～という感じ。

また、 Ctrl+Space で入力候補の表示非表示切り替え、プロパティ名の自動補完もやりたいけど、 Pull Request がずっと開きっぱなしで締まりがないし別の Issue に切り分けた。 #19, #20

一旦プロパティ指定検索が完成したら main branch に合流する。

手が空いた時しか趣味プロやらないので、小分けにして取り組まないと何やってたかわからなくなる。これは今回デカめの feature にしてしまったことで当初の予定より大幅に長く開発してる。もっと小気味好いリズムを刻みたいので反省点として次に活かす。

...という計画で進めているのでテストケースを書いてたら、エグいバグに気づいた。これ PSCustomObject 利用した際に描画できないし、何なら戻り値が破壊される。やば。

ちょうどプロパティ指定検索でテストケースを書くときに PSCustomObject 使ってたら、期待の通り動かず、気づいた。このままやとテスト書けへんやん。

ちょっとショッキングなバグだったので初めからか？いつからか？と混乱したが、よくよく考えると普段自分で作った PSCustomObject に対してインタラクティブな絞り込みやってないわ...と気づいた。なんで使ってなかったのか？自分で定義するからインタラクティブに調べるほどでもなかったからか。普段使ってない＆テストザルで見落としてたのか～かっこ悪う...

とりあえず最低限の原因調査として、PowerShell Gallery から pocof の旧版をインストールしテストしたところ、 hahstable をサポートした pocof 0.2.0-alpha でぶっ壊れた模様。 PSObject の wrapping を引き剥がすあたりでやってもーてそう。

再現コード。

$a = [pscustomobject]@{'a'=1;'b'=2}
$a

# a b
# - -
# 1 2

$b = $a | pocof -NonInteractive
$b

# 虚無が出力される。

なんか NoteProperty が吹っ飛んでるっぽいのよね。

$a.psobject.Members | ? -Property MemberType -eq NoteProperty | Format-list

# MemberType      : NoteProperty
# IsSettable      : True
# IsGettable      : True
# Value           : 1
# TypeNameOfValue : System.Int32
# Name            : a
# IsInstance      : True
#
# MemberType      : NoteProperty
# IsSettable      : True
# IsGettable      : True
# Value           : 2
# TypeNameOfValue : System.Int32
# Name            : b
# IsInstance      : True

$b.psobject.Members | ? -Property MemberType -eq NoteProperty | Format-list

# 無

このままだとプロパティ指定検索のテストが書けないので、この bugfix を優先する。 Issue 立てた。 not work with PSCustomObject · Issue #21 · krymtkts/pocof

テストに関してももうちょい強化が必要かもな。今のところ Pester で書いてる E2E テストのみなのだけど、 PSCustomObject 使ったケースなかったし。

コード自体もグチャァ...としてきたから FsUnit 導入してもう少し丁寧にやったほうが良さげ。 pocof 書き始めた頃に「可能な限りテストを書きたい所存」て書いてたけど有言不実行になってて笑える(笑えない)。

cvs2git にまつわるアレコレ

Sun, 29 Jan 2023 09:00:00 +0900

ちょっとだけ CVS から Git に変換するときの事がわかった。

先日の日記にも追記したが、 remote repo の本体にファイルアクセスできないと使えない。それはつまり repo 所有者じゃないと git repo への変換ができないんだ。もうこれだけで、自分で手を動かしてどうこうする計画は終了やなというところだが、なんか調べたことを供養するために記しておく。

cvs2svn は今や GitHub repo を残すのみ。多くのドキュメントに参照されているであろう http://cvs2svn.tigris.org/ はもう閉鎖されている。 mhagger/cvs2svn: Migrate CVS repositories to Subversion or Git. This site supersedes the old tigris.org site, which has shut down.

で、この GitHub repo に cvs2git 含む cvs2svn を動かすための Dockerfile もある。わたしはそれを知る前に、 Ubuntu 18 であればパッケージが提供されてるのを知ったのでとりあえずそれを使う Dockerfile を書いたのだけど、本家を使う方が良いだろう。

書いた Dockerfile の repo は供養のため public にした。krymtkts/ubuntu-cvs2git

更に、 PowerShell でこの Docker image をビルドし実行するにあたって、どうでもいい気付きを得た。

PowerShell で Docker の --mount オプションを使う場合は、オブションに渡すパラメータ全体を文字列にしてやる必要があった。昔は --volume 使ってたし、ビルド関係は COPY で済ますし、何なら最近触ってなかったから気づきになって良かったわ。

Bind mounts | Docker Documentation には bash かなんかの shell の例があるが、これは PowerShell では NG 。

 docker run -d \
  -it \
  --name devtest \
  --mount type=bind,source="$(pwd)"/target,target=/app \
  nginx:latest

PowerShell の流儀に従えばこうなる。

docker run -d `
  -it `
  --name devtest `
  --mount "type=bind,source=$((pwd).Path)/target,target=/app" `
  nginx:latest

因みに、 Windows の場合は Path の delimiter が \ なので / に変換する必要がある、という情報を Web でよく見る。のだけど、 \ / にかかわらずマウントできた(更新されて変わったのかな)。

# こうしてもしなくてもどっちでもよい
docker run -d `
  -it `
  --name devtest `
  --mount "type=bind,source=$((pwd).Path -replace '\\','/')/target,target=/app" `
  nginx:latest

今回調べたことで改めて知ったが、CVS/SVN -> Git の変換はもうみんな興味なく、情報は陳腐化してるしツールは放棄されかかってるようだった。作ってる人含め誰も使わなくなったらまあそうなるわ、という感じ。でもその変換の過渡期に行動を起こさなかった repo てまだありそう。頭の片隅においておこう。

(2023-02-05 追記)

後でから気づいたが、この Docker の --mount オプションみたいな回避方法って PowerShell で Maven のオプション使うときにも似たようなのあったわと思い出した。最近出くわしてなくてすっかり忘れてたみたい(老化現象か)。

Migu の CVS repo を Git repo に変換したい(そして失敗)

Sun, 22 Jan 2023 09:00:00 +0900

2023-01-29 追記

これ上手くいかないの当然で、サーバにある repo 本体に対してこれを実行しないといけない。 centralized VCS 久しぶりだったので、仕組みをすっかり忘れていた。この日記は間違いの記録となった。

Migu フォントが好きでずっと使っている。それこそ Migu で PowerLine を使うためにパッチスクリプトを改修するくらいには気に入っている。

Migu フォント : M+と IPA の合成フォント

今後も使い続けるにあたって、この度 Migu のグリフやコードを読んでみたいと思ったのだけど、 Migu は OSDN の CVS で管理されているので、なかなか読み辛い。自分が VCS を使い始めたのは SVN からだったりするので、 CVS わからない事が多い。なのでこの度 Git の repo に変換しようと考えている。

方法を調べているが、もう時代的に cvs → git の変換なんてあまり行われてないようだ。情報を調べてみても流石に最近のものはなく、いまんところ 2020 頃の記事が参考になるか。

CVS リポジトリを Git リポジトリに変換する | アルファのブログ

ひとまず Index of /mix-mplus-ipa - mixfont-mplus-ipa - OSDN にアクセスし repo の tarball を download してある。

これに対して、 WSL の Ubuntu 20 で cvs-fast-export をインストールして cvsconvert かけてみたのだけどエラーになってしまった。

$ cvsconvert -pvn mix-mplus-ipa/mixfont-mplus-ipa
2023-01-22T07:25:17Z: Reading file list...done, 0.000KB in 0 files (0.581sec)
2023-01-22T07:25:17Z: Analyzing masters with 16 threads...done, 0 revisions (0.002sec)
2023-01-22T07:25:17Z: Make DAG branch heads...done  (0.000sec)
2023-01-22T07:25:17Z: Sorting...done        after parsing:      0.583   1456KB
after branch collation: 0.583   1456KB
               total:   0.583   1456KB
0 commits/0.000M text, 0 atoms at 0 commits/sec.
fatal: stream ends early
fast-import: dumping crash report to .git/fast_import_crash_50
cvsconvert: cat mix-mplus-ipa-mixfont-mplus-ipa.git.fi | (cd mix-mplus-ipa-mixfont-mplus-ipa-git >/dev/null; git fast-import --quiet --done && git checkout) returned 128.

さっぱりわからん。

他にもツールがあるのでを試してみたいが、 cvs2git が同梱される cvs2svn は Ubuntu 20 で提供されておらず。 Ubuntu – Package Search Results -- cvs2svn

また git cvsimport はインストール済みの git とバージョン競合してしまった。

こうなったら Dockerfile 書いて Ubuntu 18 で cvs2git インストールする方が良いか？ちゃっちゃと終えられるかと思ったけど全然そうじゃなかった。どうでもいい系のタスクをまた積んでしまったけど、一度手を出したからには最後までやらないと気が済まない。

F#でコマンドレットを書いてる pt.11

Sun, 15 Jan 2023 09:00:00 +0900

krymtkts/pocof の話。

年末年始思ったほど時間取れなかったが、 pocof のプロパティ指定検索はちょっとずつ進んでいる。

前は入力できるプロパティの候補が表示されるだけだったが、最近ようやく入力できるプロパティの絞り込みと、プロパティを指定した検索ができるようになった。

プロパティ名は case insensitive に指定できる。まだ複数条件入れたときが buggy でうまく動いてないけど、あとプロパティ入力候補の表示非表示と Ctrl+space での補完ができたら、ほしいものが出揃うかなーというところだ。

F# でオブジェクトのプロパティを動的に取得する方法としては、リフレクションを利用した。これが妥当な実装なのかわからないが、現時点では一番シンプルだ。オブジェクトに GetType().GetProperty() してプロパティを特定、 PropertyInfo を介してクエリで指定されたプロパティ名の文字列を使ってプロパティの値を取得している。

元々 F# のシンボルには動的にプロパティを参照する ? が書いてある¹けど実装は提供されてない。そういうモジュール(fsprojects/FSharp.Interop.Dynamic)はある。けど、依存を増やしたくないのと、利用する範囲のコードはすぐ書けるレベルなので自分で実装することにした(使えるか検証してないのもあるし)。

簡単なはずなんだが、結構自身の F# 力不足に起因して困る場面が多かったので、その内容を記す。

結論からいうと、自前の ? 演算子を定義しようとしたところ、 ? 演算子を中置演算子として使ったときに想定外の挙動があったので、結局 /? みたいな謎の組み合わせの演算子を自作した。

こういうコードがあるとする。

let inline (?) (x: 'a) (prop: string) =
    try
        let propInfo = x.GetType().GetProperty(prop)
        Some(propInfo.GetValue(x, null) :?> 'b)
    with
    | _ -> None

先述のコードを利用した場合、プロパティ名の変数を中置演算子と共に利用すると、変数の名前が引き渡されたパラメータとして認識されてしまい、変数の値が展開されなかった。通常の関数として呼び出すとこのようなことはないのだけど... なんか言語仕様を読み落としてる気がする。もうちょっと真面目に追い込んでみる必要があるか。以下は REPL(dotnet fsi) で試してみた結果。

> let str = "hello";;
> let p = "Length";;

> let a: int option = str ? p;; // プロパティ p を探しに逝って無いから None
val a: int option = None

> let a: int option = (?) str p;; // ちゃんと変数 p の値である Length の値を取れる
val a: int option = Some 5

結局これの解消ができないので ? を諦めて /? としたのだが、その前に !? とか使ってみても駄目だったので妥協してこうなった。この場合はシンボルの組み合わせに何らかの制限があるようだが、確証を持てるドキュメントが見つけられず。

> let inline (!?) (x: 'a) (prop: string) =
-     try
-         let propInfo = x.GetType().GetProperty(prop)
-         Some(propInfo.GetValue(x, null) :?> 'b)
-     with
-     | _ -> None
- ;;
val inline (!?) : x: 'a -> prop: string -> 'b option

> let a: int option = (!?) str p;;
val a: int option = Some 5

> let a: int option = str !? p;; // なんでエラーになるのかわかってない

  let a: int option = str !? p;;
  --------------------^^^

stdin(51,21): error FS0003: This value is not a function and cannot be applied.

> let inline (/?) (x: 'a) (prop: string) =
-     try
-         let propInfo = x.GetType().GetProperty(prop)
-         Some(propInfo.GetValue(x, null) :?> 'b)
-     with
-     | _ -> None
-
- ;;
val inline (/?) : x: 'a -> prop: string -> 'b option

> let a: int option = str /? p;; // こっちはいける
val a: int option = Some 5

この辺を理解していってもうちょい pocof の開発をスムースに行いたいところやなー。

シンボルと演算子のリファレンス - F# | Microsoft Learn ↩

2023

Sun, 08 Jan 2023 09:00:00 +0900

例年通り目標をたてる。

テーマ: 不惑

2023 年で遂に本物の四十不惑になる。惑わずなので基本的に今までの方向性を維持したまま更に歩みを進めるのみ。

ただの予想だが、当面は腰を落ち着けて物事に取り組める年となるかな？という感じがしている。 2022 年までに続けていたことを深化させられるタイミングかなと。例えば 2022 年から書き始めた F# はまだまだ書いてきた量が少なく手に馴染んでないので、もう少し書く量を増すとか。

あと人間四十ともなれば経年劣化がそこそこに出てきてるので、それのメンテナンスを本格に開始することに決めた。

2023 年の目標

基本は継続するテーマ。新しいテーマも去年中に思いついたもので、既に継続中だったりする。

転居先を決める
- 実家のアレコレがあったりしてやっぱ難しいかもなーというのもあるが、ちょっとずつ条件からでも調整する。もう数年もすれば固定資産の整理とか出てきてこれまた手が空かなそうやが
- 薪ストーブの生活に憧れてるんやけど薪の調達ルート開拓とか考えると結構重いのが悩み。人脈と軽トラは最低限必須ぽいからなあ...都市圏の場合は廃材をもらったり、田舎であれば森林組合に行く等
積読消化 2022 年の実績 0.5 冊/月を超える
- 2022 年末から(仕事上必要になった)全文検索の本を読んでるので、それを勢いづけに習慣化する
自作ツールの開発
- メインは pocof 。 prerelease を外す
- 他ネタは余力があればやる。Oura API (2.0) で自分ダッシュボードを作るとか
F# を学ぶ
- pocof も F# だが他にも書く。ブログ乗せ替えたいなあという気持ちがふつふつとあるので Fable 使えないかなーとか検討する
GitHub のストリークを継続する
- commit, issue 何でもいいので継続する。今のまま継続できれば 2023 年中に 180 日、 365 日のストリークを迎えることになるが、その先に何があるか知らん
毎週ブログを書く
- 2022 は出来たので 2023 も無理やりにでも書く
ギター練習を 30 分/毎日
深酒で怪我をしない
- 年々減らせてるが、 2022 は 1 回怪我した。今年 2023 は 0 にする
自分メンテナンス開始
- 人生 100 年死ぬまで労働時代なので、メンテナンスする。まずは肌。ここ数年で顔にシミが目立ちだしたが、あるだけでめちゃくちゃ年老いて見える。これらを物理的に除去するのを考えている。金がかかるが身体の乗り捨てはまだできそうにないし、やむなし
- 神経を抜いた歯もどうにかしておきたいが、どうにかできるのかこれ...

振り返り 2022 年

Sat, 31 Dec 2022 09:00:00 +0900

2022 年を振り返る。

2022 年のテーマは「自分の人生は自分で決める」だった。

手を放れかけた人生の制御権を自分に引き戻すのを目標にしていたところ、おおよそ手元に引き戻せてきたのではないかと感じる。ここ数年は、年に 1 回は仕事上インパクトのあるネガティブイベントがあった。今年はそれ程のイベントはなかったので、それが起因しての結果だろう。

2022 年目標と成果

今年も 50% 超えでぼちぼち。いい加減に完全勝利もほしい。

❌ 住みたい場所を決める
- 理想と利便性など意見が擦り合わず
❌ 積ん読の消化 1 冊/月
- 多少ペースを上げたが 0.5 冊 / 月くらいで未達。おしいなあ
⭕ 自作ツールの更新
- マッコールさんは使う機会がなくて放置してるが、新しく pocof 、 PSJobCanAttendance が増えたので -1 + 2 = 1 だし ⭕ にする
- 自己満足だが PSJobCanAttendance でパイプラインに対応したことで月々の勤怠入力楽すぎてヤバかった(語彙力)
⭕ ギター練習を 30 分/毎日
- 継続危うかったけど、土壇場で Oura Ring を購入したことで習慣化に成功した
⭕ このブログ。毎月の更新リズムを維持する
- 毎月どころかリズムを掴んで毎週に発展した
❌ 深酒で怪我をしない
- 未達。夏に怪我をした
⭕ 知らない言語を学ぶ F#
- 学んだ結果で pocof を F# で書いてるので当初の目標は ⭕
- 踏み込んだ言語機能を使えてないのとスタイルもまだ身についていないので、今後も継続する

以下、当初の予定になかったことのダイジェストだ。

転職
週 1 ブログ
GitHub の草ストリーク 100 突破

大きな流れは去年から変わらなかったが、停滞しかけた良い流れを今年の 4 月に転職したことで加速できたかなと感じている。今年の転職はほんと運が良かった。 GitHub の個人垢を使っていい会社なのもあり、活動を可視化しやすくなった。

基本的に、自分の目標のうち殆どは自身に制御権があるものだ。自身の MP (気力とも) を如何に保ち適切なタイミングで呪文を唱えるか、にかかってる。そういう目標は、自身のコンディションを維持さえできればどうにでもなるもんやなあと改めて理解した。週 1 ブログ書いたり、毎日コミットしたり、多少 OSS へのコントリしたり、気持ちの余裕があればできるもんやなあというのが今年の大きな気付きだ。

そりゃ現職でも大変やな～というような仕事は多いが、基本的に自分でどうにかする仕事しかなく、そこが精神衛生上良く働いている気がする。新しい何かを決める・調整する・理解するとかは、メンバに頼れるけど頼ったとてそのメンバの仕事が止まるので、結局自分がやるしか無い。腹をくくり自分が責任を持ってやるだけ。それによって自分が誰かのボトルネックになることやその逆もないので、とてもシンプルだ。弊害として自分以上のパフォーマンスは望めないけど。

また現職は、振る舞いや能力のミスマッチに起因してチームメンバが飛ばされるとか「You're fired!」みたいな事故も起こってない。これとても重要。去年・一昨年は年に 1 度はそういうのがあったから、それ相応に MP を消費していたのだろう。今年は MP 足りず ≒ 意欲が湧かず何も出来ないようなことが起こらなかった。

自身に制御権がある目標はこの通りだが、逆に自分だけで決められないこと、例えば家庭に関する目標なんかをうまく進められなかった。ここ数年はタイミング的には相当転居やら移住し易いはずやけど、利便性、子供の養育環境、地理的な人間関係とか諸々、この地に縛り付けるものがあり、なかなか進められない。座して待ったとしても、そのうち決断の時は必ず来る。それまでにはなんか方向性だけでも出したいなあ。

あと酒との付き合いは、コントロールが難しく失敗してる。飲酒で怪我をするの、今年は軽いものだったけどやっぱり怪我したので、いい歳だし楽し過ぎて暴走しないようより自制心を持とう。健康面の訴求から平日の飲酒は控えめ或いはナシにできてるので、この流れで来年は怪我ゼロにつなげたい。

今年 Oura Ring を購入したこともあって、自身の身体的なコンディションを可視化するのが容易になった。先述の深酒が睡眠のスコアの低さで可視化されて注意しやすくなったり、また運動やギター練習がアクティビティとして見えるので実績回収的なノリで生活に取り入れやすくなる。意図せず好影響を得た形だ。来年はもしやクソチョロなのでは(油断は禁物)。

運動というか身体的なメンテナンスに関しては、齢四十を迎えるにあたりすごく重要になってきた。健康診断結果を見てガタが来てる部分を見つけたり「今年の冬は肌の乾燥がひどいな～いや歳やこれ」みたいな日々の気付きから、経年劣化を感じている。日本の状況を鑑みるに今後の人生は甘くなくて、人生 100 年その終わりまで働き続けるのは目に見えてるからこそ、自身のハードウェアのメンテナンスも欠かさないのが重要なんやと今更気付いた。まだサイバーパンク的世界観でインスタントにパーツ交換出来ないので、壊れないように注意しないと(はよきて)。これまでソフトウェア ≒ 精神の方は相応にメンテしてきてるから、その経験をハードウェア ≒ 肉体の方にも応用できると良いが。

まとめ

来年いよいよ本物の不惑なので、自己が揺らがないように集中していこう。毎年なんか新しいチャレンジをするのがプログラマの嗜みだと思うけど、ネタをまだ考えついてないので、なんかひねり出したい。

Oura Ring Gen3 を買った

Sun, 25 Dec 2022 09:00:00 +0900

前から欲しかった Oura Ring を購入した。買ったのは第 3 世代(Gen3)だ。

事の起こりから購入まで

ほしいな～と思い出したのは大体 1 年くらい前。 TechCrunch で Oura Ring 3 review を読んだらへん。スマートリングにも色々あるが、 NFC がついたようなのはあまりに仰々しく邪魔そうでナシ。単純にバイタルデータを取るだけのために腕時計型のウェアラブルデバイスをつけるのも好きじゃない。 Oura Ring はちょうど良い感がある唯一のデバイスとして気になり始めた。

2022-04 から勤めている現職がヘルステックなのもあって、健康関連の経費補助(満額ではないが)があるので、転職を機にこれは買うしかあるまいなと心を決めた。また、過去に Gen2 から Gen3 への転換期に買い替えユーザのメンバーシップを無償にするオファーがあったらしい。当面は経費補助で落とすにしても、いつかチャンスが来るかもということで更に背中を押してくれた。

ところが、 2022 年は記録的な円安になったこともあり、思い立った 5 月頃からずっと変えずにいた。もう仕方がないので 12 月になってやっと自分用のクリスマスプレゼントという建前で多少高くても買うことにした。

マットでシンプルな Horizon Stealth がいいかなーと思ったが、為替によるパンチ力を極力抑えるために、Heritage Black にした。

Oura Ring の購入は 12/05 。指輪のサイズなんかわからないので Sizing Kit ありで購入。購入時のコストは以下の通り。

購入価格 43,200 JPY
- 本体 299.00 USD
- 送料 15.00 USD
- 換算レートは 2022-12-06 で 1 USD = 137.581 JPY
プラス関税で DHL に 3,400.00 JPY
合計 46,600 JPY

決して安くない買い物だ。経費補助の残額的に 17,000 円位は補填できるが、自腹で 3 万かー。ちょうどこの時期日本ではソフトバンクでの取り扱いが始まったが、そっちよりは安い(ソフトバンクで買う意味あるんかが謎)。このガジェットはゴリゴリに使い倒さねばなるまい。

因みに Heritage Black は、商品ページで見るよりもかなりメタリックだ。黒というよりもガンメタリックでちょっと想像よりもチャラかった。

購入から本体到着まで

購入後の流れは非常にスムーズだった。概要は以下の通り。

12/05 購入
12/07 Sizing Kit 到着。 9 で検証
12/08 8 で検証
12/09 8 で確定
12/12 本体到着

購入の 12/05 から 2 日後の 12/07 に Sizing Kit が届く。 Oura 推奨の利き手の逆の人差し指だとギターが弾けなくなるので、右手人差し指を基準をに考えて 9 で検証はじめた(実際に左手人差し指につけてギターを弾いたら指の腹でネックを握れないのでこの判断は正しい)。ところが翌朝まで 1 日つけてみていまいちなのではと思い始めた。 9 は朝の時間帯でも少し緩い。

利手の右手だと、皿洗いや風呂洗い等あらゆる家事をする時にぶつかる、また食事の時は箸にぶつかるなど、大いに支障があるとわかってきた。左手だと皿洗い時に食器の底の凶悪なザラザラに接触する機会があるのだが、他はさして支障にならなかった。 (Oura Ring はチタン製らしい。モース硬度 4 と仮定すると茶碗などの磁器はモース硬度 7 相当であることを考えれば、皿洗いで Oura Ring が傷つくのは想像するに易い)

同時並行して、使用レビューを Web で漁り、体の変化等で人差し指が多少きつめになったときでも中指に逃げる運用があると知った。実際に自分の人差し指のサイズだと左右で結構差があるが、左手だと人差し指と中指は 8 で運用できるのがわかった。右手人差し指にずっと 8 をはめているのは窮屈だが、ギターを引くときだけはめるとかなら全然いける。なのでサイズは 8 で決定した。

決めたのは 12/09 で、待ちに待った本体到着が 12/12 。普段海外のサプリ購入で感じてるリードタイムに比べると相当に早かった。

運用を始めてみた

12/12 の午後くらいから運用している。つまり本日 12/25 時点でおよそ 2 習慣運用した上での感想を記しておく。

選択している focus area ? は Be productive and energetic 。なんとなく。これ他のも試してみたいがトレンド？のビューが変わる以外どこに影響あるかわかってない。

Readiness, Sleep, Activity いずれも概ね 90% 前後で推移しており、数値上は非常に健康であると言えるだろう。

というのも、 Oura アプリの Insight ？画面が非常によくできていて、スコアを落とすことに何らかの罪悪感のようなものを抱かせるようになっているからだ。例えば、全体的に青い色調のビジュアルをしているが、スコアが低い要素は赤くなって不安感を煽られる(現に「Pay attention」と言われるし)。また Activity が取れていないとアプリの通知で「足をストレッチする時間ちゃうか？」と ~~~脅して~~ 教えてくれるので、強制的に動くような生活リズムが形成されてくる。これが自身で設定した focus area に対応した ~~仕打ち~~ アプローチなのかは不明だが。

先にアメとムチで言うところの鞭面について触れたが、アメ面でいえば Readiness, Sleep, Activity の各スコアで 85 以上を叩き出せばクラウンをもらうことができる。クラウンはスコアの横にちょこんと表示されるのだけでなく、カレンダーでそれまで得たクラウンを確認することもできる。クラウンを得たとてどうということないのだが、ゲーマーなら一種のトロコンのような満足感を得られるだろう。現に 1 週目はクラウンが 1 つの日もあったが、 2 週目は最低でもクラウン 2 つ。来たる 3 週目は間違いなく全冠とれるだろう。~~アプリに人間が操られていると言っても過言ではない。~~

お陰で装着 1 週目から、 Readiness と Sleep のスコアを改善するために夜更かしせず寝ると決めたら即寝る、 Activity のスコアを改善するために 1 時間毎にこまめに運動する等、生活習慣を改善し始めれた。このまま継続していけば、その手に勝利をつかむ日も遠くないだろう(何と戦ってる？)。

あと 3 週程で無料のメンバーシップ期間が切れてしまうのだけど、その時アプリがどれだけ使いにくくなるのか検証してみる。それでメンバーシップの継続をするか決めたらいい。現状のレポートに結構満足してるので、多分継続しそうやけど。

台座みたいな充電器は USB Type-C を接続するやつなのだけど、中の基盤が遊んでるっぽくてちょっとガタツキがある。 Oura Ring 自体はそうそう壊れそうに無いけど、充電器の方は丁寧に扱わないと割とすぐ逝ってしまわれるかも。

プログラマからみた Oura Ring の楽しみ方

もう 1 つ Oura Ring の楽しめる点がある。それは API が充実している点だ。

ほんまか知らんがアプリで提供される数値は全て API で取ることができるらしい。名称の表記が Oura Cloud API だったり Oura API だったりどっちやねんというところではあるが、ここでは簡単のため Oura API と呼ぶことにする。現状 Oura API には Oura API V1 と Oura API V2 が存在する。 V1 は 2023 年初頭に廃止されるらしい。もうすぐやないか。

The current timeline to sunset the Oura API V1 is early 2023. We are not planning any updates—outside of required maintenance—to the Oura API V1 moving forward. A migration guide for users to transition from V1 to V2 of the Oura API will be available in February 2022.

API を利用するにあたり認証の手段は 2 つある。 1 つは Personal Access Token 、もう 1 つは OAuth の API Application だ。自分のデータにアクセスする場合は Personal Access Token で良いが、複数ユーザのデータを扱うような場合は API Application を使うらしい。でもデフォでは MAX 10 人しか扱えないようなので、より多くのユーザを扱う場合には審査を経て承認が必要だと。はいはい〇〇 Ads とかの API 利用でもそういうのあったわ。

Oura API V2 では OpenAPI spec が公開されているので、アプリに組み込むだとかのときも安心に使えそう。 Open API Generator とかで生成したやつが使いやすいかどうかは Schema が丁寧に作られてるか次第だったりするので、いつか試してみるのも良いだろう。

今日この記事を書くにあたり、 Personal Access Token を用いて自分のデータを取得してみた。

まずは Personal Access Tokens - Oura Developer API で Personal Access Token を発行する。

疎通確認の為に、自分の Personal Info を取得してみる。 Oura API V2 は Stripe の API Document のように激イケではないものの、見た目はそこそこ親切で好感が持てる。 Get Personal Info に cURL の例があるのでそれをコピり、 PowerShell 用に書き換える。

curl --location --request GET 'https://api.ouraring.com/v2/usercollection/personal_info?start_date=2021-11-01&end_date=2021-12-01' \
--header 'Authorization: Bearer <token>'

ドキュメントには書いてないクエリ文字列がついててなんか怪しい。試しに今月始めから今までで取得する。といっても配列が得られるわけではないらしい。期間指定するのはなんでだ？まあいい。

$Token = ConvertTo-SecureString "!!!PERSONAL_ACCESS_TOKEN!!!" -AsPlainText
Invoke-RestMethod -Method Get -Uri "https://api.ouraring.com/v2/usercollection/personal_info?start_date=$((Get-Date -Day 1).ToString('yyyy-MM-dd'))&end_date=$((Get-Date).toString('yyyy-MM-dd'))" -Authentication Bearer -Token $Token

# こんなのが取れる
# age            : 39
# weight         : 61
# height         : 1.8
# biological_sex : male
# email          : メアド

ドキュメントによると身長は 1m を 1 と扱う。体重は Kg らしい。ただ謎なのは 62 Kg で登録してるのに何故 61 ? 連携してるサービス由来か？と思ったが Google Fit も 62 、 Health Connect はどうかわからない。もしやゼロオリジン？わからん。今後調査を進めよう。

配列じゃないのになんで日を指定するんやろか、と思ってパラメータ削って実行してもデータ取れた。これドキュメントのサンプルコードが間違ってそうやな。ドキュメント自体はあってるので単にケアレスミスやろか。

Invoke-RestMethod -Method Get -Uri "https://api.ouraring.com/v2/usercollection/personal_info" -Authentication Bearer -Token $Token

# 取れるんかい！

認証できない時どうなるんだろうと思って Authentication 外してみたら Internal Server Error が帰ってきた。まじか。コレジャナイ感がある。試しに V1 で同じことをしてみたらちゃんと 401 が返ってくるので、 V2 まだ未完成なんかなって察する。

Invoke-RestMethod -Method Get -Uri "https://api.ouraring.com/v2/usercollection/personal_info"
# Invoke-RestMethod: Internal Server Error
$res = Invoke-WebRequest -Method Get -Uri "https://api.ouraring.com/v2/usercollection/personal_info" -SkipHttpErrorCheck
$res
# StatusCode        : 500
# StatusDescription : InternalServerError
# Content           : Internal Server Error
# ...
Invoke-RestMethod -Method Get -Uri "https://api.ouraring.com/v1/userinfo"
# Invoke-RestMethod: {"status": 401, "title": "Invalid Access Token", "detail": "The access token provided is expired, revoked, malformed, or invalid for other reasons.", "error": "invalid_token", "error_description": "The access token provided is expired, revoked, malformed, or invalid for other reasons."}

最後に Readiness, Sleep, Activity あたりのデータを取得してみる。期間なしで。アラフォーの赤裸々なバイタルデータだ。

Invoke-RestMethod -Method Get -Uri "https://api.ouraring.com/v2/usercollection/daily_readiness" -Authentication Bearer -Token $Token | ConvertTo-json -Depth 10
# {
#   "data": [
#     {
#       "contributors": {
#         "activity_balance": 84,
#         "body_temperature": 100,
#         "hrv_balance": 87,
#         "previous_day_activity": 81,
#         "previous_night": 96,
#         "recovery_index": 100,
#         "resting_heart_rate": 100,
#         "sleep_balance": 90
#       },
#       "day": "2022-12-24",
#       "score": 91,
#       "temperature_deviation": -0.08,
#       "temperature_trend_deviation": -0.02,
#       "timestamp": "2022-12-24T09:00:00+09:00"
#     },
#     {
#       "contributors": {
#         "activity_balance": 85,
#         "body_temperature": 96,
#         "hrv_balance": 85,
#         "previous_day_activity": 94,
#         "previous_night": 100,
#         "recovery_index": 96,
#         "resting_heart_rate": 76,
#         "sleep_balance": 92
#       },
#       "day": "2022-12-25",
#       "score": 90,
#       "temperature_deviation": 0.09,
#       "temperature_trend_deviation": 0.06,
#       "timestamp": "2022-12-25T09:00:00+09:00"
#     }
#   ],
#   "next_token": null
# }

Invoke-RestMethod -Method Get -Uri "https://api.ouraring.com/v2/usercollection/daily_sleep" -Authentication Bearer -Token $Token | ConvertTo-json -Depth 10
# {
#   "data": [
#     {
#       "contributors": {
#         "deep_sleep": 99,
#         "efficiency": 98,
#         "latency": 75,
#         "rem_sleep": 100,
#         "restfulness": 88,
#         "timing": 76,
#         "total_sleep": 94
#       },
#       "day": "2022-12-24",
#       "score": 91,
#       "timestamp": "2022-12-24T09:00:00+09:00"
#     },
#     {
#       "contributors": {
#         "deep_sleep": 100,
#         "efficiency": 93,
#         "latency": 91,
#         "rem_sleep": 100,
#         "restfulness": 88,
#         "timing": 83,
#         "total_sleep": 96
#       },
#       "day": "2022-12-25",
#       "score": 94,
#       "timestamp": "2022-12-25T09:00:00+09:00"
#     }
#   ],
#   "next_token": null
# }

Invoke-RestMethod -Method Get -Uri "https://api.ouraring.com/v2/usercollection/daily_activity" -Authentication Bearer -Token $Token | ConvertTo-json -Depth 10
# {
#   "data": [
#     {
#       "class_5_min": "1111111111111111111111111111111111111111111112211223333333323233333233333332222222211322222232222222232332322333234222223233223332222322222",
#       "score": 90,
#       "active_calories": 179,
#       "average_met_minutes": 1.46875,
#       "contributors": {
#         "meet_daily_targets": 78,
#         "move_every_hour": 100,
#         "recovery_time": 100,
#         "stay_active": 75,
#         "training_frequency": 100,
#         "training_volume": 97
#       },
#       "equivalent_walking_distance": 3621,
#       "high_activity_met_minutes": 0,
#       "high_activity_time": 0,
#       "inactivity_alerts": 0,
#       "low_activity_met_minutes": 119,
#       "low_activity_time": 10860,
#       "medium_activity_met_minutes": 37,
#       "medium_activity_time": 600,
#       "met": {
#         "interval": 60.0,
#         "items": [
#           1.1,
#           0.9,
#   長すぎ端折る
#           0.9,
#           0.9
#         ],
#         "timestamp": "2022-12-25T04:00:00+09:00"
#       },
#       "meters_to_target": 8000,
#       "non_wear_time": 0,
#       "resting_time": 15900,
#       "sedentary_met_minutes": 5,
#       "sedentary_time": 14340,
#       "steps": 3898,
#       "target_calories": 550,
#       "target_meters": 12000,
#       "total_calories": 1940,
#       "day": "2022-12-25",
#       "timestamp": "2022-12-25T04:00:00+09:00"
#     }
#   ],
#   "next_token": null
# }

Readiness, Sleep は 2 日分、 Activity は 1 日分取れた。日時で実行してデータストアに蓄積するような使い方なら、パラメータを指定する必要もなさそう。基本はデータストアに溜め込むようなことしないだろうし、期間指定してページネーションして利用してねってところか。

スコアはアプリ表示そのままだが、一部の小数位を含む数値はアプリで表示する精度以上に持っている様子。また Activity は結構色々データを持っていて面白そう。 METs で 1 分刻みのデータ持ってるのかーとか、 class_5_min に 5 分刻みのサマリを持ってんのかとか。この強烈なデータ表現はアプリ用なんかな？

単純にデータを見てもまだピンとこないので、更なる探索はアプリの利用も熟れてきてからが良いかも知れない。

おわりに

自分の体調を可視化できるのすごく良い。踊らされやすい人種なだけかも知れんがこうも行動を変容させられると、可能性を感じざるを得ない。実際にその変わった行動が健康に寄与してるかは健康診断とかの結果見なわからんけど。

アプリの継続に関しては、仮に自分ダッシュボードを作り上げれたら案外要らないのか？まだ装着期間が短いこともあり出ないレポートもあるみたいなので、その辺を拝ませてもらってからメンバーシップなしにするとかの判断もありか。

F#でコマンドレットを書いてる pt.10

Sun, 18 Dec 2022 09:00:00 +0900

krymtkts/pocof の話。

少しだけ pocof のプロパティ指定検索対応を進めた。

PSCmdlet.ProcessRecord のときに PSObject.Properties から PSPropertyInfo.Name を取り出して Set<string> の変数に格納する。その変数を画面の描画のときに通知領域のところに出すまでを実装した。うまく出てるのを見てみようということだ。

当然のごとく、常時プロパティの補完候補が出ているのはヘンなので、クエリの入力状況に応じた表示＆プロパティ候補表示 ON/OFF のオプションの追加が必要になる(のが見えてきた。行き当たりばったり)。

ここで「クエリの入力状況」と書いたが、「プロパティ指定子」(poco に倣い既定で : を検討している)が入力されていて、かつカーソルがその「プロパティ指定子」に連続する文字列のポジションにある時が、「プロパティ入力」。つまり入力中のクエリとカーソル位置でモードを切り替える必要がある。

これ結構めんどくて、クエリとか内部状態として持っているレコードにモードを足して、あとキー押下時やカーソル移動のそれぞれのアクションでモードの ON/OF をやらないといけない。

もう他にも面倒なやつらしかないんやけど、今とりあえずプロパティ指定検索では以下を実装しようとしている。

オプションにプロパティ候補 ON/OFF を追加する
内部状態に入力モード(通常・プロパティ)を追加する
「プロパティ入力モード」のときに
- プロパティのタブ補完できるようにする
- プロパティ名入力に合わせてプロパティ表示を絞り込み
InputObject のプロパティ指定検索対応

途中 PSPropertyInfo の型に合わせて入力の検査をしたら...とか思い始めたが、これ今やるのは違うわ今はいいわと思って虚無に帰した。やったら楽しそうなので、そのうち復活してくるかも。他にも湧いては消え × N するアイデアはポツポツあるので、プロパティの対応が終わったらボチボチ真面目に検討できるようになるかなー。

試しに実装してみて、使い勝手を検証して、更に実装していく。

これまさにプロトタイピングなのだけど、それなら紙芝居でもいいのでは...という気はしなくもない。が、紙芝居で作ったらすぐさま試用できるモノが手に入らないので、常に動くものを持てるこっちの方法が楽しい。仕事で気分任せに進めるとヤバい(終わりのないプロトタイピングで金食い潰すとかヤバい)けど趣味プロは誰にも邪魔されない。

とは言えこのアプローチは継ぎ足し〃の九龍城砦になりがちなので、都度再構築されて然るべきなんだろうとひしと感じている。出発点が PowerShell から F# への写経だったのもあって、当初から微妙と感じるところがいくつかあるのと、 F# の腕が悪いのもあってかっこよくないところとか。来年に持ち越しかなー。これも楽しいのでやりたいけど、先にプロパティを始末したい。

F#でコマンドレットを書いてる pt.9

Sun, 11 Dec 2022 09:00:00 +0900

krymtkts/pocof の話。

師走は何かと忙しくて pocof のプロパティ指定検索対応に時間が割けていない。あんまり手も動かせないので、プロパティ指定どうやったらいいかなーと思案している。つまりこの記事は壁打ちだ。

どー考えても一番楽なのは、 PSCmdlet.InvokeCommand にクエリ文字列から組み立てた FilterScript を渡す方法。でもこのやり方でやったとして自分の知見が広がるわけでもないし、楽しくない。

ということでどうせなら F# の世界からどうにかしてやろうと思っている。やはり正攻法なのは、PSObject.Propertiesにアクセスする方法だろう。

難点は、 pocof の InputObject を内部では PSObject[] から obj list に変えてしまってるので、それらを適宜補正してやる必要があるくらい(そもそもなんで obj list にしたか覚えてない)。なんかできそうに思えてきた。

フィルタの方は、 PSObject.Properties にクエリ文字列をパースして抜き出したプロパティ名で値を取れば、クエリ式内で where に使うのは造作もないことだろう。 hashtable のときだけ特別サポートしているので、そこと折り合いつけれれば困ること無いのでは(油断している)。

プロパティの入力候補出すやつは...どうかな。パラメータ InputObject に単一の型だけが含まれるのであれば、先頭の要素の PSObject.Properties から候補を一覧するだけでいいのだけど、奇しくも pocof は複数の型も許容する包容力を持ってるから...

まー単純に考えて、全走査しているタイミングは 2 つあるので、そこで型情報も一緒に控えておくのが良かろう。

PSCmdlet.ProcessRecord で list に詰めてるのでその時に GetType する
List.rev してるときか(ProcessRecord で計算量減らすため逆に詰めているから)

フツーに PSCmdlet.ProcessRecord いいな。型情報取るだけならなんかこれもできそうな気配してきたな。

問題は取得したプロパティをどう表示するかやけど、スペース的に空いてるのは正規表現パターンのエラー表示するための行だけなので、そこに出そう。要素数が多い場合は水平方向のスクロール機能(！)を実装しないと使い物にならなさそう...全く実装イメージつかんなこれ。

会社の期末が 2023-01 なので、なんか来年頭は忙しくなりそうやな～と思うし、この年末年始のお休み期間で如何に F# と戯れることができるかが重要な気がする。 pocof の至らぬ点諸々の棚卸しもやっておきたいし。それに今年の振り返りもボチボチやり始めとかないと...

PowerShell で忘れがちなこと pt.1

Sun, 04 Dec 2022 09:00:00 +0900

小ネタ。

hashtable は PowerFighter(勝手に作った PowerShell 使いの呼び名) なら誰しも使いまくるに違いない。

リテラルが用意されており書きやすいから、ついつい適さない用途にふんだんに利用してしまい、たまにハマる(自分調べ)。この度、仕事で使っている PowerShell で書いたスクリプトを久しぶりにメンテしたときハマったので、備忘のため記す。ハマったのは次のような内容だ。

「複数の数値から重複を取り除く術として hashtable を使ったが、hashtable に重複が残った」

PS> $hash

Name                           Value
----                           -----
1                              True
1                              True

なんだこりゃ。

コレが起こった理由は簡単。 1 つ目と 2 つ目の型が異なるからだ。

PS> $hash.Keys | % GetType

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     String                                   System.Object
True     True     Int32                                    System.ValueType

理由がわかれば簡単でまじでしょーもない内容だったが、本当にコレで小一時間ハマった。異なる型が混在したのは単純に全ての分岐で同じ型になっていなかったバグなのだけど、REPL だと一見同じ値にしか見えないのでびっくりする。

こんなことにならないように、重複を除く用途では型を厳密にできる System.Collections.Generic 名前空間のコレクションを使うべきだろう。型属性がクソ長くなるけど。

先述の、億劫して hashtable を使った重複の除去は、 System.Collections.Generic.HashSet を使えば以下のように安全だ。

ただ各メソッドに戻り値があるので PowerShell の戻り値と相性悪い。そこが面倒なら System.Collections.Generic.Dictionary<TKey,TValue> かなあ...宣言がさらに長くなる。

PS> $h1 = @{}
PS> $h1[1] = 1
PS> $h1['1'] = 2
PS> $h1

Name                           Value
----                           -----
1                              2
1                              1

PS> [System.Collections.Generic.HashSet[int]]$h2 = @{}
PS> $h2.add(1) | Out-Null # 戻り値を無に帰すのがメンドイ
PS> $h2.add('1') | Out-Null # 同上
PS> $h2

Key Value
--- -----
  1     2

PS> [System.Collections.Generic.Dictionary[int,int]]$h3 = @{} # 長いな...
PS> $h3[1] = 1
PS> $h3['1'] = 2
PS> $h3

Key Value
--- -----
  1     2

とはいえ、型属性の長さやメソッドの戻り値の取り回しにさえ目を瞑れれば、あとは提供される暗黙的変換ライフにより安全な生活が始まる。

簡潔な構文糖は手に入らないけど、「こんなに長いのタイプできないにょ...」となるときは、代わりの術はあるから...それで以て茶を濁す。

Terminal でなら [hashset とタイプして TAB を押下すれば、あ～ら不思議、完全名称が自動補完される(これは速くてまじですごい)
VS Code であれば [hashset とタイプして補完候補から選ぶ。Terminal と比較すると若干もっさり感じる

雑多に書きたいときに Generic Type を使うのはちょっと大げさかなという気がしないでもないが、安心安全の PowerLife を送るにはこういうのも必要ということで。 ↓ に引用した通り Generics のサポートも手厚くなってるわけだし。

about Calling Generic Methods - PowerShell | Microsoft Learn

Beginning with PowerShell 7.3, you can specify the types for a generic method.

F#でコマンドレットを書いてる pt.8

Sun, 27 Nov 2022 09:00:00 +0900

krymtkts/pocof の話。

前回書いた、 composite query の実装をした。 #9

デフォルトでは and で複数のクエリを合成するようにしてる。一応理由がある。最初から or だと絞り込む前の状態を覚えていて、追加でほしい候補のためにクエリを書くような使い方になる。そういう使い方もできるが、ちょっと上級者感がするので、まずは見える範囲で徐々に候補を絞り込めるような and をデフォルトとすることにした。

そのうちショートカット含めた初期値の変更にも対応したいと思ってたし、起動時から or にしたい場合はそこに盛り込めたらいい。

ただこの and での合成は hashtable を絞り込むときに出来が悪くて、まだ思ったような絞り込みになっていない。現状 hashtable は or でのみ気持ちよく絞り込むのができなかった。

これは、 List.allPairs した複合クエリの List × エントリの List に and の場合は List.forall or の場合は List.exists してることで、 hashtable はエントリ Key-Value の二要素あるので and だと両方に共通の文字がないと釣れない...となっているため。正しくは、エントリ内の検索候補プロパティは or で、各エントリ毎は and / or のモードを適用できるようにするのが良いか。プロパティ指定の絞り込みするときにこの問題対処するの必須。

あと like matcher のときだけクエリが空の状態でもフィルタリングされて表示が 0 件になる挙動を直した。 #10

流石に初期表示が 0 件だとはじめ何で絞り込んだらいいんや...(wildcard 埋めたらいいだけやけど)と困惑するので、はじめは全件表示する。

最後に、今回 PowerShell Gallery に公開する時手間取ったのが、 platyPS 。

前にモジュールの掃除した影響で platyPS の version 2 preview より前のモジュールを消し去ってた。コレにより New-ExternalHelp Cmdlet がなくなっていて、 psake のリリーススクリプトがエラーするようになってた。全く想定外。 v2 で消えるのかこの Cmdlet ？？て感じ。まだ README.md に消えるような話書いてないし、対応待ってたらいだけなんかな ↓↓

Create external help xml files (MAML) from platyPS Markdown.

とりあえず preview でない platyPS を使うことで回避した。 pocof に v1 刻むときにはヘルプファイルもきれいにする必要があるし、その時までに platyPS が v2 でほんとに Cmdlet 失われるのかとかチェックする必要が出てきた。

F#でコマンドレットを書いてる pt.7

Sun, 20 Nov 2022 09:00:00 +0900

krymtkts/pocof の話。プロパティ指定の検索に対応しようとしていて、今日のはその思考整理のようなもの。 Add a property support. · Issue #2 · krymtkts/pocof

実は？ jasonmarcher/poco を使ってたときから今に至るまで、プロパティ指定の検索をあまりやってこなかった。可能性は感じていて何なら使いたかったけど、プロパティをいちいち覚えて打つとかできなくて、使いこなせなかった。なので pocof でそれを実装するからには、障壁を取り除いて簡単に使える機能にしたい。そのため、まず pocof が機能に対応したと仮定してどんな風に使うか手を動かすイメージをして、そのあと今の pocof との差を表出させるようなことをしている。

このアプローチだけでも色々足りないものが見えてきて面白い。 pocof の時から今の pocof に至るまでの自分の使い方が非常に限定的だったのがよく分かる。今の自分のユースケースの殆どは、文字列化されたオブジェクトに対して正規表現でフィルタできたら、それで済んでしまうのがわかった。Where-Object でフィルタするタイミングを、実行してデータがわかったその時まで遅延させる、そんな使い方しかしてない。だから今の pocof はほんとにそれを満たすだけのミニマルさになってて、欲を言えばツールが使用者に違った視点を与えるとかのフィードバックするとか、そいういうモノがないんやなと改めて感じている。

例えば、 poco の頃にあったスペース区切りで複数の and filter できる機能は pocof にはない。自分が使ってこなかったから作ってなかった。でもプロパティ指定の検索をするとしたら、これは絶対に使いたい。 1 つのプロパティで絞り込んだとて満足な結果を得られることはないだろう。なんならこれらの複数のプロパティの絞り込みは and だけじゃなくて or でも結合させたい場面が出てくるだろう。他にも、いま正規表現で .+dir/*+.js とか書いてるのもスペース区切りで置き換えて dir js でできたらタイプ数も減って楽でいいよなとか。(正規表現は正規表現で使ったらいいけどほとんどはもっと少ないルールに従ってフィルタできるであろうから)。こんな感じで、ある 1 つの使い方から芋づる的に派生していく。確信はないけど、こういった派生が自分の普段の使い方に変化をもたらす気配がしてる。

とりあえずこの複数のフィルタは composite query と(若干中二病的に)名付けて Issue を起こした。Support composite query · Issue #9 · krymtkts/pocof やることのイメージが膨れ上がりそうやし、プロパティ指定の検索に必要な最低限を細かく刻んで機能を追加して、その後の成長はまた別に考えるのが良さそうかと考えている。

はじめに述べたプロパティ指定の検索も、この「普段の使い方に変化をもたらす」気配がしてる。例えば、わたしは仕事が AWS のリソースを探るのによく使う AWS Tools for PowerShell 。 Cmdlet の出力をフィルタするのやプロパティの確認なんかで、何度か結果を出力したり変数に格納したり、ステップを踏むことが多い。でもこれが pocof のインタラクティブな検索で試行錯誤できるようになれば、何度もコマンドを実行しなくても粘土をこねるみたいに try & error しやすくなったりしないかな？とか。選択したプロパティが列になって検索結果に表示されることでわかりやすさが向上しそうだな、とか。

個人開発では主にゴミスクリプトしか書かないのもあって、改めて自分用のツールを育てる面白さがわかりだした。個人的な嗜好として、あまり長く同じやり方を続けることを良しとしないのだけど、自分で自分のツールを開発するのってコレとめちゃくちゃ相性良いのでは？と最近思ったりしてる。

全然関係ないけど .NET 7 出たし、 pocof もさっさと乗り換えてしまのが良さそう(今 .NET 6)。 prerelease なので気兼ねなくやれる。 .NET 7 対応した PowerShell 7.3 かなり速くなった気がするのよな(気だけ？)。その恩恵にあやかりたい。

師走に向けて PowerShell モジュールの大掃除

Sat, 12 Nov 2022 09:00:00 +0900

PowerShell あるあるなのだけど、過去のモジュールが溜まってしまって自分で掃除しないといけない。開発中でもない限りモジュールを切り戻することもないので、一気に消す。これが PowerFighter(勝手に作った PowerShell 使いの呼び名)の嗜み。

ゆーてもこしらえてあるスクリプトを流すだけ。以下の通り。個人的に -Scope AllUsers でモジュールを入れてるからそれに合わせた形となっている。簡単のため改行を入れている。

# $PSGetPath.AllUsersModules をロードするために一度流す。
Get-InstalledModule
# Uninstall 対象の取り方。 AllUser 向けに入れてる場合。
Get-Module -ListAvailable | Where-Object -Property Path -Like "$($PSGetPath.AllUsersModules)*" `
| Group-Object -Property Name | Where-Object -Property Count -GT 1 `
| ForEach-Object { $_.Group | Sort-Object -Descending -Property Version | Select-Object -Skip 1 } `
| ForEach-Object { [pscustomobject]@{
        Name = $_.Name;
        RequiredVersion = "$($_.Version)$(if ($_.PrivateData.Values.PreRelease) {'-'+$_.PrivateData.Values.PreRelease} else {''})"
    } }

# 心配なときは以下の出力の最新バージョンが Hit してないことを目検する。
# Get-Module -ListAvailable | ? -Property Path -like "$($PSGetPath.AllUsersModules)*"

# エグゼキューション。
# はじめは -WhatIf アリで流し、処理する時心配なら Confirm で一個ずつ確認する。
Get-Module -ListAvailable | Where-Object -Property Path -Like "$($PSGetPath.AllUsersModules)*" `
| Group-Object -Property Name | Where-Object -Property Count -GT 1 `
| ForEach-Object { $_.Group | Sort-Object -Descending -Property Version | Select-Object -Skip 1 } `
| ForEach-Object { [pscustomobject]@{
        Name = $_.Name
        RequiredVersion = "$($_.Version)$(if ($_.PrivateData.Values.PreRelease) {'-'+$_.PrivateData.Values.PreRelease} else {''})"
    } } | Uninstall-Module -AllowPrerelease

prerelease なモジュールの削除も一緒に含めるため、ごちゃごちゃしている。 -Version の指定を楽にする場合は Get-InstalledModule を使ったらいいけど、モジュールごとに実行すると遅いし...と思って使ってない。

これで消しきれるかなと思ったけど、依存関係を忘れてたことでいくつかエラーをもらった。 2 周したらきれいになるかなと思いきや、以下のモジュールに関しては消しきれなかった。

Configuration
Metadata
PackageManagement
PowerShellGet

これらは AWS.Tools.Installer と PowerShellGet が依存しており消せないとのこと。先述のスクリプトでは最新版は確保するようになってあるし、壊れても入れ直したらいから、古いものに関してはやや強引に -Force を付与して消し去る。

Get-Module -ListAvailable | Where-Object -Property Path -Like "$($PSGetPath.AllUsersModules)*" `
| Group-Object -Property Name | Where-Object -Property Count -GT 1 `
| ForEach-Object { $_.Group | Sort-Object -Descending -Property Version | Select-Object -Skip 1 } `
| ForEach-Object { [pscustomobject]@{
        Name = $_.Name
        RequiredVersion = "$($_.Version)$(if ($_.PrivateData.Values.PreRelease) {'-'+$_.PrivateData.Values.PreRelease} else {''})"
    } } | Uninstall-Module -AllowPrerelease -Force

この如何にも PowerFighter な近距離パワー型アプローチ、まさに PowerShell って感じ(いいたいだけ)。穢れたモジュールフォルダを綺麗にできた。

PSJobCanAttendance の公開

Sun, 06 Nov 2022 09:00:00 +0900

自分が使う機能はおおよそできたので、 krymtkts/PSJobCanAttendance を PowerShell Gallery に公開した。

PowerShell Gallery | PSJobCanAttendance 1.0.1

デバッグプリント仕込んだまま publish してしまって速攻パッチが上がっている。これ過去に何度かやらかしたので防ぎたいけど防げてない。横着せずにログレベルちゃんと使ってやれよというところか...

公開のために、前回見つけた勤怠の実績を一覧する機能のバグを修正した。

休暇があると日付と実績がずれる
最終日の実績が欠落する

休暇の実績を含めるようになったので、稼働していない日もひと目で分かる。

動作確認を行うにあたり、指定した月の勤怠の実績を出力できる必要があったため、それも実装した。ついでにパイプラインからパラメータを受けるようにしたことで、複数月の勤務実績を取得するのも容易だ。しかも期間が連続していない実績を引っこ抜くことができる。この挙動、画面ではできないはず(使い道が思い浮かばんけど)。

# 何故か 8 月を飛ばして 7,9 月の実績を一覧するムーブ
7,9 | % {Get-Date -Month $_} | Get-JobCanAttendance

ただいまこれ書いてて、休日出勤の実績がある場合にちゃんと一覧できるかな？と思いついたので動作確認してみる必要がありそう。ダメそうなら Issue 行き。

今後やること

勤怠管理サービスを CLI で処理できるようにするの、非公開のものも含めたらこれで 3 個目になった。私的用途だと、大抵の勤怠管理で以下の機能を作ってきた。自動打刻は作れるが作らないのが良心。

出退勤のリアルタイム打刻
事後の打刻(編集機能)
実績の一覧

今回のケースでいうと、あとコレができたらいいなーというのに以下がある。いずれもジョブカン勤怠管理ローカルな使い勝手を改善するものだ。

グループが 1 つの場合に group_id の入力を省略できるようにする
実績の削除

まず 1 からできたらいい。大抵の場合入力パラメータを減らせるから、楽さが増す。 2 は画面での編集が面倒でなければ普段作らないのだけど、今回のケースではほしいかなと思っている。理想はインタラクティブに削除対象を選べるようにしたいけど、まずは指定のパラメータで消すとこからやるか。

あと krymtkts/PSJobCanAttendance 自体 krymtkts/PSMFAttendance のコピペで作ったのもあって、今見るとなんか至らないイマイチな箇所がチラホラある。それらを直したい気持ちもあるが、直したとて勤怠入力体験が良くなるわけでもないので、あんま動機づけにならない。

個人的には、 krymtkts/pocof の方をいじれてないから、さっさと勤怠スクリプトは終えてしまいたい。でも、やり始めたら気になって止めにくいのもあって止まらない状態が続いてる。要は惰性だ。なのでリストアップしたものの、やる気がわかない場合はやらないかも...これぞ趣味プロの醍醐味(しらんけど)。

PSJobCanAttendance の公開準備

Sun, 30 Oct 2022 09:00:00 +0900

krymtkts/PSJobCanAttendance を PowerShell Gallery に公開する準備をしている。一括編集機能に若干の改善をした。

従来は、パイプラインを使った一括編集が可能だったが、出勤とか退勤とかの打刻イベント毎にパイプを分ける必要があった。

# 従来はこんなん
@(12..16;20..22) | %{get-date "2022-09-$($_) 08:15:00+0900"} | Edit-JobCanAttendance -TimeRecordEvent work_start -AditGroupId 10
@(12..16;20..22) | %{get-date "2022-09-$($_) 12:00:00+0900"} | Edit-JobCanAttendance -TimeRecordEvent rest_start -AditGroupId 10

これ自分で使ってみて結構面倒に感じて、時刻と打刻イベントをパイプラインで渡せるように調整した。この調整により、 1 ヶ月分の出勤・休憩の開始＆終了を一気に登録できる様になってしまった。怠惰が捗る(打刻を必要とする勤怠管理なのは触れてはならない)。

# 1 ~ 31 日の間で 7 日、 10 日、土日を除いた日に出勤と休憩開始・終了を一括登録する。
1..31 | ? {$_ -notin 7,10 } | % {get-date -Day $_} | ? -Property DayOfWeek -notin 0,6 | % {
    [PSCustomObject]@{
        TimeRecordEvent='work_start'
        RecordTime= Get-Date -Date $_ -Hour 8 -Minute 15 -Second 0
    }
    [PSCustomObject]@{
        TimeRecordEvent='rest_start'
        RecordTime= Get-Date -Date $_ -Hour 12 -Minute 0 -Second 0
    }
    [PSCustomObject]@{
        TimeRecordEvent='rest_end'
        RecordTime= Get-Date -Date $_ -Hour 13 -Minute 0 -Second 0
    }
} | Edit-JobCanAttendance -AditGroupId 10 -Verbose

これには ValueFromPipelineByPropertyName を使った。 Cmdlet のパラメータにパイプラインの入力オブジェクト(hashtable は No)が持つ同名プロパティをマッピングできるので、複数のパラメータをバインドできる。これ自分の書いた Cmdlet で使うことなかったので、いい勉強になった。

その後 PSScriptAnalyzer の指摘を修正して、さて公開しよう、というところで登録済みの勤怠を一覧するところにバグが見つかった。登録した日と勤怠の実績がずれるバグで、これは直したいな～というやつなので、公開はまた先送り・未遂に終わった。

続く。

あと別の文脈で、放置していたkrymtkts/PSMFAttendanceにメンテの予定がないよとアナウンスを追記した。これで Archive する準備も整った(まだしてない)。

これまた別の文脈で、現職では Slack に日報を投稿してから退勤するようにしてるので、そこから投稿時間を拾って退勤実績を作るようにしたいと考えている。そのために Slack からメッセージの一覧を取得し、 PSJobCanAttendance での一括編集にもっていきたい。

過去に似たようなことをしたとき、 RamblingCookieMonster/PSSlack を使った。しかし PSSlack は 2021 年頃の Slack API の変更に追いついてないので、使うには自力でパッチする必要がある。 (パッチは来てるが適用されていない Fix API deprecation 2021-02-24 by simonfagerholm · Pull Request #115 · RamblingCookieMonster/PSSlack)。

以前使った時はそうしたが、面倒なので .NET の Slack のモジュールとか探してなんとかしたい。でも、どのモジュールがいいんか...と調べるのも面倒なので、悩み中。

PowerShell の My Profile を掃除する

Sun, 23 Oct 2022 09:00:00 +0900

PowerShell の profile を Gist で管理してるのだけど、この度掃除をした。

My PowerShell profile.

片手間にできる範囲しかやらなかったので、使ってないモジュールと関数の取り除きが主。あとは順番をちょっと入れ替えてみたり、把握してなかった全貌を眺めてみた。

これらの取り除きついでに、供養がてら何のためにつかってたのかとか振り返ってみる。

モジュール取り除き

mklement0/ClipboardText: Universal clipboard text support for PowerShell, notably also in PowerShell Core (cross-platform) and Windows PowerShell v2-v4

ClipboardText というモジュール。コレなんで使ってたのかすら忘れてしまったけど、結構使ってた記憶がある。 Set-ClipboardText Get-ClipboardText が使えるようになる。 PowerShell Core を使い始めた頃はクリップボード操作の Cmdlet がなくてできなかったとかそんな理由だったか？

今やフツーに Set-Clipboard Get-Clipboard 使ってるので不要になったけどずっと消してなかった。今までありがとう、消した。

pocoも残ってるかな？と思ったが、そうでもなかった。 (変え漏れを除けば)意外にも pocof への変更は忘れてなかったらしい。

あとモジュールは跡形もなかったが、昔 GoogleCloud を使って勉強してたときの名残があったのでそれも消した。このモジュールもう 4 年くらいメンテされてない様子、残念やけど多分重要でないんだろうな。

関数取り除き

明らかな消し忘れ。 VirtualBox 関連

function Start-VBoxMachine() {
    vboxmanage list vms | Select-Pocof -CaseSensitive | Out-String -Stream | Select-String -Pattern '\{(.+)\}' | ForEach-Object { vboxmanage startvm ($_.Matches[0].Groups['1'].Value) --type headless }
}

function Stop-VBoxMachine() {
    vboxmanage list runningvms | Select-Pocof -CaseSensitive | Out-String -Stream | Select-String -Pattern '\{(.+)\}' | ForEach-Object { vboxmanage controlvm ($_.Matches[0].Groups['1'].Value) poweroff }
}

function Get-RunningVBoxMachines() {
    vboxmanage list runningvms
}

こんなのがあった。VirtualBox の GUI を介さずに VM の起動・停止をするための奴らだったか確か。前々職でコンテナ移行しきれてない秘伝の開発環境 VM がチラホラあって、それで使ってた記憶がある。あの VM ちゃん達は今も元気に VM してるのだろうか。もはや使うこともないので消す。でも供養がてら Gist に残しておいた。

krymtkts/scripts-for-virtualbox.ps1

なんだコレ。 `find` ぽい？やつ

function find {
    [CmdletBinding()]
    param(
        [string]$path = '.',
        [Parameter(Mandatory = $True,
            ValueFromPipeline = $True)]
        [string[]]$name,
        [switch]$delete
    )

    begin {
    }

    process {
        foreach ($n in $Name) {
            if ($delete) {
                Get-ChildItem -Recurse -Path $path | Where-Object -Property Name -Like $n | Remove-Item
            }
            else {
                Get-ChildItem -Recurse -Path $path | Where-Object -Property Name -Like $n
            }
        }
    }

    end {
    }
}

なんか薄っすらと、 Makefile から find 呼ぶときに何のシェルか考えるの面倒で PowerShell で find 作ろうとしてた覚えがあるのだけど、それをいつやってたのかわからない。いま使ってもないのでなんでここにあるのか不明。消す。

何故 profile に足した？クソデカテキストファイルを作る関数

function New-TextFile {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory)]
        [string]
        $Name,
        [Parameter()]
        [long]
        $Byte = [Math]::Pow(1024, 3),
        [Parameter()]
        [int]
        $Basis = [Math]::Pow(1024, 2)
    )
    begin {
        if (Test-Path $Name) {
            Write-Error 'overrides currently not supported.'
            return
        }
        $Remains = $Byte % $Basis
        $Per = $Byte / $Basis
    }
    process {
        1..$Per | ForEach-Object { 'x' * $Basis | Add-Content $Name -Encoding ascii -NoNewline }
        if ($Remains -ne 0) {
            'x' * $Remains | Add-Content $Name -Encoding ascii -NoNewline
        }
    }
}

前に書いた PowerShell でクソデカテキストファイルを作るの関数版だと思われる。わざわざ profile に入れておいたのはなんでだろう。スクリプトにするだけで良いのでは...過去の自分に問いたい。消した。

`psake` の auto completer 壊れてるで...

あと今回の掃除を通して psake の auto completer 壊れてるやんと言うのに気づいたので、直した。

Invoke-psake の存在チェックをしてあったら Register-ArgumentCompleter するようにしてた。けど、どっかのタイミングから invoke-psake が invoke-cpsake になってて、 auto completer が登録されなくなってた。

auto completer 周り、 aws_completer で Register-ArgumentCompleter 設定するとこも、 AWS CLI 1 の頃から使ってたのもあり AWS CLI 2 では要らなくなった部分がある(良くないけど PyPI からモジュール取ってたときの名残)。今回は対応を先送りにした。

おわり

そこまで消すものなかったな、というのが率直な感想だが、掃除してないな～という profile だった。

コマンドの存在をチェックしてから関数とか auto completer 登録するみたいなの増えてるので、この辺共通化したいなあ。でも共通化しだすとファイル分割もしたくなり、結局のところ今の Gist から取ってくるの終焉に向かうのでは...と思った。

なんかより良い(楽な) PowerShell の Profile 管理手段ないかなー。

F#でコマンドレットを書いてる pt.6

Sun, 16 Oct 2022 09:00:00 +0900

krymtkts/pocof の話。

hashtable サポートした。

やはり IDictionary 実装用に特別処理みたいなのを書いてあげないといけないかなーという気が若干してる。コイツ以外にも色々出てきたら面倒なので気が向かないけど、特別扱いなのはたしかにそうなので。

前回コメントしていた実装方針にした。先のことはわからないので、いま想定できない未来は未来の自分に託す。

これによって pocof は hashtable のエントリをフィルタできるようになった。クエリは hashtable の Key / Value それぞれに適用される。こんな感じ ↓。

@{a='1';b='2';c='3';d='a1';e='b2'} | pocof -NonInteractive -Query a

# Name                           Value
# ----                           -----
# a                              1
# d                              a1

ただしフィルタして得られる値は hashtable ではなく、 Object[] (中身は System.Collections.DictionaryEntry) になる。一瞬 hashtable に戻したいかな～と思ったが、色々使い道を模索しているときに以下のようなおもしろ利用法あるとわかったので、そのケースで不都合ありそうでやめた。

# 十把一絡げ
$misc = @(Get-Date; @{a=1;b=2;c=3}; (10..15))

# Sunday, 16 October, 2022 15:25:19
#
# Key   : c
# Value : 3
# Name  : c
#
#
# Key   : b
# Value : 2
# Name  : b
#
#
# Key   : a
# Value : 1
# Name  : a
#
# 10
# 11
# 12
# 13
# 14
# 15

$misc | pocof -NonInteractive -Query 15

# Sunday, 16 October, 2022 15:25:19
# 15

因みにこういったケースの活用方法はまだ見出していない。ただなんかこのファジーな検索あると面白そうなので残している。例えば、色んなものを array に詰め込んでおいて後でから見ようってアプローチとかになるんではないかと。仕事の製品コードにこういうの見つけたら卒倒しそうやけど、自分が terminal でなんかデータを捏ねくり回すときにあったら、新たな世界が開けるのでは？的な。しらんけど。

Out-ConsoleGridView はこういう事できなくて、同じ型が揃ってないとエラーになる。

$misc | Out-ConsoleGridView
# Out-ConsoleGridView: Object reference not set to an instance of an object.

Where-Object は流石懐が深くて、 -FilterScript を使えば同様のことができる。

$misc | ? {$_ -match 15}

ひとまず hashtable サポートも終えたので、プロパティ指定でフィルタする機能を実装する気持ちが高まってきてる。だけど、このファジーなフィルタの発見によって、フィルタ対象の array に登場する型をチェックしてプロパティを得て...みたいなことが必要になり、面倒さが増した。

率直に言ってコレだるいｗのだけど、こういう楽しみって趣味プロならではの醍醐味じゃないかな。第一ユーザが自分なので、自分が納得できないモノは許容し難いのよな。

まだまだゆるく長く楽しめそうな気配がしていて、良い。

Razer Blade Stealth 13 (2017)のバッテリーを換装する

Sun, 09 Oct 2022 09:00:00 +0900

My Laptop は Razer Blade Stealth 13 2017 モデルなのだが、流石に経年劣化が目立つようになってきた。バッテリーの膨張だ。

Razer Blade Stealth 13 は美しいアルミ削り出しボティなのだけど、ここ 1 年くらいは底面が何か弧を描いてんな～と感じていたものの、実用上支障がなかったので放置していた。ところが、夏を過ぎた頃になって蓋を締めたときにピッチリ閉まらなくなってきて「あ、これはヤバイな」と感じた。早急に交換が必要だと(あんま放置すると筐体の歪みが戻らなくなる)。

もう 4,5 年ものなので CPU の遅さや RAM の少なさ(16GB)も目立つといえば目立つのだけど、 PC のスタートアップやソフトウェアのアップデートに時間がかかる以外ではまだ開発したりゲームする上で対して不満はない状態(仕事だとイライラしそうだが)なので、~~円安世界で不要な出費を抑えるためにも~~バッテリーを交換して長く使おうと考えた。

参考にした記事 →RazerBlade のバッテリーを換装する – NEAREAL

ホントのところは iFixit のリペアキット込み込みバッテリが欲しかったのだけど、おま国で購入できなかった(結果無駄にアカウントだけ作ってしまった)。

なもんで Razer Blade Stealth 13 2017 モデルの型番を Amazon.co.jp で調べて、交換バッテリーをサクッと見つけた。何個もあったので一番安いのを選ぶ。購入したバッテリ

この判断が良くなかったのか、発送から到着まで 1 ヶ月以上かかった。「コロナ禍の影響で香港で物流が滞っている」と聞いたけど果たして...

正規バッテリじゃないみたいなので心配といえば心配だったけど、届いた品を見たら デル(株) て書いてたし、 PSE マークもあった。でも ㈱ の印字がみょーにずれてる。やっぱ模造品かな。

このバッテリ到着までの長い待ち時間の間にもどんどん膨らみ続け(最近特に酷かった)、タッチパッドのところが一目でわかるくらいに弧を描くようになった。もう限界や...というところで先日バッテリが届いたのでようやく換装に着手できた。

換装する

換装で触った範囲、バックパネルとバッテリの固定には 3 種類のネジが使われており、それぞれに対応するドライバが必要だった。

バックパネル
- トルクス T6 x 8 箇所
バッテリ
- プラス #1 x 6 箇所
バッテリコネクタの蓋
- プラス #0 x 2 箇所

バックパネルのネジを外すと自然とバックパネルが浮き上がった。かなりのエネルギーが抑圧されていたらしい。恐ろしすぎる。

先程 バッテリコネクタの蓋と書いたけど、バッテリのコネクタを覆うようにプラ板がついてた。恐らく外れないようにするための固定器具だが、コイツが後で困る。

バッテリはめてみたら 1 箇所だけ 0.3 mm ほどネジ穴とずれてしまってバッチリはまらなかった。仕方ないのでその一箇所だけ無理やりネジ込んだ。

そしてバッテリのコネクタ、フラットケーブルが長過ぎる...折りたたまないと接続できない。ここで先程のバッテリコネクタの蓋が組み合わさり、うまくはめるためにピンセットで絶妙な畳み込みをする必要があった。

以下の写真で波打つフラットケーブルとビミョーにずれた ㈱ が確認できる。

バッテリコネクタの蓋の隙間に畳み込まれたフラットケーブル。

バッテリの新旧を見比べてみる。古い方(下)からははち切れんばかりのエネルギーを感じる。ほんまに危なっかしいな。爆発する前に新バッテリが届いてほんと良かった。

換装後

換装前後で明らかに差を感じられる。異様に熱くならなくなってファンが回らなくなった。

ただ powercfg.exe /BATTERYREPORT でバッテリ容量が取れない。これってどうやったら解消されるんだろう？バッテリ残容量も 100% を指しててホンマか？というお気持ち。

powercfg.exe /ENERGY したらバッテリの容量が取れないというエラーになった。

Battery:Battery Capacity Unknown
The battery capacity could not be determined. This may indicate a firmware (BIOS) problem.
Battery ID RazerRazer Blade Stealth

バッテリ容量わからないと残容量もわからないのでは？再起動したら認識されるときもあって、その時は 41% だった。Razer Blade Stealth はバッテリ容量が少ないと赤いランプが灯るのだが、そこも真っ赤っ赤。試しに置きっぱなしにしてたら電力不足でシャットダウンしてた。

どうしたもんかと調査してみたところ、バッテリ交換後は使い切る → フル充電を数回繰り返すと良い、というような情報があったので参考にして 12,3 時間充電してみた。

よく見たら Amazon のバッテリのページにも同じようなことが書いてた。不自然な日本語でわからなかった。無理に日本語にせず英語にでもしたらいいのに。充電の部分がすっぱり抜けてて当初わからなかった。以下引用

''' 1.新しいバッテリを正常に使用する前に、容量を 10%程度に放電してからサイクルを 3 ～ 4 回満たしてください。0%まで放電しないように注意してください。そうすると、バッテリが壊れやすくなります。 '''

充電後、今朝改めて powercfg.exe /BATTERYREPORT してみたところ、 98% 48,949 mWh まで表示されるようになった。規格は 53.6Wh なのでまだまだ上まで充電されるのかな。 powercfg.exe /ENERGY のバッテリ容量のエラーも解消された。あと何度か繰り返してみて状況見てみるつもり。

正直なところ筐体が歪んでしまったかもな～と思っていたが、換装後はバッチリ元の平坦さを取り戻せた。たとえ模造品であろうと今のところは満足度が高い。放電充電繰り返して規格 MAX まで充電されるまでちょっと様子見。

F#でコマンドレットを書いてる pt.5

Sun, 02 Oct 2022 09:00:00 +0900

krymtkts/pocof の話。ほぼ実装におけるメモ、壁打ち。

Out-ConsoleGridViewを見て hashtable をフィルタできるのいいな～と思ったので、 hashtable サポートを始めている。誰得な機能ではあれど、これがあると自分にとって利用の幅が広がる。

ProcessRecord メソッドにおいて、 IDictionary 実装の場合のみ展開した要素を内部で保持するようにしてみた。一見して煩雑なので、なんかマシにしたい。 list にして list 外すあたりがどーにも。

     override __.ProcessRecord() =
-        input <- List.append input <| List.ofArray __.InputObject
+        let entries: list<obj> =
+            List.ofArray __.InputObject
+            |> List.collect (fun (o: PSObject) ->
+                match o.BaseObject with
+                | :? IDictionary as dct ->
+                    Seq.cast<DictionaryEntry> dct
+                    |> Seq.cast<obj>
+                    |> Seq.toList
+                | _ as o -> [ o ])
+
+        input <- List.append input entries

破壊的な操作ならすぐマシなのが思いつくが、ちょっと寝かせる。とはいえそっちでスッキリするならそっちがいいかな。いや待て、ここまで書いて fold の方がスッキリする気が...してきたので後でやってみる。

追記(2022-10-03)

要らんコードも取り除いてこうした。幾分マシかなあ。

     override __.ProcessRecord() =
-        input <- List.append input <| List.ofArray __.InputObject
+        input <-
+            List.ofArray __.InputObject
+            |> List.fold
+                (fun acc o ->
+                    match o.BaseObject with
+                    | :? IDictionary as dct ->
+                        Seq.cast<obj> dct
+                        |> Seq.fold (fun a d -> d :: a) acc
+                    | _ as o -> o :: acc)
+                input

     override __.EndProcessing() =
+        input <- List.rev input

この変更を加えることで hashtable の各要素を扱えるようになるけど、依然フィルタした結果は得られない。

pocof はいま内部的に各要素の ToString メソッドの結果に対して LINQ のクエリをかけてる。そのため DictionaryEntry のような ToString の結果が自身のクラスを示す文字列 System.Collections.DictionaryEntry を返す場合、使い物にならない。

未実装のプロパティ指定可能にする機能があればまあ使えるので先にやるべきと考えるが、プロパティ未指定時の挙動が定義できてないといけない。常時プロパティ指定なんてしないので、 ToString に値が反映されないタイプのオブジェクトの場合に、デフォルトでフィルタ可能な挙動を定義する必要がある。あーこっちのが大事やわ。やはり IDictionary 実装用に特別処理みたいなのを書いてあげないといけないかなーという気が若干してる。コイツ以外にも色々出てきたら面倒なので気が向かないけど、特別扱いなのはたしかにそうなので。

つづく

PowerShell でジョブカン勤怠管理を操作する

Sat, 24 Sep 2022 09:00:00 +0900

現職について半年が経とうとしている。幸運なことに毎日忙しく過ごしており打刻もままならん(~~単にいつも忘れてるだけ~~)。なので、またアレを作った。打刻スクリプトだ。

krymtkts/PSJobCanAttendance

現職はジョブカン勤怠管理を使ってるので、また新しく作る必要があった。とはいえkrymtkts/PSMFAttendanceをベースに開発(コピペ)しているので、構造的には同じ。異なるのはスクレイピングの部分だけといって過言ない。

個人的に考える目玉機能は以下の 2 つ。

OTP 対応
一括編集

1 については、認証時に OTP を取得する ScriptBlock 差し込めるようにしてある。現職では都合が良いことに 1Password を使わせえてもらえてるので、 op を使って取得した OTP が渡せるのだ。 ScriptBlock がない場合は入力を求めるプロンプトになる。

2 については、自分の現職における勤務実績の入れ方を考えると、絶対必要だったものだ。現職はフレックスでかなりゆるいのでほぼ勤怠管理無いに等しいが、打刻は求められている。ただ自身が怠惰なせいもあり、3 週間くらい打刻を忘れていて〆前に急いで入力するなんてことが多発している。これを楽にこなすためにも、今回は絶対に一括編集機能を作りたかった。休憩時間が自動入力の設定じゃないようなので、打刻漏れしたときの作業の重さは尚更だ。

以下のようにパイプを使った一括編集ができる。端的に言って、楽過ぎてヤバい(打刻しろ)。

@(12..16;20..22) | %{get-date "2022-09-$($_) 08:15:00+0900"} | Edit-JobCanAttendances -TimeRecordEvent work_start -AditGroupId 10

上記の様な感じで試しに 3 週ほどの実績をドバドバと書き込んでみたが、リクエストが拒否されることもなく使えて一安心だった。今回の打刻スクリプトを作るにあたり、毎度のごとく利用規約はチェック済みだ。利用規約｜ジョブカン勤怠管理を確認したが、こういうスクリプトを作ることに関し問題なさそうだった。

本当は 2022 年夏頃には一通り作ってたのだけど、その後 2 ヶ月位使わずに来てたので、この週末でまとめ上げた。来週から実際に使ってみて、熟れてきたら PowerShell Gallery に公開しようと考えている。

今回作ってみて気づいたこと。krymtkts/PSMFAttendance を作ったときは、同サービスの前例が 1 つくらいしかなかったのに、今回は前例を探せば結構ヒットした。「No.1 勤怠管理」の名は伊達じゃないな！と思わせるものがあった(何様)。

前に作った Money Forward クラウド勤怠のやつは、前職を離れて実行環境がないからもうメンテもできないし、そろそろ Archive してもイイ気がする。バグ残ったママだけど直して動作確認できないからしゃーない。

データ IDE DataStation のビルド関連メモ

Sun, 18 Sep 2022 09:00:00 +0900

ちょっと前に DataStation という OSS の IDE を知った。 GitHub の repo はこちら。multiprocessio/datastation: App to easily query, script, and visualize data from every database, file, and API.

データベース・ファイル・HTTP リクエストまで多様なデータソースへの接続をサポートしてたり、簡単にグラフ化、コードで加工したり、とにかく良い。 Notebook みたいといえばそんな感じ。

ちょっとコントリしたいネタがあり、その動作確認のためにビルドして実行する必要があった。その時の手順・つまづきポイントを備忘のために雑メモで記しておく。

DataStation のアーキテクチャについてはこちらのメモにある。そんなに詳しくないので自力で色々読んだり試したりした方がイイか。

datastation/ARCHITECTURE.md at main · multiprocessio/datastation

デスクトップアプリのビルドと実行

datastation/HACKING.md at main · multiprocessio/datastation

手順はこれを参照した。でも試してる途中でよくわからなくなってくるので、package.json を読んで各スクリプトが何者かは読んだ方がイイかも(実際そうした)。

ビルドと実行には WSL2 を使う。手順に記載のある通り Windows でもできるっぽい(tdm-gccというのを使う)けど、なんか面倒な気配がしたので Linux で楽をする。いつかチャレンジしてもよいが今ではないと判断した。 GCC は Go の SQLite3 モジュールをビルドするので必要っぽい。

ビルドの事前準備には依存関係のインストールスクリプトが用意されてる(CI 用だけど)。それを使って楽をする。 datastation/prepare_linux.sh

DataStation のデスクトップアプリは Electron アプリの様子。以下のビルド実行時に権限が必要だったのと、それによって --no-sandbox が必要になった。

sudo yarn build-desktop --no-sandbox

このビルド実行でライブラリが不足しているのがわかり、以下を参考にパッケージをインストールした。なんのエラーが出たかはメモを失念したが、 lib* が足りない系。足りない依存関係は皆 Electron のビルドに必要なものばかりだった。

この依存関係のインストール後にビルドが成功するようになったが、実行すると SQLite3 のエラーになった。内容は SQLite3 が古いと言われるものだった(メモ失念)。エラーログを見る限りこれの解消には Electron の再ビルドが必要なようだった(これあとから見てもピンとくるのかわからん。エラーログをメモらなかったことが悔やまれる)。

↓ の記事を参考にした覚えあり。 npm - Node - was compiled against a different Node.js version using NODE_MODULE_VERSION 51 - Stack Overflow

./node_modules/.bin/electron-rebuild

ここまでやって初めて ↓ のコマンドで Electron アプリを動かして動作確認できるようになった(理解のために結局 package.json に書かれたスクリプトを直で叩くようになる)。

yarn electron --trace-warning --unhandled-rejection=warn build/desktop.js --no-sandbox

runner の UT

DataStation のデスクトップアプリはいわばフロントエンドで、データソースとの接続やデータ読み取りは Go で書かれた datastation/runner で行われてるようだった。

なので UT の実行に関しては先述のディレクトリで go test するだけで OK だった。とはいえ前の節で先述した通り、 GCC に依存したモジュールのビルドがあるので WSL2 でやるのが良かろう。

終。

F#でコマンドレットを書いてる pt.4

Sat, 10 Sep 2022 09:00:00 +0900

krymtkts/pocof の話。

めちゃめちゃ放置してたのだけど、 8 月末くらいから触れるようになってきたので、気になる部分ですぐ変えられる部分を書き換えて、 PowerShell Gallery に公開した。はじめたころから 4 ヶ月くらい経ったのか。

PowerShell Gallery | pocof 0.1.0-alpha

現時点に公開する動機としては、自分の普段遣いでは未だ poco を使ってるというのもあって、折角なのでそれを pocof に変えようと考えた次第だ。一部機能に関しては未実装なので、オプションはコメントアウトして隠した形で公開している。

大きい変更としては、PowerShell オブジェクトを作成せずに PSCmdlet のサブクラスの中で PowerShell の Cmdlet を呼び出す方法がわかったので、その辺を書き換えた。これが非常に参考になった →InvokeCommand.InvokeScript not returning Output · Issue #12137 · PowerShell/PowerShell

DLL のモジュールを公開するのは初めてだったので、これまた躓きつつも先達の知恵を借りて乗り越えられた。これ → Writing a PowerShell Core Module With F#, A Complete Guide | Brianary

結局始めた頃はフォルダ指定の公開でええんちゃうかと思ってたが、 Import-Module してから公開する方がめっちゃ楽なので、参照元に従いそう変えちゃった(こだわり無し)。そもそもこの記事がなかったら pocof はサクッと始めてなかったので、感謝しかない。

それと特に意図があった訳ではないが、 PowerShell Module Manifest で使ったことがなかった PreRelease を使ってみたりもした。

公開にあたっての目玉機能は何もない。何なら poco の機能で未だ実装してないものもある。ただいくつか自分が poco を使っていて困ってたことは、これで解消される。

正規表現パターンの記述中にエラーで落ちない
クエリ記述中に左右カーソル移動ができる(buggy な疑いアリ)
(あとテスト用の非対話モード ← 普段利用ではまじで意味ないけどテストが楽)

今後欲しい機能としては、とりあえず自分の使い方だと、プロパティ周り。プロパティ指定のフィルタとプロパティ入力の補完ができたら相当楽になる。表示するプロパティが選べたりしたら最高。

pocof で印字されたアイコングリフが ?? になってたり他にも色々未実装・直さないといけない点あれど、自分が普段使うツールを自分の手でコントロールできる(しかも学習まで兼ねて)というのは、イイことやなと改めて思った。

Out-GridView の CUI 版 Out-ConsoleGridView

Sat, 03 Sep 2022 09:00:00 +0900

最近知ったのだけど、 Out-GridView の PowerShell Team 謹製 CUI 版 Out-ConsoleGridView があったらしい。これが使えるヤツだったら poco も今作ってる pocof も要らんやん、と思った。

PowerShell/GraphicalTools: Modules that mix PowerShell and GUIs/CUIs! - built on Avalonia and gui.cs

元々 CUI 使ってるのに Out-GridView で GUI 表示しないとインタラクティブな絞り込みできないのがイヤで peco を使ってたってのがある。 peco は PowerShell に最適化されてないから、その後オブジェクトのまま取り扱える jasonmarcher/poco にたどり着いた。その後 poco の独自実装を自分で始めたのが pocof(F# の練習がてら)。

なもんで、 Out-GridView の CUI 版があってもしイイ感じに使えるのなら、この長年の変遷に終止符を打つんちゃうかな的な。

以下 README.md に従い試す。

Install-Module Microsoft.PowerShell.ConsoleGuiTools -AllowPrerelease -Scope AllUsers

Get-ChildItem | Out-ConsoleGridView

space キーでオブジェクトを選択するか Ctrl+A で全選択して、 Enter で選択した結果を出力する。 -Filter オプションに渡した値で初期表示がフィルタリングされた形になる。そのままタイプしてもフィルタ入力できない。Tab キーを押してフィルタのテキストにフォーカスできる。フィルタは正規表現のみみたい。不正なパターンを入れたらちゃんとエラー表示されてエライ。必ず結果を洗濯した状態でEnter 押さないと結果が得られないのはちょっとメンドイ。わたしは使わないけどマウスコントロール(クリックどころかスクロールまで)できるのもすごいな。背景変わるの好きになれないので、今後色とかキーとかのオプション充実したりするかなあ。インクリメンタルサーチじゃないのも微妙に好みじゃない操作性だ。

poco、 pocof 共にバッファを元に戻すとレイアウトの崩れが起きるのだけど、 Out-ConsoleGridView は崩れない。素晴らしい。表示域にないスクロール可能な部分は吹っ飛んでしまうけど、崩れない方法は真似させてもらいたい(MIT ライセンスなので)。けど、コード読んだ感じどこかわからなかった。

Out-ConsoleGridView は CmdLet の出力に FormatViewDefinition Class (System.Management.Automation) | Microsoft Docsを自前で作ってるみたい。なので PowerShell で表示される内容とちょっと違う。それ故か、例えば Get-InstalledModule のような情報量の多い結果を表示するとちょっと悲しい感じになってしまった。 format.ps1xml が利用されないせいかな。しかしこのクラス使い方がわからなかったので勉強になるわ。

Get-InstalledModule | Out-ConsoleGridView

pocof でやりたいことと方向性が違うなあという感じなので、作ってるものを今すぐブン投げ捨てる必要はなかったようだ。こちらの開発は趣味プロで続けようと思った。しかしコード参考にできるものが増えたのでとても助かるなぁ。

Bootstrap のバージョンを上げる

Sat, 27 Aug 2022 09:00:00 +0900

先週の記事を書いたあとで、何の気なしに Measure page quality - web.dev で当ブログの測定をした。そこで既知の脆弱性があるライブラリ (Bootstrap@3.3.0 と jQuery@1.11.0)使うなよ！みたいなレポートがでたので、 Bootstrap の更新を思い立った。

変更した内容 → Upgrade bootstrap from 3 to 5. · krymtkts/krymtkts.github.io@c4adeac

ブログ作成当時の記事(Clojure でブログを作った)を見ると、このブログのテーマは Cryogen 備え付けのテーマである blue_centered をコピって作ったものだった。そのままずっと使ってるので、当然の如くテンプレで利用しているライブラリも古いままだったという訳だ。

さて、 Bootstrap のマイグレーションは当然ドキュメントがあるわけだが、

今回は~~手抜きによる~~ v3 → v5 という飛び級であるし、わたし自身は Bootstrap に慣れてないので、とりあえずマイグレーションで対応するのは目で見て影響がある範囲のみとした。マイグレーションとしては正攻法な感じじゃなくて、割りと雑な感じだ。

それらの変更は例えば CSS のセレクタの変更だったり、 class 属性の変更だったりだ。一応レスポンシブなデザインなので PC とモバイル(ブラウザのエミュレータだけど)も見ている。ちょいちょい以前と違うデザインにした・或いは意図せず変わった箇所もある。

途中コンテンツを空で更新したままデプロイしてしまうしょーもないミスがあったが、再度コンテンツを生成して事なきを得た。これ Cryogen の差分ビルドの影響でちょいちょいやらかすのだけど、普段は人間力でカバーしていたところを今回はできず、デプロイしてしまった次第。この記事の投稿時点で設定を見直した。

今回の VerUp により Best Practices は 92 -> 100 に、あと Performance も 93 -> 94 と意図せず微妙な好影響があった。

before
after

Bootstrap 5 では CSS カスタムプロパティでフォントサイズとか色とか変えられるみたいなので、このブログ用に再定義してるスタイルのいくつかは不要になるんじゃないかな。これを機にちょっと見直すのもありかも知れない。あるいは別の静的サイトジェネレータに乗り換えるとか。他にやることなくなったらそれも一興か。

終。

Windows Terminal で OSC133 する

Sat, 20 Aug 2022 09:00:00 +0900

先週は盆の関係で時間が取れず書くのをサボった。まあその前の日曜に余分に書いてたし相殺したことにしておく。

きょうは Windows Terminal でもシェル統合みたいなのができるらしいと気づいたので、それを試す。

ちょっと古い Windows Terminal Preview のリリースノートを見てて気づいた。

Release Windows Terminal Preview v1.15.186 · microsoft/terminal

Get-GitHubRelease -OwnerName microsoft -RepositoryName terminal -Tag v1.15.1862.0 | select -ExpandProperty body | % {$_ -split "`n"} | sls -Pattern '\[Experimental\]' -Context 0,10 で雑に抽出。

[Experimental] We now support scrollbar marks! (#12948) (#13163) (#13291) (#13414)

Use the addMark action to add a scrollbar mark

The color optional parameter can be used to specify a color

Use the scrollToMark action with a specified direction parameter to scroll between the marks
Use the clearMark action to remove a selected mark
Use the clearAllMarks action to remove all scrollbar marks
The experimental.autoMarkPrompts profile setting can be set to true to automatically mark each prompt

NOTE: This uses the FTCS_PROMPT sequence from FinalTerm, OSC 133 ; A, which we now support! (#13163)

The experimental.showMarksOnScrollbar profile setting can also be set to true to display the marks on your scrollbar

ほう？プロンプトに自動でマーカーを付けられる様になったらしい。

この機能使いたかったが、端末乗り換えて profile にシーケンス足して...みたいなのが必要っぽかったのでメンドイなーと思ってけど、端末だけで対応できるのなら非常に楽。

これはやりたい。試してみる。

Windows Terminal の設定

利用している Windows Terminal Preview のバージョンは Version: 1.15.2282.0 だった。

以下のような感じの設定で試す。実際の settings.json は他の設定でゴチャついているので、要所だけ切り抜いた。

{
  "$help": "https://aka.ms/terminal-documentation",
  "$schema": "https://raw.githubusercontent.com/microsoft/terminal/main/doc/cascadia/profiles.schema.json",
  "actions": [
    {
      "command": {
        "action": "addMark",
        "color": "#CB4B16"
      },
      "keys": "ctrl+m"
    },
    {
      "command": {
        "action": "scrollToMark",
        "direction": "previous"
      },
      "keys": "ctrl+up"
    },
    {
      "command": {
        "action": "scrollToMark",
        "direction": "next"
      },
      "keys": "ctrl+down"
    },
    {
      "command": "clearAllMarks",
      "keys": "ctrl+d"
    }
  ],
  "profiles": {
    "defaults": {
      "experimental.autoMarkPrompts": true,
      "experimental.showMarksOnScrollbar": true
    },
  },

JSON Schema については、https://aka.ms/terminal-profiles-schema の方はバージョンが古いので Preview 使ってると色々不都合がある。ので repo 直で見る。

試してみて、とりあえずすべて期待通りに動くのがわかった。

はじめスクロールバーに色がつかなくて、はて？だったけど、これは settings.json の記述が間違ってたからだった。 experimental.autoMarkPrompts, experimental.showMarksOnScrollbar は profiles 直下じゃない。 profiles.defaults に書かないとダメ。

これに気づいたのは settings.json の JSON Schema のここ見たら、 Profile 毎の property であることがわかったから。

ドキュメントにもこの機能出てた。あとから気づいたわ。 Scroll marks (Preview)- Windows Terminal Advanced Profile Settings | Microsoft Docs

ドキュメントの方は、タイトルも「Advanced profile settings in Windows Terminal」やし、こっちならパっと見で気づけたかな...まあよし。

今回この件を調べてから、 megathread: Scrollbar Marks · Issue #11000 · microsoft/terminal という巨大な Issue を見つけた。きょう試した experimental な feature もここ由来のもの。

まだ VS Code のそれに比べると相当しょぼい。またコマンドの成功・失敗に対応してマーカーの色分けがつくとかもない。けど、この Issue 見るにそれらはそのうちやるっぽい(category というやつかな)。なので、 subscribe しておいて新しいのが来たら是非試したい。

普段仕事で使う標準出力が長い cdk とか AWS Tools for PowerShell とかの実行結果を飛び回るのに、こんなに有効な機能が来たことは喜ばしい。来週の仕事から早速使う。

余談

ついでに useAcrylic = true じゃないとき、 opacity だけで古き良き透過にできるのにも気づいた。 Windows 11 で ver1.12 から使えたらしい...気づくのに時間がかかったけど、これもやりたかったことのひとつなので、良い。

Opacity - Windows Terminal Appearance Profile Settings | Microsoft Docs

git で local repo が自分のものじゃないとなったやつ

Sun, 07 Aug 2022 09:00:00 +0900

今日はブログ書くつもり無かったけど、これまた起こったらなんかハマりそうやなーと思ったので、したためた。

何があったかわからんが、 git に local repo の所有権が自分にないと言われてエラーになった。

PS> git status
fatal: detected dubious ownership in repository at 'C:/Users/takatoshi/dev/github.com/krymtkts/Get-GzipContent'
To add an exception for this directory, call:

        git config --global --add safe.directory C:\Users\takatoshi\dev\github.com\krymtkts\Get-GzipContent
Set the environment variable GIT_TEST_DEBUG_UNSAFE_DIRECTORIES=true and run
again for more information.

safe.directory が設定されているパスなのだけど。

PS> git config --list | ? {$_ -like 'safe*'}
safe.directory=C:/Users/takatoshi/dev/*

GIT_TEST_DEBUG_UNSAFE_DIRECTORIES でデバッグメッセージを有効化できるそうなのでしてみたところ、以下の様なのが出た。最近使ってた local repo では出なくて、~~放置してた~~ 最近ご無沙汰だった repo で出ている。

PS> $env:GIT_TEST_DEBUG_UNSAFE_DIRECTORIES=$true
PS> git status
warning: 'C:/Users/takatoshi/dev/github.com/krymtkts/Get-GzipContent/.git' is owned by:
        'S-1-5-32-544'
but the current user is:
        'S-1-5-21-3808303910-2770483448-703627078-1001'
fatal: detected dubious ownership in repository at 'C:/Users/takatoshi/dev/github.com/krymtkts/Get-GzipContent'
To add an exception for this directory, call:

        git config --global --add safe.directory C:/Users/takatoshi/dev/github.com/krymtkts/Get-GzipContent

owner が違う...なんで owner 変わってしまってたんだろう。ユーザー 1 人しかいないのに。あーハイハイ、と想像がついたので試したところ、管理者権限でならエラーが出ない。

どうも過去に管理者権限で作成した local repo の所有者が Administrator になってた模様。それが最近の Git for Windows の更新で検知されるようになったんだ。

Windows で所有者を変更する方法を調べてみて、それっぽい手順があったのでそれに倣う。 Windows のこの辺の昨日全然知らないので、どっかのタイミングで調べないといけないな。 Using Takeown.exe Command to Take Ownership of a File or Folder – TheITBros

takeown /F C:\Users\takatoshi\dev\github.com\krymtkts\Get-GzipContent /R
# SUCCESS: The file (or folder):  ....
# えげつない量の印字...

PS> git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

イイね。直せた。他のディレクトリも所有者を変えた。

takeown.exe /f . /r | Out-Null
# えげつない量の印字を無に帰す...

終。

Get-GzipContent のユースケース

Sat, 06 Aug 2022 09:00:00 +0900

以前 krymtkts/Get-GzipContent: Get-Content for gzip files. というのを作って PowerShell Gallery に公開した。

当時 gzip された JSON を扱う機会が多かった。その時の職場は bash 文化だったのだけど、自分のローカルでは PowerShell を使うし...ということで、モジュールが欲しかった。この PowerShell で gzip を展開するコード自体よく知られてるパターンらしかったけど、登録されてるモジュールがなかったので、自分で作った。ちゃんと探したら似たモジュールはあったのだろうけど、周辺モジュールもドカッと入るのは期待するところでないので、単機能のモジュールを作ったんだ確か。

最近になってまた gzip されたファイルを扱う機会が増えたので、改めて使う機会が来たのだけど...これちょっとイマイチやなーと思っている。

CloudFront のアクセスログで標準ログというのがあるのだけど、こいつは gzip された TSV で、これを PowerShell で取り扱うのに以下の関数を作った。

function ConvertFrom-CloudFrontAccessLog {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory = $true,
            Position = 0,
            ValueFromPipeline = $true,
            ValueFromPipelineByPropertyName = $true,
            HelpMessage = 'Path to one or more locations.')]
        [Alias('PSPath')]
        [ValidateNotNullOrEmpty()]
        [string[]]
        $Path
    )
    begin {
        $header = 'date', 'time', 'x-edge-location', 'sc-bytes', 'c-ip', 'cs-method', 'cs(Host)', 'cs-uri-stem', 'sc-status', 'cs(Referer)', 'cs(User-Agent)', 'cs-uri-query', 'cs(Cookie)', 'x-edge-result-type', 'x-edge-request-id', 'x-host-header', 'cs-protocol', 'cs-bytes', 'time-taken', 'x-forwarded-for', 'ssl-protocol', 'ssl-cipher', 'x-edge-response-result-type', 'cs-protocol-version', 'fle-status', 'fle-encrypted-fields', 'c-port', 'time-to-first-byte', 'x-edge-detailed-result-type', 'sc-content-type', 'sc-content-len', 'sc-range-start', 'sc-range-end'
    }
    process {
        $Path | ForEach-Object { (zcat $_) -split "`n" } | ConvertFrom-Csv -Delimiter "`t" -Header $header
    }
}

ForEach-Object { (zcat $_) -split "`n" } ここがイケてない。まじで使いにくい。改行コードずつ Write-Object するようにしてないから、自分で分割しないといけなくなってしまっている。当時は改行なし JSON ばかり取り扱ってたので、全く気づかなかったのかなと思っている(しらん)。

↓ こうできたらすごくイイ気がする。

$Path | zcat | ConvertFrom-Csv -Delimiter "`t" -Header $header

breaking change なのもあるしバージョン 1 にするかーとか思っている。後方互換のスイッチ要るかな？とか分割単位を指定できるのが良いのかな？とか考え出すと、やる気が... ま、 Get-Content と似た動きにしたいってのがあるので、 -Delimiter かなー。

でも、とりあえず数年後し？のセルフ使用レビューを経てツールを改善しよ...という気になったので、自分のために書いたモジュールでもあるし自分が必要な範囲で直そ。使ってる人がおこになったらちょっと考える。

さっさと直したらいいのだけど、動機づけとしてこの記事をしたためた。あとはやるだけ... Add the -Delimiter option like Get-Content. · Issue #3 · krymtkts/Get-GzipContent

AWS Tools for PowerShell のビルド素振り

Sat, 30 Jul 2022 09:00:00 +0900

今年は積極的に？ AWS Tools for PowerShell を使ってることもあって、また Issue 書くことあるかなー、なんなら PR 書いて貢献した方がいいよなと考えるに至り、 aws/aws-tools-for-powershell のビルドを素振りしてみた。残念ながら、 contribution 関連でビルドの方法がレクチュアされてる文書とかなかったので、手探りでやってる。

まず、サービス毎の膨大なプロジェクトがあるし、試しに単体のプロジェクトをビルドしたかったのだけど、関連付く DLL が無くてビルドできなかった。 Amazon.Runtime とかいうやつ？この repo 内のどれかのプロジェクトでビルドされるんだろうけど。

buildtools/ 配下を見ると、どうも CI が CodeBuild らしい(当然のごとく)。この buildtools/ci.buildspec.yml の中に記載されている全体のビルドで使ってるプロジェクトなら上手くいきそうな雰囲気がしたので、これでフルビルドを試した。

dotnet --version
# 6.0.302
dotnet build .\buildtools\build.proj
# めちゃくちゃ大量のビルドログが出力される...

ところがこのフルビルドしだしたらクッソ重い...ビルドが終わらない。わたしの Razer blade stealth 2017 モデルだと CPU 使用率が天井に貼り付いて、過去にない位にヒートアップしてて心配な気持ちにさせてくれた。

結果、 41 分かかってなんとかビルドに成功した。

で、出力結果を見たら改行コードが変わってしまったみたいでエグい差分が発生してしまった。元コードは全部 LF なのだけど、 Windows でのビルドによって CRLF になってしまったみたい。CodeBuild では .NET Core 3.1 でビルドしてるから .NET の関連ツールを使ってても LF になるんやろが、こちとら Windows 。どこで変わったか調査して再発を防ぎたいけど、別の機会にする。

これで基盤的な DLL は生成されたであろうし、サービス個別のプロジェクトのビルドを試すと、うまくいった。

dotnet build .\modules\AWSPowerShell\Cmdlets\Lambda\AWS.Tools.Lambda.csproj
# ...中略...
#
# Build succeeded.
#     0 Warning(s)
#     0 Error(s)
#
# Time Elapsed 00:00:01.81

テストは PowerShell で Cmdlet に対して行う Pester のやつがあるのみで、かつこれらの内容を見てると当然のごとく AWS リソースがある前提。なので、多分個人では金がかかってできないやつ。デプロイ用の CFn とかもないし。 PR のワークフローで対処してんのかなー。

想定以上に時間がかかったけど、とりあえずなんか修正したいときに手元でビルドするための知識は貯まった。フルビルドで改行コードが書き換わってしまう、サービス単体のビルドに必要な最小限の依存関係を理解する、辺りが宿題かな。

世界中の誰にも使われていない？ Glue のタグ付け Cmdlet

Sat, 23 Jul 2022 09:00:00 +0900

現職にて AWS のコストを可視化すべく、既存の AWS リソースにひたすらコスト配分タグを付与していく作業をしている(勝手に)。 Cost Explorer を眺めてコストのかかり具合を見るのは、 AWS の醍醐味というか楽しみだと思ってるのだけど、あんまり共感を得られたことがない。

タグ付けにはタグエディタを使ってしまっても良いのだけど、折角なので、何を実行したかを形に残せしたい。そこで AWS Tools for PowerShell でやってる¹のだけど、とあるサービスだけなんか他のサービスのタグ付け Cmdlet は作法が違ってた。

Glue 君のことね。 Glue: Add-GLUEResourceTag Cmdlet | AWS Tools for PowerShell

この御方なんか知らんけど Tag[] じゃなくて hashtable を受けつける。コレまた当然のごとく Reference にはサンプルコード載ってないので、念のためググるかーと思いググったところ...

9 件しかヒットしなかった(2022-07-22 時点)。マジで？世界中で誰も使ってないのか、はたまたショボ過ぎて誰も記事にしないのか。

因みに使い方には困ることもなく、実行した結果も期待通り、ちゃんとタグが付いてた。

$AccountId = Get-STSCallerIdentity | Select-Object -ExpandProperty Account
$Region = Get-DefaultAWSRegion | Select-Object -ExpandProperty Region
$Tag = @{
    'service' = 'my-service'
    'stage' = 'dev'
    'cost' = 'my-service-dev'
}
Get-GLUECrawlerList | ForEach-Object {
    # Glue Crawler の ARN が `Get-GLUECrawler` から持ってこれなくて、みすぼらしく手で組んでる。
    Add-GLUEResourceTag -ResourceArn "arn:aws:glue:${Region}:${AccountId}:crawler/$($_.Name)" -TagsToAdd $Tag
}

AWS Glue でリソースタグがサポートされて 3 年ばかり経ってるけどみんな使ってないのかなーとか、他にも使われてない Cmdlet があるんやろなーと、思いを馳せた。

AWS CLI の方はというと "aws glue tag-resource" で 3 件しかヒットしなかった。

しかしながらヒットした記事は実行例が分かるものになってて、こう...なんか AWS Tools for PowerShell の人気の無さが際立つなーと感じた。

他を見る

雑だが、 AWS Tools for PowerShell のリソースタグ関連の Cmdlet で、タグのパラメータの型が何か調べるスクリプトを書いた。 CRUD 全部の Cmdlet が含まれるのであまり正確ではない。

わたしは AWS Tools for PowerShell の特定のモジュールしか入れてないから全体はわからんけど、傾向は見られる。

# AWS.Tools.* modules must be imported first to get all property information.
Get-Module -Name *AWS* | Import-Module
Get-Command *Tag* | Where-Object -Property Source -Like '*aws*' | ForEach-Object {
    [pscustomobject]@{
        Name = $_.Name
        TagParameterType = $_.Parameters.Values | Where-Object -Property Name -Like '*tag*' | Select-Object -ExpandProperty ParameterType
    }
} | Where-Object -Property TagParameterType -NE $Null | Group-Object TagParameterType

# Count Name
# ----- ----
#    31 System.String[]
#     8 Amazon.IdentityManagement.Model.Tag[]
#     4 System.Collections.Hashtable
#     3 {System.String[], System.String[]}
#     3 Amazon.CodeDeploy.Model.Tag[]
#     3 System.String
#     2 Amazon.OpenSearchService.Model.Tag[]
#     2 Amazon.AutoScaling.Model.Tag[]
#     2 Amazon.EC2.Model.Tag[]
#     2 Amazon.S3.Model.Tag[]
#     2 Amazon.Redshift.Model.Tag[]
#     2 Amazon.CertificateManager.Model.Tag[]
#     1 Amazon.ECS.Model.Tag[]
#     1 Amazon.CloudWatch.Model.Tag[]
#     1 Amazon.SimpleNotificationService.Model.Tag[]
#     1 Amazon.StepFunctions.Model.Tag[]
#     1 Amazon.SecretsManager.Model.Tag[]
#     1 Amazon.ECR.Model.Tag[]
#     1 Amazon.RDS.Model.Tag[]
#     1 Amazon.KeyManagementService.Model.Tag[]
#     1 Amazon.KinesisFirehose.Model.Tag[]
#     1 Amazon.DynamoDBv2.Model.Tag[]
#     1 Amazon.ECR.ImageTagMutability
#     1 Amazon.ElasticLoadBalancingV2.Model.Tag[]
#     1 Amazon.ElastiCache.Model.Tag[]
#     1 Amazon.QuickSight.Model.Tag[]
#     1 Amazon.EventBridge.Model.Tag[]

*.Tag[] が多数派かなーと。 31 System.String[] これは多分削除とか取得かな。ただしこいつら *.Tag[] グループの中でも、プロパティが Key だったり TagKey だったりの派閥があるので、ほんま「みんな違ってみんないい」的状態。

おわり。

既存リソースは IaC じゃないので、コマンドでタグ付けするため。 ↩

F# の AWS CDK で EventPattern の記述を無理やり通す

Sat, 16 Jul 2022 09:00:00 +0900

前に書いた、 F# の AWS CDK で EventRule のパターンが正しいのにエラーとなるやつ。

こういうのをしたいところ、

EventPattern:
  source:
    - aws.s3
  detail-type:
    - Object Created
  detail:
    bucket:
      name:
        - Ref: バケツ
    object:
      key:
        - prefix: test/

以下の記述だとエラーになる。

EventPattern =
    EventPattern(
        Source = [| "aws.s3" |],
        DetailType = [| "Object Created" |],
        Detail =
            dict [ ("bucket", dict [ ("name", [| bucket.BucketName |]) ])
                    ("object", dict [ ("key", [| dict [ ("prefix", "test/") ] |]) ]) ]
    )

Unhandled exception. System.ArgumentException: Could not infer JSII type for .NET type 'IDictionary`2' (Parameter 'type')

この Issue っぽい。 DotNet: Unable to pass interface instance through in a Dictionary<string, object> · Issue #1044 · aws/jsii

けど、 IDictionary<string,obj> は使えてる部分もあって微妙に違うしなー。より詳細な型がここ(EventPattern)にはないし、どないすりゃいいんじゃ。

色々とこねくり回した末に、 CFn のリソースを直接上書きすることで回避できるのがわかった。 Escape hatches - AWS Cloud Development Kit (CDK) v2

krymtkts/aws-cdk-fsharp-trial からコードを抜粋する。

配列内に IDictionary<string,obj> がいると型が解決できなようだったので、空の配列で定義しておき、後でから IDictionary<string,obj> 要素を差し込む！野蛮過ぎる...

    let rule =
        Rule(
            this,
            "bucket-event",
            RuleProps(
                RuleName = "buckt-event",
                Description = "bucket event.",
                EventPattern =
                    EventPattern(
                        Source = [| "aws.s3" |],
                        DetailType = [| "Object Created" |],
                        // NOTE: cannot write like below because JSII is unable to use `IDictionary<string, object>` inside the array.
                        // Detail =
                        //     dict [ ("bucket", dict [ ("name", [| bucket.BucketName |]) ])
                        //            ("object", dict [ ("key", [| dict [ ("prefix", "test/") ] |]) ]) ]
                        Detail =
                            dict [ ("bucket", dict [ ("name", [| bucket.BucketName |]) ])
                                   ("object", dict [ ("key", [||]) ]) ]
                    )
            )
        )

    // NOTE: the escape hatch for IDictionary<string, object>` inside the array is raw overrides.
    do
        match rule.Node.DefaultChild with
        | :? CfnRule as ep -> ep.AddPropertyOverride("EventPattern.detail.object.key.0", dict [ "prefix", "test/" ])
        | _ -> failwith "You passed a wrong variable that is not of type CfnRule!"

cdk synth でエラーせずに、以下の出力が得られるようになった。

bucketeventF2FCD38A:
  Type: AWS::Events::Rule
  Properties:
    Description: bucket event.
    EventPattern:
      detail:
        bucket:
          name:
            - Ref: sourcebucketE323AAE3
        object:
          key:
            - prefix: test/
      detail-type:
        - Object Created
      source:
        - aws.s3
    Name: buckt-event
    State: ENABLED
    Targets:
      - Arn:
          Fn::GetAtt:
            - samplefunctionAA39FD5B
            - Arn
        Id: Target0
  Metadata:
    aws:cdk:path: AwsCdkFsharpStack/bucket-event/Resource

宣言的に書きたいのにこんなツギハギが要るとか、めちゃくちゃ不便極まりない。

これは F# のせいじゃないけど、この .NET の不便な側面を許容してまで F# で CDK したいかというと、まずないな...と思った。これに関連して AWS CDK の Issue をちょいちょい調べたが、 .NET や Java で CDK するの辛そうやな..とうっすら思えた。茨の道を突き進むなりの良さがあるのだろうか。

改めて、仕事は素直に TypeScript を採用して良かったと実感した。

PowerShell で大量の HTTP リクエストを送る場合の Tips

Sat, 09 Jul 2022 09:00:00 +0900

大量のアクセスログがほしい事情で、テスト環境に大量のリクエストを送りつける必要があった。

JMeter とか Gatling 使えば済む話なのだけど、すぐに使い回せるものがなかったし、パパっとやってしまいたかったので PowerShell を使ってみたら、エラーになった。

$requests = 'aaa=10&bbb=20', 'aaa=11&bbb=21', 'aaa=12&bbb=22'
$requests * 100000 | ForEach-Object -Parallel {
    Invoke-WebRequest -Method Get -Uri "https://$using:testDomaain?$_"
    $jitter = Get-Random -Minimum 3 -Maximum 23
    Start-Sleep -Milliseconds (95 + $jitter) # 待ち
} -ThrottleLimit 100 | ConvertTo-Json | Set-Content ./responses.json

こういうのでタコ殴りにすると...

Only one usage of each socket address (protocol/network address/port) is normally permitted

15000 件を超えた辺りでこうなった。なんだ？ググる。

System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted

ポートが枯渇するんだと。 PowerShell の実装を見た訳じゃないけど、大量に実行された Invoke-WebRequest で HttpClient を大量作成したのであろうことは、想像するに易い。

同じ HttpClient を使い回せば良いらしいので、そうした。

$requests = 'aaa=10&bbb=20', 'aaa=11&bbb=21', 'aaa=12&bbb=22'
$h = New-Object System.Net.Http.HttpClient
$requests * 100000 | ForEach-Object -Parallel {
    ($using:h).GetAsync("https://$using:testDomaain?$_").GetAwaiter()
    $jitter = Get-Random -Minimum 3 -Maximum 23
    Start-Sleep -Milliseconds (95 + $jitter) # 待ち
} -ThrottleLimit 100 | ForEach-Object {$_.GetResult()} | ConvertTo-Json | Set-Content ./responses.json

そんだけ。

参照
- Need Official Guidance On using HttpClient in Functions · Issue #1806 · Azure/azure-functions-host
- Calling Async .NET Methods from PowerShell

F# で AWS CDK して躓いてる

Sun, 03 Jul 2022 09:00:00 +0900

最近仕事で AWS CDK を使ってみたが、非常に良い感触だった。仕事では TypeScript を採用したが、テンプレートが提供されている言語を見るとなんと F# がいるではないか。

PS> cdk init --list
Available templates:
* app: Template for a CDK Application
   └─ cdk init app --language=[csharp|fsharp|go|java|javascript|python|typescript]
* lib: Template for a CDK Construct Library
   └─ cdk init lib --language=typescript
* sample-app: Example CDK Application with some constructs
   └─ cdk init sample-app --language=[csharp|fsharp|go|java|javascript|python|typescript]

単に「C# のクラス用意したから継承して使ってや～」的なもので F# 向けに調整されてないだろうが、コレ誰が使うねんという気がしたので、試してみた。

参考にした前例たち。非常に参考にさせてもらった。

まずテンプレからプロジェクトを生成した素の状態で CFn を作成してみる。

cdk init sample-app --language=fsharp
cdk synth

ちゃんと CFn をビルドできた。どんなコードが出るか知りたかったので sample-app を使ったが、ここで app テンプレを使うと、利用されない this が残ってるので警告が出る。でも勿論 CFn をビルドできる。

記述に関しては TypeScript など他の言語と大差なさそう。ただ予想通り C# との相互運用は前提になってる。宣言的に記述する箇所については let バインディングして、リソースに手続き的に何かすると do バインディングみたい。

試しに S3 と Lambda を EventBridge で繋いでみたい。

F# の CDK では Amazon.CDK に必要な Construct が全部入りしてるみたい。なので Amazon.CDK.xxx みたいな感じでポチポチ . を刻んでいけば、ドキュメントがなくてもそれなりに探せる。

F# は言語固有モジュールが無いので、ここに例えば Lambda を足すとすると、個別にビルドする感じになる。あれめちゃくちゃ楽で好きなんやけど、 .Net 向けにはない。プロジェクトを別途足す方向で作るらしい。

# テンプレなかったので探してインストール
dotnet new lambda.EmptyFunction --search
dotnet new --install Amazon.Lambda.Templates

dotnet new lambda.S3 --output . --name api --language "F#"

cd src
dotnet sln add api

stack をザーッと書いてみたが、めちゃくちゃつまづきどころがある。

open System.Collections したら Stack が競合するので注意
MemorySizeに128 を渡してたら Ionide や dotnet build ではエラー検知できなかったが、 cdk synth でエラー(めんどくせ)
- MemorySizeを128から(Some 128.0 |> Option.toNullable)に
必須プロパティがビルドまでわからないのつらい
EventPattern の IDictionary<string,obj>を一息で書くのかなりキツイ(まじでめんどい)
- Value の型が揃わないところは個別に let してあとで組み合わせたり
- dict に食わせる tuple はきっちりカッコで囲むと先述の let が不要になった
EventPattern の Detail が cdk synth でエラーになる

Prefix のパターンをやりたいのだけど、 Content filtering in Amazon EventBridge event patterns - Amazon EventBridge

EventPattern:
  source:
    - aws.s3
  detail-type:
    - Object Created
  detail:
    bucket:
      name:
        - Ref: バケツ
    object:
      key:
        - prefix: test/

以下の記述だとエラーになる。

EventPattern =
    EventPattern(
        Source = [| "aws.s3" |],
        DetailType = [| "Object Created" |],
        Detail =
            dict [ ("bucket", dict [ ("name", [| bucket.BucketName |]) ])
                    ("object", dict [ ("key", [| dict [ ("prefix", "test/") ] |]) ]) ]
    )

Unhandled exception. System.ArgumentException: Could not infer JSII type for .NET type 'IDictionary`2' (Parameter 'type')

dict [ ("prefix", "test/") ] の代わりに文字列を渡してると問題なくなるけど、それってスキーマ違反なんですけど。この辺 TypeScript は困った記憶ないので、参ったなという感じ。

この辺の回答が出たら割りと参考になるかもなーと思って見ている。How to set detail on an eventpattern in java · Discussion #20894 · aws/aws-cdk 単純に F# 力の低さに起因して記述できないだけだといいけど。

もうちょっと深掘したいが今週はここまで。とりあえず repo は作った。 krymtkts/aws-cdk-fsharp-trial

F#でコマンドレットを書いてる pt.3

Sun, 26 Jun 2022 09:00:00 +0900

krymtkts/pocof の話。

PowerShell Class を使って、現在の runspace を引き継がせるとかはちょっとわかりまして、 (F# というか .NET)の世界で PowerShell の表示文字列を取り回すには PowerShell Class を使い最後に Out-String した結果を取り回すのが典型っぽいのはわかった。

ただやっぱり PowerShell の力を借りない方法を諦めきれずにいた。また今後プロパティ指定での検索を実装していったときに、指定したプロパティはなんか色付けするとかしようとしたらこっちの方が絶対やりやすいだろうというのを感じてたので、Composite formatting を使ってどうにかできないものか考えていた。

が、結論としては PowerShell の力を借りるのが良いのでは～...というところまできた。

結局のところ format.ps1xml に従って PowerShell で表示が制御されるので、 F# の中で PSObject.Properties を見たとてどいつを優先表示したらいいかわからん。またこの Properties から表示するテーブルを作るのは hashtable や array が引数の場合には適応したくないし、となると型でパターンマッチして～となる。考えるとここにこだわるのはもっとプロパティでの絞り込みとかの他の機能を実装したあとでいいかなーという気になってきた。

format.ps1xml もそうだけど PowerShell 内部実装に対する基礎知識(PSPropertyInfoとかまじで情報ない)がやっぱ圧倒的に不足してるから、蓄積されるまでは黙って PowerShell に従うが良いかと考えを改めた。であれば、もう PowerShell Class を使う方向に倒して、検索中のプロパティを Format-Table の -Properties で表示するようにしようかな、という選択肢もありかなと。

いったんこの形で検索中の表示を進めれば、他に組み込んでおきたい機能、例えばプロパティ指定の検索とかに取りかかれる。週末の 1,2 時間が主な開発時間なので、亀な進捗の中でも実装を進められる判断が必要かなー。それもまた一興。

今更 ForEach-Object -Parallel

Sun, 19 Jun 2022 09:00:00 +0900

今更だが、直列だと長時間かかる処理を分散させるために ForEach-Object -Parallel を使う必要があった。困ったというほどでもないけど、真面目に使ったことなかったので、今回学んだ気をつけポイントをまとめる。 (毎度の如く PowerShell でそれをやる必要は全くなかったが、ぱっと手を動かしたくてついやってしまった)

参照

並列数の制御

-Parallel はとにかく遅い。異なる runspace が作成されそこで実行されるからだ。なのでとにかく計算時間がかかるんやというような処理だけ渡すようにした方がいい。

今回は、あらかじめ ThrottleLimit と同じ数の InputObject に調整して重いコマンドを打つ方針を使った。消えては立ち上がり x2 するような書き方をした方ではやはり runspace 作成のオーバーヘッドが、処理時間という形で顕著に見られた。スクリプトブロックが消えては立ち上がり x2 しないように、スクリプトブロック内で重い 1 処理を実行する方が良かった(AWS のリソースを一括操作するやつだからできたことだけど)。

1 ヵ月分のデータを加工する必要があって、対象日毎に 1 処理にすることができたので、それを約 30 並列でやった。イメージ ↓

$begin = (Get-Date -Day 1 -Hour 0 -Minute 0 -Second 0 -Millisecond 0)
$end = $begin.AddMonths(1).AddDays(-1)
$dateRange = @()
while ($begin -le $end) {
    $dateRange += $begin
    $begin = $begin.AddDays(1)
}
$dateRange | ForEach-Object -ThrottleLimit $dateRange.Length -Parallel {
    # 長時間かかる処理.
}

スクリプトブロック外のリソース参照

$using: 修飾子をつけたら変数を参照できる。ただしスクリプトブロックや関数には使えない。

関数をどうしても使いまわしたいときは、文字列に変換した上で取り込む技もある。 powershell - How to pass a custom function inside a ForEach-Object -Parallel - Stack Overflow

が、スクリプトブロック内でしか使わないのであればその中に関数を定義してしまったほうが楽か。最もクリーンな方法でオススメらしいし、実際にそうした。

(Import-Module すればいいのだけどいちいちモジュールを作らないこともあろう)

技を使うとこうなる。

function Get-Identity {
    param (
        [Parameter(Mandatory,
            Position = 0,
            ValueFromPipeline
        )]
        [PSObject]
        $Value
    )
    process {
        $Value
    }
}

$funcDef = ${function:Get-Identity}.ToString()

function Test-UsingFuncInParallel {
    [CmdletBinding()]
    param ()

    1..30 | ForEach-Object -Parallel {
        ${function:Get-Identity} = $using:funcDef
        $_ | Get-Identity | Write-Host
    } -ThrottleLimit 30
}

技を使わない版。当然ながらスクリプトブロックは間延びする。

function Test-UsingFuncInParallel {
    [CmdletBinding()]
    param ()

    1..30 | ForEach-Object -Parallel {
        function Get-Identity {
            param (
                [Parameter(Mandatory,
                    Position = 0,
                    ValueFromPipeline
                )]
                [PSObject]
                $Value
            )
            process {
                $Value
            }
        }

        $_ | Get-Identity | Write-Host
    } -ThrottleLimit 30
}

使う関数が多いとスクリプトブロックも伸びがちなので、使い分けを検討した方が良かろう。用途次第だが、わたしの場合は先述の通り並列数 MAX ピッタリに調整した InputObject を使て長時間の処理を流すだろうから、 runspace の作成のコストはそれほど気にならない。スクリプトブロックの中がごちゃごちゃしないことのメリットがあるかも知れん。

あと微妙にハマったのが $PSCmdlet の参照。

$using: つけ忘れてると単に $null なだけなのでエラーメッセージ見てもピンときにくい。

Line |
   2 |          if ($PSCmdlet.ShouldProcess($_, 'Write-Host')) {
     |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | You cannot call a method on a null-valued expression.

さらに関数の呼び出し時はカッコで囲む必要がある。カッコがないと Parse Error。

 function Test-ShouldProcessInParallel {
     [CmdletBinding(SupportsShouldProcess)]
     param ()

     1..30 | ForEach-Object -Parallel {
-        if ($using:PSCmdlet.ShouldProcess($_, 'Write-Host')) {
+        if (($using:PSCmdlet).ShouldProcess($_, 'Write-Host')) {
             $_ | Write-Host
         }
     } -ThrottleLimit 30
 }

ParserError:
Line |
   6 |          if ($using:PSCmdlet.ShouldProcess($_, 'Write-Host')) {
     |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Expression is not allowed in a Using expression.

あとなんか見慣れぬエラーになる時があったが忘れた。再現できたら追記したい。

F#でコマンドレットを書いてる pt.2

Sun, 12 Jun 2022 09:00:00 +0900

krymtkts/pocof の話。

平日仕事の方ばっかりやってるので亀な進捗だ。ひとまずSystem.Management.Automation.WildcardPattern の使い方がわかったのを皮切りに、 -like,-match,-eq あたりのフィルタを実装した。

あとプロパティを指定しての絞り込みとかを実装してないが、これは PSObject から目当てのプロパティを拾ってマッチするだけなので、多分むずくないだろう。

いま一番頭を悩ませている課題は、絞り込みを確定するまでの間印字する内容についてだ。やはり PowerShell でインタラクティブなフィルタリングをするのであれば、印字する内容も PowerShell の Format-Table ライクな印字をしたい。例えば Terminal-Icons を使っていたら、カラフルな Get-ChildItem の結果のママ絞り込みしたい。ただそのやり方がさっぱり分からない。

全くわからんなりに、とりあえず F# 内から PowerShell を実行する練習として、 PowerShell.Create でコマンドレットを動かしてみただけというコードは動かしてみた。

[<Cmdlet(VerbsDiagnostic.Test, "Pocof")>]
[<OutputType(typeof<PSObject>)>]
type TestPocofCommand() =
    inherit PSCmdlet()

    override __.EndProcessing() =
        __.WriteObject
        <| PowerShell
            .Create()
            .AddCommand("Get-ChildItem")
            .AddCommand("Format-Table")
            .Invoke() // まじで意味ない

このへんまだ調査不足のため、以下に記すのはメモ書きレベル。つか PowerShell Class だけでなく PowerShell SDK のドキュメントむずくない？全体的に読んでてもよくわからん(愚痴)。

これをやろうとしたら Format.ps1xml が反映された状態の文字列を F# 内で作らないといけないが、 F# 内で PowerShell.Create したとてセッションの引き継ぎができるのかがわからん
- PowerShell.Create あたりでどうにかなりそうに見えるけど試せてない
PowerShell SDK の中には FormatTableCommand という名のまさに Format-Table そのものがあるが、こいつの Input に SelectPocofCommand からデータを食わす方法がわからん
- これも多分実行時に引数で渡せるようにみえるけど(略) PowerShell.Invoke Method
これらが想定通りで期待の Output が得られたとて、正直な気持ちは F# 内で PowerShell の実行エンジン作ってまでやりたくないなー(なんか重そう)、もっと簡単に Format-Table の出力を得る方法はないんかいな、というお気持ち

System.Management.Automation.WildcardPattern みたいな外部から見える場所に PowerShell 内部で使ってる機能がいい感じに提供されてたらいいのだけど、そんな感じではなさそう。

見た目に動きのある機能実装ができたときの嬉しさはやっぱひとしおなので、取り組みたい、けどまだ情報＆能力的に不足してるなーというところ。何やるにしても手を動かせるまでに異様に時間がかかる。ひとまずは調査継続しつつ他の課題潰していくか。

ほんま仕事とは一切接点無くて趣味プロとして最高のテーマになってる。

PoweShell で半角スペース(U+0020) -eq 全角スペース(U+3000) が True となる

Sun, 05 Jun 2022 09:00:00 +0900

転職して 3 ヶ月目を迎えた。入社以降は何の因果か CRM の導入をやることになり、既存データ(スプレッドシート)の以降のために PowerShell を駆使している。

そんな中で今まで知らなかった PowerShell の表情をいくつも知ることができ(例えばコレとか)、なんやかんやで楽しんでいる。

その中で度肝を抜かれたのが、今日のテーマ。

' '(U+0020) -eq ' '(U+3000) が True となる。

PowerShell 7 と Windows PowerShell 5.1 で試した。

Name                           Value
----                           -----
PSVersion                      7.2.4
PSEdition                      Core
GitCommitId                    7.2.4
OS                             Microsoft Windows 10.0.22000
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Name                           Value
----                           -----
PSVersion                      5.1.22000.653
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.22000.653
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

7 だと True 、 5.1 だと False だ。 -ceq だと 7 でも False を返すので -ieq の判定が違うのだけど、 PowerShell Core からこうなんだろうか？ PowerShell の実装を追ってみたが、追いきれなかった。めちゃくちゃココっぽいのだけど、 LINQ に由来するクラス DynamicExpression とかの知識がないのでまだ調査中。

どう説明したらいいか悩むのが、いくつか試してみていてわかってきたのは、 String の -ieq でこの事象が見られること。 Char だと起こらない。

' ' -ieq '　' # True
([char][int]'0x20') -ieq ([char][int]'0x3000')  # Char だと False
([string][char][int]'0x20') -ieq ([string][char][int]'0x3000') # String だと True

そしてもう 1 つ、 Unicode で General category が Separator, space と定義されているものが等値と判定されること。

Whitespace character - Wikipedia の表が非常にわかりやすい。ここから以下のテストコードを作成し、先述の事実を導いた。

'0x0009', '0x000A', '0x000B', '0x000C', '0x000D', '0x0020', '0x0085', '0x00A0', '0x1680', '0x2000', '0x2001', '0x2002', '0x2003', '0x2004', '0x2005', '0x2006', '0x2007', '0x2008', '0x2009', '0x200A', '0x2028', '0x2029', '0x202F', '0x205F', '0x3000' | % { [PSCustomObject]@{
    CodePoint = $_
    isEquals = ([string][char][int]$_) -eq ' '
}}

CodePoint isEquals
--------- --------
0x0009       False
0x000A       False
0x000B       False
0x000C       False
0x000D       False
0x0020        True
0x0085       False
0x00A0        True
0x1680        True
0x2000        True
0x2001        True
0x2002        True
0x2003        True
0x2004        True
0x2005        True
0x2006        True
0x2007        True
0x2008        True
0x2009        True
0x200A        True
0x2028       False
0x2029       False
0x202F        True
0x205F        True
0x3000        True

あーココまで来ると、意図的な挙動 ≒ 仕様というのに当たりがつく。なので .NET の String クラスの挙動を見てみると...

' '.Equals('　', [StringComparison]::CurrentCultureIgnoreCase) # True

'0x0009', '0x000A', '0x000B', '0x000C', '0x000D', '0x0020', '0x0085', '0x00A0', '0x1680', '0x2000', '0x2001', '0x2002', '0x2003', '0x2004', '0x2005', '0x2006', '0x2007', '0x2008', '0x2009', '0x200A', '0x2028', '0x2029', '0x202F', '0x205F', '0x3000' | % { [PSCustomObject]@{
>     CodePoint = $_
>     isEquals = ([string][char][int]$_).Equals(' ', [StringComparison]::CurrentCultureIgnoreCase)
> }}

CodePoint isEquals
--------- --------
0x0009       False
0x000A       False
0x000B       False
0x000C       False
0x000D       False
0x0020        True
0x0085       False
0x00A0        True
0x1680        True
0x2000        True
0x2001        True
0x2002        True
0x2003        True
0x2004        True
0x2005        True
0x2006        True
0x2007        True
0x2008        True
0x2009        True
0x200A        True
0x2028       False
0x2029       False
0x202F        True
0x205F        True
0x3000        True

StringComparison.InvariantCultureIgnoreCase は同じ結果。 StringComparison.OrdinalIgnoreCase は違う結果となった。

StringComparison Enum (System) | Microsoft Docs

全然知らんかった...また世の中に恥を晒してしまったと共に、1 つ学んだわ。まだ確かな情報源を得たわけじゃないけど、きっと世の中のﾄﾞｯﾄﾈｯﾀｰにとっては常識なんやろなあ。手始めに ↓ コレちゃんと読むようにしよう...

Best Practices for Comparing Strings in .NET | Microsoft Docs

ちなみにこの調査において、 -like には System.Management.Automation.WildcardPattern が使われていて、しかも公開されてるクラスというのがわかった。こんなのがあるの知らなかったわ。

そのまま pocof のワイルドカード検索で利用することにした。↓ こういう使い方。

([System.Management.Automation.WildcardPattern]"*ui*").IsMatch('kouiuno')

F#でコマンドレットを書いてる

Sat, 28 May 2022 09:00:00 +0900

以前 F# で PowerShell コマンドレットを書き始めたと書いた。

ひと月くらいかけて主に休みの日にちょいちょい書き進めてきて、最近最低限動くようになったので public repo にした。 krymtkts/pocof

まだ激ショボな機能しかない。プロパティを指定してフィルタリングするとか、フィルタリングした見た目をこれまたテーブルフォーマットにするとか、 PowerShell ならではの良さをまだ全然作り込めてない。

さっぱり作り方がわからん Format-Table とか -like とか PowerShell のクラスをそのまま使いたい気分。無理やったら組むねんけど。

ls | pocof したら Terminal-Icons で鮮やかになったままフィルタリングされてほしいのよなー。この辺が組み込めたら、 PowerShell Gallery で公開したい。

現状正規表現でのフィルタリングくらいしかまともに使えるものがなく亀速な進捗だけど、Cmdlet を書いたり F# で書いたのも初めてだったから、楽しく取り組めた。

前にも書いた通り、これは poco の多言語フォークなんやけど、その動機としては poco の未実装だったり使いにくいところが起因してツール自体をあまり使いこなせてなかったところがある。自分自身あまりツールの使い込みは得意じゃなくて、なんなら自分流にアレンジできるタイプのツールしか使いこなせない。

DIY キーボードとかまさにその典型例なんやけど、キーバインディングが自分の制御下に置かれた途端ブラインドタッチができるようになったりしたので、何かと自分用に手を加えないといけないんだろう。

でもこれで poco というか pocof は自分の制御下に置いたのでなんか色々試してみたいお気持ち。

F# の書き心地に関しては、まだ慣れない点もあれど結構気に入ってる。 else は矯正してほしいところやけど。

着手前は試しにコンピュート式書いてみたいなーとか考えてたが、いまんとこ使おうと思えば使えるけど敢えて使うほどでもない感じで、使い所ない。大したことやってないからパターンマッチや高階関数使ってるだけでもサクサクできる。 .NET 自体かなり久しぶりなこと(PowerShell つかってるけど全然 .NET に踏み込んでない...)と、 .NET と F# の世界の境界がまだ自分の中で曖昧で、そのへんは書きながら学んでいきたいなーという感じ。

何にせよ趣味プロのちょうどいいネタを見つけた。当分はこれで遊ぶ。

使い古しの Logicool M 705 をカスタマイズする

Sun, 22 May 2022 09:00:00 +0900

もう 15 年くらい使っている Logicool の M705 がある。

この M705 について

この M705 は、昔ロジクールに勤めていた友人からもらったものだ。現行モデルは多分これ → 3 年の電池寿命を提供するロジクール M705m マラソンワイヤレスマウス

もらってから数年の間はそんなに使ってなかったが、尋常でない電池寿命とハードデューティさに気づき、以降メインとして使っている。

わたしはマウスを「つまみ持ち」する。この M705 はわたしの持ち方に、クリックの押し込みの深さとか、軽く指を曲げた状態での親指と小指の間隔がバッチリハマっていて、同じマウスをずっと使っている。

トラッキングの位置が他のマウスとは結構違っていて、若干操作に癖を感じていたが、そこは慣れだったような記憶がある。

一時期左クリックがチャタリングを起こしたことがあって、数週間別のマウスに乗り換えて使わない時期があったのだが、放置中に直って以降はチャタリングも起こらなくなった(何故)。

異変

この M705 だが、グリップ力強化かなんかの理由で、マウスの両サイドがラバーというかやわらかい合成樹脂でできている。これが利用から 10 年も経った頃から異変を感じるようになった。ボコボコしてきたり擦れるだけでラバーが削れたり。

最近知ったが、これは合成樹脂のブリーディングとかブリードアウトという現象のようだ。合成樹脂の成分自体が分離しだしてるから、拭き取ったりしてどうにかなるものでないということだった。

ここ数年は症状の進行も激しく、指で押すだけで指紋がつくくらいにラバーが劣化していた。

マウスを買い替えることも検討したが、まだメカニカルな部分は動くし、新しいマウスを選ぶのも結構労力がかかるよなーというのが悩みだった。そこで思い切って、このベタベタボロボロラバーを取り除こうと考えた。

カスタマイズする

M705 のベタベタボロボロラバーを取り除き、手元にあった黒のテーピングを重ねて貼ることにした。テーピングならラバー部分の形状に合わせることも簡単だし、親指＆小指の接触部分が汚れたとしてもまた貼り直せばいいだけなので、我ながら良いアイデアだ。

ベタボロラバーを取り除くのには、大型刃のカッターナイフと、細かい部分にはデザインナイフを利用した。いずれもオルファだ。

分解してみてわかったが、ラバーのボコボコしていた部分には溶け出した液状の謎成分が溜まっており、中々グロテスクだった。このマウスはプラスチックの骨格みたいなところにラバーをはめ込み＆貼り付けしてるような構造をしていて、プラスチック部分を極力傷つけないようにした。

小指側のラバーを取り除くのは非常に簡単だった。単にプラウチック部分の弧に合わせてカッターをすべらせるだけでスイスイ剥がせた。

親指側は形状的に窪んでいるので結構難しく、デザインナイフを使ってできるだけ細やかに処理した。特に親指部分のスイッチ(旧モデルにのみあるやつ。進む・戻るボタンじゃなく親指の位置にある)は可動部のラバーを取り除くと空洞になる。配線にカッターのはが届くので慎重に作業する必要があった。

分解を進めると、樹脂の劣化の進行具合が、指に触れる箇所とそうでない箇所で大きく異なるのが見て取れた。劣化が進んだ箇所はグズグズで、刃を滑らせるのも簡単だったが、親指側の指が触れない部分等は結構元のママの硬度のようで、ちょっと力が必要だった。

ベタボロラバーを取り除いたあとにはテーピングを施す。

曲面へ一枚で貼り付けるのは面倒なので、いくつかの面でテーピングを区切りそれを組み合わせて貼り付けた。やはり強度面で元のベタボロラバーに大きく劣るので、少なくても二重、親指ん可動部は三重にテーピングすることで強度を持たせてみた。

感想

アイデアができてからは、作業に対した時間もかからなかったし、中々やってみてよかった。

結構長い期間をベタボロラバーの状態で触ってきたので、テーピングのサラサラした手触りになって中々新鮮味がある。

まだ使ってみて一週間程度なので、この後どの程度テーピング部分に汚れが蓄積していくかは見えていないが、まあ半年とかのスパンで交換できれば良いか。

お気に入りのマウスをより良い状態に改善し、継続して使い続ける術を新たに身に着けた。

East Asian な全角文字をキーに使った場合のアラインメントについて考える

Sat, 14 May 2022 09:00:00 +0900

掲題のとおりである。ここでいうアラインメントはメモリの話じゃなくて、字面上の整列のことを指す。

自分の中でもどうあるべきかまだ結論が出せてないので、考えをまとめるために書く。

問題

いま、 PSScriptAnalyzer で全角文字をキーに持つ hashtable を整形したとき期待どおりにならなのだけど、どう解決するのがいいのだろう？と悩んでる。

一応弁解しておくと、わたしの気持ちとしては「そんなところに全角文字使うとか危なげなことやめようや」だ。

ところが、今やってる仕事でスプレッドシートのデータをシステムに取り込むにあたり、それらをいくつかの CSV に分解・再構築する必要があって、その中でこのテーマに直面した。 PSCustomObject を CSV に変換する形でスクリプトを作ってるので、全角文字が識別子になるのだ。

普通に自分が書く範囲だとこんなの書かないので、最近まで気づかなかった。

VS Code で PowerShell を書くと、自動整形には PSScriptAnalyzer の Invoke-Formatter が使われる。この戻り値が整形後のコードになるのだけど、ここで今回のテーマに直面する。

問題は以下のコードで再現できる。

$settings = @{
    IncludeRules = @(
        'PSAlignAssignmentStatement'
    )

    Rules = @{
        PSAlignAssignmentStatement = @{
            Enable = $true
            # PSAlignAssignmentStatement.CheckHashtable が真だと、
            # hashtable の要素の並びを整形してくれる。
            CheckHashtable = $true
        }
    }
}

$script = @'
$test = @{
    A = 0
    ABC = 0
    ABCDE = 0
    Ａ = 0
    ＡＢＣ = 0
    ＡＢＣＤＥ = 0
}
'@
Invoke-Formatter -ScriptDefinition $script -Settings $settings

出力はこうなる。これは期待のとおりではない。

$test = @{
    A     = 0
    ABC   = 0
    ABCDE = 0
    Ａ     = 0
    ＡＢＣ   = 0
    ＡＢＣＤＥ = 0
}

わたしはこうなってほしいと考える。

$test = @{
    A          = 0
    ABC        = 0
    ABCDE      = 0
    Ａ         = 0
    ＡＢＣ     = 0
    ＡＢＣＤＥ = 0
}

PSScriptAnalyzer のコードを調べて、 PSScriptAnalyzer 的には PowerShell のパーサが返した列番号(EndColumnNumber)の通りに整形してるのがわかった。 PSScriptAnalyzer/AlignAssignmentStatement.cs GetHashtableCorrections の L194

次に PowerShell のパーサを直接調べる。

$script = @'
$test = @{
    A = 0
    ABC = 0
    ABCDE = 0
    Ａ = 0
    ＡＢＣ = 0
    ＡＢＣＤＥ = 0
}
'@

function getColumnNumberString {
    param (
        $Extent
    )
    "start $($Extent.StartColumnNumber.ToString().PadLeft(2)) end $($Extent.EndColumnNumber.ToString().PadLeft(2))"
}

$ast = [System.Management.Automation.Language.Parser]::ParseInput($script, [ref]$null, [ref]$null)
$hashAst = $ast.FindAll({ $args[0] -is [System.Management.Automation.Language.HashtableAst] }, $true)
$hashAst.KeyValuePairs | ForEach-Object {
    # Item1 がキーの情報、 Item2 は '=' の情報
    $e1, $e2 = $_.Item1.Extent, $_.Item2.Extent
    "key $(getColumnNumberString($e1)) | '=' $(getColumnNumberString($e2))"
}

出力はこうなって、全角文字の表示幅は考慮されてないのがわかる。

key start  5 end  6 | '=' start  9 end 10
key start  5 end  8 | '=' start 11 end 12
key start  5 end 10 | '=' start 13 end 14
key start  5 end  6 | '=' start  9 end 10
key start  5 end  8 | '=' start 11 end 12
key start  5 end 10 | '=' start 13 end 14

じゃあこれは PowerShell のバグなのか？とまで考えを至らせると、いやパーサは表示する文字の幅を意識する必要あるか？と思えるので、これは誰が解決する問題なんや...と思っているのが、今の状況。

他の言語を調べる

他の事例を調べて、全角文字を含むキーや識別子をアラインメントするとどうなるか比べてみる。

とはいえ、他の言語でアラインメントするようなフォーマットかける言語何があったっけ？少なくとも Python は違ったし、思いついたのは Go だけ。 Go 以外にも思いついたら追加したい。

Go

こんな中身の test.go があるとする。

package main

type person struct {
 A int
 ABC int
 ABCDE int
 Ａ int
 ＡＢＣ int
 ＡＢＣＤＥ int
}

これに gofmt ./test.go すると次の通り。

package main

type person struct {
        A     int
        ABC   int
        ABCDE int
        Ａ     int
        ＡＢＣ   int
        ＡＢＣＤＥ int
}

やっぱり！ PowerShell の結果と同じ。

現時点の理解

現実的には、パーサやフォーマッタがフォントの文字幅を考慮しないし、アラインメントしないのが妥当な落とし所なのかな。気持ちとしては、全角文字を含んだとしても綺麗にアラインメントしてほしいが、それもエッジケースなのでそんなに困ることがない。

とはいえ Unicode 文字の演算子とかポツポツあるし、幅の規定が厳格であればフォーマッタあたりで解消したいテーマではある気がする。

なんか締まらない締めになった。

とりあえず自分用の覚書としては、 PSScriptAnalyzer は PSAlignAssignmentStatement.CheckHashtable=$false で利用すればこの問題に悩まされることもないので、オススメする。

F#で PowerShell コマンドレットを書き始めた

Sat, 07 May 2022 09:00:00 +0900

勉強がてら、F# で PowerShell のコマンドレットを書きはじめる。 ↓ を参考にやる。ただし .NET 6.0 を対象にする。

Writing a PowerShell Core Module With F#, A Complete Guide | Brianary

初めての要素が多いので、ゆっくり進める。

F# でアプリ書くのが初
コマンドレットを書くのが初
dotnet CLI を使った開発が初
その他 PowerShell 系のツール(Pester,platyPS)をちゃんと使うのが初
- 参考にする記事にはないが、ビルドスクリプトも psake で書く

題材としては、poco の再実装をしてみるつもり。

諸々のツールが出てくるので一覧しておく。

GitHub の Repo の作成に PowerShellForGitHub
remote repo の管理に ghq
コミット署名のために Gpg4win

repo とプロジェクトを作成する

動くものになるまでは private repo で運用する。動かないなら公開しても意味がないからね。

# private repo を作成する。
$owner = 'krymtkts'
$module = 'pocof'
New-GitHubRepository -RepositoryName 'pocof' -Private

# remote repo を clone する。
ghq get -p (Get-GitHubRepository -OwnerName $owner -RepositoryName $module | Select-Object -ExpandProperty ssh_url)
cd "$(ghq root)/$(ghq list $module)"

# initial commit を刻む。
gpg-connect-agent reloadagent /bye # <- gpg-agent が立ち上がってこないので先に起こす。
git commit --allow-empty -m 'Initial commit.'
dotnet new sln

# 空のプロジェクトを作成。
dotnet new classlib --language 'F#' --framework net6.0 -o src/$module
dotnet sln add src/$module/$module.fsproj
cd src/$module
# PowerShell 開発の依存関係を追加。
dotnet add package PowerShellStandard.Library
New-ModuleManifest "$module.psd1"
'<helpItems schema="maml" xmlns="http://msh" />' | Set-Content "$module.dll-Help.xml" -Encoding utf8

これで repo と空の F# プロジェクト pocof.fsproj ができた。次に、記事に記載の通り、 pocof.fsproj に必要な情報を加筆する。

PropertyGroup に Version 属性を追加
ItemGroup 属性を追加して、コピーするファイルを記載する

また PowerShell のモジュール情報を pocof.psd1 書き込む。コマンドレットなので、 RootModule を書き忘れるとコマンドがインポートできないのでご注意(書き忘れてて Import-Module しても使えない！となった)。

あと作成後に気づいたのだが、作成された *.sln 等のエンコーディングが UTF8 with BOM だったり改行が CRLF だったりするので、それらを UTF8 と LF に手で補正した。

最後に空の XML-based help file を作成しているが、これは Get-Help で使うヘルプファイルで、後で PlatyPS で上書きされるやつ。 Naming Help Files - PowerShell | Microsoft Docs

F# 開発環境を準備する

わたしは VS Code を使っているので、F# 用の拡張機能を入れる。

Ionide for F# - Visual Studio Marketplace

F# でフォーマッタといえば fantomas のようなのだけど、個別に入れなくても Ionide がうまく拾えるらしい。 Formatting Settings · Issue #1346 · ionide/ionide-vscode-fsharp

コードを編集する

自動生成されたコードを編集する。記事に記載のものだとパラメータに Position がなくて Pester こけそうなのと、自分のやりたいことに合わせた引数を書くなど諸々の調整をする。

Pester のテストコードも作成する。テストコードは tests ディレクトリ配下に配置した。

ビルド＆テスト実行

記事に記載の通りだと typo があったり Import-Module 前に削除があって消えてしまう等ある。編集して実行した。

$ModuleName = Resolve-Path ./src/* | Split-Path -Leaf
Import-LocalizedData -BindingVariable module -BaseDirectory (Resolve-Path ./src/*) -FileName "$ModuleName.psd1"
if ($module.ModuleVersion -ne (Resolve-Path ./src/*/*.fsproj | Select-Xml '//Version/text()').Node.Value) {
    throw 'Module manifest (.psd1) version does not match project (.fsproj) version.'
}
dotnet publish
cp (Resolve-Path ./src/*/bin/Debug/*/publish/FSharp.Core.dll) (Resolve-Path ./src/*/bin/Debug/*/) -Verbose

# import して Pester 実行。
# モジュールのバージョンであったり export される Cmdlet が正しいかなど見る。
Import-Module (Resolve-Path ./src/*/bin/Debug/*/publish/*.psd1) -Force
Invoke-Pester

あとこれらを psake で実行できるように psakefile.ps1 に記載した。

F# のプロジェクトだったら FAKE を使った方がいいのかなーと考えていた。となると、依存する Paket も入れないといけない。いま dotnet CLI で管理してたのでいらないかなーと思った。また、今回作りたいのは PowerShell のコマンドレットなので、周辺のツールも PowerShell だ。これをいちいち fake.cmd や dotnet fake buildを介して実行するのなんかダルいな...と億劫だったので、 FAKE の導入は見送ることにした。

ドキュメントを生成する

記事では platyPS を使っているのでそれに従う。

# 事前にビルドしたモジュールを Import-Module しておく。
New-MarkdownHelp -Module pocof -OutputFolder ./docs -ErrorAction SilentlyContinue
# dll-Help.xml を作るときに実行する。
New-ExternalHelp docs -OutputPath (Resolve-Path ./src/*/) -Force

コメントに記した通り、他のタスクと依存関係にある。こういうのは psakefile.ps1 にまとめる。

ヘルプの作成元は Markdown をオリジナルとする方針。

PowerShell Gallery へのリリース

まだやらないけど手順だけ確立しておく。

記事に記載のものだと、ビルドコンフィグレーションを Release にして Import、その後 Import したモジュールを公開、という手順になっている。

個人的にやったことがあるのはフォルダを指定して公開する方だけなので、どっちにするかなーと悩んでいる。間違って古い Import 済みモジュールを公開するミスとかないのかな、というのが疑問。

ま、勉強のためのものであるし、やったことない方を接客的に選んでみるのも一興か。コマンドレットが正しくエクスポートできているか、リリース前にテストするにもこの方法を取るのが良さそうだし。

とはいえ記事に記載の通りやると、自分が普段利用している PowerShell Module のパスに直でリリース前のモジュールを打ち込んでしまう。これはちょっと実用始めたら困りそうなので、ディレクトリを変える必要がある。となると結局いつものパス指定でのリリース方式でええんちゃうか...

いずれを選択するかはまた検討したい。

また、これらのリリースタスクも psakefile.ps1 に定義するものとする。

おわりに

これでひとまず準備完了。ほぼ記事に記載のとおりやってきたけど、ちょいちょい自分用に変えたり、新しい要素については色々調べながらやってるので、進捗は亀のスピードだった。動くものをこしらえれたら public repo にしよう。

現時点で不足しているとわかっている点もある。今回書きたいコマンドレットはインタラクティブなものなので、きっと Pester でテストできない点が出てくる。それらは FsUnit を使って可能な限りテストを書きたい所存。

あと困っているのが、参考にしている記事にも記載があったが、 DLL への参照が切れなくてファイルを消したりできなくなる(Remove-Module 忘れとかでなく)。いまは都度 PowerShell のセッションを作り直してるけど相当に面倒なので、原因を突き止めてどうにかしたいな。

未経験のものに触れるのは普段得られない刺激があって良い。

さよなら oh-my-posh モジュール

Fri, 29 Apr 2022 09:00:00 +0900

いつものように PowerShell Module を更新して PowerShell を立ち上げると次のようなメッセージが表示された。

Hey friend

In an effort to grow oh-my-posh, the decision was made to no
longer support the PowerShell module. Over the past year, the
added benefit of the module disappeared, while the burden of
maintaining it increased.

However, this doesn't mean oh-my-posh disappears from your
terminal, it just means that you'll have to use a different
tool to install it.

All you need to do, is follow the migration guide here:

https://ohmyposh.dev/docs/migrating

あら... oh-my-posh 3 から Go で実装されて、マルチプラットフォームなプロンプトテーマエンジンになってたけど、ついにその時が来たか...という感じ。

とりあえず使えなくなる(というか更新できなくなる)と困るので、移行手順に記載された移行手順を行うことにした。

わたしの移行手順

記載の順番にやってもいいけど、慎重を期すため順番を変えた。

まず oh-my-posh が PATH にある状態で、 Set-PoshPrompt を oh-my-posh init pwsh に変え、プロンプトの表示をチェックした。

# Set-PoshPrompt -Theme ~/.oh-my-posh.omp.json
oh-my-posh init pwsh --config ~/.custom.omp.json | Invoke-Expression

当然のごとくきれいに出力されるので、 PowerShell Module から置き換える。

Windows 向けの公式なインストール手順では winget, scoop それか手動での更新になっている。

でもわたしは永らく chocolatey を使っていることもあり、有志が公開してくれているパッケージを利用する。見たところバージョンも最新に追随していていい感じ。 Chocolatey Software | Oh-My-Posh 7.74.3

管理者権限で cmd を開き、インストールする。補足：PowerShell でもインストールできるが、PowerShell 自体を chocolatey でインストールしているのもあり chocolatey でのインストールは cmd で行うようにしている。

choco install oh-my-posh -y

このインストールの最後に、

PROFILE: C:\Users\takatoshi\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
oh-my-posh has been added to your profile. You may wish to append 'Set-PoshPrompt paradox' to set a theme

と言われたが、 Windows PowerShell のプロファイルはおろかどこにも加筆されてないようだった。

管理者権限で PowerShell を起動し、 oh-my-posh の Powershell Module を削除する。

Uninstall-Module oh-my-posh -AllVersions

Import-Module oh-my-posh は元々書いてなかったので削除なし。代わりにプロファイルの中でインストール・更新するモジュール名を管理しているので、そこから取り除いた。

以上。

感想

何事もなく移行できて良かった。

ただこれを機に、もう oh-my-posh にこだわらず、 Starship みたいなもっとイケてるプロンプトテーマエンジンに積極的に乗り換えてもいいかなーと思えてきた。

元々 oh-my-posh を使ってたのは、 2018 年頃の PowerShell でいい感じの Powerline ができる唯一のツールだったからだ(わたしの観測範囲では。もう一つその名の通り Powerline というモジュールがあったが満足の行くカスタマイズができなかった¹)。テーマを PowerShell で書けて、PowerShellGet からインストールできるのも楽だった。

とはいえ、それがマルチプラットフォームに対応した oh-my-posh の足枷になったみたいやけど。

逆に利用者の立場からいえば、 oh-my-posh が明確に PowerShell に特化しなくなったということ。これは、わたしが Power Fighter(勝手に作った PowerShell 使いの呼び名)であるから oh-my-posh を使い続けていたという理由もなくなったことになる。

oh-my-posh が Go で書き換わったときに一番気に入らなかったのは 設定ファイルが JSON なとこなので、そのフラストレーションを解消するいい機会をもらったのかも知れない。

まだあったわ →PowerShell Gallery | PowerLine 3.4.0 ↩

AWS リハビリのハマり集

Sat, 23 Apr 2022 09:00:00 +0900

現職は半年ぶりの AWS ということで、ちまちまリハビリをしている。諸々忘れてたりものによってはハマっている現状。記憶に定着させるため、ハマったところを記す。

Hello World 以外の `sam init` できません

AWS SAM は前職でも使っていたが、久しぶりに触ったら詰まるところがあったので書いておく。

久しぶりに sam init すると 100%エラーで終わる。端末は Windows 11。こんな風に ↓。

Cloning from https://github.com/aws/aws-sam-cli-app-templates (process may take a moment)
Error: Can't find application template quick-start-web - check valid values in interactive init.

Unable to create Serverless API using SAM v1.40.0 · Issue #3692 · aws/aws-sam-cli

どうも Windows 限定の問題らしい。 sam が使う template repository を git clone できないという深刻なやつ。 AWS SAM の一時ディレクトリを消して、手動で git clone したら解消する。これは Issue は Closed になっているものの、中々気付かんし原因を究明したい気がする。

MFA 有効化されたアクセスキーの使い方忘れた

タイトルの通り。

そのまま使うとワンタイムパスの入力を求められないが、一時クリデンシャルを発行するときに出る。

昔は MFA が必要な switch role するときに aws-mfa を使っていたが、この度 AWS Tools for PowerShell で自分の利用ケースのみシンプルにこしらえた。ワンタイムパスワードの入力には 1Password の CLI である op を使うと究極に楽。現職で 1Password を使ってるので導入したみた。

$env:AWS_REGION = 'ap-northeast-1'
$user = 'krymtkts'
$AWSLogin = 'AWS'
$c = Get-STSSessionToken -SerialNumber (Get-IAMMFADevice -UserName $user).SerialNumber -TokenCode (op item get $AWSLogin --otp) -ProfileName $user
$env:AWS_ACCESS_KEY_ID = $c.AccessKeyId
$env:AWS_SECRET_ACCESS_KEY = $c.SecretAccessKey
$env:AWS_SESSION_TOKEN = $c.SessionToken

楽～。これは PowerShell の profile に関数書いておいた。

AWS Tools for PowerShell は自動補完で一覧する profile を絞り込んでる

.aws/credentials にこういう profile があるとする。これ、 mfa_serial が紛れ込んでる。

[profile]
aws_access_key_id = XXXXXXXXXXXXXXXXXXXX
aws_secret_access_key = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
mfa_serial = xxx

AWS CLI のタブ補完コマンド aws_completer はこういうのがあっても問題なく profile を一覧できるが、 AWS Tools for PowerShell では一覧されなくなる。 mfa_serial 以外には role_arn, source_profile があると一覧されなくなる。

これ初めて知った。今後は、書き間違ってるから一覧されないんだ～と思いつくことができるが、一発目だったのでとても時間がかかった。ドキュメントに書いてる挙動なんかな～しらんけど。今度調べたい(いつ)。

続くかも。

古のはてなダイアリー XML を Markdwon に変換する(いい感じに)

Sat, 16 Apr 2022 09:00:00 +0900

先日 Google ドライブの中に眠っていた XML を発掘した。古のはてなダイアリーからエクスポートされたやつだこれ。

昔、プレーンテキストで日記をつけ始める前に、誰に見せるでもないブログを書いていた。何度かブログサービスに書いては止めるを繰り返していた。そのうち最も最近までやってたのがはてなダイアリーで、そのバックアップがこれっぽい。 178 記事、2009 ~ 2011 の 3 年間もあるのに、すっかり忘れていた。

これはぜひ今の日記に統合したい。ということではてなダイアリーの XML を Markdown に変換して取り込むことにした。

変換する

今回は Pandoc を使わず純粋に PowerShell だけで処理する。 Pandoc ではてな記法から Markdown に変換できるが、ごく一部の記事は既に日記があって追記しないといけないこともあり、PowerShell だけでやる方が融通が利く。

XML なら PowerShell の主戦場なので、何をするにも楽だ。使っているはてな記法もおおよそパターンマッチで置換できる(鬼の連続置換)。

引用だけ正規表現での変換がわからんけど、一桁件数しかなかったので、手で書き換える。

以下変換スクリプト。 hatena2md.ps1

[CmdletBinding()]
param (
    [Parameter(
        Mandatory,
        HelpMessage = "XML Path of hatena diary.")]
    [ValidateScript({
            if (-Not ($_ | Test-Path) -or ($_ -notmatch "\.xml")) {
                throw "The file specified in the XmlPath argument must be XML."
            }
            return $True
        })]
    [System.IO.FileInfo]
    $XmlPath,
    [Parameter(
        Mandatory,
        HelpMessage = "Output Path of Markdown diaries.")]
    [ValidateScript({
            if (-Not (Test-Path $_ ) -or -not (Test-Path $_ -PathType Container)) {
                throw "The BlogPath argument must be a folder."
            }
            return $True
        })]
    [System.IO.FileInfo]
    $BlogPath
)

$xml = [XML](Get-Content $XmlPath)
Write-Host "Convert $($xml.diary.day.Length) hatena XML to Markdown."

$xml.diary.day | ForEach-Object {
    $date = Get-Date $_.date -ErrorAction SilentlyContinue
    if (-not $?) {
        Write-Error "Cannot convert diary of $($_.date)"
        return
    }
    $diaryPath = "$BlogPath/$($date.Year)/$($date.ToString('yyyy-MM'))/$($date.toString('dd')).md"
    Get-ChildItem $diaryPath -ErrorAction SilentlyContinue | Out-Null
    if ($?) {
        Write-Host "Add Content to exists diary of $($_.date)"
        $InvokeContent = 'Add-Content'
        $content = @"

## はてなの日記

"@
    }
    else {
        Write-Host "Create new diary of $($_.date)"
        $InvokeContent = 'Set-Content'
        mkdir -Force (Split-Path $diaryPath -Parent) | Out-Null
        $content = @"
# $($date.ToString('yyyy-MM/dd (ddd)'))

## はてなの日記

"@
    }
    $content += (
        $_.body -split "`n" | ForEach-Object {
            $_ `
                -replace '^\*\d+\*(.+)$', "### `$1`n" `
                -replace '^=+$', "`n---`n" `
                -replace '^--(.+)', '    - $1' `
                -replace '^-(.+)', '- $1' `
                -replace '^\+\+(.+)', '    1. $1' `
                -replace '^\+(.+)', '1. $1' `
                -replace '\>\|(\w+)\|', "`n```````$1" `
                -replace '(\>\|\||\>\|)', "`n``````" `
                -replace '(\|\|\<|\|\<)', "```````n" `
                -replace '\[(.+?)\:title=(.+?)]', '[$2]($1)'
        }) -join "`n"
    $content | & $InvokeContent -Path $diaryPath -Encoding utf8 -NoNewline | Out-Null
}

はてなダイアリーの XML から、自分の日記の構造に変換している。はてなダイアリーの記事にはわかりやすく「はてなの日記」というセクションを設ける。

基本ファイルを作成するが、既存のファイルが存在する場合は、追記する。先述の通りセクションがあるので追記しても自然だ。

ディレクトリ構造は前回の Textile → Markdown 変換で記した通り ↓ 。 1 つの XML からこの形にファイルを出力する。

+---2013
|   +---2013-01
|   |       17.textile
|   ︙      ︙
︙
\---2022
   +---2022-01
   ︙
   \---2022-03
            01.md
            ︙
            31.md

実行する。

. .\hatena2md.ps1 -XmlPath $XmlPath -BlogPath $BlogPath

変換後の処理

変換後のファイルから>> で検索して該当するものを一覧し、書き換える。

ls -File -Recurse | ? {cat $_ | % {$_ -split "`n"} | ? {$_ -match '^>>'}} | select -Property FullName

ココに来て順序付きリストの数字をやっぱりインクリメントしたい(前のステップでは1.固定でいいかと思ってた)...ということで一部書き直した。

最後に全体を Prettier で清書する。

prettier --write .

最終チェックをして完了。

まとめ

Textile からの変換よりも、量が 1/10 程度と少なかったこともあり、簡単にできた。

コンテンツそれ自体は中々に青臭く、読んでると「わー！！！」と声を上げたくなるところもある。ただ人生の転機が集中した期間だったこともあって、興味深い内容だった。貴重なログなので、これまた自己分析に使いたい。

転職した 2022

Sat, 09 Apr 2022 09:00:00 +0900

また転職した。前回の転職から半年しか経ってないけど。

退職前に諸々の誓約書に署名してるので諸々の守秘義務があり、多くを語ることはできない。結構高く評価してもらってたのに辞めた理由を語るとすれば、ただひとえに「音楽性の違い」が原因かな。あ、入社して知り合った 1 ヶ月パイセンが信頼のおける人だったのは良かった。

幸運にも、より良い条件で次のご縁があったので、これは自分の真摯な姿勢が信頼を紡いできたおかげなんかなーと自分自身を讃えてみる。讃えてみるテスト。

結果的にジョブホッパーみたいになってしまったから、ヘッドハンター()とかには「キャリアに傷がついてる」とかいちびられそうだが、こちとら仕事はちゃんと納めたからええのよ。

この半年の間で伸びたところもなくはないけど、結構停滞感みたいなのを感じていた。結局半年の間、技術情報を交換したり意見することもないし、あらゆる権限がなくて何なら自分の Google アカウントのアバターを変更する権限もなかった。全然人に会うこともなくコミュニケーションは週 1 回くらいとかだったので、初対面の人と会話したり、単に送るメッセージ考えるのも疲れるというのが現状。

自分の職掌にはクラウドの「ク」もなく、全く触ることがなかったので、使っていない筋肉が随分衰えてしまった。細かいことを忘れてるので、現職でしょーもないことであっても「アレ？どうやっけ？」となったりする。まだリハビリ中。

また、ビジネスサイドの声から遠ざかっていたことで、言葉の理解力とか肌感覚が鈍った気がする。ここもリハビリ中。

たった 1 週間程働いてみこの感覚なので、これからも他の衰えに気づくことが度々あるだろう。

いずれの衰えも「強くてニューゲーム」できると嬉しいけど、そこはやってみないとわからんから、ただただ真摯に取り組むのみやな。自分の変化に気づけてるだけでアドバンテージかな。

それにしても久しぶりに「仕事してる！」という実感があって良い。これはまさに「音楽性」が一致した結果なんかな。しらんけど。

ただのポエムになった。

Textile を Markdown に変換する(いい感じに)

Sat, 02 Apr 2022 09:00:00 +0900

プレーンテキストで日記をつけ始めて今年で 9 年目になったぽい。その日記だが、昔 Redmine を使ってたこともあって、最初の 5 年位の間 Textile で日記を書いていた時期がある。この頃の文書を Markdown に変換したいと度々思っていたが、最近重い腰を上げて取り組み始めた。

マークアップ言語の相互変換といえば、やはり Haskell で書かれた Pandoc やろーというのが個人的なイメージ。簡単なケースで永らく使ってきたが、今回は困ったというか一筋縄ではいかない点が出てきた。

例えば、 Pandoc で過去の日記を Textile から Markdown に変換するとしたらこんな感じのコマンドになる。

(以降は視認性を確保するため、実際に実行したコマンドに改行を含めて記載する)

pandoc --from=textile --to=gfm+east_asian_line_breaks `
       --shift-heading-level-by=-4 --eol=lf --wrap=preserve `
       ./diary.textile --output=./diary.md

参照 Pandoc - Pandoc User’s Guide

結構いい感じの結果を導くオプションの組み合わせに手間取った。

改行に半角スペース 2 つを使い、表の syntax も使うので gfm+east_asian_line_breaks
見出しのレベルを変えるための shift-heading-level-by=-4 を指定
- Redmine の見た目上 h5. にしてた(確か)
改行コードは LF で統一する --eol=lf
長い行に空白があると折り返そうとするので --wrap=preserve 原文を維持する

仮に日記が以下のような記述とする。

h5. 見出し

# 順序付きリスト1
** 箇条書きリスト1-1
# 順序付きリスト2
** bullet listアイテム2-1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
* 箇条書きリスト3
## 箇条書きリスト3-1
箇条書きリスト3-1の 改行したコンテンツ

* *箇条書きリスト2*
箇条書きリスト2。
|_.行1|1|
|_.行2|20|

* *箇条書きリスト3*
<pre>
コード
</pre>
テキスト

|_.行1|1|
|_.行2|20|

    |_.行1|1|
    |_.行2|20|

<pre><code class='sh'>
コード
</code></pre>

これを先述のコマンドで Textile から Markdown に変換すると...

# 見出し

\# 順序付きリスト1

箇条書きリスト1-1

\# 順序付きリスト2

bullet listアイテム2-1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

-   箇条書きリスト3
    1.  箇条書きリスト3-1  
        箇条書きリスト3-1の 改行したコンテンツ

<!-- -->

-   **箇条書きリスト2**  
    箇条書きリスト2。  
    \|\_.行1\|1\|  
    \|\_.行2\|20\|

<!-- -->

-   **箇条書きリスト3**
        コード

      
    テキスト

| 行1 | 1   |
|-----|-----|
| 行2 | 20  |

\|\_.行1\|1\|  
\|\_.行2\|20\|

    <code class='sh'>
    コード
    </code>

このように、おもしろいことになる。

順序付きリストと箇条書きリストが同じレベルに存在すると、後ろの方(この場合箇条書きリスト)しか変換できない
- これは事前に混在するリストを Textile から取り除くしかないか
リストと文の間の過剰な空白が気持ち悪い
- まだどうにかできそうなオプションを見つけられていないので、これは Textile -> Markdown 変換後に Prettier で変換する必要があるか
新たに挿入された謎の HTML コメントの行は、以下の Pandoc の仕様によるらしい
- Ending a list | Pandoc - Pandoc User’s Guide
- To “cut off” the list after item two, you can insert some non-indented content, like an HTML comment, which won’t produce visible output in any format:
表の変換は、箇条書きに連続しない＆インデントされていない箇所に限り、 Markdown の Table Syntax に変換される
当時の Redmine で使えなかったこともあり、コードブロックを <pre><code class='lang'> で表現していた。これが Markdown に変換したとき pre 要素だけ解釈されてしまう

1,4 は Pandoc で変換をかける前に手で直さざるを得ないので、正規表現に引っかかる範囲は一括変換をかける。1000 超える Textile ファイルがあるので流石に手作業は無理、可能な限り一括変換や。

2, 3, 5 は変換後に対処する。これも機械的にどうにでもできそうか。

日記のディレクトリ構造はこのような形になっており、変換作業はルートディレクトリから行う。

+---2013
|   +---2013-01
|   |       17.textile
|   |       18.textile
|   ︙      ︙
|   \---2013-12
︙
\---2022
   +---2022-01
   ︙
   \---2022-03
            01.md
            ︙
            31.md

(色々 try & error して変換していたので、入力の手間を省く目的でわかりきったコマンドはエイリアスを多用している)

4 の解消

インデントされている表はなかったが、箇条書きの後に表が記載されているパターンがあり、そのうち、以下の 2 パターンがあった。

箇条書き直後に表がある
箇条書きの後、更に文を挟んだ後に表がある

この 2 を引っ掛けるパターンを書くのに難儀した。何故なら、表の syntax の行末に余分に空白や不要な文字がついていて、どうにもわたしの正規表現力では引っ掛けられない。

どうにもうまくできないので妥協して、 2 回に分けて変換する。

1 については雑ながらも一括変換可能。

ls -Recurse -File *.textile |
? {(cat $_.FullName ) -join "`n" | sls -Pattern '(\*|#).+\n\|'} |
%{
    $file = $_.FullName
    ((cat $file) -join "`n") -replace '((\*|#).+\n)(\|)',"`$1`n`$3" |
        Set-Content $file -NoNewline
}

改行コードは LF を使うので -NoNewLine だ。

2 はリストアップして清書がてら手メンテ...

# ファイル一覧をクリップボードへ
ls -Recurse -File *.textile | ? {
    (cat $_.FullName ) -join "`n" | sls -Pattern '\n[^\*#\|].+\n\|'
} | select -ExpandProperty FullName | Set-Clipboard

1 の解消

Textile を見るに、箇条書きの後に太字 *〇〇* を書いて見出しの代わりにしたかったような気配がするので、それを除外した順序づき/箇条書きリストを変換の対象にする。

番号を参照していたりすると文脈が失われるので、一括変換できるか対象 23 件を目検したところ、レベル誤りだったり単に順序付きリストにし忘れているだけの箇所だったり。それぞれに対処の仕方が異なるので、仕方ないがリストアップした対象を清書がてら手メンテ(2 回目)...

# ファイル一覧をクリップボードへ
ls -Recurse -File *.textile | ? {
    (cat $_.FullName | ? {$_ -match '(^\*\s[^\*]|^#\s[^\*])'}) -join "`n" |
        sls -Pattern '(\*.+\n#|#.+\n\*)'
} | select -ExpandProperty FullName | Set-Clipboard

Textile -> Markdown の変換

先述の通りのオプションで Pandoc を実行する。

ls -Recurse -File *.textile | %{
    pandoc `
        --from=textile --to=gfm+east_asian_line_breaks `
        --shift-heading-level-by=-4 --eol=lf `
        $_.FullName --output="$($_.Directory)\$($_.Name -replace 'textile','md')"
}

3 の解消

変換後、まず最初に  を取り除く。最後に Prettier を実行してきれいな状態にしたいからだ。

置換対象が Pandoc によって追加されたコメントだけなのか調べる。

PS> ls -Recurse -File *.md | % {cat $_.FullName | sls -Pattern '^<!--.+-->'} | group

Count Name                      Group
----- ----                      -----
 2275 <!-- -->                  {<!-- -->, <!-- -->, <!-- -->, <!-- -->…}

問題ないようなので一括置換する。

ls -Recurse -File *.md | ? {sls -Path $_.FullName -Pattern '^<!--.+-->'} | %{
    $file = $_.FullName
    (cat $file | ? {$_ -notmatch '^<!--.+-->'}) -join "`n" |
        Set-Content $file -NoNewline
}

この一括変換結果、1000 超のファイルの差分に問題ないか git diff --word-diff で見る。流石に多いので変更をグルーピングして見た。全部同じ変換結果なら1つにまとまる。

git diff --word-diff | ? {$_ -match '\[(\+|-)'} | group

この置換により HTML コメント削除後は空行が 2 行になり、かつ文末の改行が消えてしまうが、後に行う Prettier で補修される(はず)。

5 の解消

幸い、class 属性なしの code タグはなかった。

<code class="${language}" → ```${language} 、 </code> → ``` へ変換する。一緒にやるイメージがなかったので 2 回置換する。同時に、pre タグが変換されたことによる半角スペース 4 個があると文章のインデントと合わず正しくレンダリングできないので、取り除く。

ls -Recurse -File *.md | ? {sls -Path $_.FullName -Pattern '<code class='} | % {
    $file = $_.FullName
    (cat $file | % {
        $_ -replace '\s{0,4}<code class="(\w+)">','```$1' `
           -replace '\s{0,4}</code>','```'
    }) -join "`n" | Set-Content $file -NoNewline
}

2 の解消

Prettier を使う。数年前から Markdown の整形に使っているのでそれに合わせる。

ForEach-Object して 1 ファイルずつ prettier を実行するとそこそこに遅い。 glob にまとめた方が速く実行できるので、ちょっとパターンが雑だがそのようにする。

prettier --write "**/{$((
    ls -Recurse -File *.textile | select -ExpandProperty DirectoryName |
    Split-Path -Leaf | group | select -ExpandProperty Name ) -join ',')}/*.md"

が、先述のコマンドを実行したあとでPrettier 導入前から Markdown で書いていた古い日記もあまり綺麗でないことが判明した。なので、全体的に整形してしまう。

prettier --write .

このとき箇条書きの書き忘れが見つかった。後述するような箇条書きがあると、 prettier に見出しと判断されてレイアウトが崩れるので、事前に手で取り除く。

- Bad な bullet list
  -

最終チェック

ココまで来たらもう大丈夫やろう、という感じで最終チェックしてたら、ココに来て痛恨のミス。どうも箇条書き/順序付きリストの階層を誤っていると変換に失敗するようだった。 1 の解消のときに回収しきれていないかった。

before.

** 壊れる箇条書きリスト
#### 壊れる順序付きリスト

after.

壊れる箇条書きリスト

\#### 壊れる順序付きリスト

調べてみたら 50 ファイルくらい結構派手にぶち壊れている部分があった。

ls -Recurse -File *.md | ? {sls -Path $_.FullName -Pattern '\\(\*|#)\s'} |
    select -ExpandProperty FullName

これらは textile の段階から手直しし、 Textile → Markdown の変換からやり直す。

ls -Recurse -File *.md | ? {sls -Path $_.FullName -Pattern '\\(\*|#)\s'} | % {
    pandoc `
        --from=textile --to=gfm+east_asian_line_breaks `
        --shift-heading-level-by=-4 --eol=lf `
        ($_.FullName -replace '.md','.textile') --output="$($_.FullName)"
}

この後で先に行っていた 2,3,5 の変換をすれば、期待の変換結果が得られた。

後始末

最後に、残しておいた Textile を全て削除する。当然、削除対象が正しいことを確認した後に消す。

# Dry run.
rm * -Include *.textile -Recurse -WhatIf
# Execution.
rm * -Include *.textile -Recurse

まとめ

なかなか手間がかかったが、うまくできた。今回の移行作業の中で、検知していない見落としもあるはずなので、そういうものは見つけたときに対処するものとする。

以下気づき。

Pandoc のオプションが大量にあり選ぶのが大変だが、おかげで期待する変換がしやすい
- 2013 年位からちょくちょく使うがこんなにゴテゴテとオプションをつけたのは初めて
「息の長くなりそうなドキュメント」は事前にわからないので、普段からきれいなフォーマットにすれば、後々変換する機会があっても手間が省ける
プレーンテキストは正義
複数行またがるタイプの正規表現のパターン記述力が足りない
日記に事象と感情の変化をセットで書いていたので、あとから見ても面白い。自己分析に使えそう