チラシの裏は意外と白くない

最近忘れっぽくなったので調べたことをチラシの裏に書きます

見ず知らずの人のお通夜にいく

夜中、父がどこかに電話している声で目が覚めた

尿意を感じてトイレに起きたところ、和室に布団が敷き詰められいて、見ず知らずの人たちが10人近く寝ている。なかには着物姿のおばあさんもいる

トイレまでの動線確保が大変だ。一体何事なんだろう

 


トイレから戻ると、人々が起き出してきている。先程は気づかなかったが男性はスーツ姿だ

 


自室に戻ると、部屋が勝手に片付けられていてゴミが外に出されている

ビールの空き缶はキッチンに出されている。また母に嫌味を言われると考えるとうんざりだ

なぜか整理整頓までされていて、自分のものが一体どこにあるのかわからない

 


起き出した人々とうちの家族との会話から、どうやら、

・妹の旦那の親族が亡くなったらしいこと

・会場の都合で、明け方に出発すること

・寝ていた人は早朝出発に備えて前泊している向こうの親族らしいこと

がわかった


いよいよ出発の時間だ

だが、携帯が見つからない。整理されたときにどこかにやられたのか?隠されたのか?

時間がない。持って行くのは諦めるしかないか

 


スーツに着替えて玄関に向かうも、今度は革靴が見つからない

探しながら革靴の利便性のなさをディスりまくった

高くて手入れが必要で歩きにくい

しかし残念ながら誰からも同意を得られない。いつものことだ

 


靴を探している間に、向こうの親族がどこかから車を借りて来た

もともと電車で行くと言う話だったが、革靴探しに手間取っている間に、うちの車と二台体制で式場に行くことにしたらしい

 


ようやく革靴が見つかったが、長く手入れをしていないためにボロボロだ

さすがにみすぼらしいので、道中で調達することになった

 


玄関を開けると雨だ。それも豪雨。そのこともあって車でいくことに変更したのか

当然だが向こうの親族ばかりなので、うちの車にも何人か向こうの親族が乗り込んでいる

見ず知らずの人を乗せて運転するなど気が重い

 


ところで携帯がないから、今日、会社を休むことを連絡ができないのだった

なんで前もって直接教えてくれなかったのか尋ねると、昨晩はお前が部屋で酒飲んでいたから言いづらかったのだと逆におこられた

そう言う問題ではないのではないか

大体そうならば晩酌のアルコールが抜けきっている保証もないのに、車を出せなどとよくいえたものだ

 


父がカメラを持ってきた。式が終わったら集合写真を撮るつもりらしい

それならいいカメラを持っていってはどうかと一眼レフを渡す

携帯は見つからないのに、カメラはすぐに見つかった

 


いよいよ出発だ

道中、早朝でも営業しているスーパーを見つけたので、店の前に車をつける

開店前ということで、駐車場と一階の一部の売り場だけが営業しているようだ

革靴を見つけた。7万ちかくもする

革靴なんて好き好んで履かないのだから、もっと安いもので十分と思ったが、ブランドものでお買い得だからと母に強力に勧められる

どうでも良くなったので買うことにした

合うサイズが在庫しているといいのだが

 


自分のサイズの箱が見つかった。次は試着だ

靴箱の中にはやたら緩衝材が入っていたので、靴を取り出すのに苦労した。

どうせ多少合わなくても買わざるを得ないのだ、と半ば開き直って取り出したところ一部の包装が破れてしまった

 


幸いサイズは問題ない。時間もないので、箱には戻さず、そのままレジにもっていく

店員がいやらしい笑みを湛えながらあなたには売れない、と言う

このスーパーのクレジットカードで支払う人、もしくは駐車場利用者だけのための早朝営業らしい

一般客は開店後にしか物を買えないらしい

 


購入を断られた革靴を箱に戻すが、なかなかうまく戻らない

一部梱包材を破って取り出したのだ。綺麗に戻るはずがない

 


破らなければよかったな、もしくは路駐しないでちゃんと駐車場に停めれば買えたのに

いや、そもそもちゃんと革靴の手入れをしておけばこんなことにならなかった

後悔はつきない

 


