「プログラミング」に関する日記(16)

レーダーチャートのプログラム、軸名まで表示できるようになりました。
本当は数値も表記できればレーダーチャートとして完成なのですが、この部分は個人的事情により作る気はありません。

レーダーチャートのプログラム、軸名が表示されない以外は完成しました。
さほど高性能ではありませんが、ちゃんと補助線も引けたりします。

1312382912.png

レーダーチャートを描くPHP作っています。
当初はレーダーチャートの画像を生成するように作っていたのですが、大きな画像の一部としてもレーダーチャートを描けるようにしたいため、画像の生成は行わずに描画だけを行うようにしました。

検索文解析器、公開しました。
やってくれるのはツリーを作るところまでなのでその先の処理は自分で作らなければいけません。

検索文解析器微調整。
あまり使われなさそうな構文を削りました。

レーダーチャートを作るプログラムを作っていました。
とりあえずいろんな都合上PHPで。
いろんなグラフを書けると楽しいな。

検索文解析器、構文解析の都合上やたらと深くなりがちなツリー構造を単純化するようにしました。
これをやっておかないと最終的にSQL文を作るときに括弧だらけになってしまって見通しが悪くなるのです。

結局LL法の構文解析をまともに実装するやり方が理解できなかったので、拡張性だとか可読性だとか全く無視で、構文規則を直接関数に書き下して無理やり実装してしまいました。
とりあえずこれで検索ワードの構文ツリーが作れるようになったので、もうちょっと調整すればいろんなところに組み込めそうです。

日本がなんか世界一になったそうですね。
めでたいことです。

LL法なかなかわからんです。
集合論とかももうちょっと勉強せねばならなさそうです。
いつか頓挫したあのスクリプトよりは簡単だとは思うのですが…。

検索条件解析プログラム、字句解析解析中に追加の処理を入れられるようにしました。
これにより特殊な書式で書かれたものも解析できるようになりました。

そういえばライモンシティの連中、レベル20以上差があってもタイプ相性とその他条件次第ではなんとか勝てることもあるようです。
たとえばレベル38ガーメイル(虫・飛行)でレベル65ドレディア(草)を倒せたりとか。
もっとも、攻撃を4分の1に軽減してやっと1～2発耐える程度なので安定はしませんが。

PHPには、余計なコメントや空白を除去したソースを出力するオプションがあります。
それを使えばコードが短くなってコンパイル時間も含めたPHP実行時間の削減に役立つかなーと思ったのですが、あまり効果はないようです。
コメントや空白の除去は元々短時間で終わる字句解析にしか影響が無いためでしょうね。
実測してみたところ、むしろ空白除去版の方が処理時間が長くなる傾向が見られました。
おそらく改行が無くなったことにより切りのいいところで処理を切れなくなったからだと思います。
実際の字句解析の仕様は知らないのであくまでも根拠のない予想ですが。
数百KB以上のソースファイルのほとんどがコメントと空白なんて状態でもなければ目に見えて速くなるなんてことはありませんでした。

複雑な検索条件を構文解析するPHPプログラムを作成中です。
アンパンマンDBバージョン3用ですが、構文木まで作れればアンパンマンDBに限らずいろいろ応用が利きそうです。
PHPにはyaccとかlexみたいなのが見当たらないけど、少なくとも字句解析は正規表現でなんとかできそうです。
構文解析については、これも正規表現で頑張るか、昔頓挫した言語作成の延長線上でやるか、どちらかで頑張ることになりそうです。

やっぱりSmarty使うことにしました。
変数の割り当てやヘルパー関数の用意などを考えると、新規に自分でテンプレートエンジンを作っていると時間がかかってしまいそうなのです。
私が作りたいのは「スマートな設計のプログラム」ではなくて、「しっかり動くプログラム」なのです。
理想を追うあまりいつまでたっても何も動かなくては何の意味もないのです。

