トップ > DKUT

3年ぶり？にDKUTに触ってみる

Program DKUT

Powered by dKingyo IT-Text | アセンブラ | 図解 辞典 | Visual Basic | ツクール


　本当に久しぶりにDKUTに触ってみた。
目立った更新をした履歴を見ると3年前2005年12月･･･何年触っていなかったんだ！！？


　早速ビルドしてみたらunit_testの部分でexpatが無いと怒られた。入っていたはずなのだが･･･*1


　2006年10月30日に制作し始めたdkcStaticPool2 というモジュールがunit_testを通らない･･･はてはて困った。今そのソースコードを見てもいったいどういったコンセプトで作ったのかがおぼろげにしか分からない。久々にプログラムを見るとこういう事は厄介だ。こういう時なって更新履歴の重要さが身に染みる。


　最後に重要な事。絶対にdkutilの完成版はリリースはします。

*1:外部ライブラリはまとめて別にインクルードする必要があるようにしてたのが原因だった。

VS2008爆誕！

Program DKUT

http://japan.cnet.com/news/ent/story/0,2000056022,20360370,00.htm
via http://masafumi.cocolog-nifty.com/masafumis_diary/2007/11/2008.html

http://itpro.nikkeibp.co.jp/article/NEWS/20070606/273787/


な、なんだってーーー！！！VS2003やVS2005すらまともに使った事無いって言うのに！
まだまだ現役のVC6ですよ！

　もう、Windows95や98のことを考えていたらまともにプログラミングできない時代になってきましたね･･･。
yaneSDK3rdの設計思想、好きだったのにな･･･。いままで、何故、Windows95やVC6でも動くようなコードを書いてきたのだろうと後悔の念が･･･鬱々とします。おｒｚ


　だからこそ、このようなことを解決するためのDKFSMなる計画を着々と練っているわけですが･･･

Red Black Tree 対決

Program DKUT

Powered by dKingyo Rails | ソフトウェア開発技術者 | GPU Gems | 画像処理 | C言語

某氏が公開していたRed Black Treeの実装と既存のRed Black Treeの実装を対戦させてみた。
インクリメントキー



1	/ Challenger red black tree delete	/ 2035

2	/ red black tree insert	/ 54441

3	/ STLport red black tree delete	/ 78082

4	/ Challenger red black tree insert	/ 101272

5	/ STLport red black tree insert	/ 140324

6	/ red black tree delete	/ 181662
ランダムキー


1	/ Challenger red black tree delete	/ 5127

2	/ red black tree delete	/ 18825

3	/ red black tree insert	/ 96301

4	/ Challenger red black tree insert	/ 108134

5	/ STLport red black tree insert	/ 118734

6	/ STLport red black tree delete	/ 188965
deleteが異様に早い。
某氏のソースコードを見てみたが、理解するには１日つぶしそうだ･･･。



さて、このテストをやっていて気付いた。
dkutil_cのred black treeがランダムな要素をキーとしdeleteする時に内部に格納していたデータが入れたデータと違っているという現象が発生したのだ。これは忌々しき事態だ。
dkutil_cはかなりバグチェックは行っているはずなのだが･･･
要素を二重削除していたのでバグっていました。dkutil_cのミスではなく完全にプログラミングしている私のミスでした。

dkutilって使いやすい･･･

Program DKUT

C++用ライブラリとしてdkutilを作っていますが*1、RubyにかぶれてきてC++を使う際、いろいろ面倒だと思うのです。
ですが、C++でdkutilを使うと「ちょっとしたUtilityとしてはかなり便利だな」と思ったのです。
自分で言うのもなんなんですけど･･･そう実感してしまったのだからしようがない。

*1:すでに数年放置･･･内部実装、およびインターフェースは原型をとどめないくらいに変わってきている

DKFSMでするべき事

Program DKUT DKFSM

.NET Framework等の共通言語基盤によってプログラム言語から生成される実行コードの差異は事実上なくなった。
これによりプログラム言語はただの状態遷移の表現でしかない。
よってプログラム言語にこだわる事はただの嗜好となる。


私はこの嗜好が許せないのである。
すべての環境で.NET Frameworkが使えるわけではないのである。
よって非対応の環境に対してその状態遷移の表現を別の言語で書き下したりする事自体が許せないのである。
CLIはVirtual Machine上でプログラムが動くようにしてプログラムの移植に関する解決を図ったのだろうが、
それはこの恩恵を受けるためには暗黙的にCLIに従えと言う事なのだ。


これが嫌なのである。
さらには未だにテキストエディタでプログラム言語によってプログラムを書くという軛から解放されていないではないか。
この軛が職人的でありプログラマーの誇りであるとも感じるが、これが一種のプログラムを組む際の支障になっているのではないかと感じているのだ。


私は嗜好に甘んじない。状態遷移の本質は常に一つなのだから。
この本質を表現するテキストのみに依存しない表現が必要なのだ。
この表現とプログラム言語を双方向に変換できるようにする事がDKFSM Projectの意義である。

XMLとRubyを中心に･･･

DKUT 備忘録

XMLとRubyを中心に活動でしている。
Rubyはgoogle:Rubyと検索すれば山ほど資料が出てくる。

XMLは
http://www.wisdomsoft.jp/
の
http://www.wisdomsoft.jp/dev/data/xml
を参考にしている。


前に
http://d.hatena.ne.jp/studiokingyo/20070324
のような話題が合ったので実際にXMLに触れてみるとかなり便利だ。
これからも詳細を学習していく予定だ。