TomlViewの構想を書いておこうぜ☆（＾～＾）？

「　TomlView　の構想を書こうぜ☆？」

「　何だぜそれ☆？」

retention_days = 2

「　↑　例えば　上記は ファイル保持日数の設定だが……☆」

retention   2   days   [↑]
          -----        [↓]

「　↑　うまく説明できないが、 GUI が欲しいわけだぜ☆」

「　そうか☆」

level = Trace

「　↑　一番欲しいのは、選択形式のやつだぜ☆」

        +--------+
level = | Trace  |
        +--------+
        | Trace  |
        | Debug  |
        | Info   |
        | Notice |
        | Warn   |
        | Error  |
        | Fatal  |
        +--------+

「　↑　まあ、だから GUI が欲しいんだぜ☆」

「　誰かが作っているのでは☆？」

「　View が乱立してて Visual Studio Code の エクステンション になってりゃいいのかもしれないが、
製品に縛られたくない……、どんなPCにでもあるのは ターミナル☆」

「　Webブラウザーで見るのが　筋が良くない？」

「　Web サーバー立てるのが大変だろ……、 Localhost で立てるにしても☆」

「　今なら Docker があるだろ☆」

「　かなり長い道のりだな……☆　やるなら　Nginx + uWSGI + Python + Flask on Docker がベターだが、
Nginx + FastCGI + Golang on Docker のスキルも習得したい……☆」

「　Golang でやると 配るの大変だろ☆ crates.io みたいな パブリッシュ サイトがない☆」

「　Webブラウザーって、ローカルのファイルを編集できないのかだぜ☆？」

「　サンド・ボックスがどうなのかしらねぇ？」

「　調べてみるか……☆」

ブラウザからドライブにファイルの書き込みができるNative File System APIとは？

「　↑　Google chrome が手を付けてるみたいだが、もっと調べてみるぜ☆」

ChromeのNative File System APIを触ってみる
The Native File System API: simplifying access to local files
Native File System APIでローカルの画像をリサイズする

「　↑　HTTPS にしないといけないのか☆　めんどくせ☆」

「　ジョークソフトとして CUI で作れだぜ☆ toml-cui で Rust で☆」

rcmdnk/sentaku

「　↑　何かはあるが、それが何かは分からない☆」

「　MS-DOS　のあれ、名前　なんだったっけ☆？」

「　あれじゃ分からん☆」

「　基本ソフトみたいなやつ☆ じゃあストレートに command-line-toml とかでいいのか……？」

「　お父んがやりたいのは　リストボックスなんだよなあ☆」

「　あー、toml-menu とか☆」

「　どんなことが　できんの？」

> retention_days  [     2 ]
  level           [ Trace ]
  timeout_secs    [    30 ]

「　昔風に言えば　こういうやつだぜ☆」

「　なんだこの BIOS みたいなの☆」

「　Rust でそもそも　こんなんできたっけ……☆？
カーソル入力とか☆　調べてみるか……☆」

casual-logger.type.toml:

# This file is a test.
# このファイルはテスト用です。

file_name = { type = 'string', regex = true, default = 'default', value = '^[a-zA-Z0-9_-]+$' }
file_ext = { type = 'select', default = '.log.toml', value = ['.log.toml', '.log'] }
retention_days = { type = 'i16', default = 7, min = -100000000, max = 100000000 }
level = { type = 'select', default = 'Trace', value = ['Trace', 'Debug', 'Info', 'Notice', 'Warn', 'Error', 'Fatal'] }
timeout_secs = { type = 'u32', default = 30, min = -100000000, max = 100000000 }

「　例えばこう☆」

「　そうか☆　このあとお父んは　OS　を作ってしまうのか……☆」

「　ディレクトリ階層を移動してそうだよな☆　あれ　何ていう名前だったかな☆？」

「　あれじゃ分からん☆」

「　シェルじゃないの？」

「　シェルに　リストボックスは無いだろ☆」

「　アドベンチャーゲームみたいなやつ☆」

「　じゃあ　TOMLアドベンチャー　でいいだろ☆」

「　Rust でそんなに CUI 操作できたか分からん……、やはり調べないと……☆」

コマンドラインアプリケーション
Command line apps in Rust

「　↑　色を付けたりする説明が出てこないな……☆」

コンソール・アプリケーションで文字色や背景色を変えるには？［2.0、C#、VB］

「　↑　C# にはあるし、昔は もっと普通にでけた☆」

[Rust] 標準出力に色をつける - 3bit/8bit/24bit color

「　↑　やってるやつはいる☆　なんでこんな古いこと　やらなければいけないのか……☆？」

「　↑　とりあえず　ファイル読取はできるので、これを整形したい……☆」

「　桁ぞろえとか、やること多くない？」

「　罫線も引かなければならないだろうし、ページングはどうする？」

「　帳票ソフト作るぐらい大変だよな☆　連休に何をやろうとしてるんだろうな☆？」

「　パーサーを作る前に、トークンナイザーを作らないといけないよな☆」

「　何を言ってるか分かんないわね」

