いずみのぶろぐ

ソケットライブラリをいじっているのですが、BREWなので当然ソケットの読み書きは非同期になります。
で、EWOULDBLOCK 相当の戻り値だった場合、コールバック関数を登録するのですが、読み出し用のコールバック登録メソッドが ISOCKET_Readable()...（実はカプセル化してるのでクラスメソッドになってますがここではBREW生APIで話を進めてます）
「読み出し可能になった」のがわかるのはこの関数ではなくて、この関数で登録した関数のはず なので、このネーミングが既におかしいのですが、何も考えずに書き込み用のコールバック登録をISOCKET_Writable() で登録しようとしたらコンパイルエラー...

もう、何がおかしいのかわかりませんでしたが、念のためヘッダを見てわかりましたよ。

正しいメソッド名は ISOCKET_Writeable()。
ISOCKET_Writeable()ですよ奥さん！！

BREWを考えた人は英語すらできない、という事実を私は今日学びました。。。がそんなこと学びたくもなく、もういい加減解放されたいです。。。。

普通のcharで動くモノを、もちろん文字型はテンプレートパラメータ化するということで、AECHARにしてみましたが、ものの見事に動きません…

いろいろあーでもないこーでもないしてみたのですが、その結果こーんなことがわかりました。

まず、AECHARに日本語文字列を入れると、１バイト文字はそのままの数値で入りますが、２バイト文字はバイト順が入れ替わります。
たとえば、半角空白文字は0x20、全角空白文字はシフトJISで0x8140ですが、AECHARに変換すると、前者は素直に0x0020になるのですが、後者は0x4081になるのでした。
BREWが動くARMは基本的にリトルエンディアンなので、文字列バッファからベタに読み出すとそりゃ上下バイト入れ替わるわけですが…いったいどんな設計になってるのやら…大苦笑

次に、せっかくのワイド文字なのに、WSTRUPPER() / WSTRLOWER() で、２バイトアルファベット文字の大文字小文字変換はできません。

どちらも、AECHARのまま文字列として扱うことは考えてない、ということなのでしょうけれど、それならなんでAECHARなんか導入したのか。

もう、QUALCOMMの考えてることは、まったく理解できません。。。ってそりゃ私の能力＆脳力の問題か。(u_u)

昨日更新しようと思ったのですが、まったくキーボード上の指が動きませんでした。。
というわけで多少復調した今夜書いています。

ただいまのお題はBREW上で動かす非決定性有限オートマトンエンジンを作る。ちなみにオライリー本は持っておらず買うつもりもありませんので、純粋に理論から組みます。

BREWなのでメモリ制限（正確には、フラグメンテーションに対する制限）がキツいのですが、とりあえずは普通にノードを構造体で抱えてグラフを作ることにします。

そして、それらノードを抱えておくメモリプールをどう管理すればよいのか、で時間が空しく失われてしまっていったのでした…涙

もっと読む...

BREW用C++ライブラリを作っていていつもハマるのが、ARMコンパイラのC++、特にテンプレート絡みでのバグの多さです。。。

今日ハマったのは、こんなケースです。（実際にはもっとテンプレート引数多し）

template<class Key> class EqualTo { ... };
template<class Key> class DefaultHasher { ... };
template<> class DefaultHasher<int> { ... };
template<> class DefaultHasher<const CString&> { ... };

template<class Key, claee Value, class Hasher = DefaultHasher<Key>, class Compare = EqualTo<Key> > class CHashTable { ... };

CHashTable<int, CPairT<int, int> > map; // <- ERROR OCCURRED!

コンパイラのメッセージとしては「テンプレート引数が無効」だとか…

いろいろ調べましたが、どうやら、以下のようなカラクリがあるようでした。

• テンプレートクラスのテンプレート引数に、前方参照で引数を用いるテンプレートがあって、
• そのテンプレートに、その引数で一致する特別バージョンがあると、
• ARMコンパイラはそのテンプレートを解決済みの普通のクラスとみなしてしまい、
• 大元のテンプレートクラスをインスタンス化する際に「テンプレート引数の型が合わない」とみなしてしまう

あぁなんのこっちゃ。。。

ちなみに、特別バージョンのない EqualTo<Key> ではそういう問題は起こりません。

ARMコンパイラは、少なくとも VC6 よりはテンプレートをまともに解釈できるようですが、そのまともぶりが中途半端なので、時としてこういうよくわからないワナにはまってしまうのでした。。。。涙

昨日はまずまずの調子も、今日は昼までもう大変な状態になってしまい、落ち着いたところで出勤、その後はなんとか過ごせました。。。

で、今は例外が使えない（のでboostどころかSTLすら使えない）BREW用にC++のライブラリを実装しているのですが。。。

