アイス履歴を10個ほど増やしました(リンク)。これで55種類かな。そろそろカウントが面倒になってきました…。
最近はパピコやモナカのような棒アイス以外にも手を出しているので、アイスの袋の増え方が激しくアップロードしきれていません。そのうち載せます。
夏、秋は果実系のさわやかなアイスがおいしい季節でしたが、冬は味濃い系が恋しくなります。個人的にまた発売してほしいなー、と思うアイスは、
辺りですね。他のアイスもおいしいです。ぜひ見かけたら食べてみてください、と言いたいところですが、アイスは商品の入れ替わりが激しくて、すぐにお店から消えるんですよねえ……。
その反面、アイスはほぼ毎週と言って良いほど、新商品が出ていてマンネリとは無縁です。メーカーさんの努力は素晴らしいです。
この記事にコメントする
一応、テレビ向けのSoCを作るお仕事をしていますので、たまに電器屋さんにテレビを見に行ってますが、どこに行ってもテレビのコーナーは年々狭くなっています。
土曜日に梅田ヨドバシに行きましたが、一時期は3Fをテレビが支配していたのに、今や1/3位です。ホームシアターを除いて純粋にテレビだけでカウントしたら、もっと狭いかもしれません。テレビを家電の1つと見れば、フロアの1/3を占めているのは破格の待遇と言えますが、つい過去の栄光と比べてしまいます。
同じ階にはオーディオコーナーと、キャンプ用品コーナーがありました。テレビはオーディオコーナーと同じか、やや負けてるくらいの広さでしょうか?この先、テレビの面積が復活することは無いでしょうから、そのうちオーディオと合併して、オーディオ・ビジュアルコーナーになるんでしょう、たぶん。
レコーダーは悲惨で棚2つしかありませんでした。BD-RとかDVD-Rみたいなメディアそのものを売っている棚の方が多いように見えますけど、バランスおかしくないです??
番組を録画する文化は日本特有らしく、もともとレコーダーは日本でしか流行っていません。海外でも販売していますが、プレーヤーの方が好まれるようです。頼みの日本がこの状態だと、そのうちレコーダーという製品は無くなるかもしれません。
プレーヤーは細々と続くと思います。とはいえ、黒物家電メーカーは全員ボロボロで、次世代の光ディスク規格を作るほどの元気は無いでしょう。BDを8K規格まで延命して、ネットにバトンタッチして終わりか、下手したら4Kで燃え尽きて終わりかもね……。
この記事にコメントする
目次: Kindle
いつのまにかKindleがアップデートされており、フォントが変になる問題(2017年10月13日の日記参照)が直っていました。あとストアアプリのメニューがダブって表示される問題(2017年10月12日の日記参照)も直っていました。
直してくれてありがとう。やっぱりおかしいってわかってたんだね……。
この記事にコメントする
目次: ゲーム
ポケモンGOのアプリはいつまで経ってもバグだらけです。新しく実装された機能(ジムバトル)は当然バグバグで、通信周りが弱くハングしまくります。
操作不能になったり、ハングされたりするとアプリを再起動するしかないですが、ハイエンド機じゃないせいか起動も動作も遅くてイライラします。
1日15分もやってないのにこの有様なので、もっと長時間遊んでいる人はイライラで憤死するんじゃなかろうか?
折角面白いのにアプリが残念すぎる……。
この記事にコメントする
目次: Android
昨日(2017年11月8日の日記参照)の続きです。
本来見たかった道をざっくりまとめておくと、
これが2017年11月6日の日記の前半で分かった部分。
これが2017年11月6日の日記の後半で分かった部分。
これが2017年11月7日の日記で分かった部分。
これが2017年11月8日の日記で分かった部分です。そのあとはlooperとは何ぞや?という点を追いかけていましたが、まだわからない状態です。
肝心のACodec::BaseState::mCodecに何が入っているのか?についてはUninitializedStateを手掛かりに見ていきます。
//android/frameworks/av/media/libstagefright/ACodec.cpp
struct ACodec::BaseState : public AState {
BaseState(ACodec *codec, const sp<AState> &parentState = NULL);
...
ACodec *mCodec; //★★これが知りたい★★
//★★UninitializedStateを手掛かりに見てみる★★
struct ACodec::UninitializedState : public ACodec::BaseState {
...
ACodec::UninitializedState::UninitializedState(ACodec *codec)
: BaseState(codec) { //★★BaseStateに丸投げ★★
}
//★★BaseStateを見てみる★★
struct ACodec::BaseState : public AState {
BaseState(ACodec *codec, const sp<AState> &parentState = NULL);
...
ACodec::BaseState::BaseState(ACodec *codec, const sp<AState> &parentState)
: AState(parentState),
mCodec(codec) { //★★引数をそのまま設定しているだけ★★
}
//★★UninitializedStateの生成個所を探す★★
ACodec::ACodec()
: mQuirks(0),
...
mDescribeHDRStaticInfoIndex((OMX_INDEXTYPE)0) {
mUninitializedState = new UninitializedState(this); //★★thisが指すものはACodec★★
mLoadedState = new LoadedState(this);
つまりACodec::BaseState::mCodecは、UninitializeStateを生成したACodecです。もう一つの謎getLooper()が何を返すのか?も見てみます。
//android/frameworks/av/include/media/stagefright/foundation/AHandler.h
struct AHandler : public RefBase {
...
wp<ALooper> getLooper() const {
return mLooper; //★★mLooperを返すだけ★★
}
...
inline void setID(ALooper::handler_id id, wp<ALooper> looper) {
mID = id;
mLooper = looper; //★★mLooperはsetIDの引数そのまま★★
}
//android/frameworks/av/include/media/libstagefright/foundation/ALooperRoster.cpp
ALooper::handler_id ALooperRoster::registerHandler(
const sp<ALooper> looper, const sp<AHandler> &handler) {
Mutex::Autolock autoLock(mLock);
if (handler->id() != 0) {
CHECK(!"A handler must only be registered once.");
return INVALID_OPERATION;
}
HandlerInfo info;
info.mLooper = looper;
info.mHandler = handler;
ALooper::handler_id handlerID = mNextHandlerID++;
mHandlers.add(handlerID, info);
handler->setID(handlerID, looper); //★★setIDを呼んでいる個所はここだけ★★
return handlerID;
}
//media/libstagefright/foundation/ALooper.cpp
ALooperRoster gLooperRoster;
...
ALooper::handler_id ALooper::registerHandler(const sp<AHandler> &handler) {
return gLooperRoster.registerHandler(this, handler);
}
ALooper::registerHandlerはALooperをAHandlerに登録する仕組み、AHandler::getLooper()はAHandlerに登録されたALooperを返す仕組みのようです。取得/設定が一致しないのでややこしいです。設計を失敗したのかなあ?
例えばAHandler *hogeとALooper *fugaがあってfuga->registerHandler(hoge)としたならば、hoge->getLooper()は先ほど登録したfugaを返します。
ちなみにACodecはAHandlerを継承しているのでgetLooper()関数を持っています。
ここまで分かればALooper::registerHandler()を呼んでいる個所を見て、引数がACodecオブジェクトであろう場所を見つければ、looperが指すのはどのALooperなのか?がやっと判明します。
しかしregisterHandler()の呼び出し箇所は非常に多くて、追いきれません。うーん、別のアプローチが必要でしょうか……?
この記事にコメントする
| < | 2017 | > | ||||
| << | < | 11 | > | >> | ||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| - | - | - | 1 | 2 | 3 | 4 |
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | - | - |
wiki
Linux JM
Java API
2002年
2003年
2004年
2005年
2006年
2007年
2008年
2009年
2010年
2011年
2012年
2013年
2014年
2015年
2016年
2017年
2018年
2019年
2020年
2021年
2022年
2023年
2024年
2025年
過去日記について
アクセス統計
サーバ一覧
サイトの情報合計:
本日: