MakoServerを動かしてみた

MakoServerというものがある

Lua ServerPage(LSP)を処理するWEBサーバという位置づけで、LSPという拡張子のファイルをHTMLとして表示してくれる
LSPの中にはLuaScriptを書くことができる
ログインフォームのサンプルを表示してみた

これをIISなどで表示するのであれば、
IISからMakoServerへポートフォワードしてやればよさそう
Luaは型の無いスクリプト言語で最速といわれている

GitのサンプルにはWebSocketなどもあり
コンパイル無し（内部ではやってるようだけど）で動かせるため開発効率も高いはず

HTML＋JavaScriptで封筒宛名印刷

封筒の宛名印刷をしようと思いHTML＋JavaScriptで作ってみました

サンプルをこちらに置きます

ダウンロードして開くとこのようなページが表示されます

キーボードのnでNext、pでPrevious、rで１８０度回転します

うちのHP SmartTank 6006では回転印刷ができないので、

rを押してひっくり返った状態で印刷をします

ブラウザからプリントで封筒へ印刷できます

封筒は前面給紙トレイに、封筒の表面を下＋封筒の閉じる側を手前に向けてセット

位置がずれる場合は適宜調整をお願いします（HTML内に座標が書いてあります）

データはHTML内にJSONで定義されているので、それを参考に差し替えてください

DBでMAX

 DBでIDなんてものはオートインクリメントにしておけよと思うのだけど

select

    max(id)

from

    TBL_A;

こういうのでIDのMAXを取得してインクリメントしてインサートというパターンがある

ところで、上記SQLには大問題がある

データが入ってない場合、NULLになってしまうのだ

するとMAX取得ができないでエラーとなる

仕方ないのでこうする

select

    COALESCE(MAX(id),-1)

from

    TBL_A;

これだと一件もデータがないときには-1となり、インクリメントして０

そのままインサートしてIDが０のデータが出来上がる

次からはMAXを取得するので0が取得できるため、インクリメントして１

そのままインサートしてIDが１のデータが出来上がる

元からダミーデータが入っているような環境だと気が付かないので要注意だ

ついでに書いておくけど

DBにテーブルを作るとPrimaryKeyが必要になる

これが何のために使われるかというと２点あって

１．重複しないため

２．ソートのため

ここで２はあまり重要ではない

IDでソートするパターンなんてあまりないからだ

なので重複しない目的のためならUDIDのようなものを割り振っても構わないはずだ

しかし、本当にそうか？

実はDBのPrimaryKeyとは、インデックスがあるため、順番を検索してインサートが行われる

すると、UDIDの山を一生懸命探しに行くことになるのでインサートは遅くなる

ちなみに大手のDBでは、インデックスを３つ作成するとインサートが１０倍遅くなると言う

わたしはこの点、もはやDBの構造的問題に思えて仕方ない

ここ数年かけてXML DBについて考えてきたが

XML DBであればこういうソートだのインデックスだのいう概念をうまく包括できると考えている（インデックスが自動的に勝手に存在するようになる）

その果てにたどり着いたのはファイルシステムで表現してしまえばいいではないかという結論だった（様々な考察をして利点があると考えた）

しかし、次にファイルシステムでは足りないということにも気が付いた

そこで既存ファイルシステムでは何が嫌なのかという点を列挙してみることにした

1. 同じフォルダに同名のファイルやフォルダが作れない

2.ファイルやフォルダに任意のプロパティを設定できない

3.ファイルやフォルダの順序が明確ではない

4.パスに限界がある

何言ってるかわからないかも知れないが

わたしは非常識な事を言っているのである

逆に言うと常識で考えないでほしい

WindowsでもLinuxでもファイルシステムはかなり昔からあるものを拡張し続けている

しかし、上記４点を改善できれば、XMLのタグやInnerTextなどをそのままファイルシステムで表現できるようになる

もちろん、JSONやYAMLもファイルシステムに置き換えられるだろう

早速ファイルシステムを考え始めた（いまさらか？）

世の中にはFUSEというものがある

これを使うと結構簡単に実現できるかもしれない

あとは設計製造だ

今ここまでたどり着いた

３Dプリンタを園芸へ

 最近３Dプリンタを園芸に使っている

バラ用の鉢はこれに統一することにした

PETGで作れば耐候性も充分だ

サボテンの方は以前投稿した通り

TPUで六角形の小さい鉢を作り沢山植えてある

XML Dataをフォルダやファイルシステムでシリアライズする方法に関して考察

XML Databaseライクなものを作るために、XML構造をフォルダとファイルにシリアライズする方法をずっと模索してきた

大体アイデアが固まったので、ChatGPTに聞いてみた

そしたらPythonコードで確認までしてくれて、おいおいお前まぢかってなった

ただし、わたしは知っている

途中に挿入するコメントの事を考えてない（コメントは無視で保存したいが、、、）

ネームスペースはフォルダにアンダーバーで区切って保存するように考えている

