不具合修正のみ。
修正したはずの輪符貼り付け不具合の報告があったが,特に再現せず,原因も見当が付かなかった。新規報告でようやく原因が判明,修正出来た。
輪括操作ボタンの事象で吊るし輪郭個体を取得する際,輪郭個体が初期化される方法を使っていた。これ自体はよくあったことだが,修正しきれていなかった。目立たないところで同様の交度は残っている可能性があるため注意しておく。
デライトには「使い方」というページがあるのだが,これは最初の頃からまともに更新出来ていない。デライト開発もありがたいことに快調で,いちいち更新していられないほど変化が激しかった。このあたりも近日中に刷新するので,もうしばらくお待ち頂きたい。
もっとも,多くのデライト初心者が躓いているのは,細かい操作方法というより,どういう考え方で使っていくものなのか,という所なのではないかと思う。デライトで躓きやすい「使い方の考え方」について,このあたりで少し補足しておきたい。
デライトは風変わりで慣れが必要なものではあるが,特に難解なものではない。開発者の力不足による不親切さは多々あるものの,あくまで誰でも使えるものを目指している。まずは,ちょっとしたゲームのルールを覚えるつもりで読んでもらいたい。
デライトは,個人の知識をよりよく育て,生活の様々な場面で役立ててもらうためのサービスだ。それを突き詰めた結果として,互いに入れ子に出来る「輪郭」という単位で情報を扱う仕組みを持っている。
ここでいう「輪郭」というのも,まずはごく普通の言語感覚で理解してもらえればいい。ある物事の全体を取り囲むもの,という意味だ。もっと具体的にイメージしたければ,手で輪っかを作り,目に見える風景の一部分を切り取って見てほしい。写真の構図を考える時などに似たことをよくやるが,その時に手で作っている輪っかは,世界のある部分の輪郭だ。
その輪郭を,自由に“保存”出来たらどうだろうか。輪郭の中にまた輪郭を作ることも出来る。一つの輪郭は,他の無数の輪郭を含むものであると同時に,他の無数の輪郭に含まれるものになる。そのようにして,“世界を捉える”ことは出来ないだろうか。さらに,この考え方をコンピューティングに応用することで,従来の情報管理が抱えていた問題を解決出来るのではないか。ここからデライトの輪郭という仕組みが生まれた。
例えば,ファイルをフォルダ(ディレクトリ)という入れ物で分類管理する仕組みは広く使われているものの,人間が頭の中で扱っているようには情報を扱えない。一つの物事をどこに分類するかは,見方によっていかようにも変わりうるからだ。これは,一つの情報を一つの入れ物に所属させるような「階層構造」一般の問題(こうもり問題)としてよく知られている。
他方,こうした問題を解決するため,より柔軟な「ネットワーク構造」(グラフ構造とも)を利用した仕組みも広く使われている。Wikipedia などで利用されているウィキはその代表例だ。ウィキは,ウェブのハイパーリンクという仕組みを最大限に活かし,縦横無尽にリンクを張り巡らしながら情報を整理出来るように設計されている。しかし,こうした技術も万能ではない。柔軟な分,散漫・乱雑になりがちで,焦点を絞って情報をまとめることには向いていない。
主力機更新を本格的に検討するようになり再現性の低い SLFS 環境の問題がより大きくなってきたため,円滑な移行のためにも SLFS の整理を急ぎたい。ここで,構想段階のまま中断していた SLFS 0.003 はお蔵入りにし,SLFS 0.004 として仕切り直すことにした。
SLFS 実機のフジ型場当てを利用するつもりだったが,やはり試行錯誤を実機でするのは負担が大きい。仮想機を利用するのも出与えの管理などをどうするかという問題があった。
この際,親環境(SLFS 実機)との完全な出与え共有は考えず,1つの SLFS 仮想機を作りそのフジ型場当てで実験を繰り返し,構築手順が熟れてきたところで SLFS 実機で再現を試みることにした。この時にもフジ型場当ては重要なので,親子で二重に利用することになる。
現行の SLFS 環境は混沌としていて移植しにくいため,作業用の Linux 出来採りとして先日救出用 DVD に採用した Slax を使うことにした。
_dg
}{_dg_oln
}{握接}{希哲15年8月31日9歩}(75)いったん終了。
この問題に気付いたのは今日正午前だが,昨日26時頃までは問題無かったため,この10時間ほどの間に発生したと思われる。
具体的には,_dg_oln で自我知番が K#F85E の場合に限り n_fg・n_bg がそれぞれ一つの数値に統一されてしまっているという問題だった。この数値は _dg で前景・後景の自我知番を検索した時の数値に一致することを確認した。
このことから,誤った UPDATE 求頼で K#F85E の全ての輪郭に更新をかけてしまった,ということは間違いない。その求頼がどのように発生したのか,ということまでは突き止め切れなかった。n_fg・n_bg を更新するのは dg_sync_n_fg()・dg_sync_n_bg() くらいなので,直接的にはこれらの仕業だろう。
発見してすぐ全輪郭に対して dg_sync_n_fg()・dg_sync_n_bg() をかけ,完了した13時30分頃には正常化したことを確認済み。
最後に1輪だけ,修正されないまま残った輪郭があることに気付き調べてみると,知番 A- 以後が 0 の明らかに不正な輪郭だった。描出は希哲9年6月26日,知名は「イタリアの地方自治」だった。デルンもまだ不安定な時期だったので,こんな輪郭が紛れ込んでいてもおかしくはない。いずれにせよ存在してはいけない知番なので,当該輪郭は削除済み。
一つの可能性として考えられるのは,この輪郭に誰かが握接し,不正知番が dg_sync_n_fg() か dg_sync_n_bg() の誤作動を引き起こした,ということだ。最近,クローラーの巡回も激しいので,握接したのは誰であっても不思議ではない。
ただ,軽く試象してみた限り,問題箇所は見つからなかった。流石に,多少の不正知番で WHERE 句が致命的な狂い方をしないようにはしてある。
それほど深刻な問題ではないこと,概ね可能性が絞り込めたこと,復旧も容易なことから,ここでいったん調査は打ち切ることにした。今後はこの問題を頭の片隅に置いて周辺作業を進め,再現した時は再調査することにした。
元々前後景輪数表示に関しては多少狂うことがあるのを認識していたが,この復旧作業によってそれらもいったん正常化したようだ。
また,全輪郭を再同期すると現状およそ1時間30分ほどかかることが分かったのも収穫だった。今後同様の対応が必要になった時の参考にする。
「輪郭に空白名があると検索→新規作成の際にASCII加算符に置き換えられてしまう」という不具合報告について,ようやく尻尾が掴めた気がしたので再調査に入る。
結局,decodeURIComponent() が + を半角スペースに置換しないというよく知られた落とし穴のせいだった。
decodeURIComponent() に渡す前に置換処理をしておくというのが定石らしいので @URI.dcd() を修正。
+ と半角スペースという時点で URI 符号化絡みの問題なのは明らかだったが,最初の調査では交度に論理的な問題が見つからず,再現性も明確ではなかった。
当然,全知検索窓に直接入力すれば問題なく,Firefox ではアドレスバーの URI を直接編集して半角スペースを含んだ検索をしても問題なかった。問題は,アドレスバーに直接検索語を入力した場合で,この場合は %20 ではなく + に半角スペースが置換され,これが JavaScript 側ではそのまま通っていた。
更に問題をややこしくしていたのは,捌き手では問題なく + を半角スペースに復号していたため,そのような検索をすると表示上も描出も問題なく行われるが JS で制御している描出後の転送先のみ + が残った検索になっていたことだった。
さっき何となく半角スペースを含んだ検索語から描出したことで再現し,交度を見直してもやはり問題が分からず,まさかと思って decodeURIComponent() の仕様を確認したところで原因が判明した。
今後のためにもなる勉強になって良かった。