昔の最近の出来事(2019.02)

2019/02/28

早めに帰着。

あまりの眠さに急速停止。

早めに帰着。

ちょろりGTS。プロリーグ以上のイベントは時間がかかるのが 辛いです。でも、時間当たりの賞金獲得効率は上位リーグの方が 良いみたいですが。

早めに帰着。

ちょろりGTS。GTリーグで追加されたイベントを消化してみてます。 ビギナーリーグはどうにかゴールドで埋められたのですが、 アマチュアリーグの古い車限定イベントがどうにも歯が立たない 感じだったり。うーむ。

早めに帰着。

あまりの眠さに急速停止。

AM中に起床。

掃除したり洗濯したり。

以前、SixelGraphicsというものが あるのを知ったのですが、全然関係無い流れから libsixelという ライブラリ(とその中に含まれるimg2sixelというツール)と、 Cygwinのminttyで表示可能な事を知ったり (参考blogページ)。 ただ、minttyを使っても 以前知った ppmtosixel で出力を単純にターミナルに ぶちまける方法では表示できないようです。libsixelのimg2sixelで、 何かしら表示する為のシーケンスが埋め込まれているのかなぁ？と思ったり。



img2sixelは色々な画像フォーマットを読み込める上に、URLを指定 すれば直接Web上の画像ファイルも表示できるようです。また、標準入力からも読み込み可能 なので、サポートされていない画像フォーマットだとしても、ppmなどに変換 できればパイプでsixel表示可能です。Xserverの使えないような 状況で、ターミナルでちょっと画像を見たいんだけど？と思ったときに 便利かも。 そういや、4Kディスプレイでターミナルウインドウを画面の横幅半分に広げると、 ピクセル数的にはフルHD×2面分になるんだなぁ？と改めて思ったり。 というのも、まぁまぁなサイズの画像をimg2sixelで表示しても画面内に収まる ので、あれ？こんなもんだっけ？と 未だにスケール感覚がズレた感じに なります(^^;

ちょろりお出かけ。「はじめアルゴリズム(6)」を捕獲できず。なんでだ？

昼過ぎ起床。寝すぎ。

ちょろり調べ事。

ぼちぼちGTS。

早めに帰着。

Cygwinの3.0.xが来ているのですが、MailingListを読んでいると 色々地雷があるようだったので少し様子見してました。しかし、 パッケージで入れたいものがあったのでついでに入ってみたり(入れたのは32bitの3.0.1-1)。 で、入れてみたのですがEmacsを起動するとスレッドの生成に失敗したような メッセージが出てSegfaultしたり。決まった操作やタイミングで落ちる訳では ないようなので原因が良くわからず。そんな訳でCygwin 2.x系に戻したり。 2.11.2-1に戻したら落ちないので原因はCygwin本体にあると推測されますが....

早めに帰着。

調べ事をして終了。

遅めに帰着。

あまりの眠さに急速停止。

早めに帰着。

perl で以下のような書き方で同じ文字列を指定した数だけ繰り返す事が できるのを知ったり。

コード:
print "abc" x 3 . "\n" ;
print "/" . "*" x 78 . "/\n" ;

結果:
abcabcabc
/******************************************************************************/

早めに帰着。

そういやPCのリセットボタン。我が家で買ったPCには随分前から付かなくなってますが、 新しいPCで まだリセットボタンが付いたものって存在するのだろうか？と思ったり。 実際の所、OSが生きている状態でいきなりリセットボタンを押すと ファイルシステムの整合が取れなくなったりするので、 今となっては害しか無いように思われます。逆にOSなりハードの不具合で ハング状態になった場合も、リセットボタンによる復帰よりも電源ボタン 長押しによるOFF→ONの方がより確実に復帰する可能性が高いようにも 思います。ハード的な挙動で言えば、昔のパソコンとかでは、 リセットボタンを押してもメインメモリの内容が消えないという 違いがあったりするものの、システムとして使う分には OFF→ONとの 違いは無いようにも思えます。 という訳で、リセットボタンが付いているパソコンなりゲーム機は 何故リセットボタンを付けようと思ったのか？とふと思ったりも。

昼頃起床。

ここ最近、PCB(ポリ塩化ビフェニル)を使用した照明器具等の廃棄処分を 促すTVCMが流れていたり。PCBってなんぞ？と思い調べてみた所、いわゆる ダイオキシン類/ダイオキシン様 の物質という事みたい (参考Wikipedia)。 日本では1972年に生産・使用の中止が促されていたようですが、 それ以前に製造されたPCBを含む製品については、管理下に置くことで そのまま使用継続してたようです。でも、全然管理できていなくて 出回っている量が把握てきていないのが現実みたい。で、何故今になって TVCMで？という所なのですが、最終処分のリミットを2022年前後 (地域によってプラスマイナス1年の差があるようです)に設定しているらしく、 時期が迫っているというのが理由のようです (環境省のページ)。
ところで、アスベスト(石綿)なんかも同じ感じで 1990年台には建物の 壁に使われてたのを剥がしたりしてましたが、TANE自身が健康被害があると 知識として認識したのは1987年頃だったと思います。 その後、建物の壁を張り替えたりという話を聞いたりしてたので、 割と直ぐに対応されていたのかなぁ？と思っていたのですが、 石綿のWikipediaを 眺めてみると、吹き付アスベストの使用が禁止されたのは1975年の事で、 今にして思うと「なんか回収するの遅くね？」とは思ったりも。まぁ、 そういう時代だったと言われればそれまでかも知れませんが(^^; 因みに、理科実験に使われてたいわゆる「石綿網」は、1990年くらいまでで 製造されなくなって、現在では「セラミック金網」というものに なっているようです。

AM中に起床。

何気にPixivを眺めていたら、割とPNGでアップロードしている 人が居るなぁ？と思ったりも。

早めに帰着。

Emacsでは「M-なんとか」は「メタキー」 (参考Wikipedia) を押しながら「なんとかキー」を 押すという事なのですが、Windowsでは「メタキー」の代わりに「ALTキー」を代用できます。 ただ、普通のVT100ターミナルではALTキーを受け付けなかったり、 1990年前後のマシンのキーボードにはメタキーや代用になるキーが無かったり する場合に対応できるよう、「ESCキーを押した後、なんとかキーを押す」 で同じ操作を行えるようになっています。という歴史的な背景もあって、 TANE自身は ESCを押す 2ストローク方式にすっかり慣れてしまっています。 ところが、Webとかを見ていると「M- == ALTキーを押しながら」 で使用している人が割と居るように感じました。
何故こんな事を書いたかと言うと、Cygwin のmintty ではALTキーが認識されるというのを今頃知ったから(^^; ついでにTeraTermでも 設定→キーボード の中にMetaキーを onにする設定があって、onにするとVT100エミュレーションでも ALTキー押しでメタキー入力できるというのも知りました(^^;;; VT100ターミナルでは自動的にALTキーは封印されるものと 思っていたのですが、そんな事は無くなっていたようです。

早めに帰着。

あまりの眠さに急速停止。

早めに帰着。

調べ事をして終了。

早めに帰着。

ちょろり調べ事をして終了。

昼過ぎ起床。寝すぎ。

掃除したり洗濯したり。

そういやC言語の 整数型について。「short int」、「int」、「long int」、「long long int」 のbit幅ですが、「short int」は16bit、「long long int」は64bit、 「int」はレジスタ幅16bitのCPUでは16bitの場合もありましたが、現在は 概ね 32bitと解釈して良いかも知れません。で、「long int」なのですが、 これがWindowsの64bit環境と UNIX系の64bit環境とで異なるみたいです。 整数型のWikipedia の"データモデル"という項に、IL32P64(LLP64)、I32LP64(LP64)というモデルが ある事が記されています。IL32P64は「intおよびlong intが32bit、ポインタが64bit」、 I32LP64は「int が32bit、long int およびポインタが64bit」と解釈するそうで、 Windows 64bitではIL32P64、UNIX系 64bitではI32LP64となっているそうな。 確かにsizeof(long int)を調べてみるとCygwinでは4、Fedora(64bit)では8となりました。 ただ、あまり問題になった事が無い気がするのは、Windowsでは intと long int は同じな為、intしか使わないというのが理由かも知れません。 逆にUNIX系だと intは32bit、long intは64bitなので、むしろ綴りが長い long long intの方を使わない可能性が考えられます。その場合、Windowsに持って くると動かないかも知れません。いずれにしても、「long int」を使わなければ WindowsでもUNIX系でも問題になる事は無さそうですが、C言語の文法に 触れたWebサイトでは環境によって違いがある事には触れずに long intは64bit (もしくは32bit)と記されている場合があるようなので注意が必要かも知れません。

それにしても、何故こんな事になっているんだろう？と思ったり。 intが16bit幅のCPUからの流れを考えると、Microsoft系列システムと、UNIX系 では次のようになっているかと思います。

型	MS-16bitSYS	MS-32&64bitSYS	UNIX-32bitSYS	UNIX-64bitSYS
short int	16bit	16bit	16bit	16bit
int	16bit	32bit	32bit	32bit
long int	32bit	32bit	32bit	64bit
long long int	-	64bit	64bit	64bit

MSの方は、16bit時代のシステム(MS-DOSとか)では、intがshort intに対して違いが無い のがなんのこっちゃ？という感じだったのが、32bitではintとlong intに対して違いが 無くてなんのこっちゃ？という感じになってると思います。ただ、intの曖昧な定義 から言うと、ここんところは別に変ではなくて、64bitでも踏襲した感じに思われます。 一方、UNIX系の方は32bitネイティブスタートなので、元々MSの32bit/64bitと同じだったのが、 64bitの方で何を思ったかlong intのbit幅を変えるという謎の対応が行われた様に思えます。 ソースコードの互換を考慮するならばMS系のように32bitをベースにfixしてしまうのが妥当に思えます。 むしろint以外は型とbit幅が1:1に対応していたのに....という感じです。 UNIXの64bitは、ただただ long int型のソース互換を損なっただけで、誰も得をしないように 思えます。

AM中に起床。

先日のEmacsでのSegfaultの件。xmalloc()の問題かと思ったのですが、 よくコードを見るとxmalloc()は無実だったり。該当箇所は以下のような感じ。

src/process.c
    :
   7762 void
   7763 setup_process_coding_systems (Lisp_Object process)
   7764 {
   7765 #ifdef subprocesses
   7766   struct Lisp_Process *p = XPROCESS (process);
   7767   int inch = p->infd;
   7768   int outch = p->outfd;
   7769   Lisp_Object coding_system;
   7770
   7771   if (inch < 0 || outch < 0)
   7772     return;
   7773
   7774   if (!proc_decode_coding_system[inch])
   7775     proc_decode_coding_system[inch] = xmalloc (sizeof (struct coding_system));
   7776   coding_system = p->decode_coding_system;
   7777   if (EQ (p->filter, Qinternal_default_process_filter)
   7778       && BUFFERP (p->buffer))
   7779     {
   7780       if (NILP (BVAR (XBUFFER (p->buffer), enable_multibyte_characters)))
   7781         coding_system = raw_text_coding_system (coding_system);
   7782     }
   7783   setup_coding_system (coding_system, proc_decode_coding_system[inch]);
     :

20004858 [main] emacs 18528 tty_list::allocate: No pty allocated

AM中に起床。

昼前にうっすら雪が降ってたり。毎度 暖冬とか言われていても、関東地方では 必ず1回以上、雪が降るんだよなぁ。その後、やんだり。植木に積もってたのも すっかり溶けてたり。

全然関係無い流れで、アニメのカードキャプターさくらは35mmフィルムが 映像マスターというのを知ったり。へぇ。

GTS。あと数時間でプレイ時間が100時間となる所で、数カ月プレイしてなかったり してたのですが、今日ちょろっとやったら100時間に到達。 まだ走行時間とか獲得賞金のアチーブメントはLV3には到達していないので、 ボチボチ進めるという感じです。そういやGTSが発売されて1年と数カ月と いった所なのですが、アップデートでコースやイベント追加は定期的に 行われています。逆に、PS4ではナンバリングされたGTは出ていないという 事になる訳ですが、次世代機の出る時期から考えるとPS4ではナンバリングタイトル は出ないかも？と思ったりも。

昔の地図を観る事のできる 「ウェブ地図」と いうサイトを知ったり。古い地図は東京周辺のみだったりする場合がある ようですが面白いです。今住んでいる所の 1990年頃の航空写真を見て、 そういやこんなになってたなぁとか、この建物この頃からあったっけ？とか 思い出してみたり。まだレインボーブリッジもお台場も無い頃で、こんな だったんだと改めて知ったりも。

Emacsでは例えば「C-x C-r」でReadOnlyでファイルを読み込む際に、 「*.c」といったように正規表現を使って複数のファイルを読み込む事ができます。 で、何気に160個ほどのD言語の複数ファイルを読み込もうとしたところ、 SegfaultでEmacsが死んだり。再現性があったのでズッコケ原因を少し 調べてみた所、メモリ割り当て関数であるところのxmalloc()が0xffffffff を返してました。NULLではないのでメモリ確保に成功してる風なのですが、 まぁ普通に考えればこんなポインタがメモリ割り当てに成功している訳は 無く、参照してSegfaultになるという流れでした。xmalloc()が0xffffffff を返す原因を追跡してみたのですが原因が判らず。何やら xmalloc()が値を返す前に再びxmalloc()が実行されている節が見られてて、 マルチスレッドに起因する不具合っぽい予感。

早めに帰着。

あまりの眠さに急速停止。

早めに帰着。

訳あって pythonをスクリプトとして使う目的で調べ事。 C言語由来のプログラム言語ではいわゆるブロックステートメントを 中括弧でくくりますが、pythonではインデントの深さが同じ行が ブロックステートメント内にあると解釈されます。 事前に知ってはいたのですが、これは肌に合わないかも(^^;
2.x系と3.x系の非互換もあってか、文法に関してWebサイトを検索 するとどちらも同じ感じで出てくるので、ダメな方を見てしまうと 何故ダメか判らなくてハマりそうです。あと、文字列に対する formatメソッド。何これ？面倒くさい。「% 記法」も一応使える ようなので、用途に合わせて使い分けるのが良いみたい。

早めに帰着。

キャッシュレス決済。消費税を10% にするのにキャッシュレス決済で 5% 還元という謎な 仕組みが導入されるようですが個人的には現金じゃダメなのかね？ と思う所もあります。なんだかよく分からない理由で推進している 所もあるように思えます。

少し整理してみたいと思います。銀行に預金があったとして、そこにある お金から商品を手に入れるまでを考えてみると、預金→現金→商品 という経路でも、預金→現金→プリペイドカード→商品 という経路でも、お金と商品の価値を等価交換していると考えられます。 損失の無い完璧な等価交換なのであれば、電子マネーを経由したキャッシュレス決済 でも良いんじゃないか？と一瞬思うのですが、実際には完璧な等価交換では 無いと考えられます。例えば、カードの年間手数料を取られたり、 実際に購入したギフトカード額をぴったり使う事が困難だったり、 チャージした瞬間から使用可能店舗に縛りが生まれたり、店側が決済代行会社 に手数料を取られていたりと、何かしら取引損失が生じているように 思われます。 取引損失を埋め合わせてる風に見せる為に、現金還元ではなくポイント が付く場合がありますが、ポイントには現金と同じ自由度は無い (使用可能な店舗やケース(場面)が決まってたり、理論上使い切る事が 不可能だったり)場合が多いと思われます。

結局、自分と店との間で 取引損失ゼロ のキャッシュレス決済というのは 存在してなくて、間に入って便利とか安全とか理由を付けて少額を横取り されてたり、取引先縛りがかけられるというのがキャッシュレス決済の現状 というのが個人的な意見です。

キャッシュレス決済の話に必ずセットで付いてくるのが「よその国では 〇〇%(==日本より高い割合) がキャッシュレス決済になっている」という話。 その国の人口が少ないから上手く移行できたとか、偽札が流通してて現金に 信用が無いからとか、治安が良くないのでキャッシュレスの方が安全だからとか、 何かしらのバックグラウンドがあっても、あまりそういう事には触れず、 ただ「現金決済が古臭く感じるのがダメ」という主観的な理由によってる ように感じます。日本では現金で持ってて危険な目に合う場面なんて そうそう無いし、信用のある通貨だし、現金決済ならば取引損失ゼロ なのに、何故、電気が無いと取引きできなくなったり、取引損失が生じたり、 取引条件に縛りが生じたりする キャッシュレス決済の方が良いと言えるのだろう？ と思ったりもします。

早めに帰着。

あまりの眠さに急速停止。

早めに帰着。

「金剛寺さんは面倒くさい(3)」。未来の話の件の中で 樺山君の片方の角が切れていたのが何の伏線か気になる。

「アオイホノオ(20)」。まだまだ続きます。って、もう10年くらい 続いているのに今気づきました。細野不二彦氏が使っている原稿用紙が アートカラーの原稿用紙だと判るのは35年後って、逆算するとつい最近の話？！ と思ったり。いや、この物語はフィクションですが(^^;

昼前起床。

掃除したり洗濯したり。

ちょろり本屋に。やっと「アオイホノオ(20)」を捕獲できたり。

昼過ぎ起床。寝すぎ。

「美の巨人たち」で紹介されていた 吉村芳生という人。 理論上可能と思っても実際にはやらないであろう方法で描くと いうのがすげぇ。

恵方巻。良いんですけどちょっと高いなぁ...と感じます。

全然関係無い流れで知った 「Windows 10の新しい壁紙はこうやって作られた」 という記事。今頃ですが「あの画像って写真だったの！？」って所に驚いた。

早めに帰着。

先日の野良パッチをあてて使っている kesen-mule.el の バグを直して しれっと Emacsの雑記 に置きました。ファイルを差し替えたので雑記本文は更新してませんが、 御参考まで。

放送されてた「ローグ・ワン」を観たり。Blu-rayで何気に何度も観たくらい気に入ってる 作品ですが、久しぶりだけどやっぱり観てしまいます。 因みに、割と重要なスイッチが屋外にあったり、記録メディアがまぁまぁデカかったり、 巨大アンテナの下にデータ読み取りのドライブが設置されてたりと、割とアナログ感 漂うギミックが散りばめられていますが、これは エピソードIVのテクノロジー感と あまり違い過ぎないようにしている意図があるようです。