もう、私の脳では、プリミティヴなメモリ管理をしながらも汎用性を持つようなクラスを書くのはかなり困難だってことを、改めて感じつつも作業しています。
まだギブアップしていませんししなくて済みそうな気もするのですが、いかんせん作業遅すぎ重過ぎなのでした。

似たことをしてるJavaのサンプルソースを見て、これならまだ今の自分にだって楽に書けるさ、とかは正直思うのですが…この落差、確実に「感じていなかった」少し前までの自分を思い出すに、老化をリアルに体感しています。。。

• なんでシーク可能な抽象ストリームクラスがないんだ？
• なんでBASE64 encoder/decoder が IWebUtil に実装されてるんだ？

前者のおかげで、MIME マルチパートを各パートの抽象クラスから汎用的に合成しようとすると、独自の読み出しインタフェースを作らざるを得なくなってしまってます（boundary用文字列チェックのためｎ度読みが発生するのです）。

後者のおかげで、仮にMUAとか作ろうと思ったとき（今回は作らないけど）、http叩かないのにIWebUtilのインスタンスこさえなくちゃいけません。

もうホントにいい加減にしてほしいよ…

まぁでも、もともとBREWって、海外のシンプル機能携帯での実装、またはスマートフォンでの組み込みアプリ実装のためのもので、今の日本の異常に高機能リソース潤沢なケータイで使うことは考えられていないのでしょうけどね…

こういう諸々、「プリエンプティになるらしい」 BREW4.0 ではちっとは改良されるんですかね。まぁ、もし改良されてももうBREWの仕事は私は請けないので関係ないですけどね。

あぁ、せめてもの気紛らわしのため、BR×W Ｔシャツでも作って、それ着て仕事しちゃおっかなー。笑

というか、BREWのすべてがメチャクチャなだけとも言いますが…

IWEBUTIL_UrlEncode() のAPIリファレンスを読むと、冒頭に「RFC2936に従い」と書かれてますが、RFC 2936 って、MIMEタイプのマッチングの手順じゃないかと思うんですが…

これ、恐らくは2396のtypoなのでしょうけど、しかしそうだとしても、いわゆる「URLエンコード」はRFC 2396 とは違うもののはずです。

このメソッド（マクロだけど）、実際に動作させると、「application/x-www-form-urlencoded 用のエンコード」を行ってくれるようです。すなわち、PHP の urlencode() と同じ動作をしてくれます。

というわけで、BREW1.1 の頃からずっとマニュアルがメチャクチャなまま、という、BREWではやっぱりよくありがちなことのようです。

やっぱり、BREWは世界中で最も汚く不条理なプログラミング環境です。

単なる備忘録です。

BREW のコールバック設定・解除用構造体である AEECallback ですが、APIリファレンスを見ると

pNext: 予約済み。 コール側でこのメンバを変更する必要はない。
pmc: 予約済み。 コール側でこのメンバを変更する必要はない。

と書かれていますが、それを真に受けて、適当に確保した構造体インスタンスに CALLBACK_Init() だけ施した上で BREW API に渡したりすると、BREWシミュレータは見事に異常終了してしまいます。

Visual Studio のデバッガで追った感じから、「あぁたぶんこれゼロクリア必須なんだろうなぁ」と思い、そうしてみたらやっぱり落ちなくなりました。

まぁ、BREWの場合、MALLOC()で確保できるメモリはデフォルトでゼロクリアされてきますし、コールバック関連の変数はスタックに持てるわけないし(笑)、そういう前提で言うなら「変更する必要はない」んでしょうけどね…

やっぱり、BREWは世界中で最も汚く不条理なプログラミング環境です。

ここのところ、お仕事でブチ切れる局面が増えています。

１つのBREWアプリを作るために、いくつもの会社（うちいくつかは世界的に有名な企業）が集まってそれぞれのモジュールを作っていたりするわけですが、もう、おまえホントにプログラマなのか？？とあきれるしかないコードの数々がそこで繰り広げられています。

なんでみんな基本中の基本も知らないでコード書けるんだろう…

そしてこういう人たちのメンドウを看るために、私たちの時間はどんどん失われていくのです。

あぁ、こういう連中がたくさん、厚顔無恥にもプロを名乗っていられるから、私もまだまだプロでいられるのでは…とつい妄想。

でも、Java経験のない私にとってはやっぱりそれは妄想でしかないのです。PHPだと単価安いし、いまどきC++の仕事なんぞとても難しい仕事ばかりでそれは私にとっても難しいのですよ…

本日のお題は、BREWのログ取りです。

BREWには DBGPRINTF() という、シリアルにログを吐くマクロがありますが、これが今３くらい信頼性に欠けるものでして、しっかりログを取るためにはやはりファイルにダンプできることも必要になってきます。