早速テンプレートをPHPコードに書き換え始めたわけですが、変数とか関数の扱いをあまり考えていませんでした。
テンプレートは関数を使って呼び出すことになるのでグローバル変数は使用不可。
テンプレートに変数を渡す方法を考える必要あり。
関数は常にグローバルスコープなので呼び出しに関しては何の問題もなし。
逆に、テンプレート用関数の定義をするときにどうするのかが問題。
このへんを充実させれば扱いやすくはなるかもしれないけど、今度は普通のテンプレートエンジンと何が違うのかってことになりかねない…。

アンパンマンDBバージョン3で、デザインとロジックの分離、デザインを複数用意したいという希望からテンプレートエンジンのSmartyを導入していたのですが、どうにも今回はSmartyにあまり利点がないような気がしてきました。
Smartyは高速なテンプレートエンジンですが、その高速化の根拠はテンプレートをPHPコードにコンパイルして、ほとんどの場合単にPHPファイルをインクルードするだけで済ませてしまいところにあります。
それだったらむしろSmartyなど間に介さず直接インクルードすればもっと速くて手っ取り早いわけです。
Smartyはデザインとロジックの分離のため、テンプレートファイル中では極力PHPコードを実行できないようにしてあります。
これはデザイナーが余計なコードを書いてプログラムをバグらせるのを防ぐという点では素晴らしいのですが、個人開発では単に自分一人が気をつければ済むだけの話です。
そもそも、PHPそのものが最初からテンプレート的な使い方をできるように設計されていて、Smartyはそのテンプレート的な使用法に特化したものに過ぎないのです。
そう考えると、Smartyはただのインクルードより設定が大変なだけでメリットがあまりないなぁ…と。

Tympoleは早くもただのガマガルになってしまいました。
進化すると日本語の名前に戻ってしまうのですね…。

手元においてあるPHPマニュアルに簡易的な検索機能をつけてみました。
基本的に関数を調べることが多いので関数名のリストを作って、検索エリアに入力すると関数名が自動補完されるようにしています。

Svg2Xaml、ストローク対応版公開しました。
実際に変化しているファイルは2つだけで、ほかのファイルについてはオリジナル版をそのまま使っています。
あと、付属しているテキストはライブラリそのものではないのでLGPLの適用外だと思われます。

TGWSAdminを修正しました。
RSSをアンパンマンDBの最新っぽい情報群に取り込むプログラムが、Twitter連携のときと同じように特定の状況下で働かないことがあったのです。

LGPLのことはよくわからないのですが、元のライブラリと微妙に違う名前をつけて、元著作権者を表記して、LGPLを継承すれば大きな問題はなさそうな気がします。
とにかくやってみなければ始まらないので、まずは自分の思うようにsvg2xamlのバグ修正版を公開したいと思います。

svg2xamlどうしましょう。
自分で使うために治したんだから自分で使うのは当然として、成果物の公開とかもしたいのですが、LGPLのライブラリの派生版の公開なんてしたことがないからこのあたりの流儀やら何やらがわからんのです。
それを言うなら私自身が1から作った作品も流儀を知らないといえば知らないのですが、自分のものなら公開方法が変でも特に迷惑がかかるようなことはないのです。

group_concatの件、結論から言うと、ダメでした。
共用サーバーゆえ、下手にバージョンアップすると互換性が失われてみんなのプログラムが動かなくなるかもしれないとのこと。
残念ですが、仕方ないので頑張って自分で実装してみます。
SQLiteには自分で関数を追加することができるらしいのです。
パフォーマンスはガクッと落ちるだろうから使うのは最小限にしなければいけないとは思いますが、うまく使えばかなりの威力を発揮しそうです。

svg2xamlで線がうまく表示されないバグ、頑張って原因を調査しました。
問題点は2つ、ストロークの接続点のスタイルが適用されない、ストロークの端点が認識されない。
問題点1は解決しました。
ストロークの接続点のスタイルを、読み込むだけは読み込んでおいて、出力時に反映していないのが原因でした。
改善の様子をアップしておきます。
もう一方の問題も、大体の原因には目星がついています。
なんとか明日には直したいところですね。

1305989806.png