たまには煩悩の話、昔新聞で見た絵に結構衝撃を受けて「ディマシオ」という名前しか記憶していなかったのだが、どうもジェラール・ディマシオという画家だったらしい. ふと思い出して検索したら見つかったのが嬉しくてメモ. こちらのサイトには作品も展示されていた.

改めて作品を見ると似た作風のギーガーに比べると随分ポジティブだなぁというカンジ、これなら普通の人にも勧められそうかも(笑)

ただ人間の陰の部分が表現されておらず、あくまで美しいものを美しく描いているという印象なので、改めてちゃんと作品を見るとちょっと物足りなさを感じてしまう部分もあったり、特に人間も若い人間が題材のもの殆どなので、個人的には老人とか、一見して綺麗では無いがよく見ると深みのあるような題材をもっと見てみたいという気もしたり(^^;;

しかしこんなマイナーな情報でもすぐに調べられるというのは良い時代になったものだなどと思ったり、ついでに上のような絵はエアブラシをメインに使うのが一般的なのだが、そのエアブラシも本当の(画材の)味となると無理だが、誰でもコンピュータでそれなりに楽しめるようになったのは当たり前に見えて結構凄い事なんだよなぁとか思ってみたり (実際エアブラシは手入れがやたら面倒でちょっと趣味で扱えるような画材じゃないし:-<

まぁつらつらとたまにはプログラム以外の意味の無い事も書いてみるテスト :-)

# そういえばギーガーの画集も欲しいと思い続けてまだ購入してないなぁなんて思ってみたり、金銭に余裕がある時は結構忘れてて、余り余裕が無い時にそういう事を思い出すのもまた人の常也哉(苦笑)

# とまーこの手の話題はホント改めて読み返しても毒にも薬にもならんね(苦笑)

PHP5.3以前はリファレンスカウンタのみでGCは無いらしい、んー :-<

まぁ標準で配列/文字列の代入・関数引数にはコピーが生成されるので、影響されるのはオブジェクトインスタンスだけ(PHP5以降のみ、PHP4ではオブジェクトもコピー)だが、、、その仕様も含め何だかなぁ(苦笑)

ちなみにevalで関数定義を連続した場合のメモリリーク (構文木・コード構造のGCテスト、これは意外と引っかかる処理系も多い) も試してみようと思ったが、関数の再宣言はできないらしい、まぁそういう考え方もアリか.

本当は自前言語で関数宣言の引数にガード節が欲しいのだが、そーすると関数のオーバーロード (今は関数自体をfirst class objectとする仕様との整合性の為1つの関数エンティティに対し複数の構文木が連結する仕様にしている) このガード条件に対するオーバーロードと構文木のGCとの相性が上手く無いので実装が思いつかずorz

しかしPHPって余り「プログラム書いている」ってカンジじゃない、表現力も限られているし、やっぱプログラム用の言語というよりはミドルウェアの為のグルーや簡単な画面の為のものなのかねーとか思いながら、何か色々なソフト組み合わせる辺り「バッチファイルの大逆襲」なんかねーとかまー色々 (まーダイアログアプリも大抵はバッチの亜種だが:-P) 分量だけ多くてスカスカで微妙な気分になる辺り(※1)は昔LW用のRenderMan RIBトランスレータ書いてた時の感覚が丁度似てるよーな気もしたり、まー無論そりゃお前が分かってないだけという話かもしれぬが.

※1) 何っつーかね、プログラムを組み木細工のように 「組む」 言うよりはダラダラhtmlを 「繋ぎ合わせてる」 ってカンジなんですよね、感覚的にはプログラムよりはむしろドキュメントを量産している時の心理に似た具合で. とは言ってもソレ系のプログラムは書かなくなって久しく、最近は計算や複雑なデータ構造が伴わないプログラムなんて殆どやらないので、以前の職場の友人が言っていた 「最近のプログラムはAPIを並べるだけだから」 という事を振り返れば、会社勤め時代のプログラムを今いじると同じように感じるかもしれないけど. こーゆー所に面白さを見出せないのはどーにも年食ったのかなぁなんて思ってしまったり(苦笑)

昨日の続き、すぐにはポリゴン化のアルゴリズムを思いつかなかったので、間に合わせでGLU (OpenGLライブラリの一部) のテッセレーション機能(gluNewTess()他) のコールバックを通して三角ポリゴン生成、エクスポートしたデータを取り合えずプロッタに食わせてみる.

当たり前と言えば当たり前だけど、特に問題もなし.

どーにも在りモノのこういうのを使うのって敗北感があるし (大体想定としての用途から外れるし、依存関係が外部に左右され得るというのはメンテナンス及び応用の観点からも余り良い事でも無い、特にソフトの中心になる機能に既存の外部のモノを使って怠けてしまうと、結局その部分に発展性が見込めないというとてつもなく馬鹿げた話にもなりかねないし) 調べればこういうのは定型化された手法がありそうな気もするのだけど、、、一方大元で使っているGetGlyphOutlineもOSごとに微妙に挙動や結果が違ったりするので、ちゃんと安定したものを作るならこの部分も自前解析でなければならないし、そういった意味では間に合わせの手法どうしという事ではアリなんかねーとかまー色々. 相変わらず何に使うかってのは無いのだけど(笑) まぁ調べたついでに区切りのいい所位までやっとくかなーとかそんなカンジ ;-)

Win32APIのGetGlyphOutlineでフォントのベクトルデータ取得

取り合えず抽出してみただけで今の所使用予定無し(笑)

2D描画用なら良いのだが、これからポリゴン作るとするとどーするかな、とかまー色々、扱いが結構面倒なので、ベクトルサポートするので無い限り自前のペイントソフトのテキストレンダラ用途は既に間に合ってるし、、、まーぼちぼち.

先週末から何となしに構造化BASICのパーサなんぞ書いている、構文の複雑さとしては制御構造に関数定義とせいぜいQuickBasicと同程度、といってもてこずったのはせいぜいトップレベルのサブルーチン呼び出し (関数呼び出しの括弧が無いヤツ) をyaccableにする部分程度で、取り合えずパースして普段使っている自前言語と同型の構文木を得る所まで完了、後は基本型を定義して得られた構文木を単純に辿ればBASICインタプリタの一丁あがりとなる.

まぁ別段目的があるワケで無く、単に中括弧系のフリーフォーマット言語向けのパーサは何回か書いているが、単純な行パースでは済まないタイプの行指向のパーサは書いた事無かったよね、という事で、これを何かに使うとは正直全く思えないのだが(笑) とまーここまで作ってふとある疑問が脳裏をよぎる、果たして今の時代 BASIC系の言語を作る事に何の価値があるのか? という所、、、どうも 思いっきり詰んだ ような気がする.

ま、実際は中括弧系って記号的だからマクロ言語とかエンドユーザー向けの言語は改行単位のBASICの方が分かり易いよねーなんて発想はあるのかもしれない(※1) そして実態は結局エンドユーザーというのは決してどのようなプログラム言語もいじる事は無く、マクロやスクリプトを他のエンドユーザー向けに発表できるタイプの人間は大抵それなりにどんな言語でも扱えるものだったりする. あるいはグループウェアやERPなどの企業向けアプリの場合には大抵エンドユーザーから外注されたプログラマがBASIC系の文法に悪態をつきながらプログラムを書く羽目になっていたりするワケで、何かそういう安易な考えで量産された「簡易」言語は結局の所害悪にしかならんのかも、なんて思ってみたり :-P

※1) 得てして自己満足的になりがちなのだが、ソフトそのものを作るよりもソフトの為のソフトやフレームワークを作ってというのはプログラマ的には魅力的に見えるものなのかもしれない(※2) でそういった大風呂敷を最初に広げるものは結局そのツールなりフレームワークなりを使用して出てくる最終的なものはショボかったり、コントロールを外れてメンテナンスコストが馬鹿高くなってしまったりが常であったりする (そもそもそれでも何とか形になるだけマシで、身の程を弁えず広げ過ぎた挙句、破綻するのもよくある光景) 本当に何度も頻繁に見かける光景だがこの落とし穴にハマる人々というのは(性懲りも無く)常にある割合で必ず存在していたりするのは如何ともし難し.

※2) こういう言い方をすると聞こえは良いのだけど、ともすると問題のメタ的なものに拘泥するのは、本来の問題 (得てしてこれは人間と道具の密接な問題であったりもする) に対する逃避的な側面もあるのかなーなんて思ったりもするワケで、結局プログラマ的な気質の負の部分なんかねーとか、だからそーゆーものの集大成でもあるUnix系のソフトとかある部分ではもの凄く優れていながら決してエンドユーザーが使えるものに (これだけ延々時間をかけてきたにも関わらず) ならないのかなーなんて思ってみたり.