====ChatGPTに聞いた内容

XMLをフォルダやファイル構造にしてシリアライズするアイデアを再考していたが

アトリビユートをファイル名にすると、元のXMLを再現する事ができない（アトリビユートの順番が再現不能）

そこでアトリビュートをAttr.txtにまとめ、タグ内のテキストはinner.txtに保存するように考えた

タグはフォルダにするが、プレフィックスとして番号付けを行う

例

<books>

    <author name="太宰治">

太宰の作品

        <book title="人間失格" price="100">

         <book title="走れメロス" price="90">

    </author>

    <author name="尾崎紅葉">

        <book title="金色夜叉" price="200">

    </author>

</books>

これを以下フォルダ構造にする

root/0_books/0_author/inner.txt(content:name=太宰の作品)

root/0_books/0_author/attr.txt(content:name=太宰治)

root/0_books/0_author/0_book/attr.txt(content:title=人間失格<crlf>price=100)

root/0_books/0_author/1_book/attr.txt(content:title=走れメロス<crlf>price=90)

root/0_books/1_author/attr.txt(content:name=尾崎紅葉)

root/0_books/1_author/

0_book/attr.txt(content:title=金色夜叉<crlf>price=200)

これであれば、元のxmlを完全にフォルダ構造から復元できる

====ここからChatGPTの答え

このアプローチは、元のXML構造を完全に再現するために非常に有効です。アトリビュートやタグ内のテキストの順序も維持できるため、正確な復元が可能です。また、プレフィックスとして番号を付けることで、同じタグ名を持つ要素の区別も明確になります。

この方法での実装は非常に理にかなっています。次に、具体的にそのフォルダ構造を生成し、XMLをファイルシステムにシリアライズするためのPythonコード例を示します。

### Pythonコード例

```python

import os

import xml.etree.ElementTree as ET

def serialize_element(element, parent_path, prefix):

    # Create directory for the current element with prefix

    dir_name = f"{prefix}_{element.tag}"

    dir_path = os.path.join(parent_path, dir_name)

    if not os.path.exists(dir_path):

        os.makedirs(dir_path)

    

    # Write attributes to attr.txt

    if element.attrib:

        attr_file_path = os.path.join(dir_path, "attr.txt")

        with open(attr_file_path, 'w') as attr_file:

            for key, value in element.attrib.items():

                attr_file.write(f"{key}={value}\n")

    

    # Write inner text to inner.txt if it exists

    if element.text and element.text.strip():

        inner_file_path = os.path.join(dir_path, "inner.txt")

        with open(inner_file_path, 'w') as inner_file:

            inner_file.write(element.text.strip())

    

    # Recursively process child elements with a numerical prefix

    for i, child in enumerate(element):

        serialize_element(child, dir_path, i)

# Load XML

xml_string = """

<books>

    <author name="太宰治">太宰の作品

        <book title="人間失格" price="100"></book>

        <book title="走れメロス" price="90"></book>

    </author>

    <author name="尾崎紅葉">

        <book title="金色夜叉" price="200"></book>

    </author>

</books>

"""

root = ET.fromstring(xml_string)

# Define the base directory where the XML will be serialized

base_dir = 'output_dir'

if not os.path.exists(base_dir):

    os.makedirs(base_dir)

# Start the serialization process

serialize_element(root, base_dir, 0)

```

### フォルダ構造生成結果

上記のPythonコードを実行すると、次のようなフォルダ構造が生成されます：

```

output_dir/

└── 0_books/

    ├── 0_author/

    │   ├── attr.txt (content: name=太宰治)

    │   ├── inner.txt (content: 太宰の作品)

    │   ├── 0_book/

    │   │   └── attr.txt (content: title=人間失格\nprice=100)

    │   └── 1_book/

    │       └── attr.txt (content: title=走れメロス\nprice=90)

    └── 1_author/

        ├── attr.txt (content: name=尾崎紅葉)

        └── 0_book/

            └── attr.txt (content: title=金色夜叉\nprice=200)

```

### この方法の利点

- **順序保持**: XMLの要素やアトリビュートの順序が保持され、正確に再現可能。

- **明確な階層構造**: 番号付きのフォルダ構造によって、同一タグ名の要素も正確に区別できる。

- **シンプルな再構築**: フォルダ構造から元のXMLを再構築するのが容易。

これで、XMLデータを正確にシリアライズおよびデシリアライズできるシステムが実現できます。

散水機付けてみました

散水機付けてみました

自分が外出してたら水あげられないので

今後はどうしても必要になります

弁が四つついてて

NOWボタンで現在時刻を合わせ

ABCDで弁を選びます

選んだらOFF長押しでタイマーOFF

蛇口マークでマニュアルで弁を開きます（その際開いてる時間を指定）

プラスマイナスは時間の調整

OKはカーソルを次に送るボタンです

タイマーは何時に弁を開くか

何分開くか

何時間おきにタイマーを繰り返すか

と言う設定が出来ます

値段は最後の写真にありますが

ホースが足りなくて

Amazon探したら同じ物が同じような値段で合ったので追加購入してます（まだセットアップが残ってます）

構文木

https://trilltrill.jp/articles/3740097

5÷(8−3)×2+1を正しく計算できる？

というやつだ

答えは3なんだけど、

LRで構文木を作ると

まず、Rを探しに行く

右端は+ 1

                    PLUS

                /                \

       5/(8-3)*2           1

続いて、LからまたRを探すと、* 2

                    PLUS

                /                \

            MUL             1

          /          \

5/(8-3)      2

さらにLの5/(8-3)にRを探すと/ (8-3)

                   PLUS

                /               \

            MUL           1

          /           \

       DIV          2

     /       \

   5      8-3

んで、今度はR側にまだ再帰できるところがあるので

                   PLUS

                /               \

            MUL           1

          /           \

       DIV          2

     /       \

   5      MINUS

           /             \

         8              3

これで構文木が完成

そんで、答えを出すには最下層から上に上がっていく

8-3=5なので

                   PLUS

                /               \

            MUL           1

          /           \

       DIV          2

     /       \

   5         5

続いて

 5/5=1なので

                   PLUS

                /               \

            MUL           1

          /           \

        1          2

 

さらに続けて

1*2=2となり

                  PLUS

                /               \

              2                1

最後は

2+1=3

という事で、答えの3が導ける

ここで、数式とプログラミング言語を比べると、C言語なんて関数なので、

例えばif文

if (a==b) {

    proc();

}

          if

       /       \

    ==    proc()

   /      \

a        b

のようになるし、forも代入も似たようなもんで、構文木を作って解釈して行くことになる

このやり方はクヌース大先生が考案したもので、その後多くのアイデアが出てくるのだけど、基本はやはり構文木を作るというやり方になっている

そして、lexやyaccが生まれ、

構文木を自動生成するためにBNF記法が生まれ、C言語などのプログラミング言語が出来た

C++では構文定義をC++の記法で置き換えたboost::spiritsなども生まれ、すぐにこの変態的実装はなくなるかと思ったが、C++17でも残ってる

lexやyaccは

flexやbisonになったが

わたしが最近触っているANTLRは構文定義からGoやSwiftのコードも出力できる

好みの言語で新しい言語を作ることができるようになってきた

XML2Json再考

突然思い出したので

忘れないうちに書いておきます

Xerces Xalan

今はなかなか見かけない

この２つのプロジェクトは

XMLを扱っていた人ならご存知でしょう

実装の中身を見ていませんが

XMLをDOMとして扱っておらず

逐次的に処理をする実装になっていると聞いたことがあります

DOMについて

公式での解説も何だかパッとしないので改めて説明します

DOMと言うのは、XMLのツリー構造を構造体などを利用してメモリやファイルなどに保存しておいて、高速にアクセスすると言う仕組みです

例えばHTMLはブラウザでツリー構造が扱えるようになっていて、そのためにDocument.getElenentByIdのようなアクセスが可能となっています

これに対してDOMでは無いパースとは、XMLを単なるテキストとして扱い

上から順にパースして該当項目を探すので

あまりパフォーマンスは良くありません

このようにXerces Xalanは逐次的にパースするので

XMLを一度DOMとしてメモリやファイルなどに展開する時間はゼロです

巨大なXMLを扱う場合にはそれをDOMとしてメモリやファイルに保存しないため、メモリやファイルの消費を抑えることが出来ると言う利点もあります

なぜ突然この二つを思い出したのかと言うと、、、

わたしが以前Goで作ったXML2Jsonの実装を見ていて

DOMでは無い方が良いかも知れないと思い始めていたからです

当時の実装は逐次的にXMLのパースを行うGoのライブラリを使用して、XMLのTokenを取得しながら自前のDOMを作り、そのDOMからJSONに変換すると言う実装でした

しかもその変換関数は再帰ルーチンとなっていました

どうも無駄だらけに見えてきました

やはり一度作ったプログラムは何度か作り直さないとダメです

わたしは天才ではありません

ゲームエンジンにBG表示とカーソル表示を実装

 作っているゲームエンジンにBG表示とカーソル表示を実装しました

地熱

G Mm/r^2

このエネルギーは潮の満ち引きなどを引き起こしている

そのエネルギーは地表の水だけでなく

地球中心と月中心間の距離の二乗に反比例し

互いの中心に絶えずエネルギーが発生していると考える

同じ事が地球と太陽でも起こり

金星と太陽でも起こっていると考える

金星の表面には太陽の熱エネルギーと金星の内部に溜まり続ける熱エネルギーによって絶えず嵐が吹き荒れている

太陽の吹き出す熱エネルギーも重力も断然金星の方が強い

ススホコリ

しばらく前に庭に発生したススホコリ