そこで私に与えられた任務：リリースビルドではきれいさっぱり消滅し、それ以外は条件コンパイルでシリアルログ・ファイルログを切り替えられる CLogger を作れ。

そしてこれを実装しようとしてすぐ直面するのが、「マクロで可変長引数を実現する」手法です。

「リリースビルドで消滅」は、、マクロ定義を切り分けて、その場合に ';' のみに置換してしまえば問題ありません。デバッグログなので、__FILE__ と __LINE__ を出力に埋め込むのは必須ですが、これもマクロの中に埋め込めばよいわけです。

そしてここではたと困るのが、DBGPRINTF() ってくらいなんだから可変長引数にしなくちゃいけないんだけど、マクロにそんな機能なんかないよ、というところなのです。

ちなみにBREWのマクロは、おおむねこんな感じ。

もっと読む...

土日は青森で癒されて空気入れられて(大笑)、で月曜から仕事にふたたび集中。

月曜はＫさんが風邪でお休みとなり、その合間に、結局は一部メンバを privateから protectedに変更することで逃げまくって、ウィンドウイングとか動くようになりましてほっ。

しかし当然、そんなコードにはダメ出しが出るに決まってました。笑

火曜にはＫさんにいろいろぶつぶつ言われ、結局は書き直すことに。笑

とはいえ、とりあえず提出するブツの期限というのもありますから、今のところはこれを使って、他のタスクが空いたときに、きちんとウィンドウマネージャを書き直すつもりであります。

今宵は青森に向けて旅立ってます。速報はいつもどおり旅blogで。

それで、会社から直接出発したのですが、その出発直前で仕事にドン詰まり。
フレームワークのウィンドウクラスを設計して実装したのですが、さーいよいよコンパイルしてみてテストしよー、とかなったときにＫさんにあっさり言われた「あ、friend 使わないでくださいね。」。

…さー困った。
なにせウィンドウの生成時にだけ、ベースクラスが持つべきウィンドウの情報や親子関係を、ウィンドウの種類によってカスタマイズするため、それらを private にして、各ウィンドウ種のやはりベースクラスだけがそれらをいじる、とするために friend 使ってしまってるのです。もち、このフレームワークを使う人はそれらメンバには触れないわけですが。

きちんと OOP させるためには、friend は演算子オーバロード以外ではご法度、というのは私もわかっています。
が、所詮 C++ 使う開発ぢゃん、という甘えにおぼれてきた私は、いつも friend でさくさくやってたので、とても困ってしまいました。

仕方がない、全体としてやりたいことは明確になっているので、生成＆管理部分とそれ以外を分割して全部書き直すかなぁ。

あぁ、こうして私の今後の休日はどんどん減っていくのでした。
そして、言われてからすぐに方針を決められなかったという現実、もうプログラマとしての終焉が、やっぱり近づいてるんだなぁ、と思わずにはいられません。

今日も今日とてBREWプログラミングの勘を取り戻しつつ実装を進めるための調査をしていたりして。

で、そのものズバリ、２ｃｈのBREWスレを見ていたのですが。

…なんだこれわ。爆

何のことだかさっぱりわからないのですが(トカイウ)、一般論としてこの>>296さんについて考えてみるとですね、

　・この人はデザインパターンについて知っている
　・「開発に直接関わった者」はデザインパターンもOOPも使える人皆無

ということで、「このプロジェクトでは開発者じゃなく、かつデザインパターンプログラミングができる人」というのが簡単に浮かび上がってくるざんすよ…

