日記

9月 1日 (木)

1. 吉里吉里

相変わらず脱線しまくって、予定外のことばかりやってます。

プラグインにArray.map()とArray.grep()を追加しました。それぞれPerlのmap関数、grep関数そのまんま(+α)です。Array.map()の引数には関数オブジェクトを渡します。場合によっては、for文による配列イテレーションの代わりになります。Array.grep()の引数にはPerl同様、正規表現オブジェクトか関数オブジェクトを渡せるようにしたほか、判定条件を逆転させるフラグも追加しました。

2. HTML2XHTML

相変わらず脱線(以下略)

XHTML1.1への変換時に、A要素やMAP要素のNAME属性をid属性に変換する処理を追加しました。重複して指定された属性を削除する処理も追加しました。同一属性の重複指定はSGML的にダメです。

9月 2日 (金)

1. 吉里吉里

プラグイン。配列から重複する要素を取り除く関数Array.uniqueを実装しました。同一判定には"==="演算子と"=="演算子から選択することができます。

配列関係の仕様はこの辺でフィックスします。

9月 3日 (土)

1. 吉里吉里

プラグイン。SQLiteインターフェースを、本体2.25beta9用に書き直しました。似非ネイティブクラス実装だったのが、まっとうなネイティブクラスになりました。これで後ろ暗いところはなくなりました(←後ろ暗かったのか)。

さて、ドキュメントを整備しないと…

2. 地球防衛軍2

INFERNO「灼熱」でアイテム稼ぎをして、イズナーFFゲット。これでペイルウィングの武器は全て揃いました。残るは陸戦兵の武器ですが、ちっとも出ません。超級が殺虫スプレーのみというのは悲しすぎます。

9月 4日 (日)

1. 吉里吉里

プラグイン。SQLiteインターフェースの書き直しに伴って、仕様が一部変更になりました。なるべく仕様を変えないつもりだったのですが、アレな部分が気に入らなかったので。もし使ってる人がいたらごめんなさい。

  • SQLite3.columnNames 関数 → SQLite3.getColumnNames 関数
  • SQLite3Cursor.columnNum 関数 → SQLite3Cursor.columnCount プロパティ
  • SQLite3Cursor.columnNames 関数 → SQLite3Cursor.columnNames プロパティ
  • SQLite3Cursor.columnTypes 関数 → SQLite3Cursor.columnTypes プロパティ
  • SQLite3.version 関数 → SQLite3.version スタティックプロパティ
  • SQLite3Statement.queryString プロパティ追加

と書いてる矢先に2.25beta10がリリースされていることに気づきました。

9月 5日 (月)

1. 吉里吉里

プラグインでバグ発見。引数で受け取ったコールバック関数を実行する場合は、クロージャで実行してやらないとダメですね。iTJSDispatch2::FuncCallで実行する場合は、objthisをきちんと指定しないと、明示的にコンテキスト指定された関数が期待通りに実行されません。以後気をつけよう。

ほか、global.getClassInstanceInfo()を追加しました。使い道は…ない?

9月 8日 (木)

1. 吉里吉里

プラグイン。ネイティブクラスだけでなく、通常の関数も半自動生成させるようにしました。これで関数やクラスメンバの記述方法をほぼ統一することができました。

ついでに、TJS2オブジェクトのコンテナ(?)となる、C++のクラス名も自動生成させるようにしました。これでプログラマ(私)はC++のクラス名を意識せずに済みます。

ついでについでに、マクロ、メッセージ、例外処理周りを強化しました。作業中に、Layer.colorEllipse()でメモリリークするバグが見つかったり…orz

ついでについでについでに、ドキュメント自動生成ツールを、関数だけでなくプロパティにも対応できるようにしました。その過程で、Layer.equalize()とLayer.equalizeColor()のドキュメントを書き忘れていたことに気づいたり。なんだかなあ、もう。

9月 9日 (金)

1. UUID枯渇問題

  • UUIDは128ビットなので、約3.4×1038通りのIDを表現できます。
  • 一人が一秒間に百億(=1.0×1010)のUUIDを消費すると仮定します。
  • 世界人口を百億人(=1.0×1010)とします。
  • 一年は60×60×24×365(≒3.2×107)秒です。

よって、このケースでは

3.4×1038÷(1.0×1010×1.0×1010×3.2×107) ≒ 1.1×1011

ですから、わずか一千億年 *1 程度で全てのUUIDを使い尽くしてしまうことになります。

  • *1: 有効桁数二桁で計算しているので、百億年程度の誤差が見込まれます。が、桁が桁だけに大した問題ではありませんね。ちなみに、太陽の寿命は残り五十億年程度と言われています。

2. UUID衝突問題

UUIDが衝突する確率を計算してみました。先程と同様、百億の人間が各々一秒間に百億のUUIDを消費すると仮定します。千年後、生成されたある一つのUUIDが、過去千年間に生成されたUUIDのいずれかと衝突する確率は、なんと0.00000093%にも上ります。

これは、ある個人が一秒間に生成した百億のUUIDのうち、約百個ものUUIDが、過去に生成されたUUIDのいずれかと衝突することを意味します。つまり、世界中で毎秒一兆もの衝突が発生することになるのです! *1

  • *1: 前提が馬鹿げているので真に受けないように。