一昨年の夏にどうやってもテスト通らなくて放置してたゲームボーイエミュレータを根本的に書き換えてみたらだいぶましになった。最初はlens/Stateを使う方針でCPUのレジスタなんかをレコードのフィールドにぶち込んでそれらを書き換えていく感じだったが、ざっと書いたところでひどく遅くかなしくなった。今回はレジスタなどの本質的にミュータブルなデータを全部Vector.Unboxed.Mutableにぶちこんだら早くなったという話。そりゃそうなんよ。


lens/StateMでできるだけイミュータブルなレコード更新をしようとした型設計。


```haskell
type CPU a = StateT CPUState (StateT MBCState (StateT LoggerState IO)) a
data CPUState = CPUState {
    _a, __f, _b, _c, _d, _e, _h, _l :: Word8,
    _sp, _pc :: Word16,
    ...
  } deriving Show

makeLenses ''CPUState
```


フラグ更新などはFレジスタに詰め込まれているのでlens関数を用いてアクセサーを書ける


```haskell
carry :: Lens' CPUState Bool
carry = lens get set
  where
    get c = testBit (__f c) 4
    set c b =
      if b then
        c { __f = setBit (__f c) 4 }
      else
        c { __f = clearBit (__f c) 4 }
```


命令の実装などはStateをつかうことで、たとえばrustの実装と比べるとselfをまるっと省略ができている。それでありながら動的言語の様な記法でもある。一方で変数名にcarryやhalfもしくは省略してcとhを使いたかったが、フラグとレジスタのアクセサーと名前がかぶるので使えないあたりが不便なところ。名前空間。


```haskell
add :: OP -> CPU ()
add op = do
  (a', c', h') <- add8CarryHalf <$> use a <*> readOP8 op
  a .= a'
  zero .= (a' == 0)
  negative .= False
  half .= h'
  carry .= c'
```


```rust
fn add(&mut self, op: OP)  {
    let (a, carry, half) = self.a.add_carry_half(self.load8(op));
    self.a = a;
    self.set_carry(carry);
    self.set_half(half);
    self.set_negative(false);
    self.set_zero(self.a == 0);
}
```


上記のhaskellの実装ではモナドスタックをつかっており、なかなかモナモナとネストしてるあたり、こんなんでいいのか感もいなめない。モナドトランスフォーマーの宿命である。バベルの塔のごとく積み上がるモナドスタックをどうにかしようという試みとしてEffectなるものがある。最近ではOCamlに公式に採用されたらしい。よくはしらんけど。そんなんでhaskellのeffect実装を調べた感じではいくつかあるものの比較的浅いスタックだとmtlより遅いらしいということで採用は見送った。


そしてそのモナドスタックを潰しながら実行してく。


```haskell
type Gameboy a = StateT GameboyState IO a

data GameboyState = GameboyState {
    _cpu :: CPUState,
    _mbc :: MBCState,
    _logger :: LoggerState,
    _car :: Cartrige
  }

makeLenses ''GameboyState

stepGameboy :: GameboyState -> IO GameboyState
stepGameboy gb = do
  let run = flip runStateT
  (((_,cpu'),mbc'),logger') <- run (gb^.logger) $ run (gb^.mbc) $ run (gb^.cpu) executeCPU
  pure $ gb 
    & (cpu .~ cpu')
    . (mbc .~ mbc')
    . (logger .~ logger')
```


`(((_,cpu'),mbc'),logger') <- run (gb^.logger) $ run (gb^.mbc) $ run (gb^.cpu) executeCPU`という風にモナドスタックみを感じる。もうちょいましになりそうだけど。上記の様な実装ではゲームプレイはできない処理速度となった。一応StateとIORefとIOVectorを比べてStateが一番マシだったのでそれを採用したので、haskellでは無理なのかとかなしくなった。


その実装をたまに思い出しては少し手を入れたりしていた。モナドスタックを潰してステートをフラットにしたりした。CPUの命令がGBモナドになるので微妙な開放感がある。3倍くらい早くなったがそれでもまだ遅かった。


```haskell
type GB a = StateT GBState IO a

data GBState = GBState {
  _cpu :: CPUState,
  _mbc :: MBCState,
  _logger :: LoggerState
  }

-- CPU.hs
add :: OP -> GB ()
add op = do
  (a', c', h') <- add8CarryHalf <$> (use $ cpu.a) <*> readOP8 w
  cpu %= 
      (a .~ a')
    . (zero .~ (a' == 0))
    . (negative .~ False)
    . (half .~ h')
    . (carry .~ c')
```


そんなところで放置してたが今年の冬にrustで書いてみたら、あまりの実装のラクさと速さに余計にhaskellとはなんだったのかとかなしみをいっそう深めたのでもう一度haskell実装を考えてみることにした。最適化をすればC++並みの速度がでるとの記載をはるか昔に見たのを思い出しながら。


IOVectorのベンチは取ったがUnboxedを失念していたのでUnboxedも見てみたところ、なんかよくわからんほどの差がでたので、なぜ忘れていたのかとさらにかなしくなった。haskellのデータはサンクと呼ばれる形で保持されている。一見ただのInt8であっても`data Int8 = I8# Int8#`というようにdata型になっている。これはヒープのポインターであり遅延評価のときなどに役立つクロージャのようなもの。しかし遅延評価の必要もないプリミティブなデータであればその様なラベルを省略して生のデータとして扱えるよねというのがUnboxedだ。ということで「もう状態全部Vector.Unboxed.Mutableにぶち込もう」となり、以下のようなデータ構造と命令の実装になった。


```haskell
newtype Store a = Store (MVector (PrimState IO) a)

data CPU = CPU { 
  mbc :: MBC,

  regs8 :: Store Word8,
  regs16 :: Store Word16,
  ...
  }

data CPURegisters8 = A | F | B | C | D | E | H | L | IME | Halt | Cycle
  deriving (Enum, Show, Eq)

readReg8 :: CPU -> CPURegisters8 -> IO Word8
readReg8 (CPU {..}) r = readStore regs8 $ fromEnum r

writeReg8 :: CPU -> CPURegisters8 -> Word8 -> IO ()
writeReg8 (CPU {..}) r n = writeStore regs8 (fromEnum r) n

readFlag :: CPU -> CPUFlags -> IO Bool
readFlag cpu flag = do
  f <- readReg8 cpu F
  pure $ testBit f $ 4 + fromEnum flag

writeFlag :: CPU -> CPUFlags -> Bool -> IO ()
writeFlag cpu flag bool = do
  f <- readReg8 cpu F
  let f' = (if bool then setBit else clearBit) f (4 + fromEnum flag)
  writeReg8 cpu F $ f' .&. 0b11110000


add :: CPU -> Op8 -> IO ()
add cpu op = do
  (a, carry, half) <- addCarryHalf <$> readReg8 cpu A <*> readOp8 cpu op
  writeReg8 cpu A a
  writeFlag cpu Carry carry
  writeFlag cpu Half half
  writeFlag cpu Negative False
  writeFlag cpu Zero $ a == 0
```


StoreはただのVector.Unboxed.Mutableのラッパーである。CPURegistersをEnumのinstanceとすることでそのままVectorのインデックスとして扱える。速さを優先してlensもStateも使わなかったのですべての関数で明示的にそれらの状態を引き回す記述が増えている。こうなってくるとただのCよりめんどくさくて遅いCである気もしてくる。


ただだいぶ早くなった。テスト用のROMを26000000CPUStepくらい回すとテストが終わる。rust版と一秒差くらいなら悪くないんじゃないかな。両方とも最適化の余地が全然あるとは思う。haskellではPPUなどを書いてないのでゲームプレイはできない。終わり。


- [gbe-hs](https://github.com/kmtoki/gbe-hs/tree/main)
- [gbe-rs](https://github.com/kmtoki/gbe-rs/tree/main)
- [gb-test-roms](https://github.com/retrio/gb-test-roms)


```powershell
# 適当に端折ってます
> time { stack run -- .\rom\gb-test-roms\cpu_instrs\cpu_instrs.gb | Out-Default }
cpu_instrs

01:ok  02:ok  03:ok  04:ok  05:ok  06:ok  07:ok  08:ok  09:ok  10:ok  11:ok

Passed all tests

TotalSeconds      : 5.6943804


> time { cargo run --release .\rom\gb-test-roms\cpu_instrs\cpu_instrs.gb | Out-Default }
cpu_instrs

01:ok  02:ok  03:ok  04:ok  05:ok  06:ok  07:ok  08:ok  09:ok  10:ok  11:ok

Passed all tests

TotalSeconds      : 4.6624661

```

追記。rust版だけloggerがオンになってたのでオフにして計測し直した。約2.5秒に早くなった。

```
> time { cargo run --release .\rom\gb-test-roms\cpu_instrs\cpu_instrs.gb | Out-Default }
cpu_instrs

01:ok  02:ok  03:ok  04:ok  05:ok  06:ok  07:ok  08:ok  09:ok  10:ok  11:ok

Passed all tests

TotalSeconds      : 2.16294
```



### 動的にステートフルなトレイトオブジェクト


ゲームボーイにはMBCというコンポーネントがある。メモリとROM（ゲームソフト）にアクセスするためのもので16bitしかないメモリアドレス空間を拡張的に使うものだ。MBCにはいくつもの種類があり、微妙に実装が違う。どのMBCを使うかはを実行時に決まるので、ここで他言語におけるインターフェイスやトレイトオブジェクト的なものがほしいのだが、haskellには静的な型クラスしかない（ゆうてここあんま調べてなかったな。ふつうにData.Dynamicでいけるんかな）。そんなこんなでhaskellでもlens/Stateでステートフルなトレイトオブジェクトもどきを使った。


```haskell
type MBC a = StateT MBCState (StateT LoggerState IO) a

data MBCState = MBCState {
    _mbcnState :: MBCNState,
    _memory :: Memory,
    _reader :: Int -> MBC Word8,
    _writer :: Int -> Word8 -> MBC ()
  }

data MBCNState
  = MBC0State
  | MBC1State {
    _bank :: Int,
    _bank1 :: Int,
    _bank2 :: Int,
    _bankRAMX :: Int,
    _enableRAMX :: Bool,
    _bankingMode :: Bool
  } 
  deriving Show

makeLenses ''MBCState
makeLenses ''MBCNState

newMBCState :: Cartrige -> IO MBCState
newMBCState car = do
  _memory <- newMemory car
  pure $ MBCState { .. }
  where
    (_mbcnState, _reader, _writer) = case car^.mbcType of
      MBC0 -> (MBC0State, readMBC0, writeMBC0)
      MBC1 -> (MBC1State 0x4000 1 0 0 False False, readMBC1, writeMBC1)
      _ -> undefined
```


newするタイミングでROMに使われているMBCのタイプを読み取り実装と状態を選択するVTable的なやつ。


```haskell
readMBC1 :: Int -> MBC Word8
readMBC1 i
  | 0 <= i && i <= 0x3fff = (V.! i) <$> (use $ memory.cartrige.rom)

  | 0x4000 <= i && i <= 0x7fff = do
    (Just b) <- preuse $ mbcnState.bank
    rom' <- use $ memory.cartrige.rom
    pure (rom' V.! (b .|. (i - 0x4000)))

  | 0x8000 <= i && i <= 0x9fff = do
    ram' <- use $ memory.ram
    lift $ VM.read ram' i

  | 0xa000 <= i && i <= 0xbfff = do
    ramx' <- use $ memory.ramx
    (Just b) <- preuse $ mbcnState.bankRAMX
    if b == 0 then do
      ram' <- use $ memory.ram
      lift $ VM.read ram' i
    else 
      lift $ VM.read ramx' (b .|. (i - 0xa000))

  | otherwise = do
    ram' <- use $ memory.ram
    lift $ VM.read ram' i
```


preuseしてちゃんと自分のステートを引っ張ってこれる。しかしpreuseはおそらく毎回直和型を走査してデータを引っ張ってきているのでコストがかかる。newしたタイミングでそれは決定していて無駄な走査なので気になる点ではある。


Vector.Unboxed.Mutableで書き直した版ではStore Word64にまとめて放り込んでいて、すべてのMBCTypeの関数で同じ型のMBCStateを引き回してる。readするたびMBCTypeを判別しているので良くない気がする。


```haskell
readMBC :: MBC -> Word16 -> IO Word8
readMBC mbc@(MBC {..}) i = case mbcType cartridge of
  MBC1 -> readMBC1 mbc i
  _ -> error "readMBC unimplement MBCType"
```


### そういえば、zig


一昨年の夏、僕がhaskellに絶望していたころzigが流行っていたのでzigでも書いたのを思い出した。早すぎて意味がわからん。こんだけちがうとrust版もなんかおかしいな。


- [gbe-zig](https://github.com/kmtoki/gbe-zig/tree/main)


```
> time { zig build run -Drelease-fast -- .\rom\gb-test-roms\cpu_instrs\cpu_instrs.gb }
Serial:
cpu_instrs

01:ok  02:ok  03:ok  04:ok  05:ok  06:ok  07:ok  08:ok  09:ok  10:ok  11:ok

Passed all tests

TotalSeconds      : 0.937751
```


haskellでゲームボーイのCPUエミュレータを書いた

前記事においてよくわからんなとかいってたやつ。単純にキャリーしないときにオンにするかんじやな。


`.carry = (a ^ i ^ result) & 0x100 != 0`を逆にして`.carry = (a ^ i ^ result) & 0x100 == 0`でよいかんじでした。


```zig
fn addU16ToSingedU8WithCarryHalf(a: u16, b: u8) u16OpResultWithCarryHalf {
    const n = @intCast(u16, bitClear(u8, b, 7));
    if (bitCheck(u8, b, 7)) {
        const i = 128 - n;
        const result = a -% i;
        return .{
            .result = result,
            .carry = (a ^ i ^ result) & 0x100 == 0,
            .half = (a ^ i ^ result) & 0x10 == 0,
            //.carry = (a & 0xff) -% (i & 0xff) < (a & 0xff),
            //.half = (a & 0xf) -% (i & 0xf) < (a & 0xf),
        };
    } else {
        const result = a +% n;
        return .{
            .result = result,
            .carry = (a ^ n ^ result) & 0x100 != 0,
            .half = (a ^ n ^ result) & 0x10 != 0,
        };
    
    }
}
```


GBEのu16+i8、キャリーしてない場合はフラグを立てるっぽいな

GBEの16bit+8bitIntのときのフラグがよくわからん

![](https://cdn-ak.f.st-hatena.com/images/fotolife/b/bercriber/20220919/20220919030638.png)


[github/kmtoki/gbe-zig](https://github.com/kmtoki/gbe-zig)


エミュレータ開発用テストROMの[gb_test_roms/cpu_instrs](https://github.com/retrio/gb-test-roms)がパスしたのでcpuはざっくり書けたっぽい。過去にTypescriptとHaskellとRustで書いてて、TSはなんとか動いたけど、haskellとrustはcpuのテストをパスできなかったので三度目の正直ぎみ。


一番最初はrustで書き始めて、cpuの一命令ごとに関数呼び出しとかあかんやろとか適当なことを思って、命令を関数ではなくマクロで書いてしまったのでコンパイルがくっそ遅くなったのとエラーメッセージが読みにくくなったのでテストROMさえ回すことなく投げた。その次に、トライアンドエラーにおけるコンパイルのストレスをなくそうというのとブラウザで動かそうというモチベーションでTypescript/denoで書き始めた。低レイヤーの知識ゼロでなんにもわからない状態から始めたのと、既存エミュレータのコードは読まずに(daaで挫折してカンニングした)、英語読めないくせに英語ドキュメントしか見ないで実装するという謎の縛りプレイをやっていたので、数ヶ月かかりつつもなんとかブラウザで「ゼルダの伝説夢見る島」が動くようになった。その次に、haskellでとりあえずcpuざっくり書いたんだけど、コンパイル時間が10秒くらいかかるくせに、TS/deno版とくらべて4倍くらい遅いというかなしい結果になってしまって心折れた。lens/mtl/StateMonadでごりごりやっていったのがよくなかったのか、IOVectorが遅いのか、よくわからんけどちゃんと最適化すればどこまで早くなるのかは興味があるがコンパイルおそすぎて諦めてる。どこに最適化の余地があるのかもわからん。というかv8早すぎるだろ。


RustとかTSで書いたのが2年前で、Haskellで挫折したのが今年の夏で、なんかZig流行りだしたしこっちで試してみるかってなっていまここ。10日くらいでなんとなくcpu部分まで書けたんだけど、cpu_instrsテストをパスするまで一ヶ月かかってしまった。ここからこまかなタイミング合わせとか、ppuとか、apuとかやってるとまたどっかで詰んで終わらない感じになりそう。今回は詰んだら既存エミュのコードをカンニングしていくしかない。というかちょっと前に、[tanakh先生が怒涛のエミュ実装祭り](https://zenn.dev/tanakh/articles/gb-emulator-in-rust)をやっていて、そのコードを見てしまったのでだいぶ影響されたコードになってしまった。良いことだろうけど。


zigで良かったところは、コンパイル早い、実行早い、黒魔術のないシンプルで素直な言語機能。便利だったのが、型が自明であれば、enumとかstructの名前を省略できる。｀read(Register::IF)｀と書かなければいけなさそうなところを`read(.IF)`と書けるのでありがたかった。おかげでinstructionの呼び出しが短く書けた。イマイチだったところはキャストがめんどい。`@intCast(u16,0xff)`と関数呼び出し的な文法で長ったらしい。演算子もデフォルトではオーバーフローするとランタイムエラーで落ちるので、GBEのケースでは`255 + 1 // :u8`を`255 +% 1`と書く必要が多くあり、めんどい。あとはメモリ管理。人類には手動でメモリ管理するのは早すぎるとかなんとかは置いといて、ファイル一つ読むだけでも長くなる。


```zig
    pub fn readFile(allocator: std.mem.Allocator, path: []const u8) !ROM {
      const file = try std.fs.cwd().openFile(path, .{ .mode = .read_only });
      defer file.close();
      const stat = try file.stat();
      const buffer = try file.reader().readAllAlloc(allocator,stat.size);
      return parse(buffer);
    }


    pub fn main() !void {
      var gpa = std.heap.GeneralPurposeAllocator(.{}){};
      var path: []const u8 = "rom/gb_test_roms/cpu_instrs/cpu_instrs.gb";
      const rom = try ROM.readFile(gpa.allocator(), path);
    }
```


いちいちアロケーター引きずり回して開放も実装して(上記ではやってない)というのは、GCがないので当然ではあるし、その分軽くて早いという恩恵を受けるためにzig選んでいるわけだが、まぁめんどいよね。仕方がないというかなんというか。そのへんrustは上手だなと思うけど、使いこなすにはプログラム全体の構造をちゃんと把握して、所有権やライフタイムをきっちり理解した設計に最初からしないと破綻しがちというのは、クソザコナメクジの私にはつらい。場当たり的に書きながら考えるやり方なので、まぁしょうがないよね。


zigでゲームボーイエミュレータ書いてる

fieldParentPtrイディオムは極めてシンプルな実装になっている。しかしfieldParentPtrイディオムはLLVMの最適化と相性が悪いらしい。zig ver0.9からはAllocgateと呼ばれる手法でstd.mem.Allocatorやstd.rand.Randomが多相化されている。`*anyopaque`を使って型を無視することで動的に実装を選択できるようになっている。ええんかそれで。標準ライブラリでそれやってるくらいならそのうちに言語機能にtraitなりinterfaceなり実装されそうな気がするが、これの構文糖みたいなもんになるのだろうか。


```zig
const std = @import("std");

/// Use @fieldParentPtr
/// https://zig.news/david_vanderson/interfaces-in-zig-o1c
const FooI = struct {
    fooFn: fn(*FooI) void,
    fn foo(self: *FooI) void {
        self.fooFn(self);
    }
};

const Bar = struct {
    sym: u8,
    fooI: FooI,
    fn init() Bar {
        return .{ .sym = 0xff, .fooI = FooI { .fooFn = fooFn } };
    }
    fn fooFn(fooI: *FooI) void {
        const self = @fieldParentPtr(Bar, "fooI", fooI);
        std.debug.print("foo({}) from Bar\n", .{self.sym});
    }
};

/// Allocgate
/// https://pithlessly.github.io/allocgate.html
/// https://github.com/ziglang/zig/blob/master/lib/std/mem/Allocator.zig
/// https://github.com/ziglang/zig/blob/master/lib/std/rand.zig
const HogeI = struct {
    ptr: *anyopaque,
    hogeFn: fn (ptr: *anyopaque) void,
    fn init(pointer: anytype, comptime hogeFn: fn (ptr: @TypeOf(pointer)) void) HogeI {
        const Ptr = @TypeOf(pointer);
        std.debug.assert(@typeInfo(Ptr) == .Pointer); // Must be a pointer
        std.debug.assert(@typeInfo(Ptr).Pointer.size == .One); // Must be a single-item pointer
        std.debug.assert(@typeInfo(@typeInfo(Ptr).Pointer.child) == .Struct); // Must point to a struct
        const gen = struct {
            fn hoge(ptr: *anyopaque) void {
                const alignment = @typeInfo(Ptr).Pointer.alignment;
                const self = @ptrCast(Ptr, @alignCast(alignment, ptr));
                @call(.{.modifier = .always_inline}, hogeFn, .{self});
            }
        };
        return .{
            .ptr = pointer,
            .hogeFn = gen.hoge
        };
    }

    fn hoge(self: HogeI) void {
        self.hogeFn(self.ptr);
    }
};

const Fuga = struct {
    sym: u8,
    fn init() Fuga {
        return .{
            .sym = 0xff / 2
        };
    }

    fn hogeI(self: *Fuga) HogeI {
        return HogeI.init(self, hogeFn);
    }

    fn hogeFn(self: *Fuga) void {
        std.debug.print("hoo({}) from Fuga\n", .{self.sym});
    }
};



pub fn main() !void {
    var bar = Bar.init();
    bar.fooI.foo();

    var fuga = Fuga.init();
    var hogeI = fuga.hogeI();
    hogeI.hoge();
}
```


zigでinterface的なやつ

![](https://cdn-ak.f.st-hatena.com/images/fotolife/b/bercriber/20220803/20220803185513.png)


zigが流行ってると聞いて。人類に手動メモリ管理はまだ早いんだよな。もっと脳が進化してくれないと難しい。足りない脳でやってくしかないのだ現代人たる我(々?)は。


SDLのビルドでつまづいたりした。自分でbuild.zigいじるのいやだったので、パッケージマネージャーであるところのgyroを使ってみたけどうまく動かなかった。直接git cloneして`/libs`にでも突っ込んどけばなんとかなるっぽい。SDL2-develもルートに置いとけば勝手に見てくれるっぽい。SDL.zigがビルド用のSdkを用意してくれてるのでそれ任せ。


```zig
const std = @import("std");
const SDL = @import("sdl2");
const math = std.math;
const complex = math.complex;

pub fn main() !void {
    try SDL.init(.{
        .video = true,
        .events = true,
        .audio = true,
    });
    defer SDL.quit();

    const height = 800;
    const width = 800;

    var window = try SDL.createWindow(
        "SDL.zig",
        .{ .centered = {} },
        .{ .centered = {} },
        width,
        height,
        .{ .vis = .shown },
    );
    defer window.destroy();

    var renderer = try SDL.createRenderer(window, null, .{ .accelerated = true });
    defer renderer.destroy();

    var texture = try SDL.createTexture(renderer, .rgba8888, .streaming, width, height);
    defer texture.destroy();

    var buf = std.mem.zeroes([width * height * 4]u8);
    var y: f32 = -2;
    var x: f32 = -2;
    var i: usize = 0;
    while (i < width * height * 4) : (i += 4) {
        const m = mandelbrot(x, y, 255);
        const c = @intCast(u8, m);
        const b = @floatToInt(u8, @fabs(@floor(x * @intToFloat(f32, m))) / 255);
        buf[i + 0] = c;
        buf[i + 1] = b;
        buf[i + 2] = c;
        buf[i + 3] = c;

        x += 0.005;
        if ((i / 4) % width == 0) {
            x = -2;
            y += 0.005;
        }
    }

    try texture.update(&buf, 4 * width, null);

    mainLoop: while (true) {
        while (SDL.pollEvent()) |ev| {
            switch (ev) {
                .quit => {
                    break :mainLoop;
                },
                .key_down => |key| {
                    switch (key.scancode) {
                        .q => break :mainLoop,
                        else => {},
                    }
                },
                else => {},
            }
        }

        try renderer.setColorRGB(0, 0, 0);
        try renderer.clear();
        try renderer.copy(texture, null, null);
        renderer.present();
    }
}

fn mandelbrot(x: f32, y: f32, limit: u32) u32 {
    const c = math.Complex(f32).init(x, y);
    var z = math.Complex(f32).init(0.0, 0.0);
    var n: u32 = 0;
    while (n < limit) : (n += 1) {
        z = z.mul(z).add(c);

        if (complex.abs(z) > 2) {
            return n;
        }
    }
    return 0;
}
```


Zigでマンデルブロ集合

PopOSをインストールして環境設定してたらくそめんどくさかったんだけど、何一つメモ残してないから何がめんどくさかったのかわからないまま、ブログアップロードテストを迎えてしまったらいなう。


- GドライブのSSDのフォーマットがMBRだったのでハマる
  - 音楽とゲームのデータ置き場だったんだけど、なぜかMBRだった。データ移して、GPTにフォーマットし直して、データ戻して、パーテーション切って解決
- nvideaのドライバー付きのISOだったはずなんだけど、インストールしてリブートしたら画面真っ黒でハマる
  - リブート前にドライバー再インストールしたら直太朗
- 日本語入力できずハマる
  - Preonic/qmkの設定が悪いのだろうと思い込んでて、GUIからちゃんと設定できるやつ見逃してた
  - mozcにIMEの有効化無効化を変換無変換に割り当てるも、そもそも入力ソースにmozcを使う設定になってなかった
- dfu-utilがキーボードを認識せずハマる
  - qmkの設定変えようとするもdfu-utilがCannot Open Device
  - util/udev/50-qmk.rulesを/etc/udev/rules.d/に入れる
  - sudo udevadm control --reload-rules
  - sudo udevadm trigger
  - でなんとかなった気がする。色々やってて気がついたら治ってたパターン
- githubに接続できずハマる
  - sshキー設定してつなぐも違うfingerprintが帰ってきて戸惑う
  - 無視してEnter。つながった。これは大丈夫なのだろうか...
- nvim-qtがバッククォート表示しない
  - なんでや
- みんな大好きVimとIME。今更再びハマる。
  - fcitx5-mozc
  - autocmd InsertLeave * call system('fcitx5-remote -c')
  - autocmd InsertEnter * call system('fcitx5-remote -o')


設定するだけしてやることない問題


Pop_OSインストールしたら夕暮れを壁を挟んで三回背にしてた

GBEのPUSH/POPについてはそういうことみたいです。


SP--してからwrite、readしてからSP++

[keymap](https://github.com/kmtoki/dotfile/tree/master/keymap)


PreonicのQMKに定義してみた。一年ほど前に。キーマップ書いて一切練習してなかったのを思い出してちょっとやってみるかっと思ってファームウェア書き込んだら、修飾キーあたりが動かんくてなるほど、それで練習しなかったのかとなっとく。調べてみたもののこれでいいはずなんだけどなーってやつが思い通り動いてくれないので、NICOLAモード中にAltやCtrlを使えないという雑な作りでもういいや状態になってしまった。

---

とかなんとか書いていて、ふと思いついた修正をいれてみたら直ったぞ。まぁよかった。


[Unicode Support](https://github.com/qmk/qmk_firmware/blob/master/docs/feature_unicode.md)


話を戻して、`rules.mk`に`UNICODEMAP_ENABLE = yes`としてUnicodeMapをわーと日本語の定義を書いて、ってこれぜったいどっかにあるだろ。自分で書くなよ。と思いつつも書いて。NICOLA配列もわーとならべて。いくぜーとフラッシュしても全然文字化けしてて。えーと思いつつぐぐると設定がもうひとつたりてなくて。UnicodeのInputModeを指定する必要があるらしく、しかしWindowsのビルドインメソッドはおすすめしないよと書いてあって、代わりに書いてあったのが、[WinCompose](https://github.com/samhocevar/wincompose)というアプリを使えと。それインスコして、`matrix_init_user`に`set_unicode_input_mode(UC_WINC)`を追加しておつかれさまでした。


QMKにNICOLA配列でも設定するか


```haskell
{-# LANGUAGE GeneralizedNewtypeDeriving #-}

data InnerState = InnerState { _y :: Int }
newtype Inner m a = Inner { runInner :: StateT InnerState m a }
  deriving (Functor,Applicative,Monad,MonadState InnerState,MonadTrans,MonadIO)

data AppState = AppState { _x :: Int }
newtype App m a = App { runApp :: StateT AppState m a }
  deriving (Functor,Applicative,Monad,MonadState AppState,MonadTrans,MonadIO)
```

GeneralizedNewtypeDerivingに任せれば良い。以下経緯。


---


```haskell
data InnerState = InnerState { _y :: Int }
type Inner m a = StateT InnerState m a

data AppState = AppState { _x :: Int }
type App m a = StateT AppState (StateT InnerState m a) a

makeLenses ''InnerState
makeLenses ''AppState

app :: App IO ()
app = do
  x += 1
  x' <- use x 
  y' <- lift $ do
    y += 1
    use y
  liftIO $ print (x',y')
```


みたいなことをやりたいとして、とりあえず動くわけだがMonadスタックが深くなってくるとtypeの書き方が気になってくる。


```haskell
type App m a = 
  StateT AppState (StateT InnerState (StateT InnerState2 (StateT InnerState3 (StateT InnerState4)))) a
```


このデータ構造の設計がそもそも悪いのではないかと言われればそうなんだが、まぁごりごりやっていくとこう成り果ててしまうこともある。それはそれとして。こういう場合にtypeの書き方を以下のように短くしたい。


```haskell
type Inner m a = StateT InnerState m a
type Inner2 m a = StateT InnerState2 m a
type Inner3 m a = StateT InnerState3 m a
type Inner4 m a = StateT InnerState4 m a
type App m2 a = StateT AppState (Inner (Inner2 (Inner3 (Inner4 m)))) a
```


しかし、


```haskell
--  • The type synonym ‘Inner’ should have 2 arguments, but has been given 1
--  • In the type synonym declaration for ‘App’
--
--  | type App m2 a = 
--  |   StateT AppState (Inner (Inner2 (Inner3 (Inner4 m)))) a
```


と怒られる。typeではうまくいかないようだ。そこでtypeをnewtypeにすると、


```haskell
newtype Inner m a =  Inner  { runInner  :: StateT InnerState m a }
newtype Inner2 m a = Inner2 { runInner2 :: StateT InnerState2 m a }
newtype Inner3 m a = Inner3 { runInner3 :: StateT InnerState3 m a }
newtype Inner4 m a = Inner4 { runInner4 :: StateT InnerState4 m a }
newtype App m a = App {
    runApp :: StateT AppState (Inner (Inner2 (Inner3 (Inner4 m)))) a
  }
```


部分的には解決しそうだが、


```haskell
--  • No instance for (Monad (App IO)) arising from a do statement
--  • No instance for (MonadState AppState (App IO))
--  • No instance for (MonadTrans App) arising from a use of ‘lift’
--  • No instance for (MonadState InnerState IO)
--  • No instance for (MonadIO (App IO)) arising from a use of ‘liftIO’
```


と怒られる。こんどはMonad系のinstanceがないぞと。こちらとしてはただの`StateT HogeState m a`のエイリアスみたいなノリで使いたいだけなのに自分で定義する必要があるらしい。


```haskell
{-# LANGUAGE GeneralizedNewtypeDeriving #-}

-- Inner[2,3,4]は省略
newtype Inner m a = Inner { runInner :: StateT InnerState m a }
  deriving (Functor,Applicative,Monad,MonadState InnerState,MonadIO,MonadTrans)

newtype App m a = App { runApp :: StateT AppState m a }
  deriving (Functor,Applicative,Monad,MonadState AppState,MonadIO,MonadTrans)
```


GNDのderivingが全部やってくれる。最初は以下のように手で書いていたがそんな必要はなくて俺はなにやってたんだ状態になったのでした。最初にGNDを試して駄目だった気がしたのは気のせいだったのだろう。


```haskell
newtype Inner m a = Inner { runInner :: StateT InnerState m a }
  deriving (Functor,Applicative,Monad)

newtype App m a = App { runApp :: StateT AppState m a }
  deriving (Functor,Applicative,Monad)

instance Monad m => MonadState InnerState (Inner m) where
  get = Inner get
  put = Inner . put

instance Monad m => MonadState AppState (App m) where
  get = App get
  put = App . put

instance MonadTrans App where
  lift m = App $ StateT $ \s -> do
    a <- m
    pure (a,s)

instance MonadTrans Inner where
  lift m = Inner $ StateT $ \s -> do
    a <- m
    pure (a,s)

instance MonadIO m => MonadIO (App m) where
  liftIO = lift . liftIO

instance MonadIO m => MonadIO (Inner m) where
  liftIO = lift . liftIO
```


Bercriber's Blog