しかし理不尽だ

購入できる人が限定されるなら、入り口でチェックすべきだし、靴を取り出そうと四苦八苦してる最中にも声をかけるタイミングはあっただろうに

そもそもあの店員の腹立たしい笑顔、理不尽な態度はなんだ?

しかし、それに対して喧嘩を売らなかった自分は偉い

波風立てないのが一番だ

 


やっぱり破ったところのせいで箱が組み上がらない

もういい加減に出発せねば間に合わない時間だ。夜が明けてきた

そういえば腕時計も付け忘れてきたから正確な時間もわからない

 


先程は理不尽に対して怒らなかった自分を褒めたが、やはり違う

理不尽にたいして怒らず、ああして反射的に愛想笑いをするようだから仕事でも漬け込まれるのだ

そうだ、そもそもこの状況が全てを表しているではないか

なぜ向こうの親族のお通夜に行く段取りをうちがして

なぜ会社を休んでまで車を出さねばならぬのか

理不尽とは戦わねばならないのだ

 


などと考えながら、箱詰め作業をしていると店外から声が聞こえる

向こうの親族を乗せたクルマからだ。きっと早くしろと言っているのだ

大声出さずに電話でもすればいいものを、嫌だなああ言う人種は

ああそうか、そういえば携帯は隠されていたから、持って来るのを諦めたのだ

そしてそれは会社に連絡できず、今日は無断欠勤をするということなのだ

 


もう理不尽な箱詰めはやめよう

どのみち二度と来ないスーパーなのだ

もう店を出よう

見ず知らずの人のお通夜にいくために

戦国北条記1

室町時代の発足〜南北朝統一

室町幕府の前の幕府でにあたる鎌倉幕府は、後醍醐天皇によって滅ぼされる(建武の新政)。これにより政権が再び幕府から朝廷に戻されるも3年ほどで足利尊氏によって打倒される。1336年に足利尊氏を初代将軍とする幕府が室町幕府ということ。

このとき、戦に負けた後醍醐天皇は京都から奈良県の吉野に脱出。尊氏は後醍醐天皇の後継として光明天皇を擁立する。そのため室町時代初期は京都の北朝、奈良の南朝と二つの朝廷が並立する事態となった。この並立した時期を南北朝時代とよぶ。鎌倉時代南北朝時代室町時代南北朝時代を含めて室町時代とする広義の解釈もある。

朝廷が二つ存在するため、勢力争いが絶えず、また足利政権内部での争いも多く、初代・尊氏の時代から室町時代は不安定な時代だったらしい。この南北朝の統一は、3代将軍・足利義満の時代に果たされ、この時期が最も安定した時代で、北山文化が栄えた。

北山文化とは、北山山荘を中心に展開された文化で、のちの8代将軍・足利義政の時代に発展した東山文化に対して、そう呼ばれる。北山文化はとにかく派手で、金閣寺が有名。脳や狂言といった文化もこの時代に発展した。調べてみて、確かにこの辺は中学で習った記憶がある。

室町幕府の衰退へ

6代将軍・足利義教が謀殺されることで、室町幕府は衰退の一途をたどり始める。この義教、もともと青蓮院に入れられてお坊さんをしていたところをくじ引きで当選したために将軍になったのだとか。そういう事情もあって帝王学を学んでおらず、強引なやり方で政治を進めた。有力守護大名の相続問題に口を出したり、鎌倉公方(後で出てくる)の足利持氏を滅ぼし、専制化を進める義教に危機感を抱いた、播磨・美作・備前国守護の赤松満祐によって殺されてしまう。嘉吉の乱

守護というのは、幕府から命じられてその地の軍事、警察、御家人の統率を行う役割ということで、まあ都道府県知事的な感じで考えておけば良いか。守護のうち力をつけたものが守護大名と呼ばれ、のちの時代に登場する、自分の実力で国を支配した戦国大名との対比になっている。

この嘉吉の乱を鎮圧したのが細川氏・山名氏であった。以後、両氏によって幕府の運営がなされていく。続いて、8代将軍足利義政の時代。飢饉や守護大名の悪政によって、一揆が頻発していた時代に、新室町殿というとんでもない豪邸を建てたことなどもあり、応仁の乱に繋がっていく。

応仁の乱

応仁の乱の主人公というのが、細川勝元山名宗全らしい。嘉吉の乱を鎮静した細川氏、山名氏の末裔。細川氏は土佐、讃岐、伊予、丹波、摂津の守護。山名氏は但馬、備後、安芸、伊賀、播磨の守護。当初、義政・勝元・宗全は牽制しつつも平穏を保っていた。 この頃、義政に変わって政所執事伊勢貞親が政治を主導した。政所というのは、幕府のお金を管理するもので、まあ大きな権力を持っていたということ。この伊勢氏が北条早雲の出自である備中伊勢氏の本家にあたる。ということで、この時点で北条早雲=伊勢氏は幕府側

この伊勢貞親、幕府の専制を推し進めるために、各地の守護大名家督争いに介入したりすることで守護大名の勢力を削減しようと小細工を働いていた。本の中では大局観のない小才子タイプと評されている。この動きに対して、細川勝元山名宗全両氏が手を組んで対抗していた。

この頃、将軍家にも後継者問題が発生していて、

  1. 当時、男子のいない義政は自分の弟、義視を後継予定者とする
  2. が、翌年に義政に義尚という子供が生まれる
  3. そのさらに翌年、義視に義材という子供が生まれる
  4. 伊勢貞親が義視親子を失脚させるべくデマを流す
  5. 4について細川勝元が糾弾し、結局義政から貞親に対し切腹が命じられる
  6. 貞親は一旦身を隠し、子息の貞宗を代理に立てて勢力挽回に努める

というゴタゴタがあった。文政の政変という。

さらにそうこうしているうちに、同時並行的に細川・山名両氏の関係が悪化し、二つの勢力に分裂していく。また、農業生産性の向上によりこれらに関係ない各地の守護も勢力を拡大、こうして応仁の乱へと進んでいく。応仁の乱では、足利義視細川勝元山名宗全が活躍する。義政はというと、伊勢貞親を追放したおかげで、権力を行使する手段を失い、東山山荘の造営などの文化事業を進め、これがのちに東山文化と呼ばれる。銀閣寺も東山文化の建造物の一つ。銀閣寺建立時は幕府が貧乏で、銀箔を貼れなかったと習った記憶があるが、なるほど納得。かくして、応仁元年1467年に東軍細川・西軍山名の武力衝突が始まる。

同年、事態を収集させるべく義政は貞親を許して元の座に戻し、東軍・細川を支持する。自分を陥れようとした貞親を許せない義視は西軍・山名に加担。これにより、義政・勝元vs.義視・宗全という構図が出来上がる。

伊勢新九郎盛時、のちの早雲庵宗瑞

北条早雲その人である。伊勢の素浪人(主君のいない武士)というのが長らくの定説だったが、上述の通り伊勢氏の分家である備中伊勢氏の出身であることが近年判明した。父は伊勢盛定、母親が本家で、貞親の兄弟にあたる。

この時代の地方の考え方

ところで、赤松氏が統治する播磨、美作、備前について、地理関係を整理しておく。

播磨といえば兵庫の南西部、美作は岡山の北東部、備前は岡山の南東部でこの3国は隣接している。この辺の守護を行なっていたのが赤松氏であると。

脇道に逸れるが瀬戸内海沿いに京都から見て順番に備前、備中、備後だ。前中後で分けた地名というと、越前、越中、越後が思いつく。越後、つまり新潟をさらに細分化して今度は上中下、すなわち上越中越下越。東京起点だとピンと来ないものだが、京都を起点に考えるとわかりやすい。

ちなみにこれらの国は山陽道に属するらしい。兵庫南西部から岡山、広島、山口にわたる、瀬戸内海に隣接する地域を示す言葉だとか。この山陽道はさらに五畿七道というの一つで、行政区画を表している。国=都道府県、地方=五畿七道くらいに考えておこう。ただ、現在は各都道府県にひとりの長だが、当時は複数の都道府県をまとめて一人で納めていた感じか。

都の周辺を畿内と呼び、五畿とは、

  • 大和:現在の奈良県に相当。大国。
  • 山城:やましろのくに。奈良から見て奈良山(京都・奈良の県境)の裏側であることから。京都の南部に相当。
  • 摂津:大阪北部と兵庫南東部。河内国和泉国を合わせて大体今の大阪府か。
  • 河内:大阪東部
  • 和泉:大阪南部

地方を道と呼び、七道とは、

さらに明治維新後に北海道が加わり、五畿八道とも呼ばれる。こうしてみると、京都から見た命名であるからし中部地方から東側の分け方が非常にざっくりしている。東京から見たら山陽も山陰もあんまり変わらないじゃないか、というのと同じか。

f:id:samurai375:20210606110707p:plain

歴史の本を読んでみようと思った話

昨今の状況から遠出はできないので、ここ最近はひたすら近場を自転車に乗ったり散歩したりしている。少し足を伸ばして東京の端の方、あるいは近隣県をぶらぶらしていると、まあ小高い丘とかちょっとした森が現れて、調べてみると城跡だったということがしょっちゅうある。 で、暇なのでどんな城なのか調べてみると、大体北条氏に滅ぼされた、とある。あっちの城もこっちの城も、いつ建てられたのかわからない城も、城主は誰なのかわからない城も、とにかく北条氏に滅ぼされたことだけは確か、と言う具合だ。と言うわけでコロナのせいですっかりアンチ北条氏になってしまった。

北条といえば北条政子とか北条時宗とか?そもそもこの人たち、名前は知ってるけどいつどこで何した人たちだっけ?というので、中学生並み(いや、それ以下?)の歴史の知識のなさが悲しい。ちなみに出身のアホ高校は当時流行りの履修漏れで世界史Aしか履修していない。もっとも、その世界史の知識すら非常に怪しいものだが。 悲しいやら情けないやらなので、少し調べてみることにした。その辺の城を滅ぼしたのは北条政子の北条ではなく、後北条氏と言われる人たちのようだ。ちなみに北条政子源頼朝の奥さんらしい。源頼朝は流石に知っている、いい国作ろう鎌倉幕府。この北条氏の後裔、つまり子孫ではないため後北条氏と呼ばれるそうだ。

後北条氏とは北条早雲からの五代を指すらしく、北条早雲小田原城にいたらしい。箱根登る途中の早雲山の早雲か?時代は室町時代後期ということ。室町時代について知っていることといえば、鎌倉時代の次であること、足利氏、それから応仁の乱。教科書で言うと、応仁の乱がどうこうしているうちに、室町時代はうやむやになって安土桃山時代に突入していたように思う。安土桃山時代は何幕府なんだ?と中学の頃思いながらも、教科書に書いてあること以上踏み込まなかった、というか興味を持てなかった当時の自分に悲しくなる。 そもそも中学の歴史の授業というのは、とにかく年表を追うことだけで結局それがどこで起きたのかがよくわからなくて、不満に思った記憶がある。まあ空間的な内容があったとしても、江戸時代になるまでは縁もゆかりもない京都が中心だからやっぱり興味は持てなかっただろうが。

まあ、そういうわけで室町時代の後期、歴史の教科書に登場する、幕府のある京都でも奈良でもなく、当時の関東地方で後北条氏がうちの近所の城を滅ぼしまくったということがわかった。後北条氏について調べてみるべく戦国北条記という本を買ってみた。

www.amazon.co.jp

買って、ちょっと目を通してみたものの日本史に関する基礎知識が無さすぎて、ちんぷんかんぷんで1ページ読むのも苦痛だ。書いてあることが理解できないのと、多分序盤の北条早雲が登場する前だからだろうか、とにかく登場人物が多く、ものすごい速さで、それも京都と関東を行ったり来たりするものだから頭がこんがらがってしまう。読書に対してあまり苦手意識はないが、これはきつい。そういうわけで、ここにメモを書きつつ読み進めることにした。最後まで読み切れるかは不明。

pythonからC++を呼び出して、jsonファイルをやり取りする②

前回、C++で書いた関数をpythonモジュールにして、それをpythonから呼び出すプロトタイプを作成した。続いて、jsonファイルをやり取りする方法を検討する。C++向けのjsonパーサとしてはjansson,picojson等いろいろあるのだが、janssonが直感的でAPIリファレンスがしっかりしているらしいので、これを使ってみることにする。

環境構築

janssonの公式ページ?を参考にインストールを行う。 jansson.readthedocs.io

janssonのmake

以下のサイトから最新のtarballをゲット。今回利用したのは2.13。

digip.org

今回、いろいろな事情で環境側(/usr/include, /usr/lib)に組み込めない想定のコンパイル環境を構築する必要があるため、--prefixでローカルのディレクトリを指定。ちなみにmake checkをするとテストコードのmakeルールが定義されていないとか何とかでエラーするが、とりあえず使えているので気にしないことにしておく。。

$ tar zxvf jansson-2.13.tar.gz
$ cd jansson-2.13
$ ./configure --prefix $PROJ_ROOT_PATH/lib/jansson
$ make 
$ make install

上記で、$PROJ_ROOT_PATH/lib/jansson以下にincludeとlibができる。

setup.pyの変更

janssonをローカルのディレクトリに展開したため、コンパイルオプションを追加する必要がある。makefileで#

  • -I$PROJ_ROOT_PATH/lib/jansson/include
  • -L$PROJ_ROOT_PATH/lib/jansson/lib
  • -ljansson

に相当するものを、setup.pyに追加する。 調べたところ、次のように書けばよいらしい:

setup(
    name = 'my_arith', 
    version = '1.0.0', 
    ext_modules = [
        Extension(
            'my_arith',['core.cpp'],
            include_dirs=[os.environ['PROJ_ROOT_PATH']+'/lib/jansson/include'],  # 追加
            library_dirs=[os.environ['PROJ_ROOT_PATH']+'/lib/jansson/lib'],      # 追加
            libraries=['jansson']                                                # 追加
            )],
)

なお、$PROJ_ROOT_PATHはあらかじめ環境変数にセットした状態で、setup.pyを呼ぶことを想定している。

まとめ

  • janssonのインストールを行った
  • setup.pyでインクルードパスとライブラリパスを指定する方法を調査した
  • 次はpythonとのAPI部とは切りはなして、janssonの詳細を見ていく

pythonからC++を呼び出して、jsonファイルをやり取りする①

背景

  • 新しいデータベースの形としてjsonを採用した
  • jsonといえばpython
  • 過去資産はC++で書かれているし、bit精度を考慮するとC++を使いたい

というようなせめぎあいの結果、とりあえず方式を調査することに。 あとで絶対わからなくなるので、ここにまとめることにする。

なお、Pythonは3.x系を対象とする。手元の環境ではPython 3.6.8。

方針

大きく2点の課題を解決する必要がある。

  1. pythonからC++の関数を呼び出す方法
  2. C++jsonを解釈する方法

調べたところ、それぞれいくつかの方法はあるようだが、どれをとっても面倒な感じだ。とりあえず、

  • 課題1に対してはpython公式のAPI(Python.h)を利用
  • 課題2に対してはjassonというC++用のjsonパーサを利用

という作戦で進めたい。

まずはpythonからAPIを介してC++関数を呼び出す方式の調査と、プロトタイプ実装から。

pythonからC++を呼ぶ方法:Python.hを利用

大きな流れは、

  1. C++側(core.cpp)でPython APIであるPython.hをインクルード
  2. 処理本体と(Pythonの)モジュール化のためのwrapper記述を追加
  3. 共有ライブラリ(.so)としてコンパイル
  4. python側でモジュールとしてimportして利用

f:id:samurai375:20210120130025j:plain

ということのようだ。大きいのは2番と3番。

Python.hのインクルード

手元の環境ではPython.hは以下のパスに存在した。

/usr/include/python3.6m/Python.h

ただ、後述するsetup.pyを用いてコンパイルを実行することで、このパスを明示的に指定する必要はない。

python用wrapper記述

C処理本体

int c_add(int num1, int num2){
    int res = num1 + num2;
    return res;
}

int c_sub(int num1, int num2){
    int res = num1 - num2;
    return res;
}

int c_mul(int num1, int num2){
    int res = num1 - num2;
    return res;
}

int c_div(int num1, int num2){
    int res = int(num1 / num2);
    return res;
}
  • 処理本体は基本的にそのままC++で記述すればOK
  • 引数や戻り値については、wrapper部を対応した記述に変更する必要がある
    • あらゆる型を取ることができるかは要調査
    • ユーザ定義した構造体のポインタとかも利用可能?

python wrapper

static PyObject *py_add(PyObject* self, PyObject* args){
    int num1, num2, res;

    if(!PyArg_ParseTuple(args, "ii", &num1, &num2)) return NULL;
    res = c_add(num1,num2);
    return Py_BuildValue("i",res);
}
  • cpp関数を呼び出すpython wrapper
    • py_addという名称にしている
  • 4行目で引数のチェックを行う
    • "ii"はint型引数を2つ取り、
    • それぞれがnum1, num2に対応する
    • 引数が不正ならNULLを返して抜ける
  • 5行目でc_addにnum1,num2を渡して、結果をresで受ける
  • 6行目でint型のresを返す
  • py_sub,py_mul,py_divも同様のため省略

メソッド登録

static PyMethodDef my_arith_methods[]={
    {"add", py_add, METH_VARARGS, "return num1 + num2"},
    {"sub", py_sub, METH_VARARGS, "return num1 - num2"},
    {"mul", py_mul, METH_VARARGS, "return num1 * num2"},
    {"div", py_div, METH_VARARGS, "return int(num1 / num2)"},
    {NULL}
};
  • 各メソッドの
    • 要素1,2番目:上記でwarpした関数"py_add"を"add"というメソッド名で登録
    • 要素3番目:引数によって変わる。いくつかあるので継続調査
      • METH_NOARGS: 引数無し
      • METH_VARARGS: 可変長引数
    • 要素4番目:メソッドの説明。任意
  • 最終メソッドはNULL

モジュール定義

static PyModuleDef my_arith = {
    PyModuleDef_HEAD_INIT,
    "my_arith",                 // モジュール名
    "arithmetic operations",    // モジュールの説明
    -1,
    my_arith_methods
};
  • 1行目がモジュール名となる。今回my_arith。
  • 構造体のメンバーで
    • 1番目はおまじない
    • 2番目はモジュール名。1行目と合わせておく
    • 3番目はモジュールの説明
    • 4番目はおまじない
    • 5番目はメソッドリスト名と合わせておく

初期化処理

PyMODINIT_FUNC PyInit_my_arith(void){
    return PyModule_Create(&my_arith);
}
  • 初期化処理で関数名はPyInit_<module名>
  • 戻り値はPyModule_Create($<module名>

共有ライブラリ化

  • g++ ...でビルド記述をべたに書くこともできるが、setup.pyを使うのが楽そう

setup.py記述

from setuptools import setup, Extension

setup(
    name = 'my_arith', 
    version = '1.0.0', 
    ext_modules = [Extension('my_arith',['core.cpp'])]
)
  • 基本的にモジュール名を変更するだけ
  • my_arith.soができる
  • ソースコードが複数ある場合は、['core.cpp', 'srcA.cpp', 'srcB.cpp'…]と続ける

setup.py実行

$ python3 setup.py build
  • setup.pyと同じ階層にbuild/ディレクトリが生成される
  • 以下のような階層構造となり、my_arith.cpython-36m-x86_64-linux-gnu.soが共有ライブラリ
  • いろいろついてしまうので、上位階層に持ってきてシンプルにmy_arith.soに名前を変えておく
.
├── build
│   ├── lib.linux-x86_64-3.6
│   │   └── my_arith.cpython-36m-x86_64-linux-gnu.so
│   └── temp.linux-x86_64-3.6
│       └── core.o
├── core.cpp
└── setup.py

pythonから呼び出し

ソースコード

from core import my_arith

def main():
  num1 = 6
  num2 = 3

  print(my_arith.add(num1,num2))
  print(my_arith.sub(num1,num2))
  print(my_arith.mul(num1,num2))
  print(my_arith.div(num1,num2))

  return 1

if __name__=='__main__':
  main()
  • coreディレクトリ以下のmy_arithモジュールをインポート
  • my_arithモジュールのadd,sub,mul,divメソッドを呼び出し
    • wrap関数名ではなく、メソッド登録時の名称を使用する

実行結果

$ ./top.py 
9
3
3
2
  • というので、無事四則演算ができている

ちなみに

  • pythonからhelp(my_arith)をすると、以下の通りモジュールのヘルプが表示される
  • モジュール定義の章で記載した説明が、モジュールの説明として表示される
  • メソッド登録時の説明が、各FUNCTIONに表示される
Help on module core.my_arith in core:

NAME
    core.my_arith - arithmetic operations

FUNCTIONS
    add(...)
        return num1 + num2
    
    div(...)
        return int(num1 / num2)
    
    mul(...)
        return num1 * num2
    
    sub(...)
        return num1 - num2

FILE
   arith/core/my_arith.so

まとめ

  • とりあえず単純なint型引数2つを四則演算して、int型戻り値を返すC++関数をpythonモジュール化してpythonから呼び出し利用した
  • C++関数として、どこまでの引数や戻り値に対応しているか。特にポインタを取り扱えるか、は継続調査
  • pythonに関して、今回でいえば特にモジュール周りの体系的な知識がないので時間があるときに勉強しておく
  • 続いて、C++用のjsonパーサであるjanssonの調査を行う

MTBの油圧ブレーキ化⑦

ブレーキ交換に伴い、不本意ながら切断したシフトの復活。アウターケーブルはそのまま使おうと思ったけど、チェーンステー・リアディレイラー間のケーブルに割れがあったので、ここだけ交換。 リアはローノーマルという不思議仕様なのだが、トップノーマルの普通のリアディレイラーと同様にあっさり調整完了。いまやローノーマルのディレイラーなんてないから、そもそもノーマルという単語自体が死語に近い気もするが、ノーマル状態=ワイヤーテンションがない時のディレイラー位置のことで、今のリアディレイラーはワイヤーテンションがないとトップ側にいて、ワイヤーを引くことでロー側にチェーンを上げていく。ローノーマルはこの逆で、テンションがかかっていない時ローにいて、テンションをかけるとチェーンがトップギア方向に落ちていく。いま見ると非常に奇妙だ。

だが、MTBSTIにおいては、ローノーマルの採用は必然といえる。というのも

  • フロント:ワイヤーを引くと重くなり、緩めると軽くなる

  • トップノーマルのリアディレイラー:ワイヤーを引くと軽くなり、緩めると重くなる

だが、これを実現しようとすると、STIの上下操作が逆になる。ロードも同様ではあるが、操作するレバー数が変わるだけで、手首の返し方が逆になるわけではない。だがMTBSTIではどうだろう。これが逆になると、フロントは重くするのにブレーキレバーを押し下げる一方で、リアは押し上げなければいけない。慣れればどうということはないのかもしれないが、非常に混乱しそうだ。というので、ローノーマルという今や異端のリアディレイラーを使って、

  • フロント:ワイヤーを引くと重くなり、緩めると軽くなる

  • ローノーマルのリアディレイラー:ワイヤーを引くと重くなり、緩めると軽くなる

を実現している。のだと思う。

一方、フロントはトリプルでなかなか大変。最初に買ったクロスバイクがフロントトリプルだったが、調整が非常にシビア。我流でやっていたが、今回はちゃんとマニュアルを読んだ。フロントディレイラーの型番はFD-M580。

最初はワイヤーテンションかけずに、リアをローにしてインナー側のプレート位置を調整。ここはいつもどおり。 f:id:samurai375:20201010164251p:plain

ワイヤーを取り付けて、リアをトップにしてアウター側のプレート位置を調整。ここもいつも通り。ところでここもなんだか不思議で、普通フロントシフトワイヤーはBB側から引き上げるのだが、このフレームは上から。トップルートタイプというらしい。

f:id:samurai375:20201010164539p:plain

さて、ここからが気をつけるところ。ミドルギアの調整という工程があるらしい。フロントを中間にして、リアをロー側に。この状態でインナー側のプレートを、アジャスタボルトを使ってギリギリまで寄せる。この工程は知らなかった。ロードではリア変速の調整に使ったりしていたが、フロントでのアジャスタボルトの正しい使い方なのか。

f:id:samurai375:20201010164801p:plain

今回はこれでうまくフロントが入るようになったので、読まなかったがトラブルシューティングがあったので、今後のためにここに転載しておく。

f:id:samurai375:20201010165136p:plain

ということで、これでブレーキ交換とそれに伴うシフトワイヤー交換が完了。しばらく通勤で使ってエアが抜けていくことを期待。

MTBの油圧ブレーキ化⑥

さっそくブリーディング。フロントはバイクをリフトアップしなくてもできそうなので、こちらから。パッドは外して、ブリード用のスペーサをかませておく。 f:id:samurai375:20201010155144j:plain

ブリードニップルを1/8回転緩めた状態で、フルード排出時に使用したプラ瓶とチューブを接続。その上で上から新しいフルードを注入。ブリーディングキットに入っていたじょうごがちょうどよかった。ちなみにこのじょうご、オイルファンネルという名前らしい。かっこいい。 とりあえずリザバータンクが満たされた状態だが、ブリードニップル側からはまだフルードが排出されない。 f:id:samurai375:20201010155416j:plain

というのでレバーを握ったり離したり。握ると一気に液面が下がって、エアを噛んでしまった…なんて恐れていた事態にはならず、むしろ全然入っていかないくらい。しばらく格闘して、ようやくブリードニップル側からフルードが出てきた。 f:id:samurai375:20201010155357j:plain

マニュアルではフルードが継続的に出てくるようになったらブリードニップルを閉めよ、とあるが大きな気泡を含まない状態になったところで閉じてみた。再度リザバータンクを満たす→ブレーキかちゃかちゃの繰り返し。気泡が少しずつ上がってきて、だんだんブレーキのあたりが出てくるようになってきた。マニュアルや他の人の作業ブログを読んだときは全然意味がわからなかったが、確かに空気が抜けてくると、明らかにあたりが出てきた。

ここからが最難関の工程。というのが、ブレーキを握りつつ、ブリードニップルを瞬間的に開け閉めせよというもの。左手でブレーキを握って、宙ぶらりんのブレーキ本体のニップルをレンチで開けて閉める。全然力はいらないし、ブレーキを握ってフルードが排出されると引き代が増えるので、左手もただ添えていれば良いというものでもない。一応これで効果的にエアが抜けるらしいが、果たして。だいたいこれ、一人でできる作業なのか?

ニップル瞬間開け閉めした後もブレーキを操作してエアを排出するも、0.1ミリくらいの気泡の発生が収束する気配がない。操作すれば操作するほど、小さい泡が出てくる。しかも泡がリザバータンクの液面まで上がりきらず、中層で止まっていたりする。ブレーキ本体を叩いてみたり、ホースを動かしたり、とりあえず10分くらいやってみるも、なかなか状況が改善しないので一旦中断。

この状態で再度リザバータンクのスレスレまでフルードを満たして、例のキャップを。怖いのでパッキンをそっと落として、プラ蓋をそっと落として、ボルトでじわじわと締め付けるように封入。やっぱりブレーキレバー周辺はビチャビチャだ。 f:id:samurai375:20201010155352j:plain

続いてリア側。やることは一緒なのだが、ホースが長いのでフロントホイールをリフトアップして作業。エアが抜けにくい上に、ホースが長いので例のブリードニップル瞬間開け閉めができない。腕が届かない、ことはないけどかなりきつい。というので、リアは輪ゴムでブレーキレバーをガチガチに引っ張った状態で。こちらもフロントと同じく、小さな気泡が消えない。

先ほどせっかく封入したフロントだが、タンクを開けてみると先ほど中層に止まっていた気泡同士がくっついて大きな気泡として液面に上がっていた。というので、リア側のエア抜きは程々にして時が解決してくれるのを待つことにした。今いくらジタバタしてもあまり効果がなさそうだ。一応フロント・リア共にリニアに力は伝達しているっぽいので、しばらく通勤に使って振動を与え続ければエアも抜けてくることを期待。