さらにダメを押せば、通常、ここまでの足跡を残しちゃったら、社会的地位が普通は危うくなるものですが、それができるということは(ry

あぁ怖いなぁ。

今日から、10月末までの７ヶ月契約で、またまた青山での日々がスタートしました。
今日はマシンのセットアップと会議で終わってしまいましたが、その会議でわかったことは、もう既に時間に余裕がないという驚愕の事実。笑

といってもこれから10月末までそんな期間が連続するというわけではなく(^^;;)とりあえず今月下旬までが「かなり厳しい」感じ、そこからは「とても厳しい」と「やや厳しい」が交互にやってきて、９・10月が「かなり厳しい」という感じでしょうか。

それでも今日は、「10時出勤21時退勤」「できるだけ土日は休む」という努力目標を決め、とにかく密度濃くしてなんとかしてこう、とは思っています。
ＧＷも、今のところ、29・30・６・７は休もうかと。って全部土日ですが。笑

そしてなんかよくわからんのですが今月もちょっとだけ働くことになってしまいました…笑
ホントに「ちょっとだけ」で、かつペイもいただけるようなので請けてみた次第。

その仕事ですが、本格的に没頭するのがGW明けからで、８月中に実装完了、というスケジュールとのこと。これだとねぶたに行けるかどうか微妙な感じでしょうか…１日だけでも参加したいのですけれども…

それと、もうウルトラシークレットなのでぼかしてすら書けないのですが、私にとってものすごくうれしい極秘情報を漏れ聞きました。これでもう、温泉に安心してドカスカ行きまくれますね！(^o^) <謎>

2.7インチ液晶搭載のワンセグ端末（ITMedia）

視聴中に電話がかかってきても、テレビ番組を約2分間まで一時保存して通話終了後に再生する「タイムシフト再生」機能を搭載する。音声付きの1.3倍速で再生するため、視聴しながら通常放送に追いつくことが可能だという。

これは同機種に搭載されてるSH-Mobile3Aの機能を利用したものと思われますが（ちなみにこの石は京ぽん２でも使われてます。もちろん京ぽん２ではワンセグは見れません。笑）、「２分間のタイムシフト」って、ワンセグでどれだけ意味があるのだろう。これ、組み込むために開発はそうとう大変だったと思いますよ…涙…

涙でキーボードがかすんできたので以下(ry

「auのワンセグ対応携帯W33SA、16日から順次発売」（ITMedia）

KDDIは移動体向け地上デジタル放送「ワンセグ」に対応した新機種「W33SA」を、12月16日から順次発売する。東北、関東、北陸、関西、四国、九州エリアでは12月16日に、北海道、中部、中国、沖縄エリアでは17日にリリースする。

…そうですかようやく発売ですか…orz

「W33SA 開発者インタビュー」（SANYO）

ワンセグの放送規格をよりどころに、操作仕様を決定していきましたが、放送規格の解釈を巡って、様々な討議が行われました。操作仕様策定に関しては、 KDDI様、アプリメーカー様と一丸となり、会議室に1日中引き篭って議論を繰り返す日々が何日も続きました・・・。
放送が無い中での開発において、最も大きな課題は「どうやって評価して、商品化に結びつけるのか？」ということでした。これについてもワンセグの放送規格をよりどころに、莫大な数の試験コンテンツを準備し、実放送が始まっても不具合が起こらないよう、入念に評価を実施しました。開発を実担当されている技術者の方々は、本当に大変だったと思います。

…orz orz orz orz orz orz orz orz orz orz…

今のプロジェクト（先行案件）がデスマーチ化した要因はいくつもの連鎖反応です。
(1)すでに納期を遅れている時点で、フレームワークをこさえていた下請け会社がケツ割り
(2)受託会社の社長の友人（スーパープログラマ）が登場、「このフレームワークではどうしょうもないので２週間延期して改造させてほしい」と総元締めに提案するも拒否される
(3)人をかき集めて何とかしようとするが能力のない人ばかり集まる
(4)スーパープログラマが飽きて仕事放棄（まぁ自社の案件も忙しかったようですが）
(5)能力に欠ける人がシビアな部分の実装を仕方なく担当するがぐぢゃぐぢゃに

で、現在はスーパープログラマも復活して、私たち後続チームが助っ人参加して、なんとかがんばってはいるわけですが。

もっと読む...

まず、本日をもってFIXEDとなるはずだった先行プロジェクト、やっぱりだめでした…u_u
そのFIXED版のソースコードに、これまでのモディファイを改めて手動マージ＋実装仕様変更部分について再度改造、という作業を施し始める予定だったわけですがそれも自動的にNG。
しかし、さすがにもう待ってられないってんで、３度めの手動マージを覚悟の上で、現段階でのソースについて上記作業を開始しました。

さすが凄腕の集まるチーム、最主力のＦさんが代休で不在だったのにもかかわらず、コンパイルまでは無事通過。コア部分が変わっている部分にかかわる不具合は出ているのですが、これで、金曜夜のリリースに向けて大きく前進、というところです。

明日からあさってお昼にかけて、東鳴子に湯治に行くわけですが、私が不在の分もみなさんフォローしてくださることでしょう(^o^)。久々に、職場向けおみやげも買っていかなくちゃ♪

期日前日にビルドが終了した先週のβ1.5に続き、明日提出のβ２のビルドも今日夜に完了。
まぁ、昨日も書いたとおり、これはさまざまな他所様の遅延によるタナボタでの「予定通り」であって、実際には予定通りでもなんでもなかったりもするのですが(u_u)、いわゆる「バグを含んでいてもよい全機能実装版」としては98％くらいの完成度なので、一応、胸を少しだけ張ってもバチはあたらないでしょう。(^^;;)

…でも、これ、パートナーさんの最新ファームで動かそうとすると、起動すらしないんですけど。

「全機能」で当然存在しているべき、初期化処理中に呼び出される新APIのエントリポイントが存在していないので、落ちるに決まってる、というやつです。笑

パートナーさんの最新ファームの次回リリースは５日。あぁ、どーせうちらのアプリでテストしようってハラなんだろうなぁ。大笑