2013-11-01 :-(
_ 午後
1300 コード書いたり
_ [艦これ]艦これ
11月のイベント開始された。軽い気持ちで E-1 に行ってボス戦は S 勝利したものの地味に小破されてしまったので立て直す( 2, 3 回繰り返しボス戦に挑み撃破しないといけない )。
_ 読書メーター
2013年10月の読書メーター
読んだ本の数:9冊
読んだページ数:1647ページ
ナイス数:25ナイス
プログラミングの宝箱 アルゴリズムとデータ構造 第2版の感想
リハビリとして読んだ。CとJavaの完全なコード(ビルドすれば実行できる)があるのはありがたい。
読了日:10月24日 著者:紀平拓男,春日伸弥
アルゴリズムイントロダクション 第1巻 数学的基礎とデータ構造の感想
間違って第1版を買ってしまった。MITで教科書として使われているらしい。数式が多用されてる。擬似言語はPascal風かしら。ヒープソートの木はいつ作られてるのこれ orz
読了日:10月24日 著者:T.コルメン,R.リベスト,C.ライザーソン
学戦都市アスタリスク 02 銀綺覚醒 (MF文庫J)の感想
星辰力を使わないガチの剣技娘キマシタ。叔父の小物感がすごく良い。室長という中間管理職も疲れそうだし、クローディアから「あれは幹部になれない」といきなり人格を否定されているあたりも素敵。序列一位との決闘と再戦でのし上がる主人公は補正されてても、もう少し苦戦してもらいたかった。剣技じゃなくて異種格闘技戦なら勝てるというのは天霧辰明流が古いから実は応用が効くということなのか、たんに「ハル姉が最強」ということを印象づけたかったのか。後者だろうなあ。星導館学園と他の学園との力量差が気になるが、大丈夫か星導館学園
読了日:10月18日 著者:三屋咲ゆう
クロス×レガリア 双貌の王 (角川スニーカー文庫)の感想
蓮花ぶんが少ない。月白弦摩による馳郎への評価「味方でも敵でもない灰色の関係を作る」このスキルが今回も発揮された。それは馳郎が情を入れることもなく恨むこともないから出来るのだろうけど、今後リコやナタなど身近なひとが傷つけられたときにどう振る舞うのか。やはり王としての振る舞いを見せるのか。楽しみすぎる。蓮花ぶんが少ない
読了日:10月13日 著者:三田誠
Febri (フェブリ) Vol.19の感想
艦これ目当て。イラストレーターへのインタビューは初めて目にするような。田中謙介インタビューも毎回楽しいですな
読了日:10月12日 著者:
艦隊これくしょん -艦これ- 鎮守府生活のすゝめ Vol.1 (エンターブレインムック)
読了日:10月11日 著者:
コンプティーク 2013年 11月号 [雑誌]の感想
艦これ目当て。今回はちゃんと予約した。ニンジャスレイヤーがry
読了日:10月11日 著者:
コンプティーク 2013年 10月号 [雑誌]の感想
別冊 艦これ目当て。重版を買った。それよりもニンジャスレイヤーってなんなのこれ....
読了日:10月11日 著者:
ゲーム開発者のためのAI入門の感想
(テレビ)ゲームで利用されるAI的なものをざっくりと説明している。しかしどうにもところどころ把握しづらい部分があるんだけど、コードが散在してるからなのか、はてさて。
読了日:10月1日 著者:DavidM.Bourg,GlennSeemann
読書メーター
2013-11-02 :-)
_ [魔法少女まどか☆マギカ]劇場版 魔法少女まどか☆マギカ 新編 叛逆の物語 を見た(1週間ぶり2回目)
@チネチッタ
ネタバレあります
OP
暁美ほむらは鹿目まどかとだけでなく、巴マミ、美樹さやか、佐倉杏子たちとも仲良くしたかったのではないか。仲間に入りたいけど引っ込み思案なのであの和に入りづらい。そんなところに鹿目まどかが手を差し伸べてくれた。そういう OP に見える。テレビシリーズの OP「コネクト」の歌詞「振り返れば仲間がいて 気がつけば優しく包まれてた 何もかもが歪んだ世界で 唯一信じられるここが救いだった」にあるように、暁美ほむらは仲間が欲しかった、仲良く過ごしたかったのではないか。だからこそ暁美ほむらが創り出した世界は 5 人が幸せである世界になっている。
暁美ほむらの影に翼がはえていた。地味にネタバレしておる。
プエラマギ・ホーリークインテット
変身シーンが怖い。魔女文字らしき文字が見えるけど解読したひと居るんだろうか。
美樹さやか
叛逆での美樹さやかは鹿目まどかと同じく円環の理の側の存在となっていて、この世界は暁美ほむらが創り出した世界であることを知っている。そうして叛逆を見ると、美樹さやかは楽しんでるなあ、ホントに良い奴だなあと。
美樹さやかはこの作られた世界でもそれほど悪くないんじゃないか、このままでもいいんじゃないかと思っている。それは中盤の美樹さやか vs. 暁美ほむらのシーンでのセリフに現れている。一番ツラいのは魔女である、魔女が創り出したこの偽物の世界は悪いことなのか、このままでもいいのではないか、といったことを言っている。これは、暁美ほむらが真相を突き止めると魔女化してしまうのでそれを防ぐため( 現状維持のため )に暁美ほむらを説得しているという面もあるし、美樹さやかが現状維持のままでもいい、この世界でキャッキャウフフしながら過ごしたいと思っているのではないかとも思える。冒頭の鹿目まどか、美樹さやか、佐倉杏子での登校シーンでは、美樹さやかはこれが偽物の世界だと知っていながら、それでも佐倉杏子とじゃれ合っている。美樹さやかは、鹿目まどかが世界を作りなおす前に佐倉杏子とこうして友達として触れ合いたかったのではないか、険悪な関係ではなく友達として過ごすことを希望していたのではないかと。それは前編後編での佐倉杏子のセリフにも「友達になれた」と言っているように、嘘の世界であっても美樹さやかは佐倉杏子と友達として過ごしたくて、だから暁美ほむらに現状維持でもよかろう、と言ったのかもしれない。
暁美ほむらが転校してきたシーン。美樹さやかは「むう ( ̄・ ̄)」といった表情をしていたけど、あれは「お前wwwそんなキャラじゃねえだろwww」というツッコミの表れではなかろうかと。
美樹さやかの戦闘力が上がっているように思える。前編後編のあとに円環の理の「カバン持ち」として何度か修羅場をくぐってきたことによるものだろう。動きが違うと思ったのは、中盤の暁美ほむら vs. 美樹さやかのシーンで暁美ほむらが魔法を使おうとする動作を防いだからそう思えた。暁美ほむらの盾の隙間に物を突っ込めば歯車が動かないので魔法が使えない。美樹さやかは前編後編のときでもあのような鋭い動きは無かったので印象に残った。美樹さやかが強くなったことは同シーンで暁美ほむらの説得に失敗して戦闘突入しそうにあまりにもスムーズにオクタヴィアを召喚していたことからも分かる。オクタヴィアを使いこなしていなければアレほどの引き際を見せることは出来ないだろう。美樹さやかは強くなっている。
なんと言っても最後 断頭台の魔女の戦闘。涙をだらだら流しながら見た。美樹さやかが巨大な鶏に食われたところを佐倉杏子が救ってからのシーン。佐倉杏子はこの世界が嘘の世界であることを知って、いま見ている美樹さやかも嘘の美樹さやかであることも知って、それでも美樹さやかと佐倉杏子が一緒に手を取り、同じ動きで踊るようにして戦う。これまで美樹さやかと佐倉杏子が一緒に居ることが当然であるという偽物の世界ではなく、美樹さやかと佐倉杏子が一緒に居ないことが真実であることを知っていながら、それでも一緒に戦う。おそらくこれが友達として過ごす最後の時間なのだと気づいているだろう。手をつないだすぐ後 佐倉杏子の手に落ちた涙は、その表れではなかろうかと。
巴マミ
巴マミは最強である。暁美ほむらの妄想の世界であっても暁美ほむらは巴マミに敵わない。それが巴マミ vs. 暁美ほむらのガンカタで明確になった。
美樹さやかの「絶好調のマミさんに挑むなんて」のセリフから、暁美ほむらは絶好調の巴マミを創り出した。その絶好調の巴マミと戦い、勝てなかった。
暁美ほむらは巴マミとこうしてガチの戦闘をしたかったのかもしれない。拳で語りあうどころか、銃で語り合う二人。そして最後はベジータのように「お前が No.1 だ」と認めたかたちである。どう見ても熱血じゃないですか。
中沢くん
暁美ほむらが自分の妄想世界に呼び寄せたのは暁美ほむらにとって何らかの意味がある人物なのだが、そのなかに中沢くん( 早乙女和子が「目玉焼きとは、固焼きですか?それとも半熟ですか? はい、中沢くん」と指名される最前列の男子だ )が含まれているのは相変わらず全然分からん。
Magia
前編後編を見てるときと、叛逆を見たあとではこの歌の印象が 180 度変わる。
前編後編: 暁美ほむらが鹿目まどかを救うための歌。
叛逆: 暁美ほむらが鹿目まどか(神)を奪い取り、悪魔へ堕ちるときの歌。
君の銀の庭
叛逆の ED
Kalafina の歌だから作品に根付いた歌詞になっているはずだが、あまり聞き取れない。
庭とは、暁美ほむらが妄想した偽物世界のことではないかと。
引き篭もり
まどか☆マギカの世界とは別の見方として、暁美ほむらは引き篭もりであり自分の殻に閉じこもっている。「私はこの部屋から一歩も外に出ない。日光に当たると死ぬ」と思っている。過去何度か会話したひとたちを呼び寄せて、自分を外に連れ出して欲しい、でも自分からは外に出ないよ。と。そういう設定の話として楽しむこともできる。
今日から配布されるポストカード。佐倉杏子
2013-11-03 :-)
_ [艦これ]艦これ
E-1 クリア。E-1 はゲージ自動回復なし。先日ボス旗艦を削っておいたので続き。
全員キラキラさせて 1 周
キラキラ解除された娘たちを交代させて 2 周。ボス戦は完全勝利だった。
伊19ゲット
E-2 へ出撃。1 回はボスを撃沈したものの
それ以降は道中で中破撤退したりボス戦に行ってもボスに攻撃が当たらなかったりなど。ボロボロになったので今日はここまでにしておいてやる。
_ ,
金剛さんを rblg しまくったところで金剛さんは出ない。
2013-11-04 :-)
_ 午前
0700 起床
0800 あにてれ:劇場版公開記念 2時間でわかる!大ヒットアニメ『魔法少女まどか☆マギカ』 前編後編のシーンをかいつまんで放送。斎藤千和ナレーションもあってもなくてもいいようなものであり、知らないひとが見てもよく分からないと思う
2013-11-06 :-(
_ 午後
1300 コード書いたり
_ [艦これ]艦これ
E-2 挑戦。
ボス削り
ボス削り
E-2-1 で旗艦大破したうえに敗北だと...
がんばります。
@miwarin そのあたりだと3-2でレベリングするのがオススメです
— ばやぺん (@bayapen) November 5, 2013
_ Windows7 が起動しなかった
「アクション センター」を見たら「your grapics driverが云々」などというログがあったのでビデオカードのドライバをアップデートした。どうか
2013-11-07 :-(
_ 午後
1300 コード書いたり
_ 健康診断結果のクレアチニンが 1.10 だった
「要観察」と云われているものの過去 2 年間とも 1.1 に近い。
Cr総量は体筋肉量を反映しているので、体筋肉率の多い男性の方が正常値も高い。正常値は施設によって若干異なるが概ね以下の通り。
血清Cr値:男性で0.6~1.2mg/dl、女性で0.4~1.0mg/dl
尿中Cr濃度:男性で20~26mg/kg/日、女性で14~22mg/kg/日
筋肉率ねえ。
_ 神への叛逆
その祈りは――そんな祈りが叶うとすれば、それは時間干渉なんてレベルじゃない!
因果律そのものに対する反逆だ!
君は、本当に神になるつもりかい?
( 魔法少女まどか☆マギカ WIKI - ネタバレ考察/台詞集/キュゥべえ 第12話 )
神になった鹿目まどか。
彼女が作った因果律。
その因果律を覆し、新たな宇宙を創った「悪魔」が居る。
_ ruby mechanize で SSL エラー
環境
- Microsoft Windows 7
- ruby 2.0 installer
C:/Ruby200/lib/ruby/2.0.0/net/http.rb:918:in `connect': SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (OpenSSL::SSL::SSLError) from C:/Ruby200/lib/ruby/2.0.0/net/http.rb:918:in `block in connect' from C:/Ruby200/lib/ruby/2.0.0/timeout.rb:52:in `timeout' from C:/Ruby200/lib/ruby/2.0.0/net/http.rb:918:in `connect' from C:/Ruby200/lib/ruby/2.0.0/net/http.rb:862:in `do_start' from C:/Ruby200/lib/ruby/2.0.0/net/http.rb:857:in `start' from C:/Ruby200/lib/ruby/gems/2.0.0/gems/net-http-persistent-2.9/lib/net/http/persistent.rb:691:in `start' from C:/Ruby200/lib/ruby/gems/2.0.0/gems/net-http-persistent-2.9/lib/net/http/persistent.rb:631:in `connection_for' from C:/Ruby200/lib/ruby/gems/2.0.0/gems/net-http-persistent-2.9/lib/net/http/persistent.rb:981:in `request' from C:/Ruby200/lib/ruby/gems/2.0.0/gems/mechanize-2.7.2/lib/mechanize/http/agent.rb:257:in `fetch' from C:/Ruby200/lib/ruby/gems/2.0.0/gems/mechanize-2.7.2/lib/mechanize.rb:432:in `get'
Ruby - OpenSSLでcertificate verify failedが出た場合 - Qiita [キータ]
CA_FILEの場所の確認
>irb irb(main):001:0> require 'openssl' => true irb(main):002:0> p OpenSSL::X509::DEFAULT_CERT_FILE "C:/Users/Luis/Code/openknapsack/knap-build/var/knapsack/software/x86-windows/openssl/1.0.0k/ssl/cert.pem"
ルイズ!ルイズ!ルイズ!ルイズぅぅうううわぁああああああああああああああああああああああん!!! とか言ってる場合じゃない。
RubyのMechanizeがSSLエラーになる。 - それマグで!
require 'openssl' OpenSSL::SSL::VERIFY_PEER = OpenSSL::SSL::VERIFY_NONE require 'mechanize'
たしかにエラーにはならないけど証明書どこなの。
2013-11-09 :-)
_ 午前
0900 起床 && 部屋掃除
_ 夜
1800 読書
2000 飯。鯖の味噌煮
2200 世界ふしぎ発見!第1295回 宇宙からの贈り物 隕石が生んだ南ドイツの奇跡 進撃の巨人の町並みに似ているということで久しぶりに見てみた。もろに進撃の巨人の絵を出していた。ドイツ女性の胸が大きい。ビール飲みたいデス
_ [叛逆の物語][魔法少女まどか☆マギカ]劇場版 魔法少女まどか☆マギカ 新編 叛逆の物語 を見てきた( 3 回目 )
@チネチッタ
来場者特典のフィルムはよく分からん風景だった。
暁美ほむらによる改変後の世界
結局どういう世界になったのか把握できん。
- 世界 A: 最初の世界。鹿目まどかによる改変前
- 世界 B: 鹿目まどかによる改変後
- 世界 C: 暁美ほむらによる改変後
世界 A | 世界 B | 世界 C | |
魔法少女 | 有 | 有 | 有 |
魔女 | 有 | 無 | 無 |
魔獣 | 無 | 有 | 有 |
円環の理 | 無 | 有 | 有 |
鹿目まどか | 有 | 無 | 有? |
世界線が複数あるわけじゃなくて、世界をそのたびに創り変えてるのだよな。
暁美ほむらは自らが魔女化してそれを浄化するための円環の理(鹿目まどか)をキュウべえに見せないために、魔女からさらにクラスチェンジして悪魔となり世界を改変した?
巴マミ、佐倉杏子が人間として存在している。
百江なぎさは人間か?魔法少女か?指輪は分からんかった。
美樹さやかは魔法少女のまま( 指輪が付いてるしオクタヴィアを召喚してる )。
断頭台の魔女戦 鹿目まどかの傷だらけの腕
前編後編での暁美ほむらループ 2 周目だったか、ワルプルギスの夜戦に敗北して、鹿目まどかと暁美ほむらが傷だらけになって倒れているときの腕か?暁美ほむらが鹿目まどかを殺したときの腕? 暁美ほむらは鹿目まどかを殺したことを後悔している。
プエラマギ・ホーリークインテット
変身シーン最後に 5 人が落下してくるときの背景は前編後編 OP のシーンの背景と同じじゃないか。
↓01:06
武器の練度
美樹さやかの刀がブレない。テレビシリーズでは我武者羅に振るっていたように見える刀だが、今回はまったくブレない。それだけ練度が上がったということ。
暁美ほむらの銃口もブレない。分かりやすいのは巴マミ vs. 暁美ほむらの最後に暁美ほむらが魔法を使い、時間停止している巴マミへ銃口を向けたときである。銃口がまったくブレずにピタっと静止する。昔 韓国へ行ったときに銃を撃ったときがあるんだけど[ 20061125#p03 ] 訓練していない素人が銃口を静止するのは無理。ワルサーP38といえどそれなりの重量はあるから、銃口がブレるんである。暁美ほむらはかなり銃の訓練をしたようだ。最初は「ちょっと走ったくらいで貧血になる」くらいに病弱だったのに。
巴マミ
見滝原に来たばかりの暁美ほむらが最初に頼ったのが巴マミであることから、なんだかんだと言って暁美ほむらは巴マミを先輩として信頼している。
巴マミ vs. 暁美ほむら。戦闘開幕直後 暁美ほむらによる射撃のすべての弾丸を巴マミは撃ち落としてる。以降も戦闘中はベベへ向けられたすべての弾丸を撃ち落としているようだ。巴マミは暁美ほむらの一手先を読むことが出来る。それだけ魔法少女としての練度が高い。円環の理の「カバン持ち」として修羅場を潜ってきた美樹さやかでさえも「絶好調のマミさんに戦いを挑むのは無謀だ」と言わせるくらいなので、巴マミの戦闘力は群を抜いている。巴マミは化け物か...。
これまでの解釈からして、暁美ほむらは巴マミにある程度の憧れを持っていたのではないだろうか。その戦闘力もそうだし、後輩への気配り、まっすぐな心、交渉力、などどれも暁美ほむらには無い( とくに交渉力はひどい )。
劇中でやたらと巴マミの胸が強調される。つまり、暁美ほむらは巴マミの胸にも憧れを持っていたのである!!!111
見滝原上空の飛行船
飛行船がなんのために居るのか分からん。暁美ほむらが自分が魔女であることに気づいたあと丘の上での鹿目まどかとの会話のときに、暁美ほむらの髪が結われているときまでは飛行船が飛んでいる。その直後 髪がほどけていくときには飛行船がもう飛んでいない。
BGM
最初のナイトメアを処理するときに 4 人が歌っていた歌。この曲の様々なアレンジがいろいろなところで使われる。
断頭台の魔女戦
オクタヴィア( 美樹さやかの魔女 )が佐倉杏子の槍を持って戦っている。これに気づいたときにまた涙がだらだら流れた。槍は、前編後編で佐倉杏子がオクタヴィアに自爆特攻を仕掛けるときに使用したもの。
オクタヴィア( 美樹さやか )、シャルロッテ( 百江なぎさ )だけでなく、前編後編に登場した魔女の手下たちも登場している。暁美ほむらを止めるための総力戦である。仲間を救うために全員が力を合わせて決戦に臨む。こういうの大好き。
暁美ほむら手下の大群を食い止めるためにゲルトルート( 薔薇園の魔女 )の手下の大群が対抗する様はまさにマスコンバットである。ロマサガ 3 をプレイしたひとならば歓喜するんじゃなかろうか。
2013-11-10 :-)
_ [学園祭][神奈川工科大学][KOTOKO][南條愛乃][飛蘭]KOTOKO・南條愛乃・飛蘭 アコーステック LIVE in 幾徳祭
@神奈川工科大学
13 年ぶり。同窓会会報に幾徳祭の話題があったので何気なくウェブサイトを見たらライブが企画されておりしかもまだチケットが買えるようなので買ってしまった。相変わらず遠いわ。
敷地の入り口がかなり増築されていてまったく面影がなかったんだが、那珂に入ってみたら見慣れた光景だった。
ちょいと早めに到着したのでチラホラ眺めるなどした。
ライブ
もしかして学園祭のライブは坂本真綾@武蔵工大[ 20011124#p03 ]以来ではないか。lucy 発売直後だったのだなあ。教えてあの頃よ 僕は今もきらめいていますか
さて、歌はほとんど知らんので曲リストなどは後日どこかに上がるでありましょう。
- 南條愛乃
- 飛蘭
- KOTOKO
3 人のうち歌声を知ってるのは KOTOKO のみだし、私の席は後方だしメガネを忘れてきて裸眼だしつまり誰が歌ってるのか分からず「栗林みな実のような歌声だなあ」と思っていたら南條愛乃らしい。
南條愛乃の破裂音が素敵すぎる。歌声が好みだしアコースティックだしこのライブの雰囲気はアレだなあ、笠原弘子ちゃんライブを思い出すなあ。などとおっさん臭く考えていた。
ラブライブの歌もあったような。隣の席のひとが感極まって泣いていた。南條「賢い!可愛い!」客「エリーチカ!」でした。
飛蘭は当初はパンツが見える衣装だったんだがマネージャーに却下されたんだとか。CANNAN オープニングなど。CANNAN がデビューだったのか。アレは結局どういう話だったのかさっぱり分からん。
安定の KOTOKO はエロゲ曲とかいろいろ。アコースティック Shooting Star 素晴らしい。(そのうち軒並み削除されそうな動画)
曲リスト
らしい
KOTOKO・南條愛乃・飛蘭アコースティックLIVE in 幾徳祭 セトリ1 ・南條愛乃 飛ぶサカナ 光 baby maby 恋のボタン START:DASH!! カタルモア #ナンジョルノ
— hiro@さすらいのイベリーマン (@hiro_furihiro) November 10, 2013
KOTOKO・南條愛乃・飛蘭アコースティックLIVE in 幾徳祭 セトリ2 ・飛蘭 mind as judgment WHITE justice 君といた日々 ALIVE 素晴らしい世界へ #faylan
— hiro@さすらいのイベリーマン (@hiro_furihiro) November 10, 2013
KOTOKO・南條愛乃・飛蘭アコースティックLIVE in 幾徳祭 セトリ3 ・KOTOKO 碧羅の天へ誘えど Imaginary affair Wing my Way Shooting Star ハヤテのごとく! #KOTOKO
— hiro@さすらいのイベリーマン (@hiro_furihiro) November 10, 2013
2013-11-13 :-(
_ 午後
1300 コード書いTARI
_ 送別会と懇親会
自社と顧客含めて。
割りと毎年恒例のアレ[ 20120829#p04 ] なんだが 10 月からまた以前の客先に舞い戻ったので再び参加するなど。
男性従業員の動作がガチャガチャと喧しかった。
パンがうまい
_ [ruby][connect]net/smtp で Permission denied - connect(2) (Errno::EACCES)
- Windows 7
- Ruby 2.0 installer
smtp.rb 関係なくて connect(2) が怒ってるんだけど。管理者で実行したり Windows ファイアウォールを無効にしても同様の現象になる。ううむ
# coding: utf-8 require 'net/smtp' Net::SMTP.start( 'smtp.example.jp', 25, 'example.jp', 'miwa@example.jp', 'PASSWORD', :login) { |smtp| smtp.send_message "hoge", 'miwa@example.jp', 'miwa@example.jp' }
>ruby smtp1.rb C:/Ruby200/lib/ruby/2.0.0/net/smtp.rb:540:in `initialize': Permission denied - connect(2) (Errno::EACCES) from C:/Ruby200/lib/ruby/2.0.0/net/smtp.rb:540:in `open' from C:/Ruby200/lib/ruby/2.0.0/net/smtp.rb:540:in `tcp_socket' from C:/Ruby200/lib/ruby/2.0.0/net/smtp.rb:550:in `block in do_start' from C:/Ruby200/lib/ruby/2.0.0/timeout.rb:66:in `timeout' from C:/Ruby200/lib/ruby/2.0.0/net/smtp.rb:549:in `do_start' from C:/Ruby200/lib/ruby/2.0.0/net/smtp.rb:519:in `start' from C:/Ruby200/lib/ruby/2.0.0/net/smtp.rb:456:in `start' from smtp1.rb:5:in `<main>'
2013-11-15 :-(
_ 午後
1300 コード読んだり
_ [スポーツ報知][まどか☆マギカ]スポーツ報知の「劇場版まどマギ特別号」
セブンイレブンと読売新聞販売店で買ってきた。
ひと月くらい前にブクマしておいてすっかり忘れていたので、日中に読売新聞販売店へ電話して取り置きをお願いし、退勤後に読売新聞販売店へ向かう途中にあったセブンイレブンに寄ったらまだあったので購入し、紆余曲折して読売新聞販売店へ到着して購入。セブンイレブンはクリアファイル無し、読売新聞販売店はクリアファイルあり。クリアファイルを貰える条件がよく分からん。
2013-11-16 :-)
_ [大洗舞祭][あんこう祭][ガルパン][ガールズアンドパンツァー]ガールズアンドパンツァー大洗舞祭 あんこう祭 1 日目
今年も yo_1 と行ってきた。去年[ 20121118#p04 ]
写真はこちら ガールズアンドパンツァー大洗舞祭 あんこう祭 2013-11-16 - a set on Flickr
前夜祭というわけではないけど、あんこう祭前日に大洗舞祭が開催されるので、今回は宿泊してきた。( 去年は日帰り )
宿
宿は 浜野屋 のガルパンプラン。気づいたときには 肴屋本店 と 大観荘はすでに満室だったのである。この宿はなかなか良かった。飯は上手いし、従業員と接しやすいし。風呂が本館とは別館( そこも宿泊できる。我々は本館に宿泊した )にあって、本館の宿泊客は一度外に出てから歩いて別館へ行くんだけど、そのレクリエーション具合いが楽しかった。
この宿だった。
メインステージ
サクっとメインステージへ移動してイベントを眺めるなど。
「サックス演奏」とあったんだがなんと云うチームだったか。ガルパン客に馴染んでいるようなのでそっち方面で常連なのかしら。
ガルパンイベント
その後「佐咲紗花が「あんこう音頭盆踊りver.」の生歌唱&渕上舞が踊るというゲストコーナー」
撮影禁止
トークなど。あんこう祭当日。あんこう祭「さい」と読んでいた。「まつり」じゃないのか。最後にステージと客席を含めて全員であんこう音頭。初めて踊った。なかなか楽しい。
おひる
出店の しらす丼(゚д゚)ウマー
コロッケ(゚д゚)ウマー
大洗探訪
アプリ「舞台めぐり ガルパン編」大洗あんこう祭限定イベント実施! というのがあるらしいのでインストールしてから移動。
磯前神社へ移動してから大洗の町を散歩するなど。
軽巡 那珂
民宿たくみ にスゲエのがあった。
割烹旅館 さかなや隠居 にあんこうが吊るしてあった。これから調理するんだそうな。あんこうをこんな近くで見るのは初めてだったので興奮してしまった。食べたい。
網戸
晩飯
ぐったりして宿に戻ってから あんこう鍋。(゚д゚)ウマー
そしてだらだらと過ごしつつ珍走団の音を聴きながら( 23 時ころになると走るようだ )一日が終わるのであった。
2013-11-17 :-)
_ [大洗舞祭][あんこう祭][ガルパン][ガールズアンドパンツァー]ガールズアンドパンツァー大洗舞祭 あんこう祭 2 日目
写真はこちら ガールズアンドパンツァー 大洗 大洗舞祭 あんこう祭 2013-11-17 - a set on Flickr
宿から
朝
新しい朝が来た。
朝飯
あんこう祭
舞台めぐりアプリをインストールして 15 箇所くらいチェックインしておいたんだが、中断したままで保存しておらず、手違いにより保存しないまま終了させてしまった。昨日の成果が水の泡であった。やる気なくなったのでやめた。
会場にはガルパンラッピングバス 2 号車が展示されていた。
あんこう吊るし切り
アライッペのデビュー ( 茨城県大洗町:大洗町イメージキャラクターデザイン募集の選考結果について )
激しく動くアライッペ
ガルパンイベント
「あんこうチームが勢揃いしたトークショーに加え、ChouCho・佐咲紗花によるミニライブ」
というイベント。
撮影禁止
我々が陣取った位置が撮影スタッフのすぐ後ろであり、イベント中は撮影スタッフが立ち上がって業務をこなしているので、がんばってその隙間から眺めるしかないという。位置取りをミスった。
ガルパンの今後の展開について 5 つの発表があったんだが、そのころになると尻が痛いし膝サポーターによる圧迫も痛いし尿意もツラかったのでほとんど頭に入っておらず。どこかに詳細が上がるでしょう。
ChouCho の歌も風によってスカートがめくれていたくらいしか記憶にない(ぇ
おひる
カニは脚が切られておらず食べるのに苦労した。
みつだんご(゚д゚)ウマー
帰路へ
宿へ戻る途中に発見。田口理髪店の横に設置されていた。出来たてのようだ。
おわりに
ステージ中の話題によると、今回はあんこう祭は一般参加者が 10 万人近いとかなんとか。ガルパンイベント中も客席が去年よりも人が多かったし、鹿島臨海鉄道で大洗駅から水戸駅までの列車も通勤ラッシュ並みの混雑だった。
次回は来るときは対策せねばなあ。
- 2 泊 3 日にする。月曜日に休暇しておきゆっくり帰る。あんこう祭も最後まで楽しめる
- 1 泊 2 日のまま。車で来場する。帰りは通勤ラッシュは無い。しかし往路に都心を抜けるときに渋滞あり。大洗の駐車場が無いかもしれないリスクもあり
また、あんこう祭期間中はステージ以外にもチラホラと見どころがあるんだが( 【ガルパン】最終チェック!あんこう祭情報まとめ : あんこうニュース )、ガルパンイベントに集中してしまうとそれらのイベントに参加できない。せっかく祭りに来ているのだからいろいろ楽しみたいんだがリソース配分が難しい。10 年前なら声優にガッツイていたけど今更それほど力を入れるほどでもないし( 疲れるのである )ガルパンは捨てるかなあ。うーん
2013-11-18 :-(
_ 午後
1300 コード読んだり
_ 2083WEB4周年記念アンケート:2083WEB 4周年記念特設サイト
アンケートに答えて、頂きました。ありがとうございます。これから聞きます。
_ ,
IT速報にマジレスしてはいけない
_ 月が綺麗ですね
2013-11-20 :-(
2013-11-21 :-(
_ 午後
1300 コード書いTARI
_ [スレッド][スケジューリング][スケジューラ][NetBSD][翻訳]Thread scheduling and related interfaces in NetBSD 5.0 (PDF) NetBSD 5.0 でのスレッドスケジューリングと関連するインターフェース
Introduction はじめに
A lot of new features were implemented in the NetBSD 5.0 release, and many improvements were made in the areas of scheduling, threading and symmetric multiprocessing (SMP). Like other modern UNIX-like operating systems, NetBSD supports traditional processes created by fork(2) and native POSIX threads (pthreads). Prior to the 5.0 release, user threading on NetBSD was implemented using a mechanism called scheduler activations (SA). The SA implementation was complicated, scaled poorly on multiprocessor systems and had no support for real-time applications. In NetBSD 5.0 these deficiencies have been addressed by replacing SA with an entirely new, scalable 1:1 threading model. In a 1:1 model each user thread (pthread) has a kernel thread called a light-weight process (LWP). Inside the kernel, both processes and threads are implemented as LWPs, and are served the same by the scheduler, as in Solaris, and other systems. In this article, we will review the scheduling of threads, related application programming interfaces, and utilities in the NetBSD operating system. Since the focus of this article is to introduce readers to new interfaces, we will not go into the details of implementations inside the kernel.
NetBSD 5.0 release にはたくさんの新機能が実装された。たくさんの改良がスケジューリング、スレッディング、対称型マルチプロセッシング( SMP )の分野について実装された。他のモダンな UNIX 風オペレーティングシステムのように、NetBSD は fork(2) によって生成された伝統的なプロセスや Native POSIX Thread (pthreads) に対応した。5.0 release 以前は、NetBSD でのユーザースレッディングは scheduler activations (SA) と呼ばれる機構を使って実装された。SA 実装は複雑であり、マルチプロセッサシステムではスケールが貧弱で、リアルタイムアプリケーションに未対応だった。NetBSD 5.0 ではこれらの欠点を完全に新規な SA に置き換えた。SA はスケーラブルな 1:1 スレッディングモデルである。1:1 モデルにおいて、各ユーザースレッド (pthread) は、ライトウェイトプロセス (LWP) と呼ばれるカーネルスレッドを持つ。Solari やその他のシステムでは、カーネル内においてプロセスとスレッドは LWP として実装され、スケジューラーからは同じように運用される{ served }。この論文では、スレッドのスケジューリング、アプリケーションプログラミングインターフェース、そして NetBSD オペレーティングシステムでのユーティリティについて再考{ review }する。この論文は新しいインターフェースの導入部なので、カーネル内の実装の詳細については触れない。
Real-time and scheduling classes リアルタイムとスケジューリングクラス
A real-time system is a predictable system which aims to meet certain time constraints (deadlines). Failure to meet these time constraints usually indicates hardware failure. Systems can be classiffied as either hard or soft real-time systems. Hard real-time systems shall meet the requirements unconditionally. That is, their predictability is deterministic. Soft real-time systems are not deterministic; they can tolerate some latencies, but their objective is to minimize them. NetBSD 5.0 provides soft real-time extensions.
リアルタイムシステムは予測可能なシステムである。制限された時間内(デッドライン)に完了する。これらの制限時間が満たされない場合、通常はハードウェア故障を意味する。システムはハードまたはソフトリアルタイムシステムとして分類される。ハードリアルタイムシステムは、絶対に要求を満たすべきである。すなわち、それらの予測可能性は決定的である。ソフトリアルタイムシステムは非決定的である。いくらかのレイテンシが許されるが、最小となることを目標とする。NetBSD 5.0 はソフトリアルタイム拡張を提供する。
According to the POSIX standard, at least the following three scheduling policies (classes) should be provided to support the POSIX real-time scheduling extensions:
POSIX 標準によると、POSIX リアルタイムスケジューリング拡張に対応するには、少なくとも以下の 3 つのスケジューリングポリシー (クラス) を提供すべきである。
- SCHED OTHER: Time-sharing (TS) scheduling policy, the default policy in NetBSD.
- SCHED FIFO: First in, first out (FIFO) scheduling policy.
- SCHED RR: Round-robin scheduling policy.
- SCHED OTHER: タイムシェアリング (TS) スケジューリングポリシー。NetBSD の既定のポリシー
- SCHED FIFO: 先入れ先出し (FIFO) スケジューリングポリシー
- SCHED RR: ラウンドロビンスケジューリングポリシー
The standard defines algorithms for the real-time SCHED FIFO and SCHED RR policies, and leaves SCHED OTHER as an implementation-defned policy; that is, it is specific to the operating system. All three policies are provided in NetBSD 5.0 and fit in the following in-kernel priority model:
POSIX 標準はリアルタイム SCHED FIFO と SCHED RR ポリシーのアルゴリズムを定義しており、SCHED OTHER は実装定義ポリシーとする。つまりオペレーティングシステム固有である。NetBSD 5.0 では 3 つすべてのポリシーを提供し、以下のカーネル内優先度モデルを適用する:
Kernel (RT) | 192 .. 223 | 32 levels | Software interrupts. |
User (RT) | 128 .. 191 | 64 levels | Real-time user threads (SCHED FIFO and SCHED RR policies). |
Kernel threads | 96 .. 128 32 levels | Internal kernel threads (kthreads), used by the I/O, VM and other kernel subsystems. | |
Kernel | 64 .. 95 32 levels | Kernel priority for user processes/threads, which is tem-porarily given when process/thread enters the kernel-space and blocks (sleeps). | |
User (TS) | 0 .. 63 | 64 levels | Time-sharing range, where user processes/threads runby default (SCHED OTHER policy). |
Kernel (RT) | 192 .. 223 | 32 levels | ソフトウェア割り込み |
User (RT) | 128 .. 191 | 64 levels | リアルタイムユーザースレッド (SCHED FIFO と SCHED RR ポリシー)。 |
Kernel threads | 96 .. 128 32 levels | カーネル内スレッド (kthreads), I/O、VM、他カーネルサブシステムから利用される。 | |
Kernel | 64 .. 95 32 levels | ユーザープロセス/スレッドのカーネル優先度。プロセス/スレッドがカーネル空間に入るりブロック( sleep )したときの一時的なもの。 | |
User (TS) | 0 .. 63 | 64 levels | タイムシェアリングの範囲。ユーザープロセス/スレッドの既定動作 (SCHED OTHER policy)。 |
These priorities are only used in the kernel, and internals are revealed only to provide a better understanding of the scheduling system as a whole. The POSIX standard requires at least 32 priority levels for the real-time scheduling policies. NetBSD 5.0 provides 64 priority levels, which are internally mapped to the appropriate kernel range shown above. It is not portable to depend on any of these constants, therefore using them is strongly discouraged. Applications should determine the priority range of the specific policy using the following functions defined by the standard:
これらの優先度はカーネル内でのみ使用され、内部についてはスケジューリングシステム全体を理解しやすい程度にする。POSIX 標準はリアルタイムスケジューリングポリシーに少なくとも 32 優先度レベルを要求する。NetBSD 5.0 は 64 優先度レベルを提供する。これは上記のカーネル範囲内に対応する。これらの内容のすべての依存性については可搬性が無いので、それらを使うことはとてもしんどい。アプリケーションは、標準によって定義された以下の関数を使うにあたって、ポリシー固有の範囲での優先度を決定すべきである:
int sched_get_priority_min(int policy); int sched_get_priority_max(int policy);
In NetBSD, the run queue of LWPs is implemented as a traditional multi-level feedback queue, like in many UNIX-like operating systems. The default SCHED OTHER policy is either the original 4.4BSD scheduling or traditional UNIX time-sharing approach like in Solaris, depending on which scheduler is chosen. It can be chosen using the SCHED 4BSD or SCHED M2 kernel options. One of the main objectives of a time-sharing queue is to give a priority boost for I/O bound threads (which allows the kernel to provide good response times for interactive tasks) and ensure fairness. Each LWP has a priority and time-quantum (amount of time allocated by the scheduler to run on the CPU). In a time-sharing queue, both values are dynamically calculated by the scheduler.
NetBSD での LWP のランキューは、たくさんの UNIX 風オペレーティングシステムのように、伝統的な多段フィードバックキューとして実装された。既定の SCHED OTHER ポリシーは、オリジナル 4.4BSD スケジューリングか、Solaris のような伝統的 UNIX 風オペレーティングシステム方法である。選択されたスケジューラーに依存する。SCHED 4BSD か SCHED M2 カーネルオプションを使えば選択できるようになる。タイムシェアリングキューのおもな目標のうち 1 つは、I/Oバウンドスレッドへプライオリティブーストさせ( インタラクティブタスクのために良い応答時間をカーネルに許可する )、公平性を保証する。各 LWP は優先度とタイムカンタム( スケジューラーによって割り当てられた CPU 動作時間の合計 )を持っている。タイムシェアリングキューにおいて、両方の値はスケジューラーによって動的に計算される。
Threads running with the SCHED FIFO policy, which is a real-time policy, have a fixed priority. That is, the kernel does not change the priority dynamically. Only the super user can set the scheduling policy to SCHED FIFO. Under this policy, a thread runs until completion, or it:
SCHED FIFO ポリシーで走るスレッドは、リアルタイムポリシーであり、固定された優先度を持っている。つまり、カーネルは動的に優先度を変更できない。スーパーユーザーのみが SCHED FIFO にスケジューリングポリシーを設定できる。このポリシーのもとではスレッドは完了するか、以下のようになるまで動作する:
- Voluntarily gives up the CPU (yields).
- Blocks on I/O operation or other resources (memory allocation, locks, etc).
- Gets preempted by a higher priority real-time thread.
- 自発的に CPU を停止する( 委譲 )
- I/O 操作か、他のリソース( メモリ確保、ロックなど )でブロックする
- より高い優先度のリアルタイムスレッドによってプリエンプトを取得される
SCHED RR works in the same way as SCHED FIFO, except threads running with this policy have a time- quantum (time-slice), which by default is 100 ms. Thus, unless it encounters one of the three cases above, the thread finishes when its time-quantum expires. Threads at the same priority level are processed in a round-robin way.
SCHED RR は SCHED FIFO と同じように動作するが、このポリシーで動作するスレッドは既定で 100 ms のタイムカンタム( タイムスライス )で動作する。このように、上記 3 つのうち 1 つが起きるまでは、タイムカンタムの満了よってスレッドは終了する。同じ優先度のスレッドは、ラウンドロビンで処理される。
Figure 1: Real-time thread dispatch latency (threads bound to pset), 8 core Xeon with background load.
図1: リアルタイムスレッドがレイテンシをディスパッチする( pset するときのスレッドバウンド )。8 コア Xeon でのバックグラウンドロード。
A simple latency test with two SCHED FIFO threads bound to the same CPU when the system is under load (running ./build.sh -j16) has shown that NetBSD with kernel preemption enabled tends to respond within 5 microseconds (see Figure 1). Microsecond-level latencies for real-time threads are usually what real-time operating systems, like QNX or VxWorks, guarantee. As we see, response times of real-time threads in NetBSD 5.0 are similar to other real-time operating systems.
システムが低負荷( ./build.sh -j16 を実行 )の場合、2 つの SCHED FIFO スレッドの簡単なレイテンシテストは同じ CPU のためにバウンドする。カーネルプリエンプションを有効にした NetBSD が 5 マイクロ秒以内に応答する傾向がある( 図 1 )。リアルタイムスレッドのためのマイクロ秒レベルのレイテンシは、通常 QNX や VxWorks 製品のようなリアルタイムオペレーティングシステムである。我々が見たように、NetBSD 5.0 でのリアルタイムスレッドの応答時間は、他のリアルタイムオペレーティングシステムと同様である。
The following C code fragment illustrates how to use the SCHED FIFO policy and set highest priority for the current (calling) thread:
以下の C コード断片は SCHED FIFO ポリシーの使い方と、現在のスレッド( 呼び出した側 )に最高優先度を設定する方法を示す。
struct sched_param sp; memset(&sp, 0, sizeof(struct sched_param)); sp.sched_priority = sched_get_priority_max(SCHED_FIFO); if (pthread_setschedparam(pthread_self(), SCHED_FIFO, &sp)) { errx(EXIT_FAILURE, "pthread_setschedparam: %s", strerror(error)); }
See the sched(3) and pthread schedparam(3) manual pages for a full description of scheduling functions.
スケジューリング関数についての完全な説明は sched(3) と pthread schedparam(3) マニュアルページを参照。
Thread affinity スレッド親和性
Thread affinity is the ability to bind threads to run only on a specified processor (or processors). This functionality is relevant to SMP systems and provides an effective way to increase CPU utilization, avoid CPU cache thrashing, ensure concurrency, and guarantee fast response times. These are of particular benefit to real-time applications.
スレッド親和性は、特定のプロセッサ( 単数または複数 )のみにスレッドを動作させるように結びつける能力である。この機能は SMP システムのためのもので、CPU 利用を増加するための効果的な方法を提供する。CPU キャッシュスラッシングの回避、並行性の確保、そして速い応答時間を保証する。リアルタイムアプリケーションのために特に効果がある。
Internally, the scheduler (this part of functionality is also called the dispatcher) tries to balance between two opposite tasks - utilize all processors and maintain thread affinity. In NetBSD 5.0, this is achieved by means of per-CPU run-queues, thread migration and balancing mechanisms. However, balancing and migration decisions are heuristic and based on observations of thread behaviour made by the kernel, meaning that the decisions made might not be optimal in all given situations. For example, the scheduler is not aware of the workload a thread is going to process, or of the relationships between threads. Because developers have such knowledge of their applications, interfaces to control affinity are provided. There are two different interfaces in NetBSD to implement thread affinity: dynamic CPU sets and processor sets.
内部ではスケジューラー( この機能の一部は、ディスパッチャとも呼ばれる )は 2 つの正反対のタスクのバランスをとる - すべてのプロセッサを利用し、スレッド親和性を維持する。NetBSD 5.0 では、これは CPU ごとのランキュー、スレッドマイグレーションと分散機構によって達成された。しかし、分散とマイグレーションを決定することはヒューリスティックであり、カーネルがスレッドの挙動を監視することに基づいているので、この決定がすべての与えられた状況{ ???? }に最適ではない可能性を意味する。たとえば、スケジューラーはプロセスに入ったスレッドの仕事量を把握していないし、スレッド間の関係も把握していない。開発者は彼らのアプリケーションの知識として持っているので、親和性を管理するためのインターフェースが提供されている。NetBSD でのスレッド親和性についてのインターフェースには 2 つの差異がある。動的 CPU 割り当てとプロセッサ割り当てだ。
Dynamic CPU sets is an interface similar to the CPU sets found in Linux and recent FreeBSD systems. It allows binding (pinning) a thread to the processors expressed via affinity mask (a simple bit-mask). Here is a C code fragment which creates a dynamic CPU set, adds the first processor (cpu0) to the set, and sets the affinity mask to the current (calling) thread:
動的 CPU 割り当ては、Linux や最近の FreeBSD システムに見られる CPU 割り当てのようなインターフェースである。親和性マスク( 簡単なビットマスクだ )によるプロセッサへスレッドを結び付ける( 繋ぐ )。ここに C コード断片がある。これは動的 CPU 割り当てを生成し、最初のプロセッサ( cpu0 )を割り当てに追加し、現在のスレッド( 呼び出し側 )へ親和性マスクを割り当てる。
cpuset_t *cset; pthread_t pth; cpuid_t ci; cset = cpuset_create(); if (cset == NULL) { err(EXIT_FAILURE, "cpuset_create"); } /* Set the first processor (cpu0). */ ci = 0; cpuset_set(ci, cset); /* Set affinity mask to the current thread. */ pth = pthread_self(); error = pthread_setaffinity_np(pth, cpuset_size(cset), cset); if (error) { errx(EXIT_FAILURE, pthread_setaffinity_np: %s", strerror(error)); } /* * At this point, the current thread runs on the first processor (cpu0). * The set can be destroyed now (or re-used for other thread, for example), * since it is already "applied" to the thread. */ cpuset_destroy(cset); perform_work();
Wrappers to set and get the process affinity are also provided:
プロセッサ親和性を設定したり取得するためのラッパーも提供されている。
int sched_getaffinity_np(pid_t pid, size_t size, cpuset_t *cpuset); int sched_setaffinity_np(pid_t pid, size_t size, cpuset_t *cpuset);
Note that while the thread is bound to the first processor, any other process/thread could also run on this processor, and share the time. A full description of dynamic CPU sets API could be found in the affinity(3) and cpuset(3) manuals. Unfortunately, neither POSIX nor other standards define any interfaces to control thread affinity and interfaces provided by various operating systems differ, so these calls are not expected to be portable.
なお、スレッドが最初のプロセッサへ結びつけられている間、他のあらゆるプロセッサ/スレッドもこのプロセッサで動作できるし、時間も共有される。動的 CPU 割り当て API についての完全な説明は、affinity(3) と cpuset(3) マニュアルにある。残念ながら、POSIX や他の標準は、スレッド親和性を管理するインターフェースや様々なオペレーティングシステムの違いで提供されるインターフェースを定義してもいない。よって、これらの呼び出しはポータブルを期待できない。
Processor sets is an interface which allows assigning processors to threads. Assigned processors are forced to run only bound threads (or processes). Thus, processor sets are more of a resource pool based solution. A similar interface is found in the Solaris and HP-UX operating systems. Here is a C code fragment which forces a processor to run only the current (calling) process:
プロセッサセットとは、スレッドへプロセッサを割り当てるためのインターフェースである。割り当てられたプロセッサは、バウンドスレッド(またはバウンドプロセス)のみを実行することを強制する。このようにプロセッサセットはより一層 資源ベースの解決策となる。同様のインターフェースは Solaris や HP-UX オペレーティングシステムにも見られる。現在のプロセス(呼び出し側)のみを実行するようにプロセッサに強制する C コード断片を示す。
psetid_t psid; cpuid_t ci; if (pset_create(&psid) == -1) { err(EXIT_FAILURE, "pset_create"); } /* * Assign cpu0 to the processor set. */ ci = 0; if (pset_assign(psid, ci, NULL) == -1) { err(EXIT_FAILURE, "pset_assign"); } /* * Bind the current process to the processor-set. */ if (pset_bind(psid, P_PID, P_MYID, NULL) == -1) { err(EXIT_FAILURE, "pset_bind"); } /* * At this point, the first processor (cpu0) runs _only_ the current process. */ perform_work(); /* * Destroy the processor set. * This operation releases all assigned processors and bound threads. */ if (pset_destroy(psid) == -1) { err(EXIT_FAILURE, "pset_destroy"); }
Note that unlike the previous example with dynamic CPU sets, in this example the first processor (cpu0) would run only one bound process, and no other processes. A full description of the processor sets API can be found in the pset(3) manual page. This interface is not defined by any standards either. However, the API is expected to be nearly compatible with Solaris and HP-UX.
先ほどの動的 CPU セットの例とは異なる。この例では最初のプロセッサ(cpu0) はたった 1 つのバウンドプロセスのみを実行し、他のプロセスは実行しない。プロセッサセット API の完全な説明は pset(3) マニュアルページにある。このインターフェースはどの標準にも定義されていない。しかし API は Solaris や HP-UX とほぼ互換性があることが期待される。
To find out how many processors are configured in the system, there is a standard option to sysconf(3):
システムにいくつのプロセッサが設定されているかを見つける方法は、sysconf(3) の標準オプションにある。
ncpu = sysconf(_SC_NPROCESSORS_CONF);
The flexibility to choose between two interfaces with different approaches, found in various UNIX-like oper- ating systems, allows developers to use the interface which best suits the needs of their applications.
異なるアプローチにより 2 つのインターフェースを選べるための柔軟性は、様々な UNIX 風オペレーティングシステムに見られるし、開発者が彼らのアプリケーションが必要とする最良の一式のインターフェースを使うことを許可する。
Controlling the scheduling of processes and threads プロセスとスレッドのスケジューリング管理
NetBSD also provides two utilities to control scheduling and thread affinity. These utilities can be used by administrators and developers. The schedctl(8) command allows changing scheduling priority and class, and setting thread/process affinity. The following examples illustrate some possible uses of this utility.
NetBSD はスケジューリング管理とスレッド親和性のために 2 つのユーティリティも提供する。これらのユーティリティは管理者と開発者が使える。schedctl(8) コマンドはスケジューリングの優先度とクラスを変更し、スレッド/プロセス親和性を設定できる。このユーティリティで出来ることいくつかの例を示す。
Show scheduling information about PID "123":
PID 123 のスケジューリング情報を表示する:
# schedctl -p 123 LID: 1 Priority: 43 Class: SCHED_OTHER Affinity (CPUs): <none>
Set the affinity to CPU 0 and CPU 1, policy to SCHED RR, and priority to 63 for thread whose ID is "1" in process whose ID is "123":
CPU 0 と CPU 1 に親和性を設定し、ポリシーを SCHED RR にし、プロセス ID 123 のスレッド ID 1 の優先度を 63 にする。
# schedctl -p 123 -t 1 -A 0,1 -C SCHED_RR -P 63
Run the top(1) command with real-time priority:
top(1) コマンドをリアルタイム優先度で走らせる:
# schedctl -C SCHED_FIFO top
Traditional utilities like top(1) (with the -t option to enable thread-view) and ps(1) (with the -l option) can be used to monitor the general thread activity.
top(1) ( -t オプションでスレッドビューを有効 )や ps(1) ( -l オプションも使う )のような伝統的ユーティリティは通常のスレッド活動を監視するために使える。
To control processor sets, psrset(8) is provided, which is nearly compatible with the one found in Solaris. The following example illustrates how to create a processor set, assign CPU 9 to it, and run httpd on that processor set.
プロセッサー割り当てを制御するために psrset(8) が提供されている。これは Solaris にあるものと割りと互換性がある。以下の例では、プロセッサセットを生成し、CPU 9 に割り当て、プロセッサセットで httpd を走らせる方法を示す。
Print current processor sets:
現在のプロセッサセットを印字する:
# psrset system processor set 0: processor(s) 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Create a new processor set, which is assigned an ID of 1, and add CPU 9 to processor set 1:
新しいプロセッサセットを生成する。これは ID 1 に割り当てられ、CPU 9 をプロセッサセット 1 へ追加する:
# psrset -c 1 # psrset -a 1 9
Print current processor sets. Note that there is now a user-created processor set with an ID of 1, and that CPU 9 is now in processor set 1 and no longer in 0:
現在のプロセッサセットを印字する。なお、現在 利用者が生成した ID 1 のプロセッサセットがあり、CPU 9 はプロセッサセット 1 になっており、0 ではなくなっている。
# psrset system processor set 0: processor(s) 0 1 2 3 4 5 6 7 8 10 11 12 13 14 15 user processor set 1: processor(s) 9
Execute httpd within processor set 1:
プロセッサセット 1 上で httpd を実行する:
# psrset -e 1 /etc/rc.d/httpd start
Note that top(1) shows httpd running on CPU 9:
top(1) で CPU 9 上で httpd が走っていることを表示する:
# top | grep httpd 29469 www 85 0 164K 1468K select/9 0:04 0.68% 0.68% httpd 15229 www 85 0 164K 1404K select/9 3:15 0.00% 0.00% httpd 18574 www 85 0 164K 1688K select/9 2:16 0.00% 0.00% httpd 14208 www 85 0 164K 1336K select/9 2:15 0.00% 0.00% httpd
A small cpuctl(8) utility is also available, which can change the state of CPU to online/offline, as well as identify its model and features. Example output from a machine with "AMD Shanghai" (codename) processors:
小柄なユーティリティ cpuctl(8) も有効である。これは CPU の状態を オンライン/オフラインに変更し、モデルと機能を区別する。コードネーム "AMD Shanghai" プロセッサのマシンでの出力例:
# cpuctl list Num HwId Unbound LWPs Interrupts Last change ---- ---- ------------ -------------- ---------------------------- 0 0 online intr Sat Nov 8 16:33:40 2008 1 1 online intr Sat Nov 8 16:33:40 2008 2 2 online intr Sat Nov 8 16:33:40 2008 3 3 online intr Sat Nov 8 16:33:40 2008 4 4 online intr Sat Nov 8 16:33:40 2008 5 5 online intr Sat Nov 8 16:33:40 2008 6 6 online intr Sat Nov 8 16:33:40 2008 7 7 online intr Sat Nov 8 16:33:40 2008 8 8 online intr Sat Nov 8 16:33:40 2008 9 9 online intr Sat Nov 8 16:33:40 2008 10 a online intr Sat Nov 8 16:33:40 2008 11 b online intr Sat Nov 8 16:33:40 2008 12 c online intr Sat Nov 8 16:33:40 2008 13 d online intr Sat Nov 8 16:33:40 2008 14 e online intr Sat Nov 8 16:33:40 2008 15 f online intr Sat Nov 8 16:33:40 2008
# cpuctl identify 0 cpu0: AMD Unknown AMD64 CPU (686-class), 2999.67 MHz, id 0x100f40 cpu0: features 178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR> cpu0: features 178bfbff<PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX> cpu0: features 178bfbff<FXSR,SSE,SSE2,HTT> cpu0: features2 802009<SSE3,MONITOR,CX16,POPCNT> cpu0: features3 efd3fbff<SCALL/RET,NOX,MXX,FFXSR,P1GB,RDTSCP,LONG,3DNOW2,3DNOW> cpu0: features4 37ff<AHF,CMPLEGACY,SVM,EAPIC,ALTMOVCR0,LZCNT,SSE4A,MISALIGNSSE,3DNOWPREFETCH,OSVW,IBS,SKINIT,WDT> cpu0: "AMD Engineering Sample" cpu0: I-cache 64KB 64B/line 2-way, D-cache 64KB 64B/line 2-way cpu0: L2 cache 1MB 64B/line 16-way cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu0: L3 cache 2MB 64B/line direct-mapped cpu0: Initial APIC ID 0 cpu0: AMD Power Management features: 0x1f9<TS,TTP,HTC,STC,100,HWP,TSC> cpu0: family 0f model 04 extfamily 01 extmodel 00
This utility can also be useful to developers who are writing multithreaded applications and want to test them under a variety of CPU conditions.
このユーティリティは、マルチスレッドアプリケーションを書いて、様々な CPU 状況でテストしたい開発者にも使いやすい。
Conclusion 終わりに
NetBSD is a general-purpose operating system, with a scalable 1:1 threading implementation and flexible interfaces to control scheduling and threads. This scalable implementation allows it to provide high quality POSIX real-time extensions and reliably suit the needs of embedded systems. NetBSD also provides modern solutions to ensure good performance for threaded workloads, which are increasingly prevalent in today's world of multi-core and multi-processor systems.
NetBSD は通常目的のオペレーティングシステムである。スケーラブル 1:1 スレッディング実装し、スケジューリングとスレッドを制御するための柔軟なインターフェースがある。このスケーラブル実装によって 高品質な POSIX リアルタイム拡張を提供し、組み込みシステムの要求に確実にぴったりである。NetBSD は threaded workloads のための確実で良いパフォーマンスのためにモダンなソリューションも提供する。これは今日のマルチコアやマルチプロセッサシステムでますます一般化している。
2013-11-22 :-)
_ [NetBSD][スクリプト]/bin などの下にはスクリプトファイルが多数ある
% file /sbin/* /bin/* /usr/bin/* /usr/sbin/* | grep "POSIX shell" /sbin/dhclient-script: POSIX shell script, ASCII text executable /sbin/fastboot: POSIX shell script, ASCII text executable /sbin/fasthalt: POSIX shell script, ASCII text executable /sbin/newbtconf: POSIX shell script, ASCII text executable /sbin/nologin: POSIX shell script, ASCII text executable /sbin/resolvconf: POSIX shell script, ASCII text executable /usr/bin/c89: POSIX shell script, ASCII text executable /usr/bin/c99: POSIX shell script, ASCII text executable /usr/bin/cleantags: POSIX shell script, ASCII text executable /usr/bin/clear: POSIX shell script, ASCII text executable /usr/bin/cvsbug: POSIX shell script, ASCII text executable /usr/bin/false: POSIX shell script, ASCII text executable :
_ [NetBSD]/sbin/nologin を読む
/etc/passwd を見るとシェルが nologin だったりする。nologin はログインさせないときに使う。
% grep nologin /etc/passwd : axfrdns:*:1012:1012:djbdns-run axfrdns user:/nonexistent:/sbin/nologin dnscache:*:1013:1012:djbdns-run dnscache user:/nonexistent:/sbin/nologin dnslog:*:1014:1012:djbdns-run dnslog user:/nonexistent:/sbin/nologin rbldns:*:1015:1012:djbdns-run rbldns user:/nonexistent:/sbin/nologin tinydns:*:1016:1012:djbdns-run tinydns user:/nonexistent:/sbin/nologin
コードを読む。
コメント吐いて終わり。
#! /bin/sh echo "This account is currently not available." exit 1
_ [NetBSD]/usr/bin/c89 を読む
cc に C89 準拠のためにオプションつけるだけ。( C言語 - C89 )
#!/bin/sh exec /usr/bin/cc -std=c89 "$@"
_ [NetBSD]/usr/bin/c99 を読む
cc に C99 準拠のためにオプションつけるだけ。( C言語 - C99 )
#!/bin/sh exec /usr/bin/cc -std=c99 "$@"
_ [NetBSD]/usr/bin/true と /usr/bin/false を読む
true は 0 を返す。
#! /bin/sh exit 0
false は 1 を返す。
#! /bin/sh exit 1
0 が正常で 1 が異常というのは伝統的なリターン値である( いつからあるのか知らん )。/usr/include/stdlib.h にもある。
#define EXIT_FAILURE 1 #define EXIT_SUCCESS 0
2013-11-23 :-)
_ [NetBSD]/usr/bin/shar を読む
shar は使ったことがなかったんだが、与えられたファイルリストをテキスト 1 つにまとめ、アーカイブとするものらしい。それ tar でいいんじゃないの。
shar よりも tar のほうが後に書かれたものなのだろうかと思ったけどそうでもないらしい。
shar の man より
HISTORY The shar command appeared in 4.4BSD.
tar の man より
HISTORY A tar command first appeared in Version 7 AT&T UNIX.
4.4BSD は 1994 年 6 月リリース ( BSD - 4.4BSD と派生 )
Version 7 AT&T UNIX は 1979 年リリース ( Version 7 Unix )
ううむ。謎
shar のコードを読む。
# ヒアドキュメントにより EOF までの文字列を印字する cat << EOF # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # EOF # for i in "$@" と同じ # つまりスクリプトの引数 $1 $2 $3... をすべて処理する ( プロフェショナルシェルプログラミング p.98 ) for i do echo "# $i" done echo "#" for i do if [ -d $i ]; then echo "echo c - $i" echo "mkdir -p $i > /dev/null 2>&1" else echo "echo x - $i" echo "sed 's/^X//' >$i << 'END-of-$i'" sed 's/^/X/' $i echo "END-of-$i" fi done echo exit echo "" exit 0
しかし shar コマンドがどういうものかかよく分からんので実際に使ってみる。
Man page of SHAR より、shar に対して実行。
% cd /usr/src/usr.bin/shar % shar `find . -print` | lv
こんなん出ました。出力されるものそれ自体がシェルスクリプトとなる。
# This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # . # ./CVS # ./CVS/Repository # ./CVS/Entries # ./CVS/Template # ./CVS/Root # ./CVS/Tag # ./obj # ./Makefile # ./shar.1 # ./shar.sh # echo c - . mkdir -p . > /dev/null 2>&1 echo c - ./CVS mkdir -p ./CVS > /dev/null 2>&1 echo x - ./CVS/Repository sed 's/^X//' >./CVS/Repository << 'END-of-./CVS/Repository' Xsrc/usr.bin/shar END-of-./CVS/Repository echo x - ./CVS/Entries sed 's/^X//' >./CVS/Entries << 'END-of-./CVS/Entries' X/Makefile/1.8/Mon Mar 24 21:59:48 1997//Tnetbsd-6-0-RELEASE X/shar.1/1.11/Thu Aug 7 11:15:51 2003//Tnetbsd-6-0-RELEASE X/shar.sh/1.3/Thu Jun 30 02:36:35 2005//Tnetbsd-6-0-RELEASE XD END-of-./CVS/Entries echo x - ./CVS/Template sed 's/^X//' >./CVS/Template << 'END-of-./CVS/Template' XCVS: ---------------------------------------------------------------------- XCVS: CVSROOT cvs.NetBSD.org:/cvsroot XCVS: please use "PR category/123" to have the commitmsg appended to PR 123 XCVS: XCVS: Please evaluate your changes and consider the following. XCVS: Abort checkin if you answer no. XCVS: => For all changes: XCVS: Do the changed files compile? XCVS: Has the change been tested? XCVS: => If you are not completely familiar with the changed components: XCVS: Has the change been posted for review? XCVS: Have you allowed enough time for feedback? XCVS: => If the change is major: XCVS: => If the change adds files to, or removes files from $DESTDIR: XCVS: => If you are changing a library or kernel interface: XCVS: Have you successfully run "./build.sh release"? END-of-./CVS/Template echo x - ./CVS/Root sed 's/^X//' >./CVS/Root << 'END-of-./CVS/Root' Xanoncvs@anoncvs.netbsd.org:/cvsroot END-of-./CVS/Root echo x - ./CVS/Tag sed 's/^X//' >./CVS/Tag << 'END-of-./CVS/Tag' XNnetbsd-6-0-RELEASE END-of-./CVS/Tag echo c - ./obj mkdir -p ./obj > /dev/null 2>&1 echo x - ./Makefile sed 's/^X//' >./Makefile << 'END-of-./Makefile' X# $NetBSD: Makefile,v 1.8 1997/03/24 21:59:48 christos Exp $ X# @(#)Makefile 8.1 (Berkeley) 6/6/93 X :
_ [NetBSD]/usr/bin/zgrep と /usr/bin/zegrep と /usr/bin/zfgrep を読む
3 つとも中身は同じ。
% diff3 /usr/bin/zgrep /usr/bin/zfgrep /usr/bin/zegrep
スクリプト冒頭で自分がどのコマンドとして呼び出されたのか判定している。
prg=$0 # handle being called 'zegrep' or 'zfgrep' case ${prg} in *zegrep) grep_args="-E";; *zfgrep) grep_args="-F";; esac
正味の処理。zcat でフィルタしてから grep する
# call grep ... if [ $# -lt 1 ] then # ... on stdin ${zcat} -fq - | ${grep} ${grep_args} -- "${pattern}" - else # ... on all files given on the command line if [ ${silent} -lt 1 ]; then grep_args="-H ${grep_args}" fi while [ $# -gt 0 ] do ${zcat} -fq -- "$1" | ${grep} --label="${1}" ${grep_args} -- "${pattern}" - shift done fi
その zcat はここにある。
/usr/src/distrib/utils/zcat/
これはシェルスクリプトではなく C のコードである。
main() に注目する。ようするに zlib の関数を呼び出して展開 gz_uncompress() している。
int main(int argc, char *argv[]) { gzFile zfp; /* save program name and skip */ prog = argv[0]; argc--, argv++; /* ignore any switches */ while (*argv && (**argv == '-')) { argc--, argv++; } if (argc == 0) { zfp = gzdopen(fileno(stdin), "rb"); if (zfp == NULL) error("can't gzdopen stdin"); gz_uncompress(zfp, stdout); return 0; } do { /* file_uncompress(*argv); */ zfp = gzopen(*argv, "rb"); if (zfp == NULL) { fprintf(stderr, "%s: can't gzopen %s\n", prog, *argv); exit(EXIT_FAILURE); } gz_uncompress(zfp, stdout); } while (argv++, --argc); return 0; /* to avoid warning */ }
_ [NetBSD]/usr/bin/zforce を読む
圧縮ファイルに拡張子が無かったらファイル名を変更する。
while test $# -ne 0; do case "$1" in # 拡張子に .gz や .tgz などが無ければ処理する。 *[._-]gz) shift ;; *.t[ag]z) shift ;; *) # file の出力に "gzip compressed data" が含まれていれば処理する if file "$1" | grep -q "gzip compressed data" 2> /dev/null then # ファイル名の末尾に .gz を追加する n="$1".gz if mv "$1" "$n" 2> /dev/null; then echo "$1" -- renamed to "$n" else ret=1 echo $prog: cannot rename "$1" to "$n" fi fi shift ;; esac done exit $ret
2013-11-24 :-)
_ 午後
1200 東京モーターショー未遂 || チケットはネットで購入済みだったんだが印刷して紙媒体を会場で提示しないといけないということに最寄り駅で気づいた || 戻ってからまた来るのも面倒くさいので来週にする
1300 不動産屋
1400 散歩
1600 ぐったり
_ [艦これ]艦これ
E-3 出撃してクリア。
2h くらいか。
出撃→ボス→完了→入渠でバケツ→出撃を繰り返した。
羅針盤的には戦艦x1 雷巡x2 軽空母x2 正規空母x1 が安定した。
装備は雷巡ハイパーズは夜戦に備えて連撃装備。空母たちは烈風 > 彗星 > {流星,天山} の配分で装備。
陣形は道中もボス戦も全部単縦。
7 回出撃して 4 回ボス戦。
昼戦で千代田が大破したので怖かったんだが夜戦へ突入。比叡さんが撃破してくれた。
歴戦の艦娘たち。結局この娘たちで連戦した。よくやってくれた。
いろいろゲット。
E-4 が開放されましたが、どうかなあ。
_ [NetBSD]/sbin/fastboot と /sbin/fasthalt を読む
/sbin/fastboot と /sbin/fasthalt
fastboot, fasthalt とはなんぞや。man を読む。
DESCRIPTION fastboot and fasthalt are shell scripts which reboot or halt the system, and when next started, the system will skip the normal the file systems checks. This is done by creating a file /fastboot, then invoking the reboot(8) program. The system startup script, /etc/rc, looks for this file and, if present, skips the normal invocation of fsck(8).
起動時に fsck をすっ飛ばすらしい。
コードを読む。
fastboot はこう。/fastboot というファイルを作り reboot する。touch /fastboot じゃダメなのかしら。
cp /dev/null /fastboot /sbin/reboot $*
fasthalt はこう。halt している以外は fastboot と同じ。
cp /dev/null /fastboot /sbin/halt $*
/etc/rc.d
man fastboot によると /etc/rc が /fastboot をチェックするらしい。
探す。3 箇所にある。
% grep -r fastboot /etc/* /etc/rc.d/fsck: if [ -e /fastboot ]; then /etc/rc.d/root: rm -f /fastboot /etc/rc.d/fsck_root: if [ -e /fastboot ]; then
/etc/rc.d/fsck はこう。
# PROVIDE: fsck # REQUIRE: localswap $_rc_subr_loaded . /etc/rc.subr name="fsck" start_cmd="fsck_start" stop_cmd=":" fsck_start() { # # ファイルがある場合は帰る # if [ -e /fastboot ]; then echo "Fast boot: skipping disk checks." return fi trap : 2 # Ignore SIGINT, SIGQUIT, so we trap : 3 # enter single-user mode on failure. echo "Starting file system checks:" fsck -x / $fsck_flags handle_fsck_error "$?" } load_rc_config $name run_rc_command "$1"
/etc/rc.d/root はこう。
# PROVIDE: root # REQUIRE: fsck_root $_rc_subr_loaded . /etc/rc.subr name="root" start_cmd="root_start" stop_cmd=":" root_start() { umount -a >/dev/null 2>&1 mount / # # 問答無用で削除 # rm -f /fastboot } load_rc_config $name run_rc_command "$1"
/etc/rc.d/fsck_root はこう。/etc/fstab を処理するらしい。
# PROVIDE: fsck_root $_rc_subr_loaded . /etc/rc.subr name="fsck_root" start_cmd="fsck_root_start" stop_cmd=":" fstab_file=/etc/fstab fsck_root_start() { if [ -e /fastboot ]; then echo "Fast boot: skipping disk checks." return fi trap : 2 # Ignore SIGINT, SIGQUIT, so we trap : 3 # enter single-user mode on failure. # Do nothing if root file system has fs_passno=0 in /etc/fstab, # or if root file system is not mentioned in /etc/fstab, or if # root file system seems to be a network mount. root_in_fstab=false while read fs_spec fs_file fs_vfstype fs_mntops fs_freq fs_passno do # skip comment or blank line case "${fs_spec}" in \#*|'') continue ;; esac # fs_freq and fs_passno default to 0 if not specified : ${fs_freq:=0} ${fs_passno:=0} case "${fs_file},${fs_passno}" in /,0) echo "Not checking /: fs_passno = 0 in ${fstab_file}" return ;; /,*) root_in_fstab=true case "${fs_spec}" in *:*) echo "Not checking /: network mount" return ;; esac ;; esac done < "${fstab_file}" if $root_in_fstab; then echo "Starting root file system check:" fsck $fsck_flags / handle_fsck_error "$?" return else echo "Not checking /: not listed in ${fstab_file}" fi } load_rc_config $name run_rc_command "$1"
/etc/rc.d/* のスクリプトを呼び出しているのは /etc/rc である。読む。
/etc/rc
# # ディレクトリにあるスクリプトを実行する # for _rc_elem in $files; do print_rc_metadata "cmd-name:$_rc_elem" run_rc_script $_rc_elem start print_rc_metadata "cmd-status:$_rc_elem:$?" done
スクリプトはファイル名順に run_rc_script に渡される。PROVIDE や REQUIRE を考慮したうえでスクリプトを実行するのだろう。
/etc/rc.d/root は /etc/rc.d/fsck_root を REQUIRE しているので
- /etc/rc.d/fsck_root
- /etc/rc.d/root
という順番で呼ばれると思われる。
_ [NetBSD]/usr/bin/cleantags を読む
RCS のタグから $ を削除。$Author は Author になる。どこで使うのかしらん。
#!/bin/sh # $NetBSD: cleantags.sh,v 1.2 2011/12/25 23:31:22 christos Exp $ # Remove the $'s from rcs tags PROG="$(basename "$0")" PAT='\$(Author|Date|CVSHeader|Header|Id|LocalId|Locker|Log|Name|RCSfile|Revision|Source|State|NetBSD)' verbose=false # # ここでひたすら置換する # dosed() { sed \ -e 's/\$\(Author.*\)\$/\1/' \ -e 's/\$\(Date.*\)\$/\1/' \ -e 's/\$\(CVSHeader.*\)\$/\1/' \ -e 's/\$\(Header.*\)\$/\1/' \ -e 's/\$\(Id.*\)\$/\1/' \ -e 's/\$\(LocalId.*\)\$/\1/' \ -e 's/\$\(Locker.*\)\$/\1/' \ -e 's/\$\(Log.*\)\$/\1/' \ -e 's/\$\(Name.*\)\$/\1/' \ -e 's/\$\(RCSfile.*\)\$/\1/' \ -e 's/\$\(Revision.*\)\$/\1/' \ -e 's/\$\(Source.*\)\$/\1/' \ -e 's/\$\(State.*\)\$/\1/' \ -e 's/\$\(NetBSD.*\)\$/\1/' \ "$1" > "/tmp/$PROG$$" && mv "/tmp/$PROG$$" "$1" if $verbose then echo "$1" fi } usage() { echo "Usage: $PROG [-v] <files>|<directories>" 1>&2 exit 1 } while getopts "v" f do case "$f" in v) verbose=true;; *) usage;; esac done shift "$(expr "$OPTIND" - 1)" if [ -z "$1" ] then usage fi # # 指定された引数をひたすら処理する # for i do if [ -d "$i" ] then # # find と while と read の組み合わせは試験に出る # find "$i" -type f -print0 | xargs -0 egrep -l "$PAT" | while read f do dosed "$f" done elif egrep -qs "$PAT" "$i" then dosed "$i" fi done
_ [NetBSD]/usr/bin/zdiff と /usr/bin/zcmp を読む
中身は同じ。
% diff -u /usr/bin/zdiff /usr/bin/zcmp
スクリプト冒頭で自分がどのスクリプトとして呼ばれたのかを判定し、処理を変える。こういう仕組みは zcmp や zdiff 以外にもいろいろなところで使われている。gcc もそうだっけ。
# Set $prog based on $0 case $0 in *cmp) prog=cmp ;; *) prog=diff ;; esac
スクリプトに与えられた引数の拡張子によって展開に使うコマンドを変える。
check_suffix() { case "$1" in *[._-][Zz]) setvar $2 "${1%??}" setvar $3 "gzip -cdqf" ;; *[._-]bz) setvar $2 "${1%???}" setvar $3 "bzip2 -cdqf" ;; *[._-]gz) setvar $2 "${1%???}" setvar $3 "gzip -cdqf" ;; *[._-]xz) setvar $2 "${1%???}" setvar $3 "xz -cdqf" ;; *[._-]bz2) setvar $2 "${1%????}" setvar $3 "bzip2 -cdqf" ;; *[._-]lzma) setvar $2 "${1%?????}" setvar $3 "xz -cdqf" ;; *.t[ag]z) setvar $2 "${1%??}"ar setvar $3 "gzip -cdqf" ;; *.tbz) setvar $2 "${1%??}"ar setvar $3 "bzip2 -cdqf" ;; *.tbz2) setvar $2 "${1%???}"ar setvar $3 "bzip2 -cdqf" ;; *.t[lx]z) setvar $2 "${1%??}"ar setvar $3 "xz -cdqf" ;; *) setvar $2 "$1" setvar $3 "" ;; esac }
# 引数のファイルが 1 つの場合は比較対象を標準入力から読む if [ $# -eq 1 ]; then # One file given, compare compressed to uncompressed files="$1" check_suffix "$1" files filt if [ -z "$filt" ]; then echo "z$prog: unknown suffix" 1>&2 exit 1 fi $filt -- "$1" | $prog $flags -- - "$files" status=$? elif [ $# -eq 2 ]; then # Two files given, compare the two uncompressing as needed # 展開に使うコマンドが filt に格納される # 展開したあとに cmp または diff を呼ぶ check_suffix "$1" files filt check_suffix "$2" files2 filt2 if [ -z "$filt" -a -z "$filt2" ]; then $prog $flags -- "$1" "$2" elif [ -z "$filt" -a -n "$filt2" -a "$1" != "-" ]; then $filt2 -- "$2" | $prog $flags -- "$1" - elif [ -n "$filt" -a -z "$filt2" -a "$2" != "-" ]; then $filt -- "$1" | $prog $flags -- - "$2" else tmp=`mktemp -t z$prog.XXXXXXXXXX` || exit 1 trap "rm -f $tmp" 0 1 2 3 13 15 ${filt2:-cat} -- "$2" > $tmp || exit $? ${filt:-cat} -- "$1" | $prog $flags -- - "$tmp" fi status=$? else echo "$USAGE" 1>&2 exit 1 fi
_ [NetBSD]/usr/bin/spell を読む
spell.sh は spellprog ( $SPELLPROG ) を呼びだす。
if [ -n "$HISTFILE" ]; then $DEROFF | sort -u | $SPELLPROG -o $TMP $STOP $STOP_LANG | \ $SPELLPROG $FLAGS $DICT $LANG $EXTRA | sort -u -k1f - $TMP | \ tee -a $HISTFILE who -m >> $HISTFILE else $DEROFF | sort -u | $SPELLPROG -o $TMP $STOP $STOP_LANG | \ $SPELLPROG $FLAGS $DICT $LANG $EXTRA | sort -u -k1f - $TMP fi
$DEROFF には deroff や detex が設定されている。roff などのタグを削除してから処理することになる。
$HISTFILE はキャッシュかと思ったがそうでもなく、たんに記録してるだけ? man spell を読む
-h spellhist Store misspelled words in the specified history file. The output of who -m is appended to the history file after the list of mis- spelled words.
今までこれだけミスったよ ( *´艸`)
という記録らしい。
2013-11-27 :-(
_ 午後
1300 コード書いTARI
2013-11-28 :-(
_ 午後
1300 仕様書読んだり || テスト設計しTARI
_ ドレッシングって自分で作れるんだっ!
( via tumblr )
おいしいドレッシングを作る大切な約束事はたった1つ、「酢が油をこえない」こと。つまり一番すっぱいドレッシングは、酢と油が同量なんです。万人向きは油:酢=2:1、塩・胡椒は適宜。あとは、サラダの材料は? 誰が食べるの?(男性か女性か、大人か子供か、若い人かお年寄りか…)、疲れているかいないか、気候は? 一緒に食べるメニューは? など、これらによって千差万別。すなわち、これが家庭の手作りドレッシングのすばらしいところ。食べる人のもろもろの条件・状況を、作る人がしっかり把握しているからこそ、いつもおいしさピッタリの味を提供できるのです。
_ [NetBSD]/etc/rc を読む まない
コメントに全部書いてある。
たとえば rc_real_wark のコメント
# # rc_real_work # Do the real work. Output from this function will be piped into # rc_postprocess(), and some of the output will be marked as # metadata. # # The body of this function is defined using (...), not {...}, to force # it to run in a subshell. # rc_real_work() (
たとえば rc_postprocess のコメント。
# # rc_postprocess # Post-process the output from the rc_real_work() function. For # each line of input, we have to decide whether to print the line # to the console, print a twiddle on the console, print a line to # the log, or some combination of these. # # If rc_silent is true, then suppress most output, instead running # rc_silent_cmd (typically "twiddle") for each line. # # The body of this function is defined using (...), not {...}, to force # it to run in a subshell. # # We have to deal with the following constraints: # # * There may be no writable file systems early in the boot, so # any use of temporary files would be problematic. # # * Scripts run during the boot may clear /tmp and/var/run, so even # if they are writable, using those directories too early may be # problematic. We assume that it's safe to write to our log file # after the mountcritlocal script has run. # # * /usr/bin/tee cannot be used because the /usr file system may not # be mounted early in the boot. # # * All calls to the rc_log_message and rc_log_flush functions must be # from the same subshell, otherwise the use of a shell variable to # buffer log messages will fail. # rc_postprocess()
すごく...丁寧です...
2013-11-30 :-)
_ 夜
1700 寝る
1800 賃貸を眺めたり
2100 飯
2200 攻殻機動隊ARISE -GHOST IN THE SHELL- 第 1 話を録画したので見ていた。さすがに声はオリジナルのほうが馴染みがある。
_ ,
以前の上司( どこぞの Debian パッケージのメンテナをやっていた )からは「私と同じくらいの仕事が出来たら昇給を推薦してやる」と言われたことがあるんだが、半分は冗談だろうけどい半分は本気で言ってそうなのでメンテナになればいいじゃない
_ ,
いいから黙ってコード書けよハゲ
_ ,
いいから黙ってコード読めよハゲ
_ ,
手元の ChangeLog メモを眺めていたら mput さんの日記からのコピペがあったんだが、ところで mput さんのところにつながらない。
* tDiary] 低・負・荷! 低・負・荷! 08:19 - mputの日記。 (2004-02-28) http://mput.dip.jp/mput/?date=20040228#p01 tdiary をプロファイル % cd ~/public_html/diary % sudo -u www sh -c 'echo "" | ruby -rprofile index.rb 1>/dev/null'
_ fallenangel [アルティメットまどかと悪魔ほむらのシルエットってさ、ridge racerシリーズのangelusまたはarchan..]
_ みわ [いやあ割りとよくあるシルエットなんじゃないかなあ http://www.bandainamcogames.co.jp..]