2020-07-27(mon) 18:50

「　TOMLのパーサーを　車輪の再発明する☆」

「　そうか☆」

# Top level
x = 1

[Apple]
    # Table level
    x = 1

「　↑　TOML の トップ・レベルは、テーブルの下と同じだぜ☆
だから TOML のトップ階層は、名前のない、空文字ですらないテーブルの下だと思えだぜ☆」

「　細かいこと気にすんのね」

apple = 'pie'

[banana]
apple = 'juice'

[[cherry]]
color = 'red'

[[cherry]]
color = 'green'

[[cherry]]
color = 'blue'

「　↑　 テーブルの下には、大きく分けて　３種類のものを置けるぜ☆
それぞれ　説明しよう☆」

apple = 'pie'

「　↑　これは Value with Key とでも覚えてくれだぜ☆
Java なら KeyValuePair と呼ぶ☆」

apple = 'pie'
-----   -----
Key     Value

「　↑　イコール（=）の左側が キー で、要するに名前だぜ☆
右側は バリュー（値）だぜ☆　バリューには色んな種類があるので　あとで説明する☆」

[banana]
apple = 'juice'

「　↑　これは banana テーブル☆　何に似ているかというと、フォルダーに似ている☆
テーブルの下に何が置けるかは　さっき説明した通りだぜ☆」

[[cherry]]
color = 'red'

[[cherry]]
color = 'green'

[[cherry]]
color = 'blue'

「　↑　最後に Array of Table with Key （名前付きのテーブルの配列）だぜ☆
同じ名前のフォルダーをたくさん作れる、みたいに考えてくれだぜ☆
名前付きテーブルの配列の下に何を置けるかも、テーブルと同じだぜ☆」

「　ごちゃごちゃ　してんな☆」

TOMLJSON Online converter

「　↑　それぞれ、 JSON に変換すると どんな形になるかを知っておくと 理解が早いぜ☆
１つ１つ見ていこう☆」

apple = 'pie'

{
  "apple": "pie"
}

「　↑　名無しのテーブルに入ってるのが見えるな☆」

[banana]
apple = 'juice'

{
  "banana": {
    "apple": "juice"
  }
}

「　↑　テーブルは、名前付き になってるのが見えるな☆」

[[cherry]]
color = 'red'

[[cherry]]
color = 'green'

[[cherry]]
color = 'blue'

{
  "cherry": [
    {
      "color": "red"
    },
    {
      "color": "green"
    },
    {
      "color": "blue"
    }
  ]
}

「　↑　名前付き配列の要素が、全部テーブルだな☆」

「　名前付きの配列は無いの？」

「　有る☆　お見せしよう☆」

apple = [ 'pie', 'juice' ]

{
  "apple": [
    "pie",
    "juice"
  ]
}

「　↑　こうだぜ☆」

「　なんで　テーブルの配列　だけ　特別に構文があんの？」

「　知らね☆
テーブルも　名前付きバリュー　のバリューのところに書けるぜ☆　やってみよう☆」

food = { apple = 'pie', banana = 'juice', cherry = 'rice' }

「　↑　これが　Inline table　だぜ☆
最後の項目の後ろにカンマを付けれないことと、 { から } まで 改行してはいけないという特徴を覚えろだぜ☆」

「　なんで改行しちゃいけないの？」

「　ふつうの テーブル があるからだぜ☆
１行にするか、１項目ずつ改行するかの２択だぜ☆」

「　ぜったい　そんなん知らない　おっちゃん　改行しちゃうわよね？」

「　専用エディターが居ると思う☆　そんなん知らない　おっちゃん　は　ウィンドウズのメモ帳　使うだろうけど☆」

「　配列は　改行していいの？」

apple = [
'pie', 'juice'
]

{
  "apple": [
    "pie",
    "juice"
  ]
}

「　↑　していいぜ☆」

「　変なの」

「　次に、ネスト　を見ていこうぜ☆？」

[pinapple]
drink = 1

[pinapple.banana]
drink = 2

[pinapple.banana.cherry]
drink = 3

{
  "pinapple": {
    "drink": 1,
    "banana": {
      "drink": 2,
      "cherry": {
        "drink": 3
      }
    }
  }
}

「　↑　テーブルのネストは　こう書くぜ☆」

「　ずっとフルパスじゃない。うざ……」

「　TOMLの特異性って そこだよな☆
つまり TOMLの テーブルというシステムは 絶対パスにしなさい という縛りだぜ☆」

「　人類はよっぽど　インデントに失敗するのだろう……☆」

[[pinapple.banana.cherry.grape]]
drink = 4

[[pinapple.banana.cherry.grape]]
drink = 5

[[pinapple.banana.cherry.grape]]
drink = 6

{
  "pinapple": {
    "banana": {
      "cherry": {
        "grape": [
          {
            "drink": 4
          },
          {
            "drink": 5
          },
          {
            "drink": 6
          }
        ]
      }
    }
  }
}

「　↑　テーブルの配列は　こうなる☆
これが、 TOML は明瞭で読みやすい、ということだな☆」

「　インデントや、閉じかっこ　を排除したのが TOML なのね」

「　べつに　インデントしてもいい……☆　しなくていいだけで☆」

「　配列には　絶対パス特典　無いんだな☆」

「　TOML のモデルは　内部的に JSON のような構造にするの？ それとも TOML のままの構造にすんの？」

「　TOML の構造のまま　持つというのも手だよな☆
そうすると　何行目でエラー、とか　出せる特典が付けれる☆」

「　マークアップの思想かだぜ☆　原文そのままに　意味だけ足す、みたいな☆」

「　TOML の ML は マークアップ・ランゲージ ではなく　ミニマル・ランゲージ　だったのね」

Document
|
+-- BroadLine
    |
    +-- Line
    |
    +-- Line    

「　↑　ドキュメントは、　ブロード・ラインを複数個持っていて、
ブロード・ラインは　行 を複数個持っている、という構造で行けるだろうか☆？」

「　折りたたまれた行、を表すいい具合の英単語は無いだろうか☆？」

pub enum Line {
    Single,
    Multiple,
}

「　Rust は Enum 型があるのよ」

「　うーむ、その方がスマートかだぜ☆」

「　しかし　Lines という名前で 途中に Multiple が挟まってたら、行数ではなくなるな……☆」

「　Variable height lines でどうか☆？」

「　名前が長いが、そういうことだよな☆」

「　ラインの中にテーブルが入ってるのって　おかしくない？
もう　パラグラフ　とかいう名前にしたら？」

「　パラグラフ、という感じじゃないんだよな……☆
セクション　でいいかな……☆
セクションだと、行だとういことが分からないだろ☆
ブロード・ライン　の方がいいかな☆」

Document
|
+-- BroadLine
    |
    +-- EmptyLine
    |
    +-- Comment
    |
    +-- KeyValuePair
    |
    +-- Table
    |
    +-- ArrayOfTable

「　↑　なるべく平易な名前にすると　こうか☆」

2020-07-28(tue)

「　行スキャナーにするべきか、行にこだわらないスキャナーにするべきか☆」

「　どういう違いがあるの？」

「　１行の終わりまでスキャンした時点で、何かしらの成果を返すか、それとも、
どこで終わったかは　サブのスキャナーに判断させるかの違いだぜ☆」

「　配列や、複数行文字列は、複数行に跨るわよ」

「　そこも　ライン・スキャナー　ではなく、　ブロード・ライン・スキャナー　という概念で作るか……☆」

Foreach Tokens
|
+-- BroadLineParser
    |
    +-- EmptyLineP
    |
    +-- CommentP
    |
    +-- KeyValuePairP
    |
    +-- TableP
    |
    +-- ArrayOfTableP

「　↑　ざっと、こう☆」

「　Empty のパーサーなんか作れるのか☆？」

「　正確には　NewLineOnly parser だよな☆」

「　何もマッチしなかった、ということを能動的に書けるのかだぜ☆？」

「　要は、残りのうち、エラー無く終わったやつだぜ☆」

「　判定しづらいのは Table と Array of table の違いだよな☆
最初に出てくる文字が [ で、２文字目が [ でないならテーブルで、
最初に出てくる文字が[[ なら テーブルの配列だぜ☆」

「　２文字目まで バッファーしなさい」

「　そこは マシン・ステート でやったらどうか☆
１文字目が [ だったら、 AfterLeftSquareBracket 状態に遷移するんだぜ☆」

「　それは 一貫性があるかも……☆！」

「　きふわらべちゃんは 偉いわねぇ」

「　……☆！」

「　テーブルと、配列のテーブルのパーサー　の終端子もまた　テーブルと、配列のテーブルというのを説明する☆」

[apple]
# 次のテーブル、または配列のテーブルまで同じセクション

[banana]

[apple]
# 次のテーブル、または配列のテーブルまで同じセクション

[[banana]]

[[apple]]
# 次のテーブル、または配列のテーブルまで同じセクション

[banana]

[[apple]]
# 次のテーブル、または配列のテーブルまで同じセクション

[[banana]]

「　めんどくせ……☆」

「　しかし、入れ子構造にしなくていい、というメリットもあるぜ☆
TOML のテーブルは、フラット☆」

2020-10-10(sat)

「　久しぶりに　ソースコード　を見たら、　ブロードライン　という概念が　分からない……☆」

「　ダメなのでは☆？」

Document scope element
|
+-- Array of Table
|
+-- Comment
|
+-- KeyValue
|
+-- Table

「　↑　ドキュメント・スコープ　と　ドキュメント・スコープ・エレメント　という概念に　変更するか……☆？」

            match self.broad_line_p.parse(token) {
                SyntaxParserResult::End => {

「　↑　プログラム中に　SyntaxParserResult　という長い名前が書いていると　頭に入ってこないぜ☆」

「　syntax_parser をモジュール名にして、構造体の名前は　Result　にしたらいいんじゃない？」

「　そうしてみるか……☆」

「　PResult にする☆」

＜書